[Building Sakai] problem with blackboard import

[Hedrick Charles]

I've given a better explanation in a jira I submitted right after that. My email was intended for a couple my own developers, and was excessively flamboyant. It was also in part the result of a very frustrated two days trying to figure out what was going on with blackboard import. Proffile2 is not an obvious place to look for such a problem. 

Yes, I realize that there used to be a purpose to deploy. However I think in the current state of Sakai it's really only a danger. Obviously it did at one point have a useful purpose.

We deployed 2.9.0-b05, I think because we had problems with b02 that b05 fixed. Our overall system is b02. Looking at the unmofieid sources, the parent is listed with a specific version of b05. There's no doubt that we should have fixed that, but it's easy for an inattentive or new developer to miss it. In today's environment I think the best solution is to comment out the call to deploy in the main pom.xml. Since with current Sakai the only thing it's likely to do is cause problems.

I would love to be able to say "use the current system's master" and not give a version. That would help us all. Maven works fine to build a standard copy of Sakai, but it's hard to build tools that will be easy to use in a customized way.


On Aug 7, 2012, at 7:47:47 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:

> Chuck,
> 
> The 'sole purpose' of that deploy pom in Profile2 is not to make your life difficult by deploying 'incorrect versions' of the libraries. As Matt noted, its a helper pom to deploy additional tomcat overlays to ensure your environment has what it needs in a small build, the versions of which come from master. Unless you go and deploy things manually with different versions that don't match what master thinks it is deploying, then everything matches. If you are deploying different versions, then I'd recommend adjusting your deploy practice and bumping the version in master so that other tools don't bind to the incorrect APIs.
> 
> It also doesn't delete anything itself directly, it deploys a Tomcat assembly which in turn deletes the old components directory. But as I said above, if your versions matched, you wouldn't have this issue.
> 
> I don't know where you are getting your version information from, but it is incorrect. From my analysis of each of the 1.5 beta tags, they each have the correct b0x version in them and are bound to the correct b06 parent.
> 
> Profile2 is an independent release. As such it does not specify Sakai versions, that is inherited from the parent. The deploy pom is also not included in the binary overlay, so unless you are making local changes to profile2, then you don't need the source.
> 
> That said, the deploy pom is from the legacy days when common was moving faster so needed to be kept in line. I would accept a Jira that called for its removal since it is no longer necessary, though could be converted to a cafe profile instead.
> 
> thanks,
> Steve
> 
> 
> 
> On 08/08/2012, at 12:28 AM, Charles Hedrick <hedrick at rutgers.edu> wrote:
> 
>> Blackboard import is broken in 2.9. I'll be deploying a fix shortly. But I wanted to explain the issue.
>> 
>> This was a mess to find. The user error was that the ZIP file isn't recognized. The archive input code calls a list of importers, asking each whether it recognizes the file. I added code to the bb6 importer to display some information. It was never called.
>> 
>> That means that something is broken in the XML structure that configures the list of importers. The components.xml was just fine. However at some point I thought to look at the version of the file actually in production. The file in production doesn't match the file in the source tree.
>> 
>> This took a long time to find, but in the end it turned out to be a problem in profile2. Finding it required searching pom files for all kinds of things. Profile2 has a subproject deploy. It's sole purpose in life is to deploy incorrect versions of two parts of common. Thus it was overwriting the version of common we built, which included the components.xml with bb6 import added, with the generic one from a different beta. (The problem would have been prevented had profile2's main pom file had the correct primary sakai version number. It was set to b05, while we're using b02. Hence it pulled in generic files rather than pulling ones we built from the local .m2 directory. But deleting core components and deploying its own version is REALLY bad form.)
>> 
>> The fix I'm trying, which I think will work, is to comment out the deploy subproject in the main pom file for profile2. The actually bb import code seems fine.
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>