[WG: Sakai QA] Sakai 2.6.2 update (artifact testing)

[Matthew Jones]

This brings up a good point,

Ideally, it seems like what we 'should' be doing is have separate api jars
for the kernel (and other often included projects that indies would use)
that change VERY rarely, as what was the original expectation. We don't have
this now because the api jars change versions with the implementation so
there will be a disconnect between projects, especially for ones that are
slower moving, unless we are going to recompile things all the time (not the
best idea). I'm not sure how well this would work but it is described here
[1]

This was similar to what java.net did for many of their packages.
http://download.java.net/maven/2/javax/javaee-api/

<http://download.java.net/maven/2/javax/javaee-api/>We'd ideally have
something like kernel-1.0-api.jar, kernel-1.1-api.jar, with no minor
revisions. The minors 1.0.11 (etc) releases would just contain
implementation fixes.

Perhaps this is something that can be considered for 2.7 (or at least 2.8),
to make it easier to both locally patch the kernel and make indie projects
depend on kernel api's that are constant.

Obviously the project won't run alone, but it will compile and deploy to the
repo. And when placed into a sakai instance that has the implementation of
any version that matches these apis it will be ready to go. I don't know how
that would work for tests, but probably if it it did need to test against
kernel implementation (in the maven test phase) it could depend on a
specific version (or a in a best case mock classes), but that wouldn't be
included in the bundles, as it just pulls it down for tests.

Thoughts? This would be some work, but it seems like the right way to do it,
or something very similar to this. Or maybe this is completely wrong. ;)
This might even allow us to move the kernel a little faster and make api
changes without waiting until 2.7 (or the 'maybe' 2.8). I'm still thinking
this one out though.

[1] http://weblogs.java.net/blog/ludo/archive/2007/01/java_ee_5_apis.html

<http://weblogs.java.net/blog/ludo/archive/2007/01/java_ee_5_apis.html>
-Matthew

On Fri, Jan 29, 2010 at 5:10 PM, Seth Theriault <slt at columbia.edu> wrote:

> Anthony Whyte wrote:
>
> > For 2.6.2 entitybroker pack and polls webapp bundle up
> > kernel-utils-1.0.12; all other projects rely on
> > kernel-1.0.13 jars.  I should also note that there were no
> > kernel-util changes between 1.0.12 and 1.0.13.  The downside
> > is that it adds to the download time of a first time
> > deployer given the extra set of kernel jars.
>
> Uh, why can't the indies being bundled with a specific Sakai
> release be REQUIRED to use the same kernel version as the
> release itself? Otherwise, it's a deployer nightmare --
> especially if I have to apply kernel patches -- and totally
> renders moot any goal of simplification.
>
> Seth
>
> _______________________________________________
> sakai-qa mailing list
> sakai-qa at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
>
> TO UNSUBSCRIBE: send email to sakai-qa-unsubscribe at collab.sakaiproject.orgwith a subject of "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20100129/ab42adb9/attachment.html