Yes, I had to walk the poms in the rule to see if the version was
specified anywhere. (the model in project always has versions filled in,
even if they aren't actually specified in the poms.) The code stops
walking up the pom tree when there is no parent specified and it doesn't
look in the super p
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
I created a jira for this and will attempt a scan through existing
issues to see how many might be related to this.
So far we've started to go off on tangential other ideas which is good
for 2.1, but I haven't seen any showstopper reason why this could
actually hurt anyone.
-Original Message
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
The documentation you saw is:
- not yet committed
- generated from the plugin module
the documentation in the parent module is 1 year old. and appart from
the descriptor, a bit dated.
I commit now the release is done.
Regards,
Raphaël
2008/2/9, Wendy Smoak <[EMAIL PROTECTED]>:
> On Feb 8, 2008
>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
Rahul Thakur wrote:
Overall I think the core of Continuum should be re-though to be more
pluggable. In particular a workflow engine should be in the middle of
the execution to orchestrate any steps involved with building a
project. This is one of the places where people should be able to plug
Rahul Thakur wrote:
1-2)I would like to bring Guice to the mix. I think it is worth
investigating for Continuum 2.0 - WDYT?
I need a reason to drop the current set of technologies, why is the
new set better etc.
My motivations behind this were:
# leverage Java 5 language and other lib
+1 for the generated file.
Cheers,
Vincent
2008/2/9, Dennis Lundberg <[EMAIL PROTECTED]>:
> I'm preparing for a release of maven-checkstyle and just found a
> hand-written NOTICE.txt file in the svn repo:
>
>
> https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-checkstyle-plugin/src/main
I'm preparing for a release of maven-checkstyle and just found a
hand-written NOTICE.txt file in the svn repo:
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-checkstyle-plugin/src/main/resources/META-INF/NOTICE.txt
Should I update this file (copyright year) or just use the one that
+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
Hi Benjamin,
AbstractProjectInfoReport uses them. We need to refactor these classes
(see MNG-3346)
Cheers,
Vincent
2008/2/8, Benjamin Bentmann <[EMAIL PROTECTED]>:
> Hi,
>
> why do subclasses of AbstractMavenReport have to implement the abstract
> methods getProject() and getSiteRenderer()? I c
On Feb 8, 2008 8:40 PM, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:
> The Maven team is pleased to announce the release of the Maven
> Archetype Plugin, version 2.0-alpha-1
Thanks Raphaël, it's great to see this moving forward. :)
I'm concerned about the lack of documentation. The published docs
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
Hello,
I used to override code-generator plugin dependencies to set a
custom generator version :
example :
org.codehaus.mojo
axistools-maven-plugin
1.2-SNAPSHOT
axis
axis
${axis.version}
+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
31 matches
Mail list logo