[Building Sakai] Trunk: ui package proposal

[Anthony Whyte]

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@...>

Date: November 4, 2009 1:32:58 PM PST

To: Developers List <sakai-dev@...>

Cc: Sakai QA <sakai-qa@...>

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@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Speelmon, Lance Day]

It seems to me that not combining into a "ui" package gives us more flexibility, which I would tend to favor.  What are the reasons we would want to combine?  Thanks, L

Lance Speelmon

Scholarly Technologist

On Nov 6, 2009, at 3:12 PM, 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@...>

Date: November 4, 2009 1:32:58 PM PST

To: Developers List <sakai-dev@...>

Cc: Sakai QA <sakai-qa@...>

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

<smime.p7s>_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Aaron Zeckoski]

I think I would prefer keeping these separate and just making a
package of the jsf and velocity ones independently.
I don't see any good reason to combine them.
-AZ


On Fri, Nov 6, 2009 at 8:12 PM, Anthony Whyte <arwhyte@...> 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@...>
> Date: November 4, 2009 1:32:58 PM PST
> To: Developers List <sakai-dev@...>
> Cc: Sakai QA <sakai-qa@...>
> 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@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
> 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
_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Steve Swinsburg-3]

+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@...>

Date: November 4, 2009 1:32:58 PM PST

To: Developers List <sakai-dev@...>

Cc: Sakai QA <sakai-qa@...>

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@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Aaron Zeckoski]

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@...> 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@...>
> Date: November 4, 2009 1:32:58 PM PST
> To: Developers List <sakai-dev@...>
> Cc: Sakai QA <sakai-qa@...>
> 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@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
> with a subject of "unsubscribe"
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
> 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
_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Anthony Whyte]

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@...> 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@...>
>> Date: November 4, 2009 1:32:58 PM PST
>> To: Developers List <sakai-dev@...>
>> Cc: Sakai QA <sakai-qa@...>
>> 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@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>> with a subject of "unsubscribe"
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>> 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
>
>

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Speelmon, Lance Day]

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@...> 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@...>
>>> Date: November 4, 2009 1:32:58 PM PST
>>> To: Developers List <sakai-dev@...>
>>> Cc: Sakai QA <sakai-qa@...>
>>> 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@...
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>>> with a subject of "unsubscribe"
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev@...
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>>> 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
>>
>>
>

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Steve Swinsburg-3]

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@...> 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@...>
>>>> Date: November 4, 2009 1:32:58 PM PST
>>>> To: Developers List <sakai-dev@...>
>>>> Cc: Sakai QA <sakai-qa@...>
>>>> 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@...
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>>>> with a subject of "unsubscribe"
>>>>
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev@...
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>>>> 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
>>>
>>>
>>
>

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Aaron Zeckoski]

Yeah, same here. I think they should be released as well, just separately.
:-)
-AZ


On Sat, Nov 7, 2009 at 1:17 AM, Speelmon, Lance Day <lance@...> 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@...> 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@...>
>>>> Date: November 4, 2009 1:32:58 PM PST
>>>> To: Developers List <sakai-dev@...>
>>>> Cc: Sakai QA <sakai-qa@...>
>>>> 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@...
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>>>> with a subject of "unsubscribe"
>>>>
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev@...
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>>>> 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
>>>
>>>
>>
>
>

--
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
_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Seth Theriault]

Anthony Whyte wrote:

> 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.

[Cross-posting to the production list]

So that folks are aware, there are now several packages (kernel,
edu-services, Samigo, etc.) with "independent release" status
being readied for 2.7. While this approach offers some benefits,
I fear there is the potential for increased work for deployers
and more production-minded folks as a result.

Why? Because for every package that attains "independent release"
status, deployers who have local changes or patches or
differences now MUST build and deploy their own versions of the
affected package. As more and more "core services" packages are
created, it is more and more likely that deployers will have to
do this with as-yet-unknown effects.

I'll give you a simple example with Samigo (which is going
independent). Locally, Samigo is not known as "Tests & Quizzes",
but rather, "Test & Quiz". This requires 3 patches, one of which
is in the Help documentation. I now MUST build my own version of
Samigo to apply this type of change.

Perhaps we could slow the move to independent releases a bit in
advance of the main 2.7.0 Sakai release and see what effect, if
any, the new "independents" have on local deployment work.

Seth

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[dlhaines]

Seth,

I'm not sure what the problem is here. You have to patch and build the project now anyway, you just have to patch and build everything at the same time (which I don't see as a fundamental advantage).  Is the issue mostly keeping track of what projects have been patched and built when they aren't done in a single mass build?

I do think we are conflating a few different things under "independent release".  The new core services packages aren't really independent releases. There is no point in having to recompile stable code that hasn't changed for months. Repackaging code to create stable artifacts is a good idea. However that shouldn't be considered a separate release of that code.  Separate tools like Samigo should truly be an independent release.  Those are option and there is no reason that a release of an improved Sakai as a whole should depend on the state of the Samigo code. 

If you need to patch non-Samigo code to release Samigo that is a different problem and should be addressed as a bug.

- Dave

David Haines

CTools Developer

