geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Genesis 2.0 Status
Date Tue, 09 Sep 2008 11:50:54 GMT

On Sep 9, 2008, at 1:48 AM, Jason Dillon wrote:

> No comments?

Your description sounds great but I won't really know until I try it  
out or study it in great detail which I haven't had time for.  The  
organization looks way better than what we have now.

Can we use the stage plugin to copy from local staging to  
people.apache.org staging and then again from there to the repo?

thanks
david jencks
>
>
> --jason
>
>
> On Fri, Sep 5, 2008 at 12:53 AM, Jason Dillon  
> <jason.dillon@gmail.com> 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
>>



Mime
View raw message