[sakai2-tcc] OSP as an indie

[Jean-Francois Leveque]

As far as the custom build is concerned, I intended to contribute my 
dummy-learned information but I've been quite busy with other things so far.

Theres already some documentation at 
http://confluence.sakaiproject.org/display/SAKDEV/Customizing+%27indie%27+releases.

I think we can make it better.

J-F

Matthew Jones a écrit :
> 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 <mailto: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