Digital Media Commons

University of Michigan 

dlhaines@...

On Nov 9, 2009, at 5:40 PM, Seth Theriault wrote:

Anthony Whyte wrote:

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.

[Cross-posting to the production list]

So that folks are aware, there are now several packages (kernel,
edu-services, Samigo, etc.) with "independent release" status
being readied for 2.7. While this approach offers some benefits,
I fear there is the potential for increased work for deployers
and more production-minded folks as a result.

Why? Because for every package that attains "independent release"
status, deployers who have local changes or patches or
differences now MUST build and deploy their own versions of the
affected package. As more and more "core services" packages are
created, it is more and more likely that deployers will have to
do this with as-yet-unknown effects.

I'll give you a simple example with Samigo (which is going
independent). Locally, Samigo is not known as "Tests & Quizzes",
but rather, "Test & Quiz". This requires 3 patches, one of which
is in the Help documentation. I now MUST build my own version of
Samigo to apply this type of change.

Perhaps we could slow the move to independent releases a bit in
advance of the main 2.7.0 Sakai release and see what effect, if
any, the new "independents" have on local deployment work.

Seth

_______________________________________________
production mailing list
production@...
http://collab.sakaiproject.org/mailman/listinfo/production

TO UNSUBSCRIBE: send email to production-unsubscribe@... with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Seth Theriault]

David Haines wrote:

> I'm not sure what the problem is here. You have to patch and
> build the project now anyway, you just have to patch and build
> everything at the same time (which I don't see as a fundamental
> advantage).  Is the issue mostly keeping track of what projects
> have been patched and built when they aren't done in a single
> mass build?

The main "problem" is that now managing a Sakai release is not a
single release but multiple releases (Matt Jones made this point
in a earlier response to the prod list) and that requires
deployers to:

1) Be aware of this shift
2) Adapt their local processes to the new situation

Is this an impossible task? No, it is not, but it requires more
work and possibly more intimate knowledge of how the new pieces
of the puzzle fit together. For example, people who have changes
to "independent" packages must deploy into a Maven repository in
some way and that's a new semi-required step. Ditto for a
required "independent" package like the K1 Kernel.

Another observation is that the semi-rapid movement from a
monolithic release (2.5) to a separated release (2.6 + K1) to a
more modular bundle (2.7 + K1 + "independents") may be leaving
some people in the dust. That's my main thrust here.

Seth

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Mark Norton]

Seth Theriault wrote:
> Another observation is that the semi-rapid movement from a
> monolithic release (2.5) to a separated release (2.6 + K1) to a
> more modular bundle (2.7 + K1 + "independents") may be leaving
> some people in the dust. That's my main thrust here.
>  
There was talk at one point about creating identified monolithic builds
after most of the major tools in Sakai were made independent.  Having a
simple way to build Sakai with Samigo automatically include (or similar
builds) is a desirable thing.  That said, I don't think we are at the
point of creating these custom aggregate builds.  We need to get the
independent pieces settled before they can be used (easily) to make
larger structures.

- Mark Norton
_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Michael Korcuska-2]

FWIW, we are planning on a normal 2.7.0 that will be "monolithic".  It  
will be built on top of some of these separate pieces but we're not  
planning on solely a "construct it yourself" approach.  What happens  
after that point is certainly up for discussion. I personally like the  
idea of letting tools evolve independently and occasionally grabbing  
the latest stable versions into a monolithic release when it makes  
sense. But I don't have to deploy Sakai on my campus.

Michael

On Nov 10, 2009, at 08:41, Mark Norton wrote:

> Seth Theriault wrote:
>> Another observation is that the semi-rapid movement from a
>> monolithic release (2.5) to a separated release (2.6 + K1) to a
>> more modular bundle (2.7 + K1 + "independents") may be leaving
>> some people in the dust. That's my main thrust here.
>>
> There was talk at one point about creating identified monolithic  
> builds
> after most of the major tools in Sakai were made independent.  
> Having a
> simple way to build Sakai with Samigo automatically include (or  
> similar
> builds) is a desirable thing.  That said, I don't think we are at the
> point of creating these custom aggregate builds.  We need to get the
> independent pieces settled before they can be used (easily) to make
> larger structures.
>
> - Mark Norton
> _______________________________________________
> sakai-dev mailing list
> sakai-dev@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>  with a subject of "unsubscribe"

--
Michael Korcuska
Executive Director, Sakai Foundation
mkorcuska@...
phone: [phone] (google voice)
skype: mkorcuska




_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Berg, A.M.]

Later when the "independent pieces settled"

I like the http://eclipsesource.com/en/yoxos/ site for Eclipse where you can blend a distribution out of Eclipses core and plugins. One could imagine a GUI like tool doing something similar for Sakai pom.xml and .externals, but then you would have to give clear definition of the quality of each generated profile so the end user could decide the relative risks and benefits.

Alan

Alan Berg

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg




-----Original Message-----
From: sakai-dev-bounces@... on behalf of Mark Norton
Sent: Tue 10-11-2009 17:41
To: Seth Theriault
Cc: production@...; Developers List
Subject: Re: [Building Sakai] [Deploying Sakai]  Trunk: ui package proposal

