On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Yikes, I'm getting forgetful in my old age. I thought the section on
that had been omitted from the final version of the book until it was
implemented.
Since we are no longer allowing changes to metadata in the repository
(unless it is an extreme case), then repeatability shouldn't be a
problem (notwithstanding bugs in the dependency mechanism which will
effect it either way), unless you are using version ranges (which to
date, haven't been popularly adopted because of the way they have
been implemented). The main culprit is plugin versions, so populating
those would be the most effective thing to do.
The plugin versions are the exact issue. I'm a little surprised by the
suggestion to just add versions to the plugin references, as I don't
see this being done in the Maven projects themselves. Additionally,
this would erode a significant portion of the "convention over
configuration" philosophy, as this would require that all of the
plugins that are inferred would have to be explicitly added to every
POM. For example, the surefire plugin, which is rarely explicitly
added to the build section. Another example would be the compiler
plugin.
-Nathan
It was my intention to review this overall with Maven 2.1 rather than
slap this back onto the release plugin as it didn't have the full
desired effect as is.
- Brett
On 08/11/2006, at 6:48 AM, Matthew Beermann wrote:
> (I asked this once before, but the thread got hijacked into other
> matters, so let's try this again...)
>
> Will the next release of the Release plugin include the
> "generateReleasePoms" functionality, e.g. the creation of a POM
> with resolved versions? If you were to believe Better Builds with
> Maven (p224), this functionality exists already, except it doesn't
> actually seem to. There doesn't seem to be a JIRA issue that tracks
> this, at least that I was able to find. Nor is it entirely clear
> from the current source code in Subversion - lots of commented-out
> code with "TODOs".
>
> This is key for us, and soon, as it helps to enable truly
> repeatable builds. Thanks for the help,
>
> --Matthew Beermann
>
---------------------------------------------------------------------
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]
