[Building Sakai] Trunk: ui package proposal

Fri Nov 6 12:12:58 PST 2009

PROPOSAL

Create a 2.x "ui" package composed initially of the Sakai jsf  
project.  In time add other ui projects to the package such as the  
Sakai velocity project.

PROBLEM

Earlier in the week I announced that Samigo is now prepped to be  
released independently of Sakai.  One impact of this change is the  
need to also release the slumbering jsf project independently since  
Samigo, a hybrid JSF/RSF application, is dependent on Sakai's jsf  
project.  Builds will fail as occurred on Nightly2 early yesterday  
morning whenever Samigo is deployed during a Sakai build and fails to  
locate its jsf dependencies, either locally or remotely.

IMMEDIATE SOLUTION

To restore the trunk build I branched jsf trunk, revised/cleaned up  
the poms, wrote a jsf assembly and deployed jsf with revised maven  
coordinates to our snapshot repository.  I then tweeked Samigo's /jsf  
project dependencies, refreshed Samigo's snapshot deployment and  
updated the Sakai master and core-deploy poms to include the new jsf- 
assembly in the build.

Branch: https://source.sakaiproject.org/svn/jsf/branches/SAK-17340/   
(a /target folder and two eclipse metadata files need to be whacked)
Repo artifacts: http://source.sakaiproject.org/maven2-snapshots/org/sakaiproject/jsf/

I have not merged these changes into trunk nor have I yet updated the  
jsf project dependencies in other Sakai JSF tools since I wanted to  
make sure the changes worked with Samigo first.

2.7 SOLUTION: A "UI" PACKAGE

At a minimum I plan to release the jsf project independently of Sakai  
so that releases such as Samigo can locate their jsf project  
dependencies without failure.  Updating other trunk sakai-jsf project  
dependencies is a trivial operation as is releasing jsf 2.7.0  
independently of Sakai.

I recommend however that we create a more general "ui" package in line  
with what we have done in common and edu-services and add to it the  
following projects:

jsf (add now)
velocity (add later)

Other projects providing ui framework support could be dropped in  
later such as sakai-wicket (in contrib) or the Java-based Sakai- 
specific portions of RSF (if for one reason or another Antranig is  
unable to support it).

IMPACT

If we limit the "ui" package to jsf for 2.7 the impact is minimal.  As  
I noted above projects destined for 2.7 (both trunk and contrib) with  
dependencies on the Sakai jsf project will require their Maven  
coordinates to be updated.   Example:

From
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-jsf-tool</artifactId>
to
<groupId>org.sakaiproject.ui.jsf</groupId>
<artifactId>jsf-tool</artifactId>

If we add velocity to the "ui" package for 2.7 the impact is greater.   
This is due principally to a short chain of velocity-courier-presence  
dependencies that must be confronted.  Releasing velocity  
independently will require releasing both the courier and presence  
independently.  People might not want to do this for 2.7.0.  For  
myself, I think prepping these projects for an independent release no  
big deal but others may think it best to go slow.

If you have any objections to the "ui" package proposal please reply  
on list.

Cheers,

Anthony

Begin forwarded message:

> From: Anthony Whyte <arwhyte at umich.edu>
> Date: November 4, 2009 1:32:58 PM PST
> To: Developers List <sakai-dev at collab.sakaiproject.org>
> Cc: Sakai QA <sakai-qa at collab.sakaiproject.org>
> Subject: Samigo 2.7 changes (svn update)
>
> The Samigo team at Stanford kindly permitted me to rework their  
> project POM files and write an assembly module so that Samigo (e.g.  
> Test and Quizzes) can be released independently of Sakai 2.7+  
> releases.  Phase I of this work is now complete and the first batch  
> of Samigo 2.7.0-SNAPSHOT artifacts (including a signed samigo-audio  
> jar) now reside in our Maven2 snapshot repo and are downloaded and  
> deployed to Tomcat whenever you build and deploy Sakai trunk code.
>
> WHAT'S CHANGED
>
> Samigo is no longer included in trunk .externals or listed  
> explicitly as a <module> in the default and experimental profiles in  
> the Sakai base pom.  So if you perform a full checkout of Sakai  
> trunk, Samigo trunk code will not be downloaded; likewise, if you  
> build Sakai trunk and deploy it to Tomcat, any Samigo trunk code  
> that you might add to your Sakai source will be excluded from the  
> build (unless you first clean and install /sam).  Instead, and in  
> line with other projects scheduled for independent release (e.g.,  
> common, edu-services, entitybroker, msgcntr, etc.), Samigo artifacts  
> will now be downloaded, installed in your local repo and deployed to  
> Tomcat automatically (including snapshot updates) whenever you issue  
> the standard maven build directives against trunk code:
>
> mvn clean install sakai:deploy
> or
> mvn -Pexperimental clean install sakai:deploy
>
> All this occurs as a result of the inclusion of the core-deploy pom  
> as a <module> in the Sakai base pom default and experimental  
> profiles.  core-deploy adds a number of assembly dependencies to the  
> build process, each of which provides a "tomcat overlay" zip file  
> that distributes each project's artifacts to their appointed place  
> in Tomcat (e.g., components, shared/lib, webapps).
>
> TRUNK DEVELOPERS
>
> 1. Trunk refresh.  Please perform an svn update or a fresh checkout  
> of trunk to pick up these changes.
>
> 2. .m2 repo.  Strictly speaking, you do not need to clean out the  
> samigo directories in your local .m2/org/sakaiproject repo since I  
> have revised the Samigo maven coordinates (e.g., <groupId>,  
> <artifactId) and the new samigo artifacts will be located under a  
> single /samigo folder instead of their current multi-folder location  
> s (e.g., sam-base, sakai-samigo-*).  However, I have not changed the  
> Samigo snapshot version (currently 2.7.0-SNAPSHOT) and your old .m2  
> sam-base and sakai-samigo-* folders will contain out-of-date and  
> stranded 2.7.0-SNAPSHOT artifacts.  I recommend deleting these old  
> artifacts.  A clean .m2 repo is always preferred.
>
> WARNING (SAMIGO DEVELOPERS)
>
> If you do development against Samigo trunk you will need to check  
> out the project separately in order to work with the source code.  A  
> standard Sakai trunk checkout no longer suffice.
>
> svn co https://source.sakaiproject.org/svn/sam/trunk samigo-trunk
>
> You can test your samigo changes locally by performing a mvn clean  
> install against your local repo before deploying to Tomcat.  SVN  
> commits to samigo trunk will NOT be reflected in the snapshot  
> artifacts until a refresh occurs.  At the moment this involves  
> shouting at me to pick up the fixes and refresh the repo.  Within  
> the next couple of weeks the snapshot refresh process will be  
> automated once I deploy a Hudson build server (server only now made  
> available).
>
> WORK REMAINING TO BE COMPLETED
>
> 1. Drop in the release plugin.  A formality at this point.
> 2. Eliminate a large number of declared but unused dependencies  
> associated with a "standalone" version of Samigo that is no longer  
> relevant.  I'm working on that now.  This should shrink the size of  
> the tomcat-overlay zip file.
> 3. Beef up reporting, documentation and a site skin in support of a  
> Samigo automated Maven site deployment.
> 4. Release Samigo 2.7.0-alpha01.
>
> JIRA TRACKING (so far)
>
> http://jira.sakaiproject.org/browse/SAK-17334
> http://jira.sakaiproject.org/browse/SAK-17335
> http://jira.sakaiproject.org/browse/SAK-17336
>
> Cheers,
>
> Anthony
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20091106/069120ae/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20091106/069120ae/attachment.bin 