geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Dillon" <>
Subject Re: Genesis 2.0 Status
Date Tue, 09 Sep 2008 05:48:12 GMT
No comments?


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