[Building Sakai] Trunk: ui package proposal
Anthony Whyte
arwhyte at umich.edu
Fri Nov 6 17:00:41 PST 2009
In the specific case of jsf and velocity I was thinking of their
stable, almost glacial nature, the near absence of active committers
(no criticism intended by the way), the similar roles they play with
respect to the venerable tools they support, the fact we neither
promote jsf nor velocity as a UI framework/templating engine for
developers writing new Sakai 2.x tools (csev will disagree regarding
velocity) and finally the ease with which I could package them up and
put out a single "ui" release of these artifacts and then largely
forget about it.
But I must admit the reasons above have nothing to do with dependency
management, that is, proposing that a set of dependencies should be
combined in one package because Sakai tools tend to depend on them in
tandem. This is clearly not the case with jsf and velocity. We have
JSF tools and Velocity tools, not JSF/Velocity hybrids that might
warrant such a combination. In Samigo we have a JSF/RSF hybrid, but
it is an exception.
I see from above that I've talked myself out of my proposal with the
help of Aaron and Lance. So I will withdraw it and limit myself to
finishing up the work required to release jsf independently in order
to support Samigo and (perhaps someday) other independent JSF tool
releases. That work is nearly complete. :)
Cheers,
Anth
jsf: one code commit since 31 Dec 2007 (excluding language bundle
updates). 16 open issues in Jira.
velocity: approx 23 commits since 31 Dec 2007; 0 commits since 31 Dec
2008 (excluding language bundle updates). 7 open issues in Jira.
On Nov 6, 2009, at 3:35 PM, Aaron Zeckoski wrote:
> If we are voting on this then -1.
> I (and others) should not have to depend on velocity and wicket if I
> am using JSF and vice versa.
> We should just package up separate ui support and integration jars for
> each framework similar to the RSF one.
> -AZ
>
>
> On Fri, Nov 6, 2009 at 11:07 PM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
>> +1
>> It gives us a central place to get our UI related dependencies and
>> all the
>> framework code is in one place.
>> As for Sakai Wicket, it would be good to get this into the UI
>> package since
>> it's never been in a Maven repository to start with. However, last
>> time I
>> looked it was very out of date and makes updating Wicket versions
>> for your
>> tool rather painful. If you are developing a new Wicket based
>> application
>> for Sakai, you don't need to use it. The existing tools that do use
>> it can
>> be updated to use this package though.
>> cheers,
>> Steve
>>
>>
>> On 07/11/2009, at 7:12 AM, Anthony Whyte wrote:
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
>>
>>
>
>
>
> --
> Aaron Zeckoski (azeckoski (at) vt.edu)
> Senior Research Engineer - CARET - University of Cambridge
> https://twitter.com/azeckoski - http://www.linkedin.com/in/azeckoski
> http://aaronz-sakai.blogspot.com/ - http://tinyurl.com/azprofile
>
>
-------------- 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/788b4247/attachment.bin
More information about the sakai-dev
mailing list