[Building Sakai] Trunk: ui package proposal
Steve Swinsburg
steve.swinsburg at gmail.com
Sat Nov 7 00:02:47 PST 2009
We should be able to package them up so that you don't need to pull in
the extra dependencies, just the ones you need for your tool. I
wouldn't want to pull in JSF dependencies into my Wicket tool either.
Just moving them to a centralised package would be sufficient.
ie
org.sakaiproject.ui
jsf
org.sasakaiproject.ui
velocity
cheers,
Steve
On 07/11/2009, at 12:17 PM, Speelmon, Lance Day wrote:
> Just to be clear - I like the idea of releasing the artifacts - just
> independent releases. Thanks, L :)
>
>
> Lance Speelmon
> Scholarly Technologist
>
> On Nov 6, 2009, at 8:00 PM, Anthony Whyte wrote:
>
>> 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
>>>
>>>
>>
>
More information about the sakai-dev
mailing list