+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
Hello,
I used to override code-generator plugin dependencies to set a
custom generator version :
example :
groupIdorg.codehaus.mojo/groupId
artifactIdaxistools-maven-plugin/artifactId
version1.2-SNAPSHOT/version
dependencies
dependency
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
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 are
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
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
+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:
profiles
activeProfiles
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
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 by
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
Rahul Thakur wrote:
snipped
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
+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:
snip comments about plugin packs that I happen to agree with
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
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
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 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
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
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
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
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 not
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
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 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 that
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
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,
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
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
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
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.
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
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
31 matches
Mail list logo