Seth Theriault wrote:
> Another observation is that the semi-rapid movement from a
> monolithic release (2.5) to a separated release (2.6 + K1) to a
> more modular bundle (2.7 + K1 + "independents") may be leaving
> some people in the dust. That's my main thrust here.
>  
There was talk at one point about creating identified monolithic builds
after most of the major tools in Sakai were made independent.  Having a
simple way to build Sakai with Samigo automatically include (or similar
builds) is a desirable thing.  That said, I don't think we are at the
point of creating these custom aggregate builds.  We need to get the
independent pieces settled before they can be used (easily) to make
larger structures.

- Mark Norton
_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[Steve Swinsburg-3]

For example, people who have changes 
to "independent" packages must deploy into a Maven repository in 
some way and that's a new semi-required step. Ditto for a 
required "independent" package like the K1 Kernel.

If you have local customisations to code that is now in one of the packages (Common, Edu Services, et al) then you can simply check out the source and patch in the usual fashion. I agree its a bit more work and a number of sources have disappeared from a trunk checkout but for most users is making things easier. 

Once patched however, you don't need to deploy these updated artifacts to a Maven repository (except your local one) for it to work. It's just like the Kernel - you can patch the source locally, build and be on your way with your updated Kernel artifacts. So there is no extra step for deployment.

If you need to share source (we've been using mSub to manage this) you could create a local shared Maven repository on a spare box in the corner pretty quickly and push your artifacts there for other local implementors to pull from.

regards,

Steve

On 11/11/2009, at 5:29 AM, Berg, A.M. wrote:

Later when the "independent pieces settled"

I like the http://eclipsesource.com/en/yoxos/ site for Eclipse where you can blend a distribution out of Eclipses core and plugins. One could imagine a GUI like tool doing something similar for Sakai pom.xml and .externals, but then you would have to give clear definition of the quality of each generated profile so the end user could decide the relative risks and benefits.

Alan

Alan Berg

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg




-----Original Message-----
From: sakai-dev-bounces@... on behalf of Mark Norton
Sent: Tue 10-11-2009 17:41
To: Seth Theriault
Cc: production@...; Developers List
Subject: Re: [Building Sakai] [Deploying Sakai]  Trunk: ui package proposal

Seth Theriault wrote:
> Another observation is that the semi-rapid movement from a
> monolithic release (2.5) to a separated release (2.6 + K1) to a
> more modular bundle (2.7 + K1 + "independents") may be leaving
> some people in the dust. That's my main thrust here.
>  
There was talk at one point about creating identified monolithic builds
after most of the major tools in Sakai were made independent.  Having a
simple way to build Sakai with Samigo automatically include (or similar
builds) is a desirable thing.  That said, I don't think we are at the
point of creating these custom aggregate builds.  We need to get the
independent pieces settled before they can be used (easily) to make
larger structures.

- Mark Norton
_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"

[jrnorman]

I would not characterise this as an either/or choice.

I believe we could (a) have independent tools and (b) distribute an  
assembly of selected tools as a single download 'package'. Thus at  
release time, you could take the default 'package' or build your own  
package.

The key question revolves around quality control expectations. If we  
say that combination in the default package has gone through a  
concerted QA effort, but other combinations rely on the independent  
tools individual QA and combinations different from the default will  
need testing by the adopter, then I think we are probably describing  
the plan for 2.7, but without calling it "monolithic". I believe all  
we are saying is "tested package/assembly/distribution of tools and  
kernel".

John

On 10 Nov 2009, at 16:58, Michael Korcuska wrote:

> FWIW, we are planning on a normal 2.7.0 that will be "monolithic".  It
> will be built on top of some of these separate pieces but we're not
> planning on solely a "construct it yourself" approach.  What happens
> after that point is certainly up for discussion. I personally like the
> idea of letting tools evolve independently and occasionally grabbing
> the latest stable versions into a monolithic release when it makes
> sense. But I don't have to deploy Sakai on my campus.
>
> Michael
>
> On Nov 10, 2009, at 08:41, Mark Norton wrote:
>
>> Seth Theriault wrote:
>>> Another observation is that the semi-rapid movement from a
>>> monolithic release (2.5) to a separated release (2.6 + K1) to a
>>> more modular bundle (2.7 + K1 + "independents") may be leaving
>>> some people in the dust. That's my main thrust here.
>>>
>> There was talk at one point about creating identified monolithic
>> builds
>> after most of the major tools in Sakai were made independent.
>> Having a
>> simple way to build Sakai with Samigo automatically include (or
>> similar
>> builds) is a desirable thing.  That said, I don't think we are at the
>> point of creating these custom aggregate builds.  We need to get the
>> independent pieces settled before they can be used (easily) to make
>> larger structures.
>>
>> - Mark Norton
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
>> with a subject of "unsubscribe"
>
> --
> Michael Korcuska
> Executive Director, Sakai Foundation
> mkorcuska@...
> phone: [phone] (google voice)
> skype: mkorcuska
>
>
>
>
> _______________________________________________
> production mailing list
> production@...
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> TO UNSUBSCRIBE: send email to production-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"