geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: Genesis 2.0 Status
Date Tue, 09 Sep 2008 13:12:42 GMT
I like the new option to force staging instead of publishing to
apache.releases (which I was bit by last week.)  Would be nice if the
default was to force staging and require a command line override to
allow publishing to apache.releases (as I think every project to publish
to a staging directory first.)

Can you create a new Draft page (as we need to keep the existing release
steps for future 2.1.x server and component releases) in our GMOxPMGT
space showing what the new Component and Server release steps would be
if we moved to Genesis 2.0?

Also, when are you planning on moving server/trunk over to use this new
code or should we upgrade Specs, Javamail or Samples to use it first to
work out any problems?


Jason Dillon wrote:
> No comments?
> --jason
> On Fri, Sep 5, 2008 at 12:53 AM, Jason Dillon <> wrote:
>> 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:
>> 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

View raw message