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