[Building Sakai] sakai-2.9.x-all build broken

[Steve Swinsburg]

Hi David,

A couple of responses:

> As for updating the version of indies in the master pom and redeploying, isn't that going to introduce other version conflicts? Seems to me that to upgrade a particular subproject, updating the source URL in the svn:externals property, updating, and rebuilding is far safer.

So long as you are updating within the same minor version, there shouldnt be conflicts. Your best bet is to check the release notes for the particular tool you are updating. Note that you would have the exact same conflicts by building the same release of the tool from source.

> In general I personally don't understand why all of these core projects are being moved to "indie" releases. Is it to shorten compile times? When I download the source code for an open source project, I don't expect that over half of it will be delivered at deploy time as prebuilt zipfile overlays from remote servers over which I have no control. If we wanted the binary distribution, we would download the binary distribution.


Fair comment about the binary, but Sakai really is a collection of tools that are glued together. Historically it has been a long time between releases, so the purpose of indies was to allow them to be released on a much faster cycle - so bugs get fix, release goes out, people upgrade that tool without having to upgrade everything. 

For example, with Profile2 there have been 11 releases of the 1.4 series, (which roughly correspond to Sakai 2.8), but only 3 release of Sakai 2.8, so people can get fixes quicker if they don't have to wait.  
For 2.7 there were 19 release of profile2, but again only 3 releases of Sakai 2.7.

> 
> Finally, if there's no benefit to providing all of the source code, then why is there a sakai-2.9.x-all branch available? If sakai-2.9.x-all has a purpose, then -all tags surely do as well.


Yep, I agree, we should probably make a -all tag, its just externals. I find the -all branches good for branch merges since you have branches of all of the tools as well.

The -all branches also came about as a result of switching the main Maven repository from the Sakai maven repo to Sonatype/Central, which happened mid 2.9, and broke things for a while as artifacts were not available.

cheers,
Steve


On 16/11/2012, at 7:12 AM, David Adams <da1 at vt.edu> wrote:

> Steve Swinsburg wrote:
>> This is an interesting discussion as it directly relates to the
>> usefulness of the indies projects. A question, why do you want
>> to build the source of all indies? Unless you've modified them,
>> you can just let Sakai deploy the binaries and then updates are
>> as easy as changing the version in the master pom.
> 
> We do modify several of the indies, however, more importantly, we modify the kernel, which I believe requires us to build everything that includes the kernel-util jar (ie, everything). But I don't claim to understand the build and deploy process very well. Delivery of elements of Sakai as overlay zipfiles can also cause other problems for people who need to do any customization to Tomcat's directory structure.
> 
> 
> -dave
> -- 
> David Adams
> Director, Learning Systems Integration and Support
> Virginia Tech Learning Technologies