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
>>>
>
|