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

[Gast, Cynthia (cmw6s)]

Hi David, jumping in, if a bit late (away for the holiday), to this discussion...  Here are some of my thoughts on the indie topic.

UVa also builds all the source, like our VT friends.   The benefit of having and building source, of course, is that we can quickly fix bugs and make changes that benefit our UVa user community, in a timely fashion.  We do make local changes in the kernel, so we must build that, and we want to ensure that all tools are built with our kernel, which is why we build all source.  We make patches for every local change we make (tied to our JIRA issues), and we actively contribute back to the community. 

So for folks like us, with a significant number of local bug fixes and customizations, the "indie" tools are an interesting issue.  I suspect the indie approach benefits those who download the pre-built tools more than those of us who are source-builders, but I see pros and cons.  The multiple versions of multiple indie tools does cause some amount of additional time, analysis and development work when updates come out after we've started a major upgrade process.   So, we repeat indie upgrades periodically as new versions show up... up until some point where we just stop upgrading, so our testing team can have time to verify everything.  Sometimes these indie upgrades involve getting all of the indie tool's source, to which we apply our patches; sometimes we apply a patch of the Sakai changes to our existing tool source. 

On the positive side of the indie tool approach, I have grown to appreciate the periodic indie tags/releases as a signal there is an approved new tool release available.

I also hope that the removal of purepoms will result in an easier upgrade process.  

>From our build-all-source perspective, it would be a time saver if I could 'svn export' a 2.9.0 'all source' tag that included all the source for Sakai 2.9.0, for all core and indie projects.  Otherwise, I do spend time determining, for every indie tool, the current latest indie version (tag) available and 'svn exporting' each one individually (to import into our SVN repo).  I've recently seen references to the 'sakai-2.9.x-all' you mention; I'll look into it.

I also find it a time-saver when detailed indie information (lists of indie tools and their version numbers) is accurately documented in the release notes (or links to the correct current docs).  I see the release documentation continually improving, and I always get my questions about indie topics answered on sakai-dev, for which I'm grateful to the community :-)


Cheers,
Cynthia Gast
University of Virginia, Sakai development team
cmw6s at virginia.edu



________________________________________
From: sakai-dev-bounces at collab.sakaiproject.org [sakai-dev-bounces at collab.sakaiproject.org] on behalf of David Adams [da1 at vt.edu]
Sent: Friday, November 16, 2012 11:14 AM
To: Matthew Jones
Cc: sakai-dev at collab.sakaiproject.org
Subject: Re: [Building Sakai] sakai-2.9.x-all build broken

Matthew Jones wrote:
> Also for 2.9, Aaron did quite a bit of work to turn *most* of kernel-util
> into a service, so that if you modified kernel you don't have to re-build
> everything. There are still classes in kernel-util but they aren't
> implementations anymore so they should be changed MUCH less often (like
> never in a major release)

This is good to hear. I see there are also "kernel-storage-util" jars in some war files and components. Are those similarly just interfaces?

All that said, we do locally modify even the interfaces for certain needs. And so a build that includes all the source code is a requirement for us. When the kernel was broken out of Sakai several releases ago, that was annoying, but not super painful to reintegrate. However, as more and more subprojects are indie-fied it has become a major effort to recreate a full source code build locally with each release. Perhaps getting rid of purepoms will make that process a little easier for us this time around.

In any case, feedback on this list seems to indicate that at least a few schools do have a need for full source availability. I wonder how many schools are actually productively using a source distribution in which literally half of the subprojects have been stripped out (sakai-2.9.x-all has 68 externals, sakai-2.9.x has 34).

I hope that some other schools will jump in with their opinions on this. If I'm the only one bugged by this trend in the "source" distribution, then I'll accept my role as a jabbering crank and go back to work. :)

-dave
--
David Adams
Director, Learning Systems Integration and Support
Virginia Tech Learning Technologies
_______________________________________________
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"