geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <jason.dil...@gmail.com>
Subject Genesis 2.0 Status
Date Thu, 04 Sep 2008 17:53:26 GMT
Folks, I've been pounding away at Genesis 2.0, in between  
hospitalization and system failures, and I think it is about ready.   
I'm sending this email to inform folks about the state of the sub- 
project as to enlist any suggestions on changes before I go about  
documenting it fully.

  * * *

The 2.0 bits consist of the following modules:

   genesis-flava
      genesis-default-flava
      genesis-java1.4-flava
      genesis-java5-flava
   genssis-maven-plugin
   genesis-packaging
   genesis-skin
     genesis-geronimo-skin

The 'flava' modules provide the basic configuration for sub-projects,  
what used to be 'project-config' in Genesis 1.x.  There are 2 modules,  
one for Java 1.4 projects and another for Java 5 projects.  Both  
inherit from the 'genesis-default-flava' which in-turn inherits from  
the top-level pom.   The top-level pom defines the versions of  
plugins, and sets up the basic profiles used to perform a release,  
stage and test a release.  The 'flava' poms define configurations  
which are intended to be inherited from by projects to setup the muck  
needed for each version.

The plugin currently only provides validation goals, which try to help  
reduce user-configuration errors.  This plugin is used by the default  
flava and avoids the need for staged builds.

The genesis-geronimo-skin module is our normal skin, hasn't really  
been changed... for better or worse.

The genesis-packaging module contains the muck that used to be in the  
tools-maven-plugin, its not hooked up by default so it needs to be  
configured as an extension where its needed.

  * * *

Release configuration currently consists of the following properties:

   * release.stageRequired
   * release.gpgPassphrase
   * release.stageDeployUrl
   * release.siteStageDeployUrl

Which usually ends up in your ~/.m2/settings.xml as somthing like:

----8<----
<project>
     <profiles>
         <profile>
             <id>release-configuration</id>
             <activation>
                 <property>
                     <name>release</name>
                 </property>
             </activation>
             <properties>
                 <release.gpgPassphrase>***YOUR GPG PASSPHRASE***</ 
release.gpgPassphrase>
                 <release.stageDeployUrl>file://***DIRECTORY OF YOUR  
LOCAL STAGE REPOSITORY***</release.stageDeployUrl>
                 <release.siteStageDeployUrl>file://***DIRECTORY OF  
YOUR LOCAL SITE STATE REPOSITORY***</release.siteStageDeployUrl>
             </properties>
         </profile>
     </profiles>
</project>
---->8----

When performing a normal (non-staged release, not the norm for ASF  
muck), one can:

   mvn -Drelease release:prepare
   mvn release:perform

For normal ASF staged releases:

   mvn -Drelease=stage release:prepare
   mvn release:perform

Stages releases, IMO, should be deployed to a local URL and once the  
build has finished the release-manager should perform an scp to deploy  
to a shared location.  The reason for this is that often times, during  
a project release which consists of many (many) modules, often times  
the network connection will break and fail release builds.  This is a  
problem because mvn's release deployment occurs for each modules, not  
at the end of the build, though for releases, before the build occurs  
some scm changes will occur.  So to minimize problems, staging to a  
local URL for the build, then after the build succeeds manually  
deploying to a shared location should provide better overall results.

It may be possible to automate this procedure at a later date... but  
for now its assumed to be manual.

  * * *

I had tried to make Genesis 2.0 generic enough to be used by other  
projects, specifically the other mvn plugins I maintain for the Mojo  
project, though I haven't really found a good way to do that  
completely.  But because of this Genesis 2.0 allows non-staged  
releases.  But projects can define 'release.stageRequired' to be  
'true' in their projects pom to require the release to be staged.   
This property is configured in the project's pom.  Which means that  
this will fail:

   mvn -Drelease *

and this will not:

   mvn -Drelease=stage *

  * * *

The site staging bits are still kinda in the works, need to get more  
experience with how we actually use it, though right now I have some  
basic configuration enabled.

Folks that want to build javadoc and source distributions for testing  
can enable the 'distribution' profile, which is very close to what the  
'full' profile in Genesis 1.x used to be.  This profile is flipped on  
automatically when -Drelease is specified.  To turn on manually w/o  
release add '-P distribution' to the invocation.

Before performing a release, its useful to run a build with '- 
DtestDistributionUrl=file://...' set which will set the DM muck to the  
URL given, allowing a preview of the release muck w/o performing any  
SCM muck.

And finally, and somewhat experimental ATM, there is a profile which  
can be flipped on optionally to ensure that no snapshots are defined  
and no plugin version are undefined via:

   mvn -Denforce=strict

This enables a SNAPSHOT version of the enforcer to run some rules to  
puke if things aren't savvy as desired.  As soon as the latest maven- 
enforcer-plugin gets released I will most likely enable this by  
default, at least for the plugin version stuff, and the non-snapshot  
stuff for release preparation.

  * * *

I've setup a test project to validate some of this muck here:

   http://svn.apache.org/repos/asf/geronimo/sandbox/genesis-test

So far all tests seem to indicate that, at least my usage, works.

And now... its times to ask for feedback before I proceed further.   
 From what I can tell this stuff works well, but I'm not sure if I  
have missed anything.  So take a look, at ping me back please.

Cheers,

--jason

Mime
View raw message