Proposal: Eliminate all Indies in trunk

Voting

Approved by lazy consensus after agreement to set aside re-versioning portion of the proposal.  No PMC members raised a material objection.

Background

Note: this proposal was amended and re-scoped downwards to refactoring "Indie" Sakai modules only.  The call to re-version trunk 4.0 was set aside.  Eliminating the indies was carried out by Aaron Zeckoski and Anthony Whyte with assistance from Matt Jones and Sam Ottenhoff.  Trunk was ultimately re-versioned 10.0 per a later proposal.  For more details see 

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

From: Anthony Whyte <arwhyte@umich.edu>
Date: June 17, 2013 5:04:35 PM EDT
To: sakai2-tcc Committee <sakai2-tcc@collab.sakaiproject.org>
Subject: Proposal: eliminate all indies, re-version trunk to CLE 4.0

The proposal below plays off our discussions in San Diego relative to working towards a simplified build/deploy process.  It represents an incremental step but I think warranted given the failure of the indie approach to capture the imagination of the Sakai Community and the attendant "version" confusion often encountered by local deployers attempting to track and manage CLE release changes.

The proposal represents a first step in the simplification/rationalization process.  I can make time to do the work starting this week, if it meets with your approval.  If Steve and Matt have any time to help all the better.  

PROPOSED CHANGES (limited to trunk)
a. All CLE modules will be versioned 4.0-SNAPSHOT (no exceptions)
b. All CLE module base poms will inherit from the master pom as their <parent>.   The Kernel and CLE master pom will retain their oss-parent <parent>.  The CLE base pom will continue to inherit from the master pom.
c. All CLE module assembly code will be deleted and references to assembly <module> will also be removed from module poms (e.g., <module>basiclti-assembly</module> will be deleted).
d. All CLE module poms that include explicit version references to Sakai dependencies will be updated.  When appropriate I'll swap in Maven property variables.
e. Eliminate 34 CLE module version <properties> from the master pom rendered redundant by the switch to a single version for all CLE core modules.
f. https://source.sakaiproject.org/svn/sakai/trunk/jstl-shared-deploy/ will be deleted (rendered redundant by deploy/ poms)
g. freebie: hybrid module will be eliminated from .externals and base pom build profiles.

WORK WILL BE DONE IN GITHUB
I will do my work in a local branch off my local fork of botimer/sakai-cle [1].   I'll create a branch called "no_indie" and make my changes there in a manner similar to the way Noah handled his spring work.  Noah keeps his repo sync'd with sakai-trunk changes and I will do the same with my local branch.  I prefer to make all changes at once, test, and then provide a single patch that can be committed to SVN trunk.

OUT OF SCOPE FOR THIS PROPOSAL (but still on the table for CLE 4.0)
Base/Master pom rationalization.  I recommend that we consider revising the base pom in a way that we end up with a pom not unlike the org.apache.apache pom,[2]  Everything else we move to the master pom, which would inherit from the base pom, which would inherent from the oss-parent.
    oss-parent
        Sakai base pom
                            project info, repos, distribution management, plugin management, plugins
            Sakai master pom
                                build profiles (from base pom), properties, dependencies, build, reporting

Note: changing the order of inheritance as suggested about would impact some contrib projects negatively.  We would need to either be prepared to help patch such projects or sufficient warning and simple steps on how to fix the <parent> element of contrib project's base pom.

IMPLICATIONS
1.  We return to a monolithic release process, circa Sakai 2.5.  Leaving aside Ian's reasons for creating kernel as the first indie, a commitment to shorter release cycles should provide a counterweight to the original rationale for creating tool indies, i.e., the need for off-cycle releases of important bug fixes or new functionality in order to compensate for overlong CLE release cycles.  However, without a commitment to shorter release cycles, eliminating indies could prove counterproductive.
2.  Faster downloads (no assemblies); consistent build/deploy behaviors for all modules (I should note that this has been addressed in trunk by importing the sakai-trunk-all approach).
3.  Elimination of version confusion.  All modules, all one version.  Simple.
4.  A lag in the elimination of Jira confusion.  The SAK project can be bulked up with additional components, which if you are working on the latest stuff represents a gain; however, as Matt notes below, the Indie Jira projects will have to be retained for tracking earlier versions.  So no victory can be claimed here.
5.  Local build script changes.  I imagine some schools have crafted build scripts that accommodate the indies.  These scripts will need to be changed (simplified).  So a local impact cannot be discounted.
6. trunk devs will need to need to a fresh check out and clean install when the poms are updated.  No biggie but it should be mentioned.

Feel free to add other implications or raise a material objection.

Cheers,

Anth

[1] https://github.com/botimer/sakai-cle
[2] http://search.maven.org/remotecontent?filepath=org/apache/apache/13/apache-13.pom