Brian E. Fox wrote:
>
> That was discussed in the thread I mentioned (below).
>
Thanks for those links Brian. As you say those threads have already come to
a conclusion about the explicit version. I guess this outcome has, however,
exposed a bug ( http://jira.codehaus.org/browse/MNG-3142 MNG-
I've completed pass one of the howto here:
http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test
Eventually this will walk through using the archetypeNG plugin to create
the sample, but several issues stopped me from fully documenting it. I
was able to make it work at one poi
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.tools.plugin.generator.PluginXdocGenerator.filterParame
ters(PluginXdocGenerator.java:253)
at
org.apache.maven.tools.plugin.generator.PluginXdocGenerator.writeGoalPar
ameterTable(PluginXdocGenerator.java:239)
>No complaints with that approach. This does beg the question, however -
>should these default versions already be specified in the Maven 2.0.x
Super
>POM?
That was discussed in the thread I mentioned (below). I personally don't
think the super-pom should presume to know what versions I want becau
In my opinion, yes. In my corporate builds, I lock down ALL versions of
plugins used by the lifecycles or bound in a pom.
-Original Message-
From: Casey Butterworth [mailto:[EMAIL PROTECTED]
Brian - would this approach hold true for all plugins (e.g. clean, compile,
install, etc?)
/qu
In my opinion, yes. In my corporate builds, I lock down ALL versions of
plugins used by the lifecycles or bound in a pom. I do this for 3
reasons: consistency across the development team, reproducibility in the
future, and stability. This allows my CM team to validate a new plugin
before deciding t
Brian E. Fox wrote:
>
> The best practice is to at least specify the versions in pluginManagement.
>
Brian - would this approach hold true for all plugins (e.g. clean, compile,
install, etc?)
--
View this message in context:
http://www.nabble.com/Should-all-plugins-have-an-explicit-version--
The best practice is to at least specify the versions in
pluginManagement.
If you search the archives of this group, you will find lengthy
discussions on this topic. The discussions specifically were around if
we should require a version in 2.1 similar to how dependencies are
handled.
-Origin
In order for the plugin to receive the dependencies, you need to specify
@requiresDependencyResolution [scope] in your mojo annotation. This will
tell maven to ensure everything is resolved and then you will get the
objects you want.
-Original Message-
From: William Ferguson [mailto:[EMAIL
I recently raised issue http://jira.codehaus.org/browse/MNG-3142 MNG-3142
as there is a problem occuring when both a release and snapshot repo are
defined and contain different versions of the same plugin, and LATEST is
used as that plugin's version.
I'm wondering if the parent pom (or wherever
Ok, let me know when you are ready (or just call a vote :)
- Brett
On 09/08/2007, at 5:48 AM, Dennis Lundberg wrote:
Yea, I just have one more thing on my todo list, and that is to
sort the plugin collections (build and reporting). Hopefully the
Plugin class implements comparable, otherwise
As suggested by Eric, I've reposted this query to the developers list.
What lifecycle phase needs to have run in order to get provided scope
dependencies made available in a plugin.
http://maven.apache.org/ref/current/maven-project/apidocs/org/apache/mav
en/project/MavenProject.html#getA
+1 too
Vincent
2007/8/8, Dennis Lundberg <[EMAIL PROTECTED]>:
> Jakarta Commons has moved to TLP and I'd like to update the URLs for the
> Commons projects in the javadoc-plugin configuration.
>
> Other than that I'm +1.
>
> Brett Porter wrote:
> > I'd like to release the parent to capture the ch
Jakarta Commons has moved to TLP and I'd like to update the URLs for the
Commons projects in the javadoc-plugin configuration.
Other than that I'm +1.
Brett Porter wrote:
I'd like to release the parent to capture the changes that have been
made for use in future releases.
From r563503.
Cha
This vote has passed with the following votes:
+1 (binding): Dennis Lundberg, Vincent Siveton, Arnaud Heritier
I'll push out the release.
Dennis Lundberg wrote:
Hi,
I'd like to release maven-docck-plugin 1.0-beta-2. It has been 9 months
since the last release.
Release Notes:
http://jira.co
Yea, I just have one more thing on my todo list, and that is to sort the
plugin collections (build and reporting). Hopefully the Plugin class
implements comparable, otherwise I'll write a small PluginComparator.
Brett Porter wrote:
Hi Dennis,
I see you've made a bunch of changes on the model
On Aug 7, 2007, at 7:20 PM, Brian E. Fox wrote:
Don't they already have access to the sandboxes?
http://docs.codehaus.org/display/MAVEN/The+Maven+Sandbox+is+for+all
+Apache+Committers!
Thanks for the link. I was able to copy maven-idea-plugin to https://
svn.apache.org/repos/asf/maven/sa
On 8 Aug 07, at 12:00 PM 8 Aug 07, Jason Dillon wrote:
Would be really nice to have a shared/common module and components
to handle filtering in the same manner as the maven-resources-
plugin, or really, perhaps with even more control over which tokens
are used and which keys are replaced t
Would be really nice to have a shared/common module and components to
handle filtering in the same manner as the maven-resources-plugin, or
really, perhaps with even more control over which tokens are used and
which keys are replaced too.
It is a very common need, and some times folks rever
19 matches
Mail list logo
