[sakai2-tcc] OSP as an indie

[Matthew Jones]

Like Noah said, there is a lot of things to be worked out with this. There's
the xsltportal that needs to go somewhere that has dependencies on portal
and osp also has dependencies on the sakai-assignment-api which seemed to be
the bigger part. That would have to go indie, and end up pulling basically
the rest of Sakai along with it. So it ended up being far from low hanging
fruit.

I believe the whole indie project really has made it *incredibly* difficult
for anyone who locally needs to modify kernel or other indie projects and do
a full build, compared to 2.5 or even 2.6 when kernel went off on it's own.
It essentially means you have to set up your own build server, do your own
release management, reversion your own artifacts, even if it's just a small
change to kernel-api. None of these best practices are really documented
anywhere, and it's really made getting to the point of releasing 2.7 (where
we have some 50 patches across almost the entire tool base) very difficult,
time consuming and expensive for Michigan.

What seems like it could make this easier? Independent revisions and
releases on the api's from the rest of the tools (especially the kernel)
probably would have helped a lot, but I didn't want to do this locally. This
would have allowed us to depend on stable api artifacts for the release
while just dropping in new implementations. Now unless we change everything
there might be a mismatch at runtime if an api from Sakai is pulled into our
build with local changes.

Also less dependencies across tools would be the obvious one, or some type
of internal (reflection style) entity broker for common services. Something
fast that tools can use without having tons of hard coded dependencies for
simple common actions. Maybe this is a far off wish, or maybe it's something
that already exists. If you can't say build a tool that needs functionality
from assignment (adding assignments) or gradebook (adding grades) without it
having <dependency> then we're really stuck to a hard to modify system.

Anyway, we're discovering a lot of specific problems with current artifacts
and practices (some tools that seem like they're 'half-indie'), and many of
these things have easy fixes, but perhaps those belong in the umich 2.7
postmoterm once we get it released next month. ;)

-Matthew

On Wed, Nov 24, 2010 at 7:17 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> Hi Noah,
>
> Runnings a grep over trunk, It looks like warehouse is only used by OSP
> itself, whereas metaobj is a bit more widely used. This would mean these
> need to be indie releases as well.
>
> Of course there may be contrib or local projects that are affected, whose
> poms will need to be updated as required if they want to move forward.
>
> I don't think anything outside OSP depends on OSP itself does it? In that
> case it should be relatively straightforward to bundle up into a discrete
> package.
>
> cheers,
> Steve
>
>
>
> On 25/11/2010, at 10:59 AM, Noah Botimer wrote:
>
> > While it generally seems like a fair idea with its merits (and some
> costs), we just didn't get to it for 2.8.
> >
> > If I remember correctly, the remaining plan was to have a look at the
> dependencies (including metaobj and warehouse) to see if anything else would
> need to be broken out, work with the OSP committers to understand the POM
> changes, and get things set up in Hudson so we could churn out releases in a
> click.
> >
> > To me, this is a case study. If it's ugly because of dependencies, and we
> talk about shuttling more stuff into the meta-modules (common,
> edu-services), we've got something grossly wrong. I've had a suspicion for a
> while that we've been half-stepping and should just get to where we're going
> if it's the right idea. Piecemeal frobbing won't help anyone. But I think
> that's a whole discussion by itself.
> >
> > Thanks,
> > -Noah
> >
> > On Nov 24, 2010, at 5:55 PM, Steve Swinsburg wrote:
> >
> >> Hi all,
> >>
> >> A while back we discussed making OSP an indie release. Did this get any
> traction?
> >>
> >> thanks,
> >> Steve
> >>
> >> _______________________________________________
> >> sakai2-tcc mailing list
> >> sakai2-tcc at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> >>
> >>
> >
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20101124/b25f07b7/attachment-0001.html