On 11/8/06, Brett Porter <[EMAIL PROTECTED]> wrote:
On 08/11/2006, at 5:10 PM, Nathan Beyer wrote:
> 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.
>
I agree - adding versioned plugin packs to maven 2.1 is one though to
resolve the latter issue.
By populating them, I did mean that the release plugin should assist
with that as part of the release, which was what was originally
requested.
Ahh, sorry. I read that incorrectly then, I thought you meant that
they should be manually populated.
-Nathan
- Brett
---------------------------------------------------------------------
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]
