On 30/07/07, Tom Huybrechts <[EMAIL PROTECTED]> wrote:
> You can use the release plugin on a multi-module project, and it will
> it walk the module graph for you.
That's what I doing currently. Nearly all of our SVN modules are
Maven2 multi-module projects; there's an unfortunate overloading of
the term. My apologies for not being more precise.
> You can also run release:prepare
> with -B (batch mode) so that all defaults will be used automatically.
Thanks, I can't see in the documentation[1], and missed it in the
source. That covers automating the prepare step. Any suggestions on
the branch / remove snapshot / increment to development versions and
merge aspects?
Cheers,
James
[1] http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html
>
> On 7/30/07, James Abley <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > We currently have the following process for our releases:
> >
> > Walk the DAG of our modules in a breadth-first traversal [1] and for
> > each module being released:
> >
> > 1) Create a branch in Subversion.
> > 2) Check out the branch
> > 3) Update the POMs so that no SNAPSHOT dependencies are stil in the
> > POMs and commit these updates in the branch.
> > 4) mvn release:prepare -D...
> > 5) mvn release:perform
> > 6) Update the POMs to reference the new SNAPSHOT dependency versions
> > and commit these updates in the branch.
> > 7) Merge the updated POMs back into main trunk.
> >
> > We have some Python scripts to do steps 1-3 and 6,7.
> >
> > Unfortunately step 4 doesn't seem to be possible to fully script due
> > to prompting for release numbers and next development numbers. We
> > could do more work with the reading and writing of child stdin /
> > stdout, but I think it would be preferable for the release plugin to
> > support being invoked in an enabling manner which assumes that we know
> > what we are doing and just to use the defaults.
> >
> > I also noticed that the maven-release-plugin has had some changes in
> > the last few months, with a new release:branch goal. And from a brief
> > look at the plugin code, the logic is in place to do steps 3 and 6
> > within the plugin, but it doesn't appear to be exposed.
> >
> > I would like to be able to move to an all Maven solution.
> >
> > 1. Does this look possible, given the process that we have? And is it
> > possible using the current release plugin, if invoked correctly, or
> > would it require changes to expose the desired functionality? Please
> > provide any examples of how you think this should work.
> > 2. If I'm correct and the prepare step can't be automated, does anyone
> > think this is a reasonable idea? If so, I'll raise a JIRA issue and
> > look at whether I can provide a patch.
> >
> > Regards,
> >
> > James
> >
> > [1] http://en.wikipedia.org/wiki/Breadth-first_search
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
