geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <jason.dil...@gmail.com>
Subject Re: Genesis 2.0 Status
Date Tue, 09 Sep 2008 13:51:10 GMT
I am going to update server/trunk to use Genesis 2.0 shortly.  Yes I  
will add some new wiki pages, just wanted to get some feedback first.

--jason


On Sep 9, 2008, at 8:12 PM, Donald Woods wrote:

> 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?
>
>
>
> -Donald
>
>
> Jason Dillon wrote:
>> No comments?
>> --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