>Um - any reason that 2.0.8.1 can't be released that only contains an
>update to the superpom's plugin-set? (again, assuming this line of
>action is pursued)
It seems pretty certain to me that this is going to happen. I'd rather
see 2.0.9 come out, but naturally sooner rather than later and I
>It may be useful to release Maven more often, so that the super pom
gets
>updates on a more regular basis, i.e. at least once a month.
In general I agree we need to release more often and intend to make sure
it starts happening. I will not however consider a release simply to
update the super po
Um - any reason that 2.0.8.1 can't be released that only contains an
update to the superpom's plugin-set? (again, assuming this line of
action is pursued)
Christian.
On 10-Feb-08, at 18:18 , Stephen Connolly wrote:
If the whole plugin versions in the super pom goes ahead, which I
think is
If the whole plugin versions in the super pom goes ahead, which I think is a
good idea by the way.
It may be useful to release Maven more often, so that the super pom gets
updates on a more regular basis, i.e. at least once a month.
I know releases are getting more regular, but from my experience
>Just please somebody implement either enforcer:display-plugin-versions
or
>help:display-plugin-versions
The code to do this is in the enforcer rule now, once I get the rule
solidified and released, I'll move it to a common piece and add it to
help.
--
Just please somebody implement either enforcer:display-plugin-versions or
help:display-plugin-versions
On Feb 10, 2008 10:37 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> The enforcer is entirely pluggable so that wouldn't be a problem if
> someone wanted to implement that.
>
> On 10-Feb-08, at
The enforcer is entirely pluggable so that wouldn't be a problem if
someone wanted to implement that.
On 10-Feb-08, at 2:29 PM, Benjamin Bentmann wrote:
I think another rule would be more appropriate.
Sounds reasonable, two different POM elements, two different rules.
To make things compl
I think another rule would be more appropriate.
Sounds reasonable, two different POM elements, two different rules. To make
things complete a third rule would be RequireSkinVersion.
Benjamin
-
To unsubscribe, e-mail: [EM
On 10-Feb-08, at 1:59 PM, Benjamin Bentmann wrote:
2.0.8, dependency and archetype all have things locked down.
In case you meant the maven-dependency-plugin:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Ma
>That's not what I understand as a version lock down. Sure, the site
might
>not be that important but I still would like it to be as reproducible
as
>anything else I can generate out of a given POM.
The reporting is the last piece and is the reason I haven't released the
enforcer yet. The report p
2.0.8, dependency and archetype all have things locked down.
In case you meant the maven-dependency-plugin:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Maven Dependency Plugin
[INFO]task-segment: [site]
[INF
If you have anything specific
Some Maven or Mojo plugins...
please file it in JIRA
Sorry, but I won't due to my laziness ;-). In lack of a
in Maven 2.0, one cannot do this simply by means of a
single updated parent POM but would really need to update each sub module
POM. I think that's some
>Of course they should :-)
>If you have anything specific, please file it in JIRA or send a mail
>here and I'll take care of it.
Don't worry, once enforcer goes out, I'll be setting up our poms to get
it all locked down. As I mentioned in my previous email, I've been
manually doing it in the me
>As a matter of advertising, it might be helpful if the Maven sources
would
>give a good example ;-)
Absolutely. I have started doing this with all my releases (I use the
enforcer snapshot to find them, then take it out for now). 2.0.8,
dependency and archetype all have things locked down.
Benjamin Bentmann wrote:
2. Those who have not locked their versions down
By the way, this includes Maven itself. For instance, I see plugin
builds that fetch other plugin SNAPSHOTs from my local repo that I have
built for testing patches.
As a matter of advertising, it might be helpful if
2. Those who have not locked their versions down
By the way, this includes Maven itself. For instance, I see plugin builds
that fetch other plugin SNAPSHOTs from my local repo that I have built for
testing patches.
As a matter of advertising, it might be helpful if the Maven sources would
g
then it will
> fail just like it does today.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of nicolas de loof
> Sent: Saturday, February 09, 2008 11:05 PM
> To: Maven Developers List; [EMAIL PROTECTED]
> Subject: Re: Plugin Ve
ary 09, 2008 11:05 PM
To: Maven Developers List; [EMAIL PROTECTED]
Subject: Re: Plugin Versions in the Super pom
Could the enforcer plugin still warn about missing plugins version if
they
are set in the super POM ?
Nico
2008/2/10, Ralph Goers <[EMAIL PROTECTED]>:
>
> In my world I re
Could the enforcer plugin still warn about missing plugins version if they
are set in the super POM ?
Nico
2008/2/10, Ralph Goers <[EMAIL PROTECTED]>:
>
> In my world I require a reproduceable build. Typically, that means a
> specific release would have to be built using a specific version of
>
>So if this proposal means that each version of Maven hard-wires default
>versions of plugins - but that those plugin versions can be overridden
>then I definitely agree that that is the correct way to go.
This is exactly what I'm proposing.
-
On 9-Feb-08, at 9:32 PM, Ralph Goers wrote:
In my world I require a reproduceable build. Typically, that means
a specific release would have to be built using a specific version
of Maven. Any attempt to build it at a later time would need to
still use that release. This isn't just becaus
In my world I require a reproduceable build. Typically, that means a
specific release would have to be built using a specific version of
Maven. Any attempt to build it at a later time would need to still use
that release. This isn't just because of default versions of plugins
but because the
--Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 09, 2008 2:26 PM
To: Maven Developers List
Subject: Re: Plugin Versions in the Super pom
On 9-Feb-08, at 12:31 PM, Benjamin Bentmann wrote:
>> I think the idea of specifying versions in the "super
On 9-Feb-08, at 12:31 PM, Benjamin Bentmann wrote:
I think the idea of specifying versions in the "super pom" is
pointless. Stability for a given release of maven is not particularly
useful when many users are using different versions of maven to build
something.
I think it's common sense tha
On 9-Feb-08, at 12:33 PM, Don Brown wrote:
On 2/10/08, Jason van Zyl <[EMAIL PROTECTED]> wrote:
You're asking for a far more complicated solutions to be implemented
which generally aren't much more helpful. You're also conflating the
solution with what people should do and what they should act
On 9-Feb-08, at 11:55 AM, simon wrote:
On Sat, 2008-02-09 at 09:04 -0800, Jason van Zyl wrote:
On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote:
For me, I am completely aware that I want to lock *everything* down
(including plugins) to have reproducible builds. So marketing,
advertising, pleadi
I think the idea of specifying versions in the "super pom" is
pointless. Stability for a given release of maven is not particularly
useful when many users are using different versions of maven to build
something.
I think it's common sense that the proposed lock down in the super POM is
not the
On 2/10/08, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> You're asking for a far more complicated solutions to be implemented
> which generally aren't much more helpful. You're also conflating the
> solution with what people should do and what they should actually be
> doing. Yes, people should use v
Could we add some SHORT meta-data in the POM to point to a maven superPOM
version ?
By default, use the running maven superPOM, but when set, use the expected
superPOM. Based on this, we could build with maven 2.0.10 a project
designed with maven 2.0.9 superPOM.
Nico.
2008/2/9, Brian E. Fox <[E
On Sat, 2008-02-09 at 09:04 -0800, Jason van Zyl wrote:
> On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote:
> > For me, I am completely aware that I want to lock *everything* down
> > (including plugins) to have reproducible builds. So marketing,
> > advertising, pleading with us, educating us is
On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote:
Brian E. Fox wrote:
We advertise the hell out of it and people will discover it as
they have a
problem that they resolve, can migrate to it as an upgrade process
in their
company environments and we don't screw someone over with our
benevolent
On 9-Feb-08, at 5:53 AM, nicolas de loof wrote:
I have to change my vote to -1 :
Current maven behavior introduces some issues when plugin version is
not
set. Many users got errors with this and learned to use version.
Having maven super-POM set plugin version will make the build depend
Brian E. Fox wrote:
We advertise the hell out of it and people will discover it as they have a
problem that they resolve, can migrate to it as an upgrade process in their
company environments and we don't screw someone over with our benevolent
power.
I think the biggest beef people have is that
>I have to change my vote to -1 :
>Current maven behavior introduces some issues when plugin version is
not
>set. Many users got errors with this and learned to use version.
>Having maven super-POM set plugin version will make the build depend on
>maven version used.
Compare this change to the
>The reality looks different: http://jira.codehaus.org/browse/MNG-3394
>As a prerequisite for the proposed additions to the super POM, this
issue
>should be fixed.
Yes. I moved it to 2.0.9 as this definitely is related.
--Brian
---
>We advertise the hell out of it and people will discover it as they have a
>problem that they resolve, can migrate to it as an upgrade process in their
>company environments and we don't screw someone over with our benevolent
>power.
I think the biggest beef people have is that we are unstable b
+1 in principle.
One thought thoughwhat if we were to add the activeProfile element as it
exists in the settings.xml into the pom.xml and advertise that users can set
something like this in their top level pom.xml:
default-maven-plugin-versioning
This lets the behavior be optiona
simply discuss the ramifications of defaulting the core plugin versions in
the super pom in 2.0 only.
+1, might also spare users from learning yet another concept like
"plugin-packs". If the super POM locks down all plugins that would be
injected by one of the various lifecycle mappings and the
I have to change my vote to -1 :
Current maven behavior introduces some issues when plugin version is not
set. Many users got errors with this and learned to use version.
Having maven super-POM set plugin version will make the build depend on
maven version used.
Simple scenario :
I create a pro
+1
I've allready done similar "fix common plugins version" work in my corporate
POM, with version set for all
org.apache.maven.plugins and many org.codehaus.mojo.
Recent release of surefire plugin demonstrates many users suffering from the
"get latest" plugin policy, and some builds not beeing re
On 8-Feb-08, at 4:52 PM, Carlos Sanchez wrote:
I'm pretty much +1
Another behavior that would change is if I build and install a plugin
in my local repo, it won't be used. I'd have to explicitly set it in
the pom.
Sure, but that's a minor inconvenience for us developing plugins in
the def
I'm pretty much +1
Another behavior that would change is if I build and install a plugin
in my local repo, it won't be used. I'd have to explicitly set it in
the pom.
On Feb 8, 2008 4:41 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> I know it's been discussed before in the context of various othe
42 matches
Mail list logo
