Hi All, Since now we are going to support multiple goals of release plugin and it's anymore not only about pre-prepare, shall we rename the plugin as "wso2-maven-release-plugin" instead of calling it "wso2-release-pre-prepare-plugin"?
Also shall we assign a plugin goal prefix to this plugin? So that it is possible to invoke goals using the prefix instead of full plugin name (similar to Apache maven release plugin). eg: wso2-release:rollback WDYT? Thanks. On Fri, Aug 7, 2015 at 12:01 PM, Kavith Lokuhewage <[email protected]> wrote: > 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> > -- *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
