Hi all,

WSO2 maven release prepare plugin [1]  was introduced to help Apache maven
release plugin to prepare releases of WSO2 specific maven projects (ESB and
Registry). These projects contain *artifact.xml* files which consists of
meta-data (including versions) of the project artifacts and they need to be
updated for both release version (tag) and the next development
version(trunk) during the release preparation. WSO2 maven release prepare
plugin addresses this requirement.

*Current implementation*

With Apache maven release plugin, it's possible to configure additional
maven plugins as completion goals of preparation goal[2].

Currently, pre-prepare goal of wso2 maven release prepare plugin should be
executed as a completion goal of Apache maven release plugin. Current
implementation only supports svn. Current implementation
is summarized below.

   - Check out already committed svn tag to a temporary location
   - Iterate though all maven projects and identify ESB and Registry
   projects
   - Read release.properties[3] file and identify release version for that
      particular project.
      - Update *artifact.xml *file with release version.
   - Commit the changes to tag.
   - Check out trunk to a temporary location.
   - Iterate though ESB and Registry projects.
   - Read release.properties[3] file and identify next development version
      for that particular project.
      - Update *artifact.xml* file with
   - commit the changes to trunk.

*Current drawbacks and limitations *

   - Only supports svn.
   - Implementing support for other scm providers require a lot of effort.
      - Even-though a common scm-api[4] was used for svn related tasks,
      implementation is too tied to svn way of doing things (Eg. Tagging in svn
      vs git).
   - Checking out a remote repository temporary may affect performance with
   large repositories and introduces an unnecessary complexity.
   - doesn't support rollback mode [5]
   - doesn't support dryRun mode [2]

*Proposed implementation*

Main goals are to support other scm providers (avoid any scm provider
specific implementations) and avoid cloning remote repositories. Rollback
and dryRun modes can also be supported with this design.

As mentioned under[2], in the release:prepare goal, Apache maven release
plugin provides two entry points for other plugins as below.


   - preparationGoals - Goals to run as part of the preparation step, after
   transformation from snapshot versions to release version, but before
   committing.
   - completionGoals - Goals to run on completion of the preparation step,
   after transformation back to the next development version but before
   committing.

These two entry points can be used to access already modified projects in
the two phases - release preparation and next snapshot preparation - but
before committing them to remote repo. New two different goals will be
introduced for WSO2 maven release prepare plugin as below. These two can be
executed as a preparation goal and a completion goal of Apache maven
release plugin.

   - prepare-release : find ESB and Registry projects in local repo and
   update *artifact.xml* files with release version for each particular
   project (captured from release.properties[3] file)
   - prepare-snapshot : find ESB and Registry projects in local repo and
   update *artifact.xml* files with next dev version for each particular
   project (captured from release.properties[3] file)

This way, it's possible to have *artifact.xml* files also modified
before Apache
maven release plugin commits the changes. Yet, Apache maven release plugin
does not commit all the changed files in the repository but only commit
changed pom.xml files. As of now, there is no way to include changed
*artifact.xml* files in Apache maven release plugin commits (there's a
configuration to exclude files though).

To address above issue, we need to commit changed *artifact.xml*  file
before Apache maven release plugin commits. It is possible to use
scm:checkin goal of maven scm plugin[6] to commit changed files to remote
repository. It is possible to use mojo-executor [7] to execute this within
mojos in WSO2 maven release prepare plugin. This way it is possible to
avoid any scm  related logic inside WSO2 maven release prepare plugin and
it will have OOB support for all scm providers which are currently
supported by maven scm plugin[6].

*rollback **support*

A new goal called rollback will also be introduced for WSO2 release prepare
plugin. However, Apache release plugin does not provide any entry point for
other plugins in release:rollback goal. Hence, this rollback goal of WSO2
maven release prepare plugin will have to be manually invoked in order to
rollback changed *artifact.xml* files.

Implementation of rollback goal can be done similar to prepare-release
and prepare-snapshot
goals (using release.properties files and maven scm plugin).  However, this
introduces the constraint that wso2-release:rollback goal should be
executed before executing rollback goal Apache release plugin (since
release.properties
file will be deleted after rollback of Apache release plugin ).

Alternatively, it is possible to introduce a backup file for each modified
*artifact.xml* (similar to what Apache release plugin does). Then again an
another issue rises - How to cleanup these backup files after
a successful release:prepare and a release:perform (release:perform also
does not provide an entry point for other plugins)?

Please share your thoughts on this.

Thanks,

[1]
https://docs.wso2.com/display/DVS371/Using+Maven+with+Developer+Studio#UsingMavenwithDeveloperStudio-MavenReleaseplug-in

[2]
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html

[3] Maven release plugin creates a file called release.properties in the
root of the repository after finalizing release versions and next
development versions for each maven project in the repository. This file
also consists of the tag name for the release and scm connection details.
This file is created during release : prepare goal of apache maven release
plugin and will be cleaned after executing release : perform.

[4] http://maven.apache.org/scm/maven-scm-api/

[5]
http://maven.apache.org/maven-release/maven-release-plugin/rollback-mojo.html

[6] http://maven.apache.org/scm/

[ 7 ] http://timmoore.github.io/mojo-executor/
-- 
*Kavith Lokuhewage*
Software Engineer
WSO2 Inc. - http://wso2.com
lean . enterprise . middleware
Mobile - +9477-9-145-123 | +9471-455-6-401
Linkedin <http://www.linkedin.com/pub/kavith-lokuhewage/49/473/419>  Twitter
<https://twitter.com/KavithThiranga>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to