Sorry, I've not read this entire thread, but have a quick comment...
This idea of plugin packs could easily be extended to the more
generic pom inclusion stuff I've talked about previously. There
other things besides plugin version binding that could be bundled up
into a reusable package
Jason van Zyl wrote:
On 1 Sep 07, at 7:42 PM 1 Sep 07, Brett Porter wrote:
I'd be ok with it looking like this:
project
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdtest/artifactId
nameTest/name
version1.0-SNAPSHOT/version
build
plugins
pluginPacks
Dennis Lundberg wrote:
Jason van Zyl wrote:
On 1 Sep 07, at 7:42 PM 1 Sep 07, Brett Porter wrote:
I'd be ok with it looking like this:
project
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdtest/artifactId
nameTest/name
version1.0-SNAPSHOT/version
build
plugins
The misunderstanding seems to be:
1) that I thought we were going to require plugin versions to be
specified in the future. You seem to say that is no longer the case.
I think you're right here. After reading your response to my comments, I
realized my (and I think Jason's) assumption is that
I haven't used the enforcer myself yet. How would turn on the enforcer
rule look inside a pom?
See here for an example. Note that multiple rules can be configured at
once. (also this rule is in the current snapshot rev)
http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requirePlugi
If this pom section is simple enough, I think people who care about
reproducibility will use it. Would it be possible to combine this
with
a warning?
I'm not 100% certain, but I think that would require pulling some of
the
enforcer logic into the core...
This might be a good thing, i.e.
Brian E. Fox wrote:
I haven't used the enforcer myself yet. How would turn on the enforcer
rule look inside a pom?
See here for an example. Note that multiple rules can be configured at
once. (also this rule is in the current snapshot rev)
Hi Brian,
Thanks for the great response - comments inline...
On 02/09/2007, at 11:30 PM, Brian E. Fox wrote:
The misunderstanding seems to be:
1) that I thought we were going to require plugin versions to be
specified in the future. You seem to say that is no longer the case.
I think you're
Everything else you said below makes sense and is pretty much in line
with my experience, so I think it's best to defer this for a general
mixins proposal (if at all).
I'm pretty sure that a general ability to include or mixin some
other piece of xml into the pom would come in handy, but this
SPAM***] - Re: [PROPOSAL] Plugin packs and concrete
versioning - Email has different SMTP TO: and MIME TO: fields in the email
addresses
On 1 Sep 07, at 4:35 AM 1 Sep 07, Hervé BOUTEMY wrote:
Le samedi 1 septembre 2007, Brian E. Fox a écrit :
I think we can do this just by generating a sample
On 03/09/2007, at 8:46 AM, Brian E. Fox wrote:
Everything else you said below makes sense and is pretty much in line
with my experience, so I think it's best to defer this for a general
mixins proposal (if at all).
I'm pretty sure that a general ability to include or mixin some
other piece
Le samedi 1 septembre 2007, Brian E. Fox a écrit :
I think we can do this just by generating a sample pluginManagement
snippet on the site somewhere. I don't think anything fancy is needed,
simply providing the snipet so someone can copy and paste will be more
than sufficient. Having it
On 1 Sep 07, at 4:35 AM 1 Sep 07, Hervé BOUTEMY wrote:
Le samedi 1 septembre 2007, Brian E. Fox a écrit :
I think we can do this just by generating a sample pluginManagement
snippet on the site somewhere. I don't think anything fancy is
needed,
simply providing the snipet so someone can
On 01/09/2007, at 8:00 AM, Brian E. Fox wrote:
It only checks for the condition and fails the build. It currently
does
not make changes or suggestions. The enforcer is about enforcing, not
fixing ;-) but the rule could be executed by another plugin and
used as
a starting place to lookup
On 1 Sep 07, at 7:42 PM 1 Sep 07, Brett Porter wrote:
I'd be ok with it looking like this:
project
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdtest/artifactId
nameTest/name
version1.0-SNAPSHOT/version
build
plugins
pluginPacks
pluginPack
Jason,
I completely agree with everything you said below, in terms of what
users want at least. So I'm obviously not communicating what I want
well, since you seem to have completely missed my point in every
response.
The misunderstanding seems to be:
1) that I thought we were going to
sorry for the brevity - I'm heading off to bed and am afk for a day
and a bit so wanted to get a quick response in...
On 01/09/2007, at 1:45 AM, Jason van Zyl wrote:
A couple notes that you can incorporate from experiences I've had
based on a client setup:
- The enforcer plugin now has a
On 31 Aug 07, at 9:20 AM 31 Aug 07, Brett Porter wrote:
sorry for the brevity - I'm heading off to bed and am afk for a day
and a bit so wanted to get a quick response in...
On 01/09/2007, at 1:45 AM, Jason van Zyl wrote:
A couple notes that you can incorporate from experiences I've had
...
A future enhancement may be to be able to (and if so, require) plugin
versions to be declared in the Maven settings files.
but in that case it could be interesting to be able to have an extend
mechanism of settings using the repository like a parent pom. The idea
is to be able to define
Comments inline also
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Friday, August 31, 2007 12:20 PM
To: Maven Developers List
Subject: Re: [PROPOSAL] Plugin packs and concrete versioning
sorry for the brevity - I'm heading off to bed and am afk for a day
20 matches
Mail list logo
