[Building Sakai] How to checkout the 2.9.0 tag source including all tagged indie source?

[Matthew Jones]

Hi Dave,

Indies were created by a different group of people at a different time
(Started around 2.6) many of which are no longer heavily (at least not
day-to-day) involved in Sakai CLE. Those involved in the process now mostly
inherited it and are trying to figure out what we've got. Back then there
were more active project teams more new tools trying to incubate their way
into the core from contrib.

One of the big issues that this process was looking to solve was to allow
an institution to add in a contrib project without having to compile the
entire source locally and then compile the project. This often can be very
time consuming to run an svn update, a mvn install on the entire source
just to build one that might just have a single api dependency because it
wants to be able to post to the gradebook or create an announcement. Having
these api's released allows contrib tools to use the released versions of
the artifacts (which should be unchanged for the entire major release) and
be built and deployed much easier. This could potentially have also lead to
"zip bundles" that would have been provided for each version, built by some
server out there (which is what the assemblies are) so someone doesn't have
to compile it at all, just uncompress it.

Another things this was looking to solve was to provide updates for single
tools if a institution found it too risky to do a full upgrade but had a
specific issue with a single tool that was under heavy development (Samigo
or Lessons for instance). They could just pick up the new version of that
tool as a "quick fix". Some places prefer to do this, upgrade a single tool
at a time when a high profile fix comes out or a specific thing is fixed,
rather than upgrade everything.

A nice side effect is that the individual indie are built and bugs are
detected faster by Hudson.

The problem with both of these is there is no undeploy goal or method of
undeployment, so if someone has version 2.9.2, it needs to clean up 2.9.1
components and api's first. We don't deploy simple wars, and there is no
OSGi for version tracking so there were a few problems that never solved
there. So places have to write this undeploy goal or always deploy the
entire thing fresh (essentially forgetting the indies).

I don't know, a lot of these artifacts don't need to be in the repository
(anything that isn't actually a dependency somewhere) and most of the full
projects with assemblies need to just be moved back into the core to make
it all easier. This entire process is a lot of work and nobody is left to
work on it part or full time. Volunteers who want to improve any of this
are desired!

On Sat, Dec 1, 2012 at 8:35 AM, David Adams <da1 at vt.edu> wrote:

> I will admit that despite all the explanation, I don't understand the
> point of the indie structure at all. I understand the usefulness of having
> more revisions of the underlying tools than we do of "Sakai", but the 2.9.0
> release consists of a suite of tools at particular specified versions. The
> 2.9.1 release will consist of a suite of tools at particular, probably
> different specified versions.
>
> Put simply, a source code download of an open source software product
> should include all the source code.
>
> If this process of having separate -all and -half branches cannot be
> automated easily, or managed via Maven profiles, then I agree with Chuck
> that we should make -all the default. Folks who rev tools often to keep up
> with new releases can manage the complexity of that, while the folks who
> just want to start from the official, tested, released suite will not have
> to jump through hoops to actually have all of the code available.
>
> I can see a very big potential value in finding a way to use Maven to
> manage a mostly-binary, partial-source build, but the current complexity is
> far too great for the majority of the users of the source, it seems to me,
> from my own experience and from reading these messages. Perhaps if the
> build process were documented in a way that deployers could comprehend,
> that would be an alternative to rethinking the entire process. But I think
> it's clear that the current trend of indifying projects because indies
> depend on them has gone well beyond the theoretical justification.
>
> -dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20121203/53e609dc/attachment.html