Kernel 1.0 RC-1

Added by Peter A. Knoop, last edited by James Renfro on Jul 11, 2008  (view change) show comment

From the sakai-dev email list:

-----Original Message-----
From: Ian Boston [mailto:ianboston@gxxxxxxxxl.com] On Behalf Of Ian Boston
Sent: Sunday, February 10, 2008 7:48 PM
To: sakai-dev Developers
Subject: Kernel 1.0 RC-1

For those watching the Source code commits, you may have noticed a  
number of commits going past with the word Kernel In them.

I have been attempting to extract a kernel from the current trunk, to  
do a 1.0 release candidate.
The aim of the 1.0 RC will be to provide a snapshot that provides the  
same code base as in the 2.5 core release of Sakai, repackaged into a  
different maven structure, that makes it work as a single unit. The  
result of this can be found at

https://source.sakaiproject.org/svn/kernel/tags/K-1.0-RC1

and both SNAPSHOT versions and the K-1.0-RC1 version are in the sakai  
maven repo at

https://source.sakaiproject.org/maven2/org/sakaiproject/kernel

binary, source and javadoc
(or at least they should be there when the upload completes, in about  
1h)


This contains no Java or Jar changes, only a re-organization of the  
maven groupID's build to make it possible to work on an identified  
kernel.

There is also maven site build (SNAPSHOT) from the kernel at

http://www2.caret.cam.ac.uk/sakaikernel/index.html

This is only one small step, in many :)

It would be helpful if those who care about the kernel, have a look  
and say what should be done before the RC1 becomes final, but  
remember, this is only a snapshot in time that will serve as a  
starting point for more work.

The reorganization has maintained all svn history, and so it should  
be possible to merge changes in the existing trunk modules into the  
kernel space..... if svn can cope with the re-factoring of layout.

Ian



----------------------
This automatic notification message was sent by Sakai Collab
(https://collab.sakaiproject.org/portal) from the DG: Development 
(a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (4)

 

  1. Jul 09

    Ray Davis says:

    (At the Paris project meetings, Ian asked for reviews of the current Kernel cand...

    (At the Paris project meetings, Ian asked for reviews of the current Kernel candidate branch. I don't think there's currently a JIRA task open, so I'll put comments here unless someone has a better idea.)

    The combination of Content Hosting + JCR is big enough, active enough, and possibly even swappable enough that it might be better to package it separately than to try to lock it into the same lifecycle as the slimmer and more stable Kernel services.

    In the kernel trunk, the sakai-kernel-pack WAR contains 64 files and 7.3 MB. By my count, 22 of those files and 6.3 MB are brought in by "content" (including jackrabbit, lucene-core, commons-codec, geronimo-jta, nekohtml, pdfbox, poi, slf4j, and tm-extractors dependencies).

    The Content modules are also under more active development than other portions of Kernel RC 1. Here are the numbers of commits made to trunk in 2008 for each of the top-level project directories. (The numbers include application code, but they still give a rough idea of relative activity.)

    90 - content + jackrabbit + jcr
    34 - event
    23 - site (mostly internationalization)
    17 - user
    16 - authz
    16 - util
    13 - db
    11 - component (mostly sakai.properties edits)
    9 - memory
    7 - alias
    7 - email
    6 - tool
    2 - cluster
    2 - entity

    It may be symptomatic of Content's relative volatility and complexity that kernel-trunk's "tools" subproject currently only contains the "upgradeschema" scripts for 2.5.x Content migration, which look a little out of place in this crowd.

    I agree with Ian and Aaron that Content needs to be able to scale and perform, that the code needs a drastic clean-up and refactoring, that Sakai is pretty useless without it, and so on. But these describe project goals rather than project packaging. For example, writing scalability regression tests for Content is the same task whether Content is packaged and deployed as part of the merged Kernel JAR or not: the only difference would be the POM dependencies. In this particular case, it may be that simplifying the dependencies will increase the costs.

    (This is all based on an initial cursory look around the branch – I apologize if I've missed some tight cross-dependency that makes such a split impractical.)

  2. Jul 15

    David Haines says:

    The argument about Content being volatile seems on target to me. Is it possible ...

    The argument about Content being volatile seems on target to me. Is it possible to provide a trivial implementation by default, and allow plugging in different versions for deployment? A trivial implementation would likely be useful for testing also.

  3. Jul 15

    David Haines says:

    The kernel should support "version discovery" of services....

    The kernel should support "version discovery" of services. It will make it much more reliable to switch tools to different release cycles if it possible for Sakai tools / services to verify that they have the required versions of other Sakai tools / services when they are installed.

  4. Jul 15

    Ray Davis says:

    Ian has added a JIRA task for the review: SAK13954

    Ian has added a JIRA task for the review: SAK-13954.