Re: Test failures in maven-source-plugin
I don't think so. sources and ear are for sure good candidates since I wrote those tests. At some point, we decided to use that testing technique and fix remaining issues (namely the local repo first install story). We need to discuss this because I'd like to work on the WAR plugin but I want more tests before changing anything. Stéphane On 3/14/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 3/14/07, Kenney Westerhof [EMAIL PROTECTED] wrote: The problem is that it uses the Verifier to test. The Verifier uses the plugin from the local repo, not the current project. First, mvn clean install -Dmaven.test.skip=true, then mvn test and it'll work. I noticed this today.. there's about 4 plugins that won't install cleanly because of this. Are the four maven-antrun-plugin, maven-eclipse-plugin, maven-plugin-plugin and maven-source-plugin by any chance? Those are the four that are failing in Continuum here. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Request for GSOC project ideas
Hi all, I'm an undergraduate student of the Computer Science and Engineering department at University of Moratuwa, Sri Lnaka. I'm interested in doing a project on Apache/maven for the Google Summer of Code 2007 competition. Currently I'm working as an intern at WSO2 (www.wso2.org) for my industrial training. By now I have been working on Apache Axis2/Java for more than 5 months. I received the Apache Axis2 Committership for implementing JSON Support for Axis2. I have posted an article on this implementation with more details at http://wso2.org/library/768 . I think I have gained reasonable amount of experiences in open source development through working on this Apache projects. So I'm really pleased if someone can suggest me a project idea for GSOC. I think I will be able to do it well if my proposal will be selected. Thanks in advance, Isuru Suriarachchi.
Re: forceVersion for maven-install-plugin?
Jason Dillon wrote:
How does a test repository help? I still need to configure in my
src/it/*/pom.xml the version of the plugin I'm testing.
The latest plugin will be used, which is usually what you're testing.
If the test repository does not contain other versions of the plugin,
the one you're testing will be used.
Maybe I don't understand what you mean by test repositories.
It's basically -Dmaven.repo.local=/tmp/foo/ - an empty repository
only used for the build.
I just want my src/it/*/pom.xml to *always* use the right version of the
plugin (ie. that which was just compiled). I don't want to have to go
updating poms each time I make a new release to use the new version.
This has nothing to do with versions, actually. See below.
And even more important... the install phase happens *before* the
integration-test phase, so I still need a way to get the artifacts
into the repository before my integration-tests fire.
No, install happens AFTER the integration test phase. Maven is very careful
not to make artifacts available that have failing tests.
If test fails, package won't run.
If integration-test fails (after package), install won't run.
Even if you were able to supply/override that testing version,
the tests will fail since the artifact is not yet in the local repository.
If you run again (and have a previous testing version in the local repo),
the version from the local repo will be tested, not the version in target/.
The problem here is MNG-2677 (originally MNG-870): maven can't resolve plugins
from the reactor.
I wrote the maven-it-plugin a while ago (at the time of writing MNG-870),
which will run an embedded maven on src/it/*/pom.xml (which was later turned
into the embedder). This embedded maven would recognize the just built plugin
from the reactor, and not use the version from the local repository.
So even with proper versions you still have a problem, since install is NOT run
before integration-test, and hence the plugin is NOT available in the local
repository.
If you can explain a better way to achieve the desired result I'm all
ears... but so far this is the only solution I can think of which will
work 100% of the time.
The proper way would be to explicitly run the tests against target/${artifact},
and not let it poms resolve it from the local or remote repositories.
So, versions for plugins are not needed in src/it/*/pom.xml. And even if you do
specify one, you can't be certain that the version matches the artifact being
built, and even worse, you can't be certain the artifact just built is being
used.
When MNG-870 was resolved (which later regressed), I succesfully ran integration
tests on the current artifact with the maven-it-plugin, so I think the easiest
and best solution here is to just fix MNG-2677.
-- Kenney
Specifically what I mean is to add an execution of the
maven-install-plugin:install w/forceVersion=testing to the
integration-tests profile in the pre-integration-test phase. So this
can be used with `mvn -Dit` to build and run integration tests, kinda
like this:
http://svn.codehaus.org/mojo/trunk/mojo/groovy-maven-plugin/pom.xml
Though ^^^ does not have any install bits. This works, but will fail if
you don't `mvn install` first to get something into the local repo...
and requires all src/it/*/pom.xml files to have the version of the
plugin. I suppose this could be avoided with parent poms etc... but
these are supposed to be simple stand-along poms... and adding parents
into the mix just complicates things way too much. Much better to
simple get know testing versions of the artifacts into the local repo
_before_ the integration-test phase.
--jason
On Mar 14, 2007, at 5:29 PM, Jason van Zyl wrote:
On 3 Mar 07, at 11:06 PM 3 Mar 07, Jason Dillon wrote:
Any comments on adding a 'forceVersion' param to the
maven-install-plugin, which will for all artifacts (including
attached) to be installed with the given version?
Why not just use test repositories? You can hack this with a settings
but is now easy to do in 2.1 expressly for the purpose of making
testing easier. Do you need to force a version if using test
repositories was simple?
Jason.
I'm thinking this would be really helpful for testing maven plugins,
so that in the pre-integration-test phase, one could use the
m-install-p to force all artifacts to be installed with a 'testing'
version, then in the 'integration-test' phase run the m-invoker-p to
execute a set of maven projects to test/validate the plugin works as
expected, and then once that passes, the normal m-install-p execution
will install the real versions of the artifacts into the repository.
This would allow the src/it/**/pom.xml files to use
versiontesting/version for all of the plugin artifacts, and would
prevent broken artifacts (which don't pass tests) from making it into
the local repo cache (and thus available to other projects).
For example:
8
build
Re: version range question
I'm sorry, what is the problem exactly?
createFromVersionSpec: treats version as a version range, so 2.0.5 is treated
as [2.0.5,).
createFromVersion: treats version as a single pinned version, so 2.0.5 is
treated
as [2.0.5].
So, createFromVersionSpec(2.0.5).containsVersion( new
DefaultArtifactVersion(2.0.6) )
is true since 2.0.6 is in [2.0.5,).
Or am I missing something here?
-- Kenney
Brian E. Fox wrote:
Done. I fixed the problem and added the tests to a branch described
here: http://jira.codehaus.org/browse/MNG-2876
Since it's very core (or maybe not if it's not really used) I'd like
someone to bless it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Wednesday, March 14, 2007 1:06 AM
To: Maven Developers List
Subject: Re: version range question
I would create a jira issue with your tests as unit tests
then search for usages of createFromVersionSpec through the whole
maven and see how it's used
On 3/13/07, Brian E. Fox [EMAIL PROTECTED] wrote:
I'm still having trouble with this. I wrote a sample class to show my
problem. The issue is that all the contains calls are correct except
that a singular version ie 2.0.5 always returns true. Is this an
artifact bug, or am I doing something wrong? According to the javadoc
for the method (shown in my original post below) the singular version
is
allowed as a version range.
Output:
is 2.0.5 contained in 2.0.5 -true CORRECT
is 2.0.5 contained in 2.0.6 -true WRONG
is 2.0.5 contained in [2.0,2.1] -true CORRECT
is 2.0.5 contained in [2.0,2.0.3] -false CORRECT
is 2.0.5 contained in [2.0,2.0.5] -true CORRECT
is 2.0.5 contained in [2.0,2.0.5) -false CORRECT
Source:
/**
*
*/
package org.apache.maven.plugin.enforcer;
import org.apache.maven.artifact.versioning.ArtifactVersion;
import org.apache.maven.artifact.versioning.DefaultArtifactVersion;
import
org.apache.maven.artifact.versioning.InvalidVersionSpecificationExceptio
n;
import org.apache.maven.artifact.versioning.VersionRange;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.MojoFailureException;
/**
* @author brianf
*
*/
public class test
{
public static void main( String[] args )
throws MojoExecutionException, MojoFailureException,
InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion(
2.0.5 );
enforceVersion( 2.0.5, actualVersion );
enforceVersion( 2.0.6, actualVersion );
enforceVersion( [2.0,2.1], actualVersion );
enforceVersion( [2.0,2.0.3], actualVersion );
enforceVersion( [2.0,2.0.5], actualVersion );
enforceVersion( [2.0,2.0.5), actualVersion );
}
public static void enforceVersion( String requiredVersionRange,
ArtifactVersion actualVersion )
throws MojoExecutionException, MojoFailureException,
InvalidVersionSpecificationException
{
VersionRange vr = null;
vr = VersionRange.createFromVersionSpec( requiredVersionRange
);
boolean result = vr.containsVersion( actualVersion );
System.out.println( is +actualVersion+ contained in
+requiredVersionRange+ - + result );
}
}
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 18, 2007 8:15 PM
To: Maven Developers List
Subject: version range question
According to the javadoc for VersionRange.createFromVersionSpec, a
singular version (ie 2.0.4) is allowed:
/**
* Create a version range from a string representation
*
* Some spec examples are
* ul
* licode1.0/code Version 1.0/li
* licode[1.0,2.0)/code Versions 1.0 (included) to 2.0
(not
included)/li
* licode[1.0,2.0]/code Versions 1.0 to 2.0 (both
included)/li
* licode[1.5,)/code Versions 1.5 and higher/li
* licode(,1.0],[1.2,)/code Versions up to 1.0 (included)
and 1.2 or higher/li
* /ul
*
* @param spec string representation of a version or version range
* @return a new [EMAIL PROTECTED] VersionRange} object that represents the
spec
* @throws InvalidVersionSpecificationException
*/
However, if I create a version range using
createFromVersionSpec(2.0.4) and then call,
vr.containsVersion(2.0.5)
the result is true. However, if I use createFromVersion(2.0.4) and
then use vr.containsVersion(2.0.5), I get the expected false.
So is this a bug in the Spec method? What is the difference between
the
two supposed to be? It seems like the fromVersion method can handle
the
spec strings also so I'm confused why there are two.
Thanks,
Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test failures in maven-source-plugin
Wendy Smoak wrote: On 3/14/07, Kenney Westerhof [EMAIL PROTECTED] wrote: The problem is that it uses the Verifier to test. The Verifier uses the plugin from the local repo, not the current project. First, mvn clean install -Dmaven.test.skip=true, then mvn test and it'll work. I noticed this today.. there's about 4 plugins that won't install cleanly because of this. Are the four maven-antrun-plugin, maven-eclipse-plugin, maven-plugin-plugin and maven-source-plugin by any chance? Those are the four that are failing in Continuum here. Yup ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: version range question
The problem is that I assumed 2.0.5 == [2.0.5,). I can understand how it is
when I see it and I can work with that. The problem now is that
createFromVersionSpec doesn't create any restrictions and restrictions.contains
returns true by default. If I add the test as shown below, it fails here:
assertFalse( enforceVersion( 2.0.6, actualVersion ) );
This is saying that 2.0.6 contains 2.0.5 which should be false.
public void testContains() throws InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion( 2.0.5 );
assertTrue( enforceVersion( 2.0.5, actualVersion ) );
assertTrue( enforceVersion( 2.0.4, actualVersion ) );
assertTrue( enforceVersion( [2.0.5], actualVersion ) );
assertFalse( enforceVersion( 2.0.6, actualVersion ) );
assertFalse( enforceVersion( [2.0.6], actualVersion ) );
assertTrue( enforceVersion( [2.0,2.1], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.3], actualVersion ) );
assertTrue( enforceVersion( [2.0,2.0.5], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.5), actualVersion ) );
}
public boolean enforceVersion( String requiredVersionRange, ArtifactVersion
actualVersion )
throws InvalidVersionSpecificationException
{
VersionRange vr = null;
vr = VersionRange.createFromVersionSpec( requiredVersionRange );
return vr.containsVersion( actualVersion );
}
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 5:45 AM
To: Maven Developers List
Subject: Re: version range question
I'm sorry, what is the problem exactly?
createFromVersionSpec: treats version as a version range, so 2.0.5 is treated
as [2.0.5,).
createFromVersion: treats version as a single pinned version, so 2.0.5 is
treated
as [2.0.5].
So, createFromVersionSpec(2.0.5).containsVersion( new
DefaultArtifactVersion(2.0.6) )
is true since 2.0.6 is in [2.0.5,).
Or am I missing something here?
-- Kenney
Brian E. Fox wrote:
Done. I fixed the problem and added the tests to a branch described
here: http://jira.codehaus.org/browse/MNG-2876
Since it's very core (or maybe not if it's not really used) I'd like
someone to bless it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Wednesday, March 14, 2007 1:06 AM
To: Maven Developers List
Subject: Re: version range question
I would create a jira issue with your tests as unit tests
then search for usages of createFromVersionSpec through the whole
maven and see how it's used
On 3/13/07, Brian E. Fox [EMAIL PROTECTED] wrote:
I'm still having trouble with this. I wrote a sample class to show my
problem. The issue is that all the contains calls are correct except
that a singular version ie 2.0.5 always returns true. Is this an
artifact bug, or am I doing something wrong? According to the javadoc
for the method (shown in my original post below) the singular version
is
allowed as a version range.
Output:
is 2.0.5 contained in 2.0.5 -true CORRECT
is 2.0.5 contained in 2.0.6 -true WRONG
is 2.0.5 contained in [2.0,2.1] -true CORRECT
is 2.0.5 contained in [2.0,2.0.3] -false CORRECT
is 2.0.5 contained in [2.0,2.0.5] -true CORRECT
is 2.0.5 contained in [2.0,2.0.5) -false CORRECT
Source:
/**
*
*/
package org.apache.maven.plugin.enforcer;
import org.apache.maven.artifact.versioning.ArtifactVersion;
import org.apache.maven.artifact.versioning.DefaultArtifactVersion;
import
org.apache.maven.artifact.versioning.InvalidVersionSpecificationExceptio
n;
import org.apache.maven.artifact.versioning.VersionRange;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.MojoFailureException;
/**
* @author brianf
*
*/
public class test
{
public static void main( String[] args )
throws MojoExecutionException, MojoFailureException,
InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion(
2.0.5 );
enforceVersion( 2.0.5, actualVersion );
enforceVersion( 2.0.6, actualVersion );
enforceVersion( [2.0,2.1], actualVersion );
enforceVersion( [2.0,2.0.3], actualVersion );
enforceVersion( [2.0,2.0.5], actualVersion );
enforceVersion( [2.0,2.0.5), actualVersion );
}
public static void enforceVersion( String requiredVersionRange,
ArtifactVersion actualVersion )
throws MojoExecutionException, MojoFailureException,
InvalidVersionSpecificationException
{
VersionRange vr = null;
vr = VersionRange.createFromVersionSpec( requiredVersionRange
);
boolean result = vr.containsVersion( actualVersion );
System.out.println( is +actualVersion+ contained in
+requiredVersionRange+ - + result );
}
}
-Original
Re: version range question
Brian E. Fox wrote:
The problem is that I assumed 2.0.5 == [2.0.5,). I can understand how it is when I
see it and I can work with that. The problem now is that createFromVersionSpec doesn't create any
restrictions and restrictions.contains returns true by default. If I add the test as shown below, it fails
here:assertFalse( enforceVersion( 2.0.6, actualVersion ) );
This is saying that 2.0.6 contains 2.0.5 which should be false.
Indeed, my last statement wasn't entirely correct.
2.0.6 is not [2.0.6,). It's merely a suggestion. In maven, the closest
dependency
wins, even if it's an older version. The 2.0.6 is treated as a 'recommended
version',
not the lower limit. So if you want to force versions to be 'at least X',
you'll have to specify version[X,)/version.
I know that's what people *think* versionX/version means, but it doesn't.
I'm not sure if we can change this - a lot of builds will fail, though it'll
certainly
meet expectations better.
-- Kenney
public void testContains() throws InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion( 2.0.5 );
assertTrue( enforceVersion( 2.0.5, actualVersion ) );
assertTrue( enforceVersion( 2.0.4, actualVersion ) );
assertTrue( enforceVersion( [2.0.5], actualVersion ) );
assertFalse( enforceVersion( 2.0.6, actualVersion ) );
assertFalse( enforceVersion( [2.0.6], actualVersion ) );
assertTrue( enforceVersion( [2.0,2.1], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.3], actualVersion ) );
assertTrue( enforceVersion( [2.0,2.0.5], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.5), actualVersion ) );
}
public boolean enforceVersion( String requiredVersionRange, ArtifactVersion
actualVersion )
throws InvalidVersionSpecificationException
{
VersionRange vr = null;
vr = VersionRange.createFromVersionSpec( requiredVersionRange );
return vr.containsVersion( actualVersion );
}
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 5:45 AM
To: Maven Developers List
Subject: Re: version range question
I'm sorry, what is the problem exactly?
createFromVersionSpec: treats version as a version range, so 2.0.5 is treated
as [2.0.5,).
createFromVersion: treats version as a single pinned version, so 2.0.5 is
treated
as [2.0.5].
So, createFromVersionSpec(2.0.5).containsVersion( new
DefaultArtifactVersion(2.0.6) )
is true since 2.0.6 is in [2.0.5,).
Or am I missing something here?
-- Kenney
Brian E. Fox wrote:
Done. I fixed the problem and added the tests to a branch described
here: http://jira.codehaus.org/browse/MNG-2876
Since it's very core (or maybe not if it's not really used) I'd like
someone to bless it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Wednesday, March 14, 2007 1:06 AM
To: Maven Developers List
Subject: Re: version range question
I would create a jira issue with your tests as unit tests
then search for usages of createFromVersionSpec through the whole
maven and see how it's used
On 3/13/07, Brian E. Fox [EMAIL PROTECTED] wrote:
I'm still having trouble with this. I wrote a sample class to show my
problem. The issue is that all the contains calls are correct except
that a singular version ie 2.0.5 always returns true. Is this an
artifact bug, or am I doing something wrong? According to the javadoc
for the method (shown in my original post below) the singular version
is
allowed as a version range.
Output:
is 2.0.5 contained in 2.0.5 -true CORRECT
is 2.0.5 contained in 2.0.6 -true WRONG
is 2.0.5 contained in [2.0,2.1] -true CORRECT
is 2.0.5 contained in [2.0,2.0.3] -false CORRECT
is 2.0.5 contained in [2.0,2.0.5] -true CORRECT
is 2.0.5 contained in [2.0,2.0.5) -false CORRECT
Source:
/**
*
*/
package org.apache.maven.plugin.enforcer;
import org.apache.maven.artifact.versioning.ArtifactVersion;
import org.apache.maven.artifact.versioning.DefaultArtifactVersion;
import
org.apache.maven.artifact.versioning.InvalidVersionSpecificationExceptio
n;
import org.apache.maven.artifact.versioning.VersionRange;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.MojoFailureException;
/**
* @author brianf
*
*/
public class test
{
public static void main( String[] args )
throws MojoExecutionException, MojoFailureException,
InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion(
2.0.5 );
enforceVersion( 2.0.5, actualVersion );
enforceVersion( 2.0.6, actualVersion );
enforceVersion( [2.0,2.1], actualVersion );
enforceVersion( [2.0,2.0.3], actualVersion );
enforceVersion( [2.0,2.0.5], actualVersion );
enforceVersion( [2.0,2.0.5), actualVersion );
}
RE: version range question
Well, I made the change and all the IT tests pass. I'm not surprised because
when I searched for the use of that VersionRange.contains() it's only used in
one place, so it's entirely likely this is not working and no one noticed.
It's easy to tweak my patch so that contains treats 2.0.5 == [2.0.5,), I
just need to change =0 to =0 because I use the compareto() method for singular
versions. Which should it be? The alternative is I just take this contains code
and move it into my plugin to work correctly, but that doesn't do much to solve
the real problem.
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 8:46 AM
To: Maven Developers List
Subject: Re: version range question
Brian E. Fox wrote:
The problem is that I assumed 2.0.5 == [2.0.5,). I can understand how it
is when I see it and I can work with that. The problem now is that
createFromVersionSpec doesn't create any restrictions and
restrictions.contains returns true by default. If I add the test as shown
below, it fails here:assertFalse( enforceVersion( 2.0.6,
actualVersion ) );
This is saying that 2.0.6 contains 2.0.5 which should be false.
Indeed, my last statement wasn't entirely correct.
2.0.6 is not [2.0.6,). It's merely a suggestion. In maven, the closest
dependency
wins, even if it's an older version. The 2.0.6 is treated as a 'recommended
version',
not the lower limit. So if you want to force versions to be 'at least X',
you'll have to specify version[X,)/version.
I know that's what people *think* versionX/version means, but it doesn't.
I'm not sure if we can change this - a lot of builds will fail, though it'll
certainly
meet expectations better.
-- Kenney
public void testContains() throws InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion( 2.0.5 );
assertTrue( enforceVersion( 2.0.5, actualVersion ) );
assertTrue( enforceVersion( 2.0.4, actualVersion ) );
assertTrue( enforceVersion( [2.0.5], actualVersion ) );
assertFalse( enforceVersion( 2.0.6, actualVersion ) );
assertFalse( enforceVersion( [2.0.6], actualVersion ) );
assertTrue( enforceVersion( [2.0,2.1], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.3], actualVersion ) );
assertTrue( enforceVersion( [2.0,2.0.5], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.5), actualVersion ) );
}
public boolean enforceVersion( String requiredVersionRange,
ArtifactVersion actualVersion )
throws InvalidVersionSpecificationException
{
VersionRange vr = null;
vr = VersionRange.createFromVersionSpec( requiredVersionRange );
return vr.containsVersion( actualVersion );
}
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 5:45 AM
To: Maven Developers List
Subject: Re: version range question
I'm sorry, what is the problem exactly?
createFromVersionSpec: treats version as a version range, so 2.0.5 is treated
as [2.0.5,).
createFromVersion: treats version as a single pinned version, so 2.0.5 is
treated
as [2.0.5].
So, createFromVersionSpec(2.0.5).containsVersion( new
DefaultArtifactVersion(2.0.6) )
is true since 2.0.6 is in [2.0.5,).
Or am I missing something here?
-- Kenney
Brian E. Fox wrote:
Done. I fixed the problem and added the tests to a branch described
here: http://jira.codehaus.org/browse/MNG-2876
Since it's very core (or maybe not if it's not really used) I'd like
someone to bless it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Wednesday, March 14, 2007 1:06 AM
To: Maven Developers List
Subject: Re: version range question
I would create a jira issue with your tests as unit tests
then search for usages of createFromVersionSpec through the whole
maven and see how it's used
On 3/13/07, Brian E. Fox [EMAIL PROTECTED] wrote:
I'm still having trouble with this. I wrote a sample class to show my
problem. The issue is that all the contains calls are correct except
that a singular version ie 2.0.5 always returns true. Is this an
artifact bug, or am I doing something wrong? According to the javadoc
for the method (shown in my original post below) the singular version
is
allowed as a version range.
Output:
is 2.0.5 contained in 2.0.5 -true CORRECT
is 2.0.5 contained in 2.0.6 -true WRONG
is 2.0.5 contained in [2.0,2.1] -true CORRECT
is 2.0.5 contained in [2.0,2.0.3] -false CORRECT
is 2.0.5 contained in [2.0,2.0.5] -true CORRECT
is 2.0.5 contained in [2.0,2.0.5) -false CORRECT
Source:
/**
*
*/
package org.apache.maven.plugin.enforcer;
import org.apache.maven.artifact.versioning.ArtifactVersion;
import org.apache.maven.artifact.versioning.DefaultArtifactVersion;
import
Re: Test failures in maven-source-plugin
Stephane Nicoll wrote: I don't think so. sources and ear are for sure good candidates since I wrote those tests. At some point, we decided to use that testing technique and fix remaining issues (namely the local repo first install story). We need to discuss this because I'd like to work on the WAR plugin but I want more tests before changing anything. MNG-2677 -- Kenney Stéphane On 3/14/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 3/14/07, Kenney Westerhof [EMAIL PROTECTED] wrote: The problem is that it uses the Verifier to test. The Verifier uses the plugin from the local repo, not the current project. First, mvn clean install -Dmaven.test.skip=true, then mvn test and it'll work. I noticed this today.. there's about 4 plugins that won't install cleanly because of this. Are the four maven-antrun-plugin, maven-eclipse-plugin, maven-plugin-plugin and maven-source-plugin by any chance? Those are the four that are failing in Continuum here. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: version range question
Brian E. Fox wrote:
Well, I made the change and all the IT tests pass. I'm not surprised because
when I searched for the use of that VersionRange.contains() it's only used in
one place, so it's entirely likely this is not working and no one noticed.
It could very well be that there's no it for it.
Try creating one with this structure:
ROOT/
A/ dep on FOO 1.0 and B
B/ dep on C
C/ dep on FOO 2.0
FOO can be any artifact where a class exists in 2.0 but not in 1.0.
For instance plexus-utils 1.0 and a later version.
C should use a class in FOO 2.0 that's not there in 1.0.
Then maven _should_ use FOO 1.0 for A, B and C, causing C not to compile, if
your patch
is applied. Otherwise, the patch isn't good enough probably becuase there's
other code
that does not honor 2.0.5 NOT being in 2.0.6...
-- Kenney
It's easy to tweak my patch so that contains treats 2.0.5 == [2.0.5,), I just
need to change =0 to =0 because I use the compareto() method for singular versions. Which should
it be? The alternative is I just take this contains code and move it into my plugin to work correctly,
but that doesn't do much to solve the real problem.
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 8:46 AM
To: Maven Developers List
Subject: Re: version range question
Brian E. Fox wrote:
The problem is that I assumed 2.0.5 == [2.0.5,). I can understand how it is when I
see it and I can work with that. The problem now is that createFromVersionSpec doesn't create any
restrictions and restrictions.contains returns true by default. If I add the test as shown below, it fails
here:assertFalse( enforceVersion( 2.0.6, actualVersion ) );
This is saying that 2.0.6 contains 2.0.5 which should be false.
Indeed, my last statement wasn't entirely correct.
2.0.6 is not [2.0.6,). It's merely a suggestion. In maven, the closest
dependency
wins, even if it's an older version. The 2.0.6 is treated as a 'recommended
version',
not the lower limit. So if you want to force versions to be 'at least X',
you'll have to specify version[X,)/version.
I know that's what people *think* versionX/version means, but it doesn't.
I'm not sure if we can change this - a lot of builds will fail, though it'll
certainly
meet expectations better.
-- Kenney
public void testContains() throws InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion( 2.0.5 );
assertTrue( enforceVersion( 2.0.5, actualVersion ) );
assertTrue( enforceVersion( 2.0.4, actualVersion ) );
assertTrue( enforceVersion( [2.0.5], actualVersion ) );
assertFalse( enforceVersion( 2.0.6, actualVersion ) );
assertFalse( enforceVersion( [2.0.6], actualVersion ) );
assertTrue( enforceVersion( [2.0,2.1], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.3], actualVersion ) );
assertTrue( enforceVersion( [2.0,2.0.5], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.5), actualVersion ) );
}
public boolean enforceVersion( String requiredVersionRange, ArtifactVersion
actualVersion )
throws InvalidVersionSpecificationException
{
VersionRange vr = null;
vr = VersionRange.createFromVersionSpec( requiredVersionRange );
return vr.containsVersion( actualVersion );
}
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 5:45 AM
To: Maven Developers List
Subject: Re: version range question
I'm sorry, what is the problem exactly?
createFromVersionSpec: treats version as a version range, so 2.0.5 is treated
as [2.0.5,).
createFromVersion: treats version as a single pinned version, so 2.0.5 is
treated
as [2.0.5].
So, createFromVersionSpec(2.0.5).containsVersion( new
DefaultArtifactVersion(2.0.6) )
is true since 2.0.6 is in [2.0.5,).
Or am I missing something here?
-- Kenney
Brian E. Fox wrote:
Done. I fixed the problem and added the tests to a branch described
here: http://jira.codehaus.org/browse/MNG-2876
Since it's very core (or maybe not if it's not really used) I'd like
someone to bless it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Wednesday, March 14, 2007 1:06 AM
To: Maven Developers List
Subject: Re: version range question
I would create a jira issue with your tests as unit tests
then search for usages of createFromVersionSpec through the whole
maven and see how it's used
On 3/13/07, Brian E. Fox [EMAIL PROTECTED] wrote:
I'm still having trouble with this. I wrote a sample class to show my
problem. The issue is that all the contains calls are correct except
that a singular version ie 2.0.5 always returns true. Is this an
artifact bug, or am I doing something wrong? According to the javadoc
for the method (shown in my original post below) the singular version
is
allowed as a version
maven-assembly-plugin release?
Hi guys, Is there any possibility I can prod you for a release of maven-assembly-plugin 2.2? As far as I can tell, all the SNAPSHOTs it depends on have now been released, it fixes about a bazillion bugs, and the docs on the site have referred to the SNAPSHOT for ages. Cheers, Richard -- Richard van der Hoff [EMAIL PROTECTED] Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-war-plugin - Override classesDirectory
Hi all,
I'm using the maven-war-plugin to generate a war file before the
maven test phase, but the cobertura-maven-plugin change the
classesDirectory to instrument the code and the war plugin don't allow
this. There is any way to make the parameter classesDirectory
overridable?
I'm using the last snapshot of the svn.
[INFO] Instrumentation was successful.
[INFO] [aspectj:test-compile {execution: default}] [INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error configuring: org.apache.maven.plugins:maven-war-plugin.
Reason: ERR
OR: Cannot override read-only parameter: classesDirectory in goal:
war:war [INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error
configuring: org.a pache.maven.plugins:maven-war-plugin. Reason: ERROR:
Cannot override read-only p
arameter: classesDirectory in goal: war:war
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:563)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecy
cle(DefaultLifecycleExecutor.java:891)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(Def
aultLifecycleExecutor.java:734)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:525)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:140)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.PluginConfigurationException: Error
configuri
ng: org.apache.maven.plugins:maven-war-plugin. Reason: ERROR: Cannot
override re ad-only parameter: classesDirectory in goal: war:war
at
org.apache.maven.plugin.DefaultPluginManager.validatePomConfiguration
(DefaultPluginManager.java:848)
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(Defaul
tPluginManager.java:558)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:390)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:534)
... 20 more
[INFO]
[INFO] Total time: 1 minute 47 seconds
[INFO] Finished at: Thu Mar 15 10:05:41 BRT 2007 [INFO] Final Memory:
30M/55M [INFO]
Thanks,
Victor Hugo B. Ramos
Important : This e-mail is intended for the above named only and may be
confidential, proprietary and/or legally privileged. If this has come to
you in error, you must take no action based on it, nor must you copy or
show it to anyone. Please contact the sender and delete the material
from any computer. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updated clover plugin?
Hi Mike, Clover plugin 2.4-SNAPSHOT has a license valid till 30th of January 2008. Maybe this warrants a release of the plugin? http://jira.codehaus.org/browse/MCLOVER? report=com.atlassian.jira.plugin.system.project:roadmap-panel Thanks -Vincent On Mar 8, 2007, at 4:53 PM, Mike Perham wrote: The license for the clover plugin expired some time ago. Is an update in the works? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updated clover plugin?
Personally I believe a release is needed ASAP. Users should not use SNAPSHOTs and no releases work anymore. On 3/15/07, Vincent Massol [EMAIL PROTECTED] wrote: Hi Mike, Clover plugin 2.4-SNAPSHOT has a license valid till 30th of January 2008. Maybe this warrants a release of the plugin? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: version range question
I'll try doing that. Strictly speaking though, I think the only thing
that makes sense is 2.0.5 = [2.0.5]. In fact, the javadoc for
createFromVersionSpec says this:licode1.0/code Version 1.0/li.
Also, when you think about this class by itself, we are testing a range.
How maven decides to handle the results of that test are separate from
how this object should behave. That being said, I do agree we need to be
carefull.
My patch only fixes the contains method because I couldn't fix the
construction of the restrictions without breaking other tests, even
though I believe the root of the problem is the restriction created. The
code is quite clear here:
else
{
version = new DefaultArtifactVersion( process );
restrictions.add( Restriction.EVERYTHING );
}
That the intent is to include everything for a singular version. I think
this should be
else
{
version = new DefaultArtifactVersion( process );
restrictions.add( new
Restriction(process,true,process,true)
}
But doing this breaks other unit tests.
I'll make an IT test and see what happens just patching the contains
method.
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 9:18 AM
To: Maven Developers List
Subject: Re: version range question
Brian E. Fox wrote:
Well, I made the change and all the IT tests pass. I'm not surprised
because when I searched for the use of that VersionRange.contains() it's
only used in one place, so it's entirely likely this is not working and
no one noticed.
It could very well be that there's no it for it.
Try creating one with this structure:
ROOT/
A/ dep on FOO 1.0 and B
B/ dep on C
C/ dep on FOO 2.0
FOO can be any artifact where a class exists in 2.0 but not in 1.0.
For instance plexus-utils 1.0 and a later version.
C should use a class in FOO 2.0 that's not there in 1.0.
Then maven _should_ use FOO 1.0 for A, B and C, causing C not to
compile, if your patch is applied. Otherwise, the patch isn't good
enough probably becuase there's other code that does not honor 2.0.5 NOT
being in 2.0.6...
-- Kenney
It's easy to tweak my patch so that contains treats 2.0.5 ==
[2.0.5,), I just need to change =0 to =0 because I use the
compareto() method for singular versions. Which should it be? The
alternative is I just take this contains code and move it into my plugin
to work correctly, but that doesn't do much to solve the real problem.
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 8:46 AM
To: Maven Developers List
Subject: Re: version range question
Brian E. Fox wrote:
The problem is that I assumed 2.0.5 == [2.0.5,). I can understand
how it is when I see it and I can work with that. The problem now is
that createFromVersionSpec doesn't create any restrictions and
restrictions.contains returns true by default. If I add the test as
shown below, it fails here:assertFalse( enforceVersion( 2.0.6,
actualVersion ) );
This is saying that 2.0.6 contains 2.0.5 which should be false.
Indeed, my last statement wasn't entirely correct.
2.0.6 is not [2.0.6,). It's merely a suggestion. In maven, the
closest dependency wins, even if it's an older version. The 2.0.6 is
treated as a 'recommended version', not the lower limit. So if you
want to force versions to be 'at least X', you'll have to specify
version[X,)/version.
I know that's what people *think* versionX/version means, but it
doesn't.
I'm not sure if we can change this - a lot of builds will fail, though
it'll certainly meet expectations better.
-- Kenney
public void testContains() throws
InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion(
2.0.5 );
assertTrue( enforceVersion( 2.0.5, actualVersion ) );
assertTrue( enforceVersion( 2.0.4, actualVersion ) );
assertTrue( enforceVersion( [2.0.5], actualVersion ) );
assertFalse( enforceVersion( 2.0.6, actualVersion ) );
assertFalse( enforceVersion( [2.0.6], actualVersion ) );
assertTrue( enforceVersion( [2.0,2.1], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.3], actualVersion )
);
assertTrue( enforceVersion( [2.0,2.0.5], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.5), actualVersion )
);
}
public boolean enforceVersion( String requiredVersionRange,
ArtifactVersion actualVersion )
throws InvalidVersionSpecificationException
{
VersionRange vr = null;
vr = VersionRange.createFromVersionSpec( requiredVersionRange
);
return vr.containsVersion( actualVersion );
}
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 5:45 AM
To: Maven Developers List
Re: version range question
I think it makes more sense to let 2.0.5 mean [2.0.5,), not [2.0.5].
If you'd do the latter we'd definitely have a problem. There are lots of
places where maven-model 2.0 is used, and also lots of places where 2.0.3 or
later
is used. Having this restriction will cause maven's build to fail..
So I'd try restriction(process, true, null, false)..
Brian E. Fox wrote:
I'll try doing that. Strictly speaking though, I think the only thing
that makes sense is 2.0.5 = [2.0.5]. In fact, the javadoc for
createFromVersionSpec says this:licode1.0/code Version 1.0/li.
Also, when you think about this class by itself, we are testing a range.
How maven decides to handle the results of that test are separate from
how this object should behave. That being said, I do agree we need to be
carefull.
My patch only fixes the contains method because I couldn't fix the
construction of the restrictions without breaking other tests, even
though I believe the root of the problem is the restriction created. The
code is quite clear here:
else
{
version = new DefaultArtifactVersion( process );
restrictions.add( Restriction.EVERYTHING );
}
That the intent is to include everything for a singular version. I think
this should be
else
{
version = new DefaultArtifactVersion( process );
restrictions.add( new
Restriction(process,true,process,true)
}
But doing this breaks other unit tests.
I'll make an IT test and see what happens just patching the contains
method.
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 9:18 AM
To: Maven Developers List
Subject: Re: version range question
Brian E. Fox wrote:
Well, I made the change and all the IT tests pass. I'm not surprised
because when I searched for the use of that VersionRange.contains() it's
only used in one place, so it's entirely likely this is not working and
no one noticed.
It could very well be that there's no it for it.
Try creating one with this structure:
ROOT/
A/ dep on FOO 1.0 and B
B/ dep on C
C/ dep on FOO 2.0
FOO can be any artifact where a class exists in 2.0 but not in 1.0.
For instance plexus-utils 1.0 and a later version.
C should use a class in FOO 2.0 that's not there in 1.0.
Then maven _should_ use FOO 1.0 for A, B and C, causing C not to
compile, if your patch is applied. Otherwise, the patch isn't good
enough probably becuase there's other code that does not honor 2.0.5 NOT
being in 2.0.6...
-- Kenney
It's easy to tweak my patch so that contains treats 2.0.5 ==
[2.0.5,), I just need to change =0 to =0 because I use the
compareto() method for singular versions. Which should it be? The
alternative is I just take this contains code and move it into my plugin
to work correctly, but that doesn't do much to solve the real problem.
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 8:46 AM
To: Maven Developers List
Subject: Re: version range question
Brian E. Fox wrote:
The problem is that I assumed 2.0.5 == [2.0.5,). I can understand
how it is when I see it and I can work with that. The problem now is
that createFromVersionSpec doesn't create any restrictions and
restrictions.contains returns true by default. If I add the test as
shown below, it fails here:assertFalse( enforceVersion( 2.0.6,
actualVersion ) );
This is saying that 2.0.6 contains 2.0.5 which should be false.
Indeed, my last statement wasn't entirely correct.
2.0.6 is not [2.0.6,). It's merely a suggestion. In maven, the
closest dependency wins, even if it's an older version. The 2.0.6 is
treated as a 'recommended version', not the lower limit. So if you
want to force versions to be 'at least X', you'll have to specify
version[X,)/version.
I know that's what people *think* versionX/version means, but it
doesn't.
I'm not sure if we can change this - a lot of builds will fail, though
it'll certainly meet expectations better.
-- Kenney
public void testContains() throws
InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion(
2.0.5 );
assertTrue( enforceVersion( 2.0.5, actualVersion ) );
assertTrue( enforceVersion( 2.0.4, actualVersion ) );
assertTrue( enforceVersion( [2.0.5], actualVersion ) );
assertFalse( enforceVersion( 2.0.6, actualVersion ) );
assertFalse( enforceVersion( [2.0.6], actualVersion ) );
assertTrue( enforceVersion( [2.0,2.1], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.3], actualVersion )
);
assertTrue( enforceVersion( [2.0,2.0.5], actualVersion ) );
assertFalse( enforceVersion( [2.0,2.0.5), actualVersion )
);
}
public boolean enforceVersion( String requiredVersionRange,
ArtifactVersion actualVersion )
throws
Implemented ClearCase support for checking out from a tag and auto-creation of config specs
Hi Emmanuel and others, I implemented the above mentioned feature. Please have a look at the patch, and apply it. If you apply it, it would be great if you could deploy a new maven-scm SNAPSHOT version to the apache snapshots repository as well. http://jira.codehaus.org/browse/SCM-287 Thanks - Arne -- View this message in context: http://www.nabble.com/Implemented-ClearCase-support-for-checking-out-from-a-tag-and-auto-creation-of-config-specs-tf3408558.html#a9495318 Sent from the Continuum - Dev mailing list archive at Nabble.com.
Re: Implemented ClearCase support for checking out from a tag and auto-creation of config specs
I applied it, it seems to be good but can't test it, I don't have Clearcase. I'll deploy a new maven-scm SNAPSHOT today. Emmanuel ArneD a écrit : Hi Emmanuel and others, I implemented the above mentioned feature. Please have a look at the patch, and apply it. If you apply it, it would be great if you could deploy a new maven-scm SNAPSHOT version to the apache snapshots repository as well. http://jira.codehaus.org/browse/SCM-287 Thanks - Arne
Re: [VOTE] Release maven and plugins parent pom
Brian,
You can see what happens just by running:
mvn -Prelease package
then look at whats in the jars.
On Wednesday 14 March 2007 20:16, Brian E. Fox wrote:
So I can remove this code from my pom then:
Correct, shouldn't be needed.
resources
!-- Include the apache process LICENSE and
NOTICE files.--
!--uncomment for release. Commented out for now
to enable eclipse-plugin to work--
resource
targetPathMETA-INF/targetPath
filteringfalse/filtering
directory${basedir}/directory
includes
includeLICENSE/include
includeNOTICE/include
/includes
/resource
But is this still needed?
Nope. Shouldn't be.
!-- Include super-pom defined main/resources
Removing this section will break the build.
Since we have defined a new build/resources
section for the Apache process LICENSE and
NOTICE
files, this original default section is now
required. --
resource
directory${basedir}/src/main/resources/directory
/resource
Dan
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 14, 2007 7:46 PM
To: dev@maven.apache.org
Subject: Re: [VOTE] Release maven and plugins parent pom
On Wednesday 14 March 2007 18:59, Brian E. Fox wrote:
Is there a way to include notice and license files in the jars by
default?
Well, we could pull the remote-resources plugin out of the release
profile and put it right in the build/plugins section of the pom to
force it to always run. However, there is a bug in it (just fixed
today) that causes issues with SNAPSHOT dependencies. Thus, that
won't
work until we release a new version of the remote-resources.
Right now, the NOTICE and LICENSE files are injected in when run with
the
release profile only. That's actually one reason we didn't discover
the SNAPSHOT issue since the releases, by definition, don't contain
snapshots.
Dan
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 14, 2007 4:15 PM
To: dev@maven.apache.org
Subject: Re: [VOTE] Release maven and plugins parent pom
On Wednesday 14 March 2007 16:05, Carlos Sanchez wrote:
so we use the latest apache parent
If we do, we should update to the latest gpg and remote resource
things as well. Specifically gpg so we don't have to have
passphrases burned into our settings.xml.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Maven PMD Plugin 2.2
I'd like to release version 2.2 of the PMD plugin. It's been over 8 months since the last release and this is a fairly significant improvement addressing 14 JIRA items. Staging area: http://people.apache.org/~dkulp/stage_pmd/ Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-pmd-plugin-2.2/ Release Notes - Maven 2.x Pmd Plugin - Version 2.2 ** Bug * [MPMD-30] - No way to PMD test the test sources in src/test/java * [MPMD-47] - pmd should support multiple source roots * [MPMD-50] - Reports are different depending on the order of files retrieved from the filesystem * [MPMD-51] - Sometimes PMD.xml doesn't contain the class name and this displays null in the verbose mode * [MPMD-52] - XRef lnks do not work with aggregated XRef ** Improvement * [MPMD-28] - Support for multi-projects poms * [MPMD-38] - Add Posibility to excludes files in Cpd * [MPMD-40] - deploy the pmd.xml with site:deploy * [MPMD-44] - Allow to specify the rulesets as described in the docs * [MPMD-46] - Add ability to choose priority for failure * [MPMD-53] - pmd mojos need a skip flag similar to surefire ** New Feature * [MPMD-43] - Add results output to pmd:check * [MPMD-49] - Add results output to cpd:check ** Task * [MPMD-41] - Upgrade to PMD 3.9 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release maven and plugins parent pom
Hi folks!
Having trouble with today's version of maven-release plugin.
Looks like maven-release-manager depends on maven-scm-provider-cvsjava, while
the deployed version is named maven-scm-provider-cvsJava (upper case j).
Isn't that a bug of some sort?
Cheers.
Denis.
-Message d'origine-
De : Daniel Kulp [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 15 mars 2007 16:02
À : dev@maven.apache.org
Objet : Re: [VOTE] Release maven and plugins parent pom
Brian,
You can see what happens just by running:
mvn -Prelease package
then look at whats in the jars.
On Wednesday 14 March 2007 20:16, Brian E. Fox wrote:
So I can remove this code from my pom then:
Correct, shouldn't be needed.
resources
!-- Include the apache process LICENSE
and NOTICE files.--
!--uncomment for release. Commented
out for now to enable
eclipse-plugin to work--
resource
targetPathMETA-INF/targetPath
filteringfalse/filtering
directory${basedir}/directory
includes
includeLICENSE/include
includeNOTICE/include
/includes
/resource
But is this still needed?
Nope. Shouldn't be.
!-- Include super-pom defined main/resources
Removing this section will break the build.
Since we have defined a new build/resources
section for the Apache process LICENSE
and NOTICE
files, this original default section is now
required. --
resource
directory${basedir}/src/main/resources/directory
/resource
Dan
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 14, 2007 7:46 PM
To: dev@maven.apache.org
Subject: Re: [VOTE] Release maven and plugins parent pom
On Wednesday 14 March 2007 18:59, Brian E. Fox wrote:
Is there a way to include notice and license files in the jars by
default?
Well, we could pull the remote-resources plugin out of the release
profile and put it right in the build/plugins section of the pom to
force it to always run. However, there is a bug in it (just fixed
today) that causes issues with SNAPSHOT dependencies. Thus, that
won't
work until we release a new version of the remote-resources.
Right now, the NOTICE and LICENSE files are injected in
when run with
the
release profile only. That's actually one reason we
didn't discover
the SNAPSHOT issue since the releases, by definition, don't contain
snapshots.
Dan
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 14, 2007 4:15 PM
To: dev@maven.apache.org
Subject: Re: [VOTE] Release maven and plugins parent pom
On Wednesday 14 March 2007 16:05, Carlos Sanchez wrote:
so we use the latest apache parent
If we do, we should update to the latest gpg and remote resource
things as well. Specifically gpg so we don't have to have
passphrases burned into our settings.xml.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for GSOC project ideas
check http://wiki.apache.org/general/SummerOfCode2007 On 3/15/07, Isuru Suriarachchi [EMAIL PROTECTED] wrote: Hi all, I'm an undergraduate student of the Computer Science and Engineering department at University of Moratuwa, Sri Lnaka. I'm interested in doing a project on Apache/maven for the Google Summer of Code 2007 competition. Currently I'm working as an intern at WSO2 (www.wso2.org) for my industrial training. By now I have been working on Apache Axis2/Java for more than 5 months. I received the Apache Axis2 Committership for implementing JSON Support for Axis2. I have posted an article on this implementation with more details at http://wso2.org/library/768 . I think I have gained reasonable amount of experiences in open source development through working on this Apache projects. So I'm really pleased if someone can suggest me a project idea for GSOC. I think I will be able to do it well if my proposal will be selected. Thanks in advance, Isuru Suriarachchi. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPOX 1.1.7 ?
OK, it seems to be something that JBoss is doing to get in the way. I used the instructions at http://docs.codehaus.org/display/CONTINUUM/Database+Configuration (with the 8.1 jdbc jar) and was able to get Continuum up and running using jetty. On 3/14/07, Jesse McConnell [EMAIL PROTECTED] wrote: server 8.2.3-1 jdbc version: 8.2-504.jdbc3 (and jdbc4) so I sure hope its not a matter of being that tight :) I'll monkey around a bit more, right now I am just making sure it works with the internal derby jesse On 3/14/07, Thierry Lach [EMAIL PROTECTED] wrote: I ran into something similar some time back. Check to make sure that you're using the same version of the postgres jdbc jar as you are the postgres database. The example on http://docs.codehaus.org/display/CONTINUUM/Database+Configuration uses the 8.0 jar. On 3/14/07, Jesse McConnell [EMAIL PROTECTED] wrote: I am getting issues with starting continuum with the jpox 1.1.7 and postgres myself different stacks though g: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index PROJECTGROUP_BUILDDEFINITIONS_pkey for table PROJECTGROUP_BUILDDEFINITIONS 2007-03-14 12:48:37,539 [main] WARN General- SQL warning: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index PROJECTNOTIFIER_CONFIGURATION_pkey for table PROJECTNOTIFIER_CONFIGURATION 2007-03-14 12:48:37,676 [main] ERROR Schema - An exception was thrown while adding/validating class(es) : ERROR: function information_schema._pg_keypositions() does not exist java.sql.SQLException: ERROR: function information_schema._pg_keypositions() does not exist at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse( QueryExecutorImpl.java:1471) at org.postgresql.core.v3.QueryExecutorImpl.processResults( QueryExecutorImpl.java:1256) at org.postgresql.core.v3.QueryExecutorImpl.execute( QueryExecutorImpl.java:175) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute( AbstractJdbc2Statement.java:389) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags( AbstractJdbc2Statement.java:314) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery( AbstractJdbc2Statement.java:221) at org.postgresql.jdbc2.AbstractJdbc2DatabaseMetaData.getImportedExportedKeys (AbstractJdbc2DatabaseMetaData.java:3237) at org.postgresql.jdbc2.AbstractJdbc2DatabaseMetaData.getImportedKeys( AbstractJdbc2DatabaseMetaData.java:3533) at org.jpox.store.rdbms.RDBMSStoreHelper.getForeignKeyInfoForTable (RDBMSStoreHelper.java:376) at org.jpox.store.rdbms.table.TableImpl.getExistingForeignKeys ( TableImpl.java:937) at org.jpox.store.rdbms.table.TableImpl.validateForeignKeys( TableImpl.java:421) at org.jpox.store.rdbms.table.TableImpl.validateConstraints( TableImpl.java:394) at org.jpox.store.rdbms.table.ClassTable.validateConstraints( ClassTable.java:2875) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation( RDBMSManager.java:3110) On 3/14/07, Thierry Lach [EMAIL PROTECTED] wrote: Yeah, that was my thought also. On 3/14/07, Jesse McConnell [EMAIL PROTECTED] wrote: have you tried it with postgres outside of jboss? I want to narrow down the factors here On 3/14/07, Thierry Lach [EMAIL PROTECTED] wrote: That's right. I knew that patch for transaction levels didn't solve it on its own, so my hopes got up with the mention of JPOX 1.1.7 and postgres last week. On 3/13/07, Jesse McConnell [EMAIL PROTECTED] wrote: I set the transaction lvls to READ_COMMITTED as well, so that didn't fix you either huh? hrm On 3/13/07, Thierry Lach [EMAIL PROTECTED] wrote: JPOX 1.1.7 doesn't correct the problems with Postgres. I've added an updated stack trace to http://jira.codehaus.org/browse/CONTINUUM-1181 On 3/13/07, Jesse McConnell [EMAIL PROTECTED] wrote: yes, and I setup the bundled for m2 and got them into place about an hour ago...will be synced into the main repos sometime soon jesse On 3/13/07, Thierry Lach [EMAIL PROTECTED] wrote: Did JPOX 1.1.7 get released yesterday? On 3/7/07, Erik Bengtson [EMAIL PROTECTED] wrote: FYI, JPOX 1.1.7 will be released next monday. It fixes the issue with postgres. You can try it out, if you like, before we release. http://www.jpox.org/downloads/maven/jpox/jars/jpox-1.1-SNAPSHOT.jar Regards Quoting Jesse McConnell [EMAIL PROTECTED]: Ok, well the little poll thread I made seemed to be strongly in favor of
Re: [VOTE] Release maven and plugins parent pom
I deployed a new version of maven-scm-provider-cvsjava without the uppercase,
sorry.
Emmanuel
Cabasson Denis a écrit :
Hi folks!
Having trouble with today's version of maven-release plugin.
Looks like maven-release-manager depends on maven-scm-provider-cvsjava, while the deployed version is named maven-scm-provider-cvsJava (upper case j).
Isn't that a bug of some sort?
Cheers.
Denis.
-Message d'origine-
De : Daniel Kulp [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 15 mars 2007 16:02
À : dev@maven.apache.org
Objet : Re: [VOTE] Release maven and plugins parent pom
Brian,
You can see what happens just by running:
mvn -Prelease package
then look at whats in the jars.
On Wednesday 14 March 2007 20:16, Brian E. Fox wrote:
So I can remove this code from my pom then:
Correct, shouldn't be needed.
resources
!-- Include the apache process LICENSE
and NOTICE files.--
!--uncomment for release. Commented
out for now to enable
eclipse-plugin to work--
resource
targetPathMETA-INF/targetPath
filteringfalse/filtering
directory${basedir}/directory
includes
includeLICENSE/include
includeNOTICE/include
/includes
/resource
But is this still needed?
Nope. Shouldn't be.
!-- Include super-pom defined main/resources
Removing this section will break the build.
Since we have defined a new build/resources
section for the Apache process LICENSE
and NOTICE
files, this original default section is now
required. --
resource
directory${basedir}/src/main/resources/directory
/resource
Dan
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 14, 2007 7:46 PM
To: dev@maven.apache.org
Subject: Re: [VOTE] Release maven and plugins parent pom
On Wednesday 14 March 2007 18:59, Brian E. Fox wrote:
Is there a way to include notice and license files in the jars by
default?
Well, we could pull the remote-resources plugin out of the release
profile and put it right in the build/plugins section of the pom to
force it to always run. However, there is a bug in it (just fixed
today) that causes issues with SNAPSHOT dependencies. Thus, that
won't
work until we release a new version of the remote-resources.
Right now, the NOTICE and LICENSE files are injected in
when run with
the
release profile only. That's actually one reason we
didn't discover
the SNAPSHOT issue since the releases, by definition, don't contain
snapshots.
Dan
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 14, 2007 4:15 PM
To: dev@maven.apache.org
Subject: Re: [VOTE] Release maven and plugins parent pom
On Wednesday 14 March 2007 16:05, Carlos Sanchez wrote:
so we use the latest apache parent
If we do, we should update to the latest gpg and remote resource
things as well. Specifically gpg so we don't have to have
passphrases burned into our settings.xml.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPOX 1.1.7 ?
I've posted a patch to JIRA that enables (at least for me, using postgres 8.1) running continuum against postgres using the built-in jetty. It should be very simple to add support for a different version of postgres also by cloning the profile. On 3/15/07, Thierry Lach [EMAIL PROTECTED] wrote: OK, it seems to be something that JBoss is doing to get in the way. I used the instructions at http://docs.codehaus.org/display/CONTINUUM/Database+Configuration (with the 8.1 jdbc jar) and was able to get Continuum up and running using jetty. On 3/14/07, Jesse McConnell [EMAIL PROTECTED] wrote: server 8.2.3-1 jdbc version: 8.2-504.jdbc3 (and jdbc4) so I sure hope its not a matter of being that tight :) I'll monkey around a bit more, right now I am just making sure it works with the internal derby jesse On 3/14/07, Thierry Lach [EMAIL PROTECTED] wrote: I ran into something similar some time back. Check to make sure that you're using the same version of the postgres jdbc jar as you are the postgres database. The example on http://docs.codehaus.org/display/CONTINUUM/Database+Configuration uses the 8.0 jar. On 3/14/07, Jesse McConnell [EMAIL PROTECTED] wrote: I am getting issues with starting continuum with the jpox 1.1.7 and postgres myself different stacks though g: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index PROJECTGROUP_BUILDDEFINITIONS_pkey for table PROJECTGROUP_BUILDDEFINITIONS 2007-03-14 12:48:37,539 [main] WARN General- SQL warning: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index PROJECTNOTIFIER_CONFIGURATION_pkey for table PROJECTNOTIFIER_CONFIGURATION 2007-03-14 12:48:37,676 [main] ERROR Schema - An exception was thrown while adding/validating class(es) : ERROR: function information_schema._pg_keypositions() does not exist java.sql.SQLException: ERROR: function information_schema._pg_keypositions() does not exist at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse ( QueryExecutorImpl.java:1471) at org.postgresql.core.v3.QueryExecutorImpl.processResults( QueryExecutorImpl.java:1256) at org.postgresql.core.v3.QueryExecutorImpl.execute ( QueryExecutorImpl.java:175) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute( AbstractJdbc2Statement.java:389) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags ( AbstractJdbc2Statement.java:314) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery( AbstractJdbc2Statement.java:221) at org.postgresql.jdbc2.AbstractJdbc2DatabaseMetaData.getImportedExportedKeys (AbstractJdbc2DatabaseMetaData.java:3237) at org.postgresql.jdbc2.AbstractJdbc2DatabaseMetaData.getImportedKeys( AbstractJdbc2DatabaseMetaData.java:3533) at org.jpox.store.rdbms.RDBMSStoreHelper.getForeignKeyInfoForTable (RDBMSStoreHelper.java:376) at org.jpox.store.rdbms.table.TableImpl.getExistingForeignKeys( TableImpl.java:937) at org.jpox.store.rdbms.table.TableImpl.validateForeignKeys( TableImpl.java:421) at org.jpox.store.rdbms.table.TableImpl.validateConstraints( TableImpl.java :394) at org.jpox.store.rdbms.table.ClassTable.validateConstraints ( ClassTable.java:2875) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation( RDBMSManager.java:3110) On 3/14/07, Thierry Lach [EMAIL PROTECTED] wrote: Yeah, that was my thought also. On 3/14/07, Jesse McConnell [EMAIL PROTECTED] wrote: have you tried it with postgres outside of jboss? I want to narrow down the factors here On 3/14/07, Thierry Lach [EMAIL PROTECTED] wrote: That's right. I knew that patch for transaction levels didn't solve it on its own, so my hopes got up with the mention of JPOX 1.1.7 and postgres last week. On 3/13/07, Jesse McConnell [EMAIL PROTECTED] wrote: I set the transaction lvls to READ_COMMITTED as well, so that didn't fix you either huh? hrm On 3/13/07, Thierry Lach [EMAIL PROTECTED] wrote: JPOX 1.1.7 doesn't correct the problems with Postgres. I've added an updated stack trace to http://jira.codehaus.org/browse/CONTINUUM-1181 On 3/13/07, Jesse McConnell [EMAIL PROTECTED] wrote: yes, and I setup the bundled for m2 and got them into place about an hour ago...will be synced into the main repos sometime soon jesse On 3/13/07, Thierry Lach [EMAIL PROTECTED] wrote: Did JPOX 1.1.7 get released yesterday? On 3/7/07, Erik Bengtson [EMAIL PROTECTED] wrote: FYI, JPOX 1.1.7 will be released next monday. It fixes the
Re: [VOTE] Release Maven PMD Plugin 2.2
+1 On 3/15/07, Daniel Kulp [EMAIL PROTECTED] wrote: I'd like to release version 2.2 of the PMD plugin. It's been over 8 months since the last release and this is a fairly significant improvement addressing 14 JIRA items. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
Of the unresolved issues for 1.1-alpha-any, 108 of them are against some version of continuum 1.0 and might not apply to continuum-1.1, but someone is going to have to verify that. On 3/13/07, Brett Porter [EMAIL PROTECTED] wrote: On 12/03/2007, at 7:35 AM, Jesse McConnell wrote: On 13/03/2007, at 10:31 AM, Carlos Sanchez wrote: These are the numbers I see in jira right now 1.1-alpha-1 11 1.1-alpha-2 72 1.1-alpha-# 156
maven-metadata.xml in version level repository directory?
Hi, Just wondering if there is a purpose to having maven-metadata.xml in the version directories (The directories that also contain the pom for the project) of the maven repository? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-metadata.xml in version level repository directory?
It's only available in snapshot version directories and contains a list of all the snapshot versions there and names the latest version. So it's useful for snapshots. Ole Ersoy wrote: Hi, Just wondering if there is a purpose to having maven-metadata.xml in the version directories (The directories that also contain the pom for the project) of the maven repository? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forceVersion for maven-install-plugin?
On Mar 15, 2007, at 2:38 AM, Kenney Westerhof wrote:
Jason Dillon wrote:
How does a test repository help? I still need to configure in my
src/it/*/pom.xml the version of the plugin I'm testing.
The latest plugin will be used, which is usually what you're testing.
If the test repository does not contain other versions of the plugin,
the one you're testing will be used.
Yes, I know... *BUT* that means the current version must be
configured in the src/it/* poms... which I do not want to have to
maintain/update. And when there is no artifact for that version
already in the repo then execution of src/it will fail when executed
from the integration-test phase.
Maybe I don't understand what you mean by test repositories.
It's basically -Dmaven.repo.local=/tmp/foo/ - an empty repository
only used for the build.
Right, that doesn't help solve any problem.
I just want my src/it/*/pom.xml to *always* use the right version
of the plugin (ie. that which was just compiled). I don't want to
have to go updating poms each time I make a new release to use the
new version.
This has nothing to do with versions, actually. See below.
See comment above... it has everything to do with versions. :-P
And even more important... the install phase happens *before*
the integration-test phase, so I still need a way to get the
artifacts into the repository before my integration-tests fire.
No, install happens AFTER the integration test phase.
Right, I mistyped that sorry.
Maven is very careful
not to make artifacts available that have failing tests.
If test fails, package won't run.
If integration-test fails (after package), install won't run.
Right... and I like that *feature* but to run integration tests my
plugin I need it to be in the repository so it will resolve...
Even if you were able to supply/override that testing version,
the tests will fail since the artifact is not yet in the local
repository.
If you run again (and have a previous testing version in the local
repo),
the version from the local repo will be tested, not the version in
target/.
Um... no... the build compiles stuff, then makes a jar, then installs
the artifact into the repo with a testing version for all its
artifacts, then runs integration-tests, where all child poms use
testing as the plugins version, if that passes, then the normal
install:install happens which puts the _real_ version into the repo,
else per-normal if the integration-tests failed, no _real_ version is
installed into the local repo.
The problem here is MNG-2677 (originally MNG-870): maven can't
resolve plugins
from the reactor.
Um... no... I agree MNG-2677 is a problem... and I'm still waiting
for that to get fixed for the Geronimo build... but that is *not* the
problem here. src/it/* tests are *not* run from the reactor, nor do
I want them to be run from the reactor.
I wrote the maven-it-plugin a while ago (at the time of writing
MNG-870),
which will run an embedded maven on src/it/*/pom.xml (which was
later turned
into the embedder). This embedded maven would recognize the just
built plugin
from the reactor, and not use the version from the local repository.
I'm using the maven-invoker-plugin and aside from this version issue
I'm really happy with it.
So even with proper versions you still have a problem, since
install is NOT run
before integration-test, and hence the plugin is NOT available in
the local
repository.
Um right... which is why forceVersion is needed here ;-)
If you can explain a better way to achieve the desired result I'm
all ears... but so far this is the only solution I can think of
which will work 100% of the time.
The proper way would be to explicitly run the tests against target/$
{artifact},
and not let it poms resolve it from the local or remote repositories.
Um... no... these are *integration tests* they are meant to test/
verify that integration with Maven works. And to do that, the
artifacts being tested need to get picked up/configured in the normal
way.
So, versions for plugins are not needed in src/it/*/pom.xml. And
even if you do
specify one, you can't be certain that the version matches the
artifact being
built, and even worse, you can't be certain the artifact just built
is being used.
Um... I don't get what you mean here at all... by using forceVersion,
running that in pre-integration-test, I can be 100% certain that the
code being tested *is* the code that was just built.
* * *
I'm happy to keep talking about this... and maybe I can convince you/
someone that this is the simplest solution... though I suppose at the
end of the day if the Maven dev team isn't interested in applying the
patch I made, I will be forced to make a new plugin to do the same
thing... which I'd like to avoid.
--jason
-
To unsubscribe, e-mail: [EMAIL
Re: Preparing for continuum-1.1-alpha-1
yes, you are also correct on that, great point On 3/15/07, Thierry Lach [EMAIL PROTECTED] wrote: Of the unresolved issues for 1.1-alpha-any, 108 of them are against some version of continuum 1.0 and might not apply to continuum-1.1, but someone is going to have to verify that. On 3/13/07, Brett Porter [EMAIL PROTECTED] wrote: On 12/03/2007, at 7:35 AM, Jesse McConnell wrote: On 13/03/2007, at 10:31 AM, Carlos Sanchez wrote: These are the numbers I see in jira right now 1.1-alpha-1 11 1.1-alpha-2 72 1.1-alpha-# 156 -- jesse mcconnell [EMAIL PROTECTED]
Re: maven-metadata.xml in version level repository directory?
I mirrored a repository, and from what I can see a lot of the non-snapshot version directories have the maven-metadata.xml as well. Also, since the snapshot version is contained in maven-metadata.xml in at the artifactId level, should we be duplicating it at the version level? After all the same info is also in the pom. So now it's in 3 different places. Thoughts? Thanks, - Ole Kenney Westerhof wrote: It's only available in snapshot version directories and contains a list of all the snapshot versions there and names the latest version. So it's useful for snapshots. Ole Ersoy wrote: Hi, Just wondering if there is a purpose to having maven-metadata.xml in the version directories (The directories that also contain the pom for the project) of the maven repository? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-assembly-plugin release?
I'd really like to see this as well, I just don't have the time to start looking at it and learning that code right now. :-( It's a much bigger chunk of code than the plugins I've been working on. About 1/2 of the projects I'm looking at use the 2.2-SNAPSHOT version due to bugs in 2.1.That tells me it really needs to be released. I guess the question is, of the 21 open items for 2.2, how many of them could be pushed to 2.3 or 2.2.1? Dan On Thursday 15 March 2007 09:28, Richard van der Hoff wrote: Hi guys, Is there any possibility I can prod you for a release of maven-assembly-plugin 2.2? As far as I can tell, all the SNAPSHOTs it depends on have now been released, it fixes about a bazillion bugs, and the docs on the site have referred to the SNAPSHOT for ages. Cheers, Richard -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Maven PMD Plugin 2.2
We are having trouble with the failurePriority in this version. We have been running a snapshot from when I added that feature. Do you know if anything changed? -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 11:20 AM To: Maven Developers List Subject: [VOTE] Release Maven PMD Plugin 2.2 I'd like to release version 2.2 of the PMD plugin. It's been over 8 months since the last release and this is a fairly significant improvement addressing 14 JIRA items. Staging area: http://people.apache.org/~dkulp/stage_pmd/ Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-pmd-plugin-2.2/ Release Notes - Maven 2.x Pmd Plugin - Version 2.2 ** Bug * [MPMD-30] - No way to PMD test the test sources in src/test/java * [MPMD-47] - pmd should support multiple source roots * [MPMD-50] - Reports are different depending on the order of files retrieved from the filesystem * [MPMD-51] - Sometimes PMD.xml doesn't contain the class name and this displays null in the verbose mode * [MPMD-52] - XRef lnks do not work with aggregated XRef ** Improvement * [MPMD-28] - Support for multi-projects poms * [MPMD-38] - Add Posibility to excludes files in Cpd * [MPMD-40] - deploy the pmd.xml with site:deploy * [MPMD-44] - Allow to specify the rulesets as described in the docs * [MPMD-46] - Add ability to choose priority for failure * [MPMD-53] - pmd mojos need a skip flag similar to surefire ** New Feature * [MPMD-43] - Add results output to pmd:check * [MPMD-49] - Add results output to cpd:check ** Task * [MPMD-41] - Upgrade to PMD 3.9 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
incubator m2 repository
Just to let everyone know, there is a long thread about the incubator M2 repository on general@incubator.apache.org: http://mail-archives.apache.org/mod_mbox/incubator-general/200703.mbox/31cc37360703140920h6a601b57gbb86ff0cd5e8049b%40mail.gmail.com Since this affects Maven users as well as projects like NMaven, it would be good to get other peoples input, especially those that run the central repository. The other complication will be if they decide to remove it, we'll have to merge it into the ibiblio sync respository. Are the tools ready for that? -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Maven PMD Plugin 2.2
+1 we can't reproduce the initial errors and everything looks good. -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 3:42 PM To: Maven Developers List Subject: RE: [VOTE] Release Maven PMD Plugin 2.2 We are having trouble with the failurePriority in this version. We have been running a snapshot from when I added that feature. Do you know if anything changed? -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 11:20 AM To: Maven Developers List Subject: [VOTE] Release Maven PMD Plugin 2.2 I'd like to release version 2.2 of the PMD plugin. It's been over 8 months since the last release and this is a fairly significant improvement addressing 14 JIRA items. Staging area: http://people.apache.org/~dkulp/stage_pmd/ Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-pmd-plugin-2.2/ Release Notes - Maven 2.x Pmd Plugin - Version 2.2 ** Bug * [MPMD-30] - No way to PMD test the test sources in src/test/java * [MPMD-47] - pmd should support multiple source roots * [MPMD-50] - Reports are different depending on the order of files retrieved from the filesystem * [MPMD-51] - Sometimes PMD.xml doesn't contain the class name and this displays null in the verbose mode * [MPMD-52] - XRef lnks do not work with aggregated XRef ** Improvement * [MPMD-28] - Support for multi-projects poms * [MPMD-38] - Add Posibility to excludes files in Cpd * [MPMD-40] - deploy the pmd.xml with site:deploy * [MPMD-44] - Allow to specify the rulesets as described in the docs * [MPMD-46] - Add ability to choose priority for failure * [MPMD-53] - pmd mojos need a skip flag similar to surefire ** New Feature * [MPMD-43] - Add results output to pmd:check * [MPMD-49] - Add results output to cpd:check ** Task * [MPMD-41] - Upgrade to PMD 3.9 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: incubator m2 repository
One question I have ... Do you want to identify the incubating projects on central in any way? A groupId prefix of org.apache.incubating.* for example? - Joakim Daniel Kulp wrote: Just to let everyone know, there is a long thread about the incubator M2 repository on general@incubator.apache.org: http://mail-archives.apache.org/mod_mbox/incubator-general/200703.mbox/31cc37360703140920h6a601b57gbb86ff0cd5e8049b%40mail.gmail.com Since this affects Maven users as well as projects like NMaven, it would be good to get other peoples input, especially those that run the central repository. The other complication will be if they decide to remove it, we'll have to merge it into the ibiblio sync respository. Are the tools ready for that? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r518445 - in /maven/core-integration-testing/trunk/core-integration-tests/src/test: java/org/apache/maven/integrationtests/ resources/it0118-attachedartifactinreactor/ resources/it0118
Are these integration tests that use the MDEP plugin? Don't put them
in the ITs if they are plugin specific.
We need to stop using production plugins in the ITs.
Jason.
On 14 Mar 07, at 10:34 PM 14 Mar 07, [EMAIL PROTECTED] wrote:
Author: brianf
Date: Wed Mar 14 19:34:52 2007
New Revision: 518445
URL: http://svn.apache.org/viewvc?view=revrev=518445
Log:
added tests that are commented out for MDEP-44 and MDEP-66
Added:
maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/one/
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/one/pom.xml
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/pom.xml
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/two/
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/two/pom.xml
Modified:
maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/IntegrationTestSuite.java
Modified: maven/core-integration-testing/trunk/core-integration-
tests/src/test/java/org/apache/maven/integrationtests/
IntegrationTestSuite.java
URL: http://svn.apache.org/viewvc/maven/core-integration-testing/
trunk/core-integration-tests/src/test/java/org/apache/maven/
integrationtests/IntegrationTestSuite.java?
view=diffrev=518445r1=518444r2=518445
==
--- maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
IntegrationTestSuite.java (original)
+++ maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
IntegrationTestSuite.java Wed Mar 14 19:34:52 2007
@@ -133,6 +133,7 @@
suite.addTestSuite
( MavenIT0111PluginsThatRequireAResourceFromAnExtensionTest.class );
suite.addTestSuite
( MavenIT0112ExtensionsThatDragDependencies.class );
suite.addTestSuite
( MavenIT0113ServerAuthzAvailableToWagonMgrInPlugin.class );
+//suite.addTestSuite
( MavenIT0118AttachedArtifactsInReactor.class );
return suite;
}
}
Added: maven/core-integration-testing/trunk/core-integration-tests/
src/test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java
URL: http://svn.apache.org/viewvc/maven/core-integration-testing/
trunk/core-integration-tests/src/test/java/org/apache/maven/
integrationtests/MavenIT0118AttachedArtifactsInReactor.java?
view=autorev=518445
==
--- maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java (added)
+++ maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java Wed Mar 14 19:34:52 2007
@@ -0,0 +1,31 @@
+package org.apache.maven.integrationtests;
+
+import java.io.File;
+import java.util.List;
+import java.util.ArrayList;
+
+import org.apache.maven.it.Verifier;
+import org.apache.maven.it.util.ResourceExtractor;
+
+public class MavenIT0118AttachedArtifactsInReactor
+extends AbstractMavenIntegrationTestCase
+{
+public void testit0118()
+throws Exception
+{
+File testDir =
+ResourceExtractor.simpleExtractResources( getClass(),
/it0118-attachedartifactinreactor );
+
+Verifier verifier;
+
+// Install the parent POM
+verifier = new Verifier( testDir.getAbsolutePath() );
+verifier.deleteArtifact( org.apache.maven.its.it0118,
parent, 1.0, pom );
+verifier.deleteArtifact( org.apache.maven.its.it0118,
one, 1.0, jar );
+verifier.deleteArtifact( org.apache.maven.its.it0118,
two, 1.0, pom );
+List cliOptions = new ArrayList();
+verifier.executeGoal( package );
+verifier.verifyErrorFreeLog();
+verifier.resetStreams();
+}
+}
Added: maven/core-integration-testing/trunk/core-integration-tests/
src/test/resources/it0118-attachedartifactinreactor/one/pom.xml
URL: http://svn.apache.org/viewvc/maven/core-integration-testing/
trunk/core-integration-tests/src/test/resources/it0118-
attachedartifactinreactor/one/pom.xml?view=autorev=518445
==
---
Re: incubator m2 repository
Joakim, The current practice (always subject to change at apache) is to use version numbers with incubator or incubating in the name. For example: 2.0-incubator-M2 There has been talks about using a groupId, but the general consensus has been that if it's in the version, it's unnecessary and it makes it harder for dependents to migrate after the project graduates. They can just update their dependencyManagement section of their top level pom and not go through bunches of child poms to change groupId's. In anycase, I just wanted folks here to be aware of the discussions going on. Dan On Thursday 15 March 2007 17:37, Joakim Erdfelt wrote: One question I have ... Do you want to identify the incubating projects on central in any way? A groupId prefix of org.apache.incubating.* for example? - Joakim Daniel Kulp wrote: Just to let everyone know, there is a long thread about the incubator M2 repository on general@incubator.apache.org: http://mail-archives.apache.org/mod_mbox/incubator-general/200703.mb ox/31cc37360703140920h6a601b57gbb86ff0cd5e8049b%40mail.gmail.com Since this affects Maven users as well as projects like NMaven, it would be good to get other peoples input, especially those that run the central repository. The other complication will be if they decide to remove it, we'll have to merge it into the ibiblio sync respository. Are the tools ready for that? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site failures using -Preporting
Daniel, I can't get the trunk for the Checkstyle plugin to work. Downgrading to a previous release like 2.1 or 2.0 works though. Daniel Kulp wrote: Brian, Two things to try: 1) Remove your local copy of the checkstyle plugin and force it to re-download. 2) Rebuild checkstyle based on trunk. I think I fixed this on Monday. Dan On Wednesday 14 March 2007 20:15, Brian E. Fox wrote: I'm getting this on several plugins when generating the site with -Preporting: [INFO] Generate Checkstyle report. [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Error during page generation Embedded error: Error rendering Maven report: Unable to process null config loca tion. [INFO] -- -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- I thought the -Preporting when away with the surrogate parent? If I gen the site without it, most of the reports are not available. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven PMD Plugin 2.2
+1 On 15 Mar 07, at 5:14 PM 15 Mar 07, Brian E. Fox wrote: +1 we can't reproduce the initial errors and everything looks good. -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 3:42 PM To: Maven Developers List Subject: RE: [VOTE] Release Maven PMD Plugin 2.2 We are having trouble with the failurePriority in this version. We have been running a snapshot from when I added that feature. Do you know if anything changed? -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 11:20 AM To: Maven Developers List Subject: [VOTE] Release Maven PMD Plugin 2.2 I'd like to release version 2.2 of the PMD plugin. It's been over 8 months since the last release and this is a fairly significant improvement addressing 14 JIRA items. Staging area: http://people.apache.org/~dkulp/stage_pmd/ Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-pmd- plugin-2.2/ Release Notes - Maven 2.x Pmd Plugin - Version 2.2 ** Bug * [MPMD-30] - No way to PMD test the test sources in src/test/java * [MPMD-47] - pmd should support multiple source roots * [MPMD-50] - Reports are different depending on the order of files retrieved from the filesystem * [MPMD-51] - Sometimes PMD.xml doesn't contain the class name and this displays null in the verbose mode * [MPMD-52] - XRef lnks do not work with aggregated XRef ** Improvement * [MPMD-28] - Support for multi-projects poms * [MPMD-38] - Add Posibility to excludes files in Cpd * [MPMD-40] - deploy the pmd.xml with site:deploy * [MPMD-44] - Allow to specify the rulesets as described in the docs * [MPMD-46] - Add ability to choose priority for failure * [MPMD-53] - pmd mojos need a skip flag similar to surefire ** New Feature * [MPMD-43] - Add results output to pmd:check * [MPMD-49] - Add results output to cpd:check ** Task * [MPMD-41] - Upgrade to PMD 3.9 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M2] is -DgroupId forbidden ?
Hi, When i call a mojo i have with -DgroupId=XX, i got a validation error on a dependent pom. when i run -DgroupIdX=XX, i got my result. I have the same result defining a groupId parameter or not in the mojo. And i also have the same result when call in the mojo in a project's dir on in an empty dir. the only difference i see between my plugin and archetype plugin don't have this problem is that my plugin depends on maven 2.0.5 artifacts and the archetype plugin depends on maven 2.0. Is this a bug ? Am i missing something obvious ? In advance, thanks for any help. Regards, Raphaël
Re: incubator m2 repository
On Mar 15, 2007, at 2:51 PM, Daniel Kulp wrote: Joakim, The current practice (always subject to change at apache) is to use version numbers with incubator or incubating in the name. For example: 2.0-incubator-M2 There has been talks about using a groupId, but the general consensus has been that if it's in the version, it's unnecessary and it makes it harder for dependents to migrate after the project graduates. They can just update their dependencyManagement section of their top level pom and not go through bunches of child poms to change groupId's. Yup... exactly. Changing the artifactId or groupId to add an incubating suffix would add a lot of extra effort to deal with graduated podlings instead of a simple version change. --jason In anycase, I just wanted folks here to be aware of the discussions going on. Dan On Thursday 15 March 2007 17:37, Joakim Erdfelt wrote: One question I have ... Do you want to identify the incubating projects on central in any way? A groupId prefix of org.apache.incubating.* for example? - Joakim Daniel Kulp wrote: Just to let everyone know, there is a long thread about the incubator M2 repository on general@incubator.apache.org: http://mail-archives.apache.org/mod_mbox/incubator-general/200703.mb ox/31cc37360703140920h6a601b57gbb86ff0cd5e8049b%40mail.gmail.com Since this affects Maven users as well as projects like NMaven, it would be good to get other peoples input, especially those that run the central repository. The other complication will be if they decide to remove it, we'll have to merge it into the ibiblio sync respository. Are the tools ready for that? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-model-converter 2.1 (take 2)
I need one more vote... -- Dennis Lundberg Dennis Lundberg wrote: Hi, Trying this vote once more. This with staging. This release is a preparation for a release of the maven-one-plugin. The issues that have been resolved can be seen in JIRA: http://jira.codehaus.org/browse/MNG-2320 http://jira.codehaus.org/browse/MNG-2327 http://jira.codehaus.org/browse/MNG-2332 http://jira.codehaus.org/browse/MNG-2335 http://jira.codehaus.org/browse/MNG-2336 http://jira.codehaus.org/browse/MNG-2338 To summarize the changes, two types of plexus-components have been added: PluginRelocators and PluginConfigurationConverters. These help by converting plugin dependencies and their configuration. Tag: http://svn.apache.org/repos/asf/maven/shared/tags/maven-plugin-tools-2.1/ Staged at: http://people.apache.org/~dennisl/staging-repository/ The vote will be open for 72 hours. Here is my +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r515406 - /maven/continuum/trunk/continuum-release/src/main/resources/META-INF/plexus/components.xml
Handy, I think this patch is wrong, we need to use this component with 'maven' role-hint because it's this component declared in maven-project. Emmanuel [EMAIL PROTECTED] a écrit : Author: handyande Date: Tue Mar 6 17:17:11 2007 New Revision: 515406 URL: http://svn.apache.org/viewvc?view=revrev=515406 Log: We need this component declaration for now, as the released components were on non-default role-hints, but the impl expects a default, so we provide it. This can be removed once continuum gets a 2.1-SNAP maven dep Modified: maven/continuum/trunk/continuum-release/src/main/resources/META-INF/plexus/components.xml Modified: maven/continuum/trunk/continuum-release/src/main/resources/META-INF/plexus/components.xml URL: http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-release/src/main/resources/META-INF/plexus/components.xml?view=diffrev=515406r1=515405r2=515406 == --- maven/continuum/trunk/continuum-release/src/main/resources/META-INF/plexus/components.xml (original) +++ maven/continuum/trunk/continuum-release/src/main/resources/META-INF/plexus/components.xml Tue Mar 6 17:17:11 2007 @@ -314,6 +314,25 @@ /configuration /component +!-- This needs to be removed once we can upgrade maven-project to 2.1-SNAPSHOT or later. -- +component + roleorg.apache.maven.artifact.metadata.ArtifactMetadataSource/role + role-hintdefault/role-hint + implementationorg.apache.maven.project.artifact.MavenMetadataSource/implementation + requirements +requirement + roleorg.apache.maven.project.MavenProjectBuilder/role +/requirement +requirement + roleorg.apache.maven.artifact.factory.ArtifactFactory/role +/requirement +requirement + roleorg.apache.maven.artifact.repository.metadata.RepositoryMetadataManager/role + +/requirement + /requirements +/component + /components /component-set
RE: svn commit: r518445 - in /maven/core-integration-testing/trunk/core-integration-tests/src/test: java/org/apache/maven/integrationtests/ resources/it0118-attachedartifactinreactor/ resources/it0118
They use the plugin, but are not testing the plugin directly. They are
testing an issue in maven-project.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 5:44 PM
To: dev@maven.apache.org
Subject: Re: svn commit: r518445 - in
/maven/core-integration-testing/trunk/core-integration-tests/src/test:
java/org/apache/maven/integrationtests/
resources/it0118-attachedartifactinreactor/
resources/it0118-attachedartifactinreactor/one/ resources/it0118-attach
Are these integration tests that use the MDEP plugin? Don't put them
in the ITs if they are plugin specific.
We need to stop using production plugins in the ITs.
Jason.
On 14 Mar 07, at 10:34 PM 14 Mar 07, [EMAIL PROTECTED] wrote:
Author: brianf
Date: Wed Mar 14 19:34:52 2007
New Revision: 518445
URL: http://svn.apache.org/viewvc?view=revrev=518445
Log:
added tests that are commented out for MDEP-44 and MDEP-66
Added:
maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/one/
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/one/pom.xml
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/pom.xml
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/two/
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/two/pom.xml
Modified:
maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/IntegrationTestSuite.java
Modified: maven/core-integration-testing/trunk/core-integration-
tests/src/test/java/org/apache/maven/integrationtests/
IntegrationTestSuite.java
URL: http://svn.apache.org/viewvc/maven/core-integration-testing/
trunk/core-integration-tests/src/test/java/org/apache/maven/
integrationtests/IntegrationTestSuite.java?
view=diffrev=518445r1=518444r2=518445
==
--- maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
IntegrationTestSuite.java (original)
+++ maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
IntegrationTestSuite.java Wed Mar 14 19:34:52 2007
@@ -133,6 +133,7 @@
suite.addTestSuite
( MavenIT0111PluginsThatRequireAResourceFromAnExtensionTest.class );
suite.addTestSuite
( MavenIT0112ExtensionsThatDragDependencies.class );
suite.addTestSuite
( MavenIT0113ServerAuthzAvailableToWagonMgrInPlugin.class );
+//suite.addTestSuite
( MavenIT0118AttachedArtifactsInReactor.class );
return suite;
}
}
Added: maven/core-integration-testing/trunk/core-integration-tests/
src/test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java
URL: http://svn.apache.org/viewvc/maven/core-integration-testing/
trunk/core-integration-tests/src/test/java/org/apache/maven/
integrationtests/MavenIT0118AttachedArtifactsInReactor.java?
view=autorev=518445
==
--- maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java (added)
+++ maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java Wed Mar 14 19:34:52 2007
@@ -0,0 +1,31 @@
+package org.apache.maven.integrationtests;
+
+import java.io.File;
+import java.util.List;
+import java.util.ArrayList;
+
+import org.apache.maven.it.Verifier;
+import org.apache.maven.it.util.ResourceExtractor;
+
+public class MavenIT0118AttachedArtifactsInReactor
+extends AbstractMavenIntegrationTestCase
+{
+public void testit0118()
+throws Exception
+{
+File testDir =
+ResourceExtractor.simpleExtractResources( getClass(),
/it0118-attachedartifactinreactor );
+
+Verifier verifier;
+
+// Install the parent POM
+verifier = new Verifier( testDir.getAbsolutePath() );
+verifier.deleteArtifact( org.apache.maven.its.it0118,
parent, 1.0, pom );
+verifier.deleteArtifact( org.apache.maven.its.it0118,
one, 1.0, jar );
+verifier.deleteArtifact( org.apache.maven.its.it0118,
two, 1.0, pom );
+List
Re: [VOTE] Release maven-model-converter 2.1 (take 2)
+1 Emmanuel Dennis Lundberg a écrit : Hi, Trying this vote once more. This with staging. This release is a preparation for a release of the maven-one-plugin. The issues that have been resolved can be seen in JIRA: http://jira.codehaus.org/browse/MNG-2320 http://jira.codehaus.org/browse/MNG-2327 http://jira.codehaus.org/browse/MNG-2332 http://jira.codehaus.org/browse/MNG-2335 http://jira.codehaus.org/browse/MNG-2336 http://jira.codehaus.org/browse/MNG-2338 To summarize the changes, two types of plexus-components have been added: PluginRelocators and PluginConfigurationConverters. These help by converting plugin dependencies and their configuration. Tag: http://svn.apache.org/repos/asf/maven/shared/tags/maven-plugin-tools-2.1/ Staged at: http://people.apache.org/~dennisl/staging-repository/ The vote will be open for 72 hours. Here is my +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site failures using -Preporting
On Thursday 15 March 2007 18:21, Dennis Lundberg wrote: Daniel, I can't get the trunk for the Checkstyle plugin to work. Downgrading to a previous release like 2.1 or 2.0 works though. Ack.. This is a different but related issue. The ResourceManager that is injected during site generation is just completely borked.The fix I made allowed it to resolve config files that are in a jar in a dependency defined in your pluginManagement section.However, the maven checkstyle config uses an http URL location for the configLocation. The ResourceManager that is injected during site generation doesn't know anything about how to resolve http URL's. Anyone know where that ResourceManager is created and how to get it configured correctly? This is something that will cause problems for all the reporting plugins if we don't get it fixed. Dan Daniel Kulp wrote: Brian, Two things to try: 1) Remove your local copy of the checkstyle plugin and force it to re-download. 2) Rebuild checkstyle based on trunk. I think I fixed this on Monday. Dan On Wednesday 14 March 2007 20:15, Brian E. Fox wrote: I'm getting this on several plugins when generating the site with -Preporting: [INFO] Generate Checkstyle report. [INFO] --- --- -- [ERROR] BUILD ERROR [INFO] --- --- -- [INFO] Error during page generation Embedded error: Error rendering Maven report: Unable to process null config loca tion. [INFO] --- --- -- [INFO] For more information, run Maven with the -e switch [INFO] --- --- -- I thought the -Preporting when away with the surrogate parent? If I gen the site without it, most of the reports are not available. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-assembly-plugin: using newly built source code
Hello, if this is a redundant question please refer me to a thread that has covered it. I searched through the last 3 months of the mail archive w/ no luck. I checked out the maven-assembly-plugin in order to add a piece of functionality. It built fine, and installed into my local .m2 repo. But trying to use it in my current project's build yielded a lovely IncompatibleClassChangeError. I'm assuming someone has run into this before, but not sure what info I should include in my post to have the community help me debug the issue. Thanks for the help, Tom Hartwell Stack Trace: [INFO] [assembly:assembly] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.IncompatibleClassChangeError at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies (DefaultAssemblyReader.java:74) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(Abst ractAssemblyMojo.java:253) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoa l(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
Re: svn commit: r518445 - in /maven/core-integration-testing/trunk/core-integration-tests/src/test: java/org/apache/maven/integrationtests/ resources/it0118-attachedartifactinreactor/ resources/it0118
On 15 Mar 07, at 6:42 PM 15 Mar 07, Brian E. Fox wrote:
They use the plugin, but are not testing the plugin directly. They are
testing an issue in maven-project.
Cool, thanks for clarifying.
Jason.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 5:44 PM
To: dev@maven.apache.org
Subject: Re: svn commit: r518445 - in
/maven/core-integration-testing/trunk/core-integration-tests/src/test:
java/org/apache/maven/integrationtests/
resources/it0118-attachedartifactinreactor/
resources/it0118-attachedartifactinreactor/one/ resources/it0118-
attach
Are these integration tests that use the MDEP plugin? Don't put them
in the ITs if they are plugin specific.
We need to stop using production plugins in the ITs.
Jason.
On 14 Mar 07, at 10:34 PM 14 Mar 07, [EMAIL PROTECTED] wrote:
Author: brianf
Date: Wed Mar 14 19:34:52 2007
New Revision: 518445
URL: http://svn.apache.org/viewvc?view=revrev=518445
Log:
added tests that are commented out for MDEP-44 and MDEP-66
Added:
maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/one/
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/one/pom.xml
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/pom.xml
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/two/
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0118-attachedartifactinreactor/two/pom.xml
Modified:
maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/IntegrationTestSuite.java
Modified: maven/core-integration-testing/trunk/core-integration-
tests/src/test/java/org/apache/maven/integrationtests/
IntegrationTestSuite.java
URL: http://svn.apache.org/viewvc/maven/core-integration-testing/
trunk/core-integration-tests/src/test/java/org/apache/maven/
integrationtests/IntegrationTestSuite.java?
view=diffrev=518445r1=518444r2=518445
=
=
--- maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
IntegrationTestSuite.java (original)
+++ maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
IntegrationTestSuite.java Wed Mar 14 19:34:52 2007
@@ -133,6 +133,7 @@
suite.addTestSuite
( MavenIT0111PluginsThatRequireAResourceFromAnExtensionTest.class );
suite.addTestSuite
( MavenIT0112ExtensionsThatDragDependencies.class );
suite.addTestSuite
( MavenIT0113ServerAuthzAvailableToWagonMgrInPlugin.class );
+//suite.addTestSuite
( MavenIT0118AttachedArtifactsInReactor.class );
return suite;
}
}
Added: maven/core-integration-testing/trunk/core-integration-tests/
src/test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java
URL: http://svn.apache.org/viewvc/maven/core-integration-testing/
trunk/core-integration-tests/src/test/java/org/apache/maven/
integrationtests/MavenIT0118AttachedArtifactsInReactor.java?
view=autorev=518445
=
=
--- maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java (added)
+++ maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
MavenIT0118AttachedArtifactsInReactor.java Wed Mar 14 19:34:52 2007
@@ -0,0 +1,31 @@
+package org.apache.maven.integrationtests;
+
+import java.io.File;
+import java.util.List;
+import java.util.ArrayList;
+
+import org.apache.maven.it.Verifier;
+import org.apache.maven.it.util.ResourceExtractor;
+
+public class MavenIT0118AttachedArtifactsInReactor
+extends AbstractMavenIntegrationTestCase
+{
+public void testit0118()
+throws Exception
+{
+File testDir =
+ResourceExtractor.simpleExtractResources( getClass(),
/it0118-attachedartifactinreactor );
+
+Verifier verifier;
+
+// Install the parent POM
+verifier = new Verifier( testDir.getAbsolutePath() );
+verifier.deleteArtifact( org.apache.maven.its.it0118,
parent, 1.0, pom );
+verifier.deleteArtifact( org.apache.maven.its.it0118,
one, 1.0, jar );
+verifier.deleteArtifact( org.apache.maven.its.it0118,
two, 1.0, pom );
+List cliOptions = new ArrayList();
+
RE: maven-assembly-plugin: using newly built source code
The latest version might be incompatible. I was having test failures last time I built it. I would suggest checking out the tag for the last release and adding your code to that. -Original Message- From: Hartwell, Tom [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 7:03 PM To: dev@maven.apache.org Subject: maven-assembly-plugin: using newly built source code Hello, if this is a redundant question please refer me to a thread that has covered it. I searched through the last 3 months of the mail archive w/ no luck. I checked out the maven-assembly-plugin in order to add a piece of functionality. It built fine, and installed into my local .m2 repo. But trying to use it in my current project's build yielded a lovely IncompatibleClassChangeError. I'm assuming someone has run into this before, but not sure what info I should include in my post to have the community help me debug the issue. Thanks for the help, Tom Hartwell Stack Trace: [INFO] [assembly:assembly] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.IncompatibleClassChangeError at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies (DefaultAssemblyReader.java:74) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(Abst ractAssemblyMojo.java:253) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoa l(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site failures using -Preporting
Ok. eclipse:eclipse -DdownloadSources=true to the rescue. :-) Seriously, it looks like the ResourceManager has to be manually configured with acceptable paths to look at. Thus, if I add: locator.addSearchPath( url, ); then the URL form works fine. I personally thing should be a default prefix for the URL locator, but at least I understand what's happening now.I'll get this checked in. I also will need to withdraw the PMD vote as I'll need to do the same there or it will be a regression from 2.1. Dan On Thursday 15 March 2007 19:00, Daniel Kulp wrote: On Thursday 15 March 2007 18:21, Dennis Lundberg wrote: Daniel, I can't get the trunk for the Checkstyle plugin to work. Downgrading to a previous release like 2.1 or 2.0 works though. Ack.. This is a different but related issue. The ResourceManager that is injected during site generation is just completely borked. The fix I made allowed it to resolve config files that are in a jar in a dependency defined in your pluginManagement section.However, the maven checkstyle config uses an http URL location for the configLocation. The ResourceManager that is injected during site generation doesn't know anything about how to resolve http URL's. Anyone know where that ResourceManager is created and how to get it configured correctly? This is something that will cause problems for all the reporting plugins if we don't get it fixed. Dan Daniel Kulp wrote: Brian, Two things to try: 1) Remove your local copy of the checkstyle plugin and force it to re-download. 2) Rebuild checkstyle based on trunk. I think I fixed this on Monday. Dan On Wednesday 14 March 2007 20:15, Brian E. Fox wrote: I'm getting this on several plugins when generating the site with -Preporting: [INFO] Generate Checkstyle report. [INFO] - -- --- -- [ERROR] BUILD ERROR [INFO] - -- --- -- [INFO] Error during page generation Embedded error: Error rendering Maven report: Unable to process null config loca tion. [INFO] - -- --- -- [INFO] For more information, run Maven with the -e switch [INFO] - -- --- -- I thought the -Preporting when away with the surrogate parent? If I gen the site without it, most of the reports are not available. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[WITHDRAW][VOTE] Release Maven PMD Plugin 2.2
I'm withdrawing this vote. While debugging the checkstyle plugin, I discovered a similar situation in which rulesets defined by URL would have worked with 2.1, but not with 2.2. That's a serious regression so I'm withdrawing this vote to get that fixed. I'll re-spin the build tomorrow and restart the vote. Dan On Thursday 15 March 2007 11:19, Daniel Kulp wrote: I'd like to release version 2.2 of the PMD plugin. It's been over 8 months since the last release and this is a fairly significant improvement addressing 14 JIRA items. Staging area: http://people.apache.org/~dkulp/stage_pmd/ Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-pmd-plugin-2. 2/ Release Notes - Maven 2.x Pmd Plugin - Version 2.2 ** Bug * [MPMD-30] - No way to PMD test the test sources in src/test/java * [MPMD-47] - pmd should support multiple source roots * [MPMD-50] - Reports are different depending on the order of files retrieved from the filesystem * [MPMD-51] - Sometimes PMD.xml doesn't contain the class name and this displays null in the verbose mode * [MPMD-52] - XRef lnks do not work with aggregated XRef ** Improvement * [MPMD-28] - Support for multi-projects poms * [MPMD-38] - Add Posibility to excludes files in Cpd * [MPMD-40] - deploy the pmd.xml with site:deploy * [MPMD-44] - Allow to specify the rulesets as described in the docs * [MPMD-46] - Add ability to choose priority for failure * [MPMD-53] - pmd mojos need a skip flag similar to surefire ** New Feature * [MPMD-43] - Add results output to pmd:check * [MPMD-49] - Add results output to cpd:check ** Task * [MPMD-41] - Upgrade to PMD 3.9 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] MNG-1577 as the default behavior
Hi, After working with it a little this week I would like to propose to make MNG-1577 behavior introduced the default. Builds are completely and totally unpredictable without this behavior. The behavior in 2.0.5 is fundamentally broken. To are totally prey to any dependency introduced by a dependency which makes no sense and completely counter intuitive. I stabilized a massive build this week simply by using the behavior present in the 2.0.x branch. I don't think we're doing anyone any favors leaving the old behavior in. After watching a disaster be recovered by using this new behavior I feel that the patch should go in as is and become the default behavior. This puts the user in control which is the way it should be. I propose we make this the default behavior. Can anyone think of a case where this degree of control would break an existing build? This patch saved my bacon this week, I think this behavior makes a world of difference to users. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] MNG-1577 as the default behavior
I can think of some cases where it might break a build, but most of them are where a transitive dependency creeps into a build because the user assumes that MNG-1577 is how it's always worked. That being said, these issues would be easily remedied since you now have more control, and anyone using depMgt put those things there for a reason. We should just include a big notice in the release notes about this change so people are at least aware of it. +1 for making this the default. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 8:33 PM To: Maven Developers List Subject: [vote] MNG-1577 as the default behavior Hi, After working with it a little this week I would like to propose to make MNG-1577 behavior introduced the default. Builds are completely and totally unpredictable without this behavior. The behavior in 2.0.5 is fundamentally broken. To are totally prey to any dependency introduced by a dependency which makes no sense and completely counter intuitive. I stabilized a massive build this week simply by using the behavior present in the 2.0.x branch. I don't think we're doing anyone any favors leaving the old behavior in. After watching a disaster be recovered by using this new behavior I feel that the patch should go in as is and become the default behavior. This puts the user in control which is the way it should be. I propose we make this the default behavior. Can anyone think of a case where this degree of control would break an existing build? This patch saved my bacon this week, I think this behavior makes a world of difference to users. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] MNG-1577 as the default behavior
i'm fine for 2.1, for 2.0.6 may be too risky What about this use case for transitive dependencyManagement? has been tested? A - B - C - D C depends on D 1.0 B has D 2.0 in dependencyManagement, no D in dependencies A should get D 2.0 On 3/15/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, After working with it a little this week I would like to propose to make MNG-1577 behavior introduced the default. Builds are completely and totally unpredictable without this behavior. The behavior in 2.0.5 is fundamentally broken. To are totally prey to any dependency introduced by a dependency which makes no sense and completely counter intuitive. I stabilized a massive build this week simply by using the behavior present in the 2.0.x branch. I don't think we're doing anyone any favors leaving the old behavior in. After watching a disaster be recovered by using this new behavior I feel that the patch should go in as is and become the default behavior. This puts the user in control which is the way it should be. I propose we make this the default behavior. Can anyone think of a case where this degree of control would break an existing build? This patch saved my bacon this week, I think this behavior makes a world of difference to users. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] maven-dependency-plugin 2.0-alpha-2
I have 3 binding (Jason, Emmanuel, Stephane) and 3 user votes, no -1. The vote succeeds and I'll start moving to the public repo. Thanks, -Brian -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Monday, March 12, 2007 11:29 PM To: Maven Developers List Subject: [VOTE] maven-dependency-plugin 2.0-alpha-2 I'd like to release maven-dependency-plugin:2.0-alpha-2 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plug in-2.0-alpha-2/ Staged at: http://people.apache.org/~brianf/staging-repository Changes: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13137styleName =HtmlprojectId=11214Create=Create Release Notes - Maven 2.x Dependency Plugin - Version 2.0-alpha-2 - HTML format Bug * [MDEP-27] - Plugin configuration error message - caused by certain liefecycle bindings * [MDEP-56] - test-jar * [MDEP-58] - linux / mac unit test failures * [MDEP-60] - Multiple plugin execution sections not correctly executed * [MDEP-66] - Sources goal not implemented * [MDEP-67] - NPE when resolving the version of a dependency Improvement * [MDEP-55] - generate javadocs and jar src files with releae * [MDEP-57] - dependency:resolve should output scope * [MDEP-63] - allow version to be stripped from useSubfolderPerArtifact New Feature * [MDEP-26] - New goal to write classpath string with all dependencies from local repo * [MDEP-54] - Exclude and Include specific dependencies based on Artifact id or group name * [MDEP-65] - Copy dependencies in a Maven repository like layout Vote is open for 72 hours. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site failures using -Preporting
Dennis, Can you give it another try? I think I understand what's happening with the ResourceManager now and it should work. Dan On Thursday 15 March 2007 18:21, Dennis Lundberg wrote: Daniel, I can't get the trunk for the Checkstyle plugin to work. Downgrading to a previous release like 2.1 or 2.0 works though. Daniel Kulp wrote: Brian, Two things to try: 1) Remove your local copy of the checkstyle plugin and force it to re-download. 2) Rebuild checkstyle based on trunk. I think I fixed this on Monday. Dan On Wednesday 14 March 2007 20:15, Brian E. Fox wrote: I'm getting this on several plugins when generating the site with -Preporting: [INFO] Generate Checkstyle report. [INFO] --- --- -- [ERROR] BUILD ERROR [INFO] --- --- -- [INFO] Error during page generation Embedded error: Error rendering Maven report: Unable to process null config loca tion. [INFO] --- --- -- [INFO] For more information, run Maven with the -e switch [INFO] --- --- -- I thought the -Preporting when away with the surrogate parent? If I gen the site without it, most of the reports are not available. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] MNG-1577 as the default behavior
A will get D 2.0. Yes, our build depends heavily on this behavior. I'm ok with it going into 2.0.6 as long as it is noted in the release notes. Based on the number of votes the issue has, this is a major problem for a lot of people. I can't imagine any reasonably sized build which has not encountered it already. mike On 3/15/07, Carlos Sanchez [EMAIL PROTECTED] wrote: i'm fine for 2.1, for 2.0.6 may be too risky What about this use case for transitive dependencyManagement? has been tested? A - B - C - D C depends on D 1.0 B has D 2.0 in dependencyManagement, no D in dependencies A should get D 2.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Design Best Practices
Issue Subscription Filter: Design Best Practices (37 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-2477Implement repository security improvements for verification of downloaded artifacts http://jira.codehaus.org/browse/MNG-2477 MNG-2642maven-archetype-webapp does not produce Standard Directory Layout http://jira.codehaus.org/browse/MNG-2642 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-1936pattern: for mojo parameters which have default values in the POM we need standard usage http://jira.codehaus.org/browse/MNG-1936 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1634move maven-core-it to integration-tests http://jira.codehaus.org/browse/MNG-1634 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1305Document Maven's own development process http://jira.codehaus.org/browse/MNG-1305 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-905 review clean repo install of m2 for download trimming http://jira.codehaus.org/browse/MNG-905 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-939 specify maven settings from command line http://jira.codehaus.org/browse/MNG-939 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-140 refactor maven-artifact http://jira.codehaus.org/browse/MNG-140 MNG-1452best practices: deployment of aggregate JARs produced by the assembly plug-in http://jira.codehaus.org/browse/MNG-1452 MNG-139 server definitions should be reusable http://jira.codehaus.org/browse/MNG-139 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-868 Use uniform format for properties and other tags http://jira.codehaus.org/browse/MNG-868 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-1437How to make additions to the POM and have it be backward/forward compatible http://jira.codehaus.org/browse/MNG-1437 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] MNG-1577 as the default behavior
I can attest to this being a major issue for complex builds. Without this behavior, it's nearly impossible to manage the build of complex projects. -Nathan On 3/15/07, Mike Perham [EMAIL PROTECTED] wrote: A will get D 2.0. Yes, our build depends heavily on this behavior. I'm ok with it going into 2.0.6 as long as it is noted in the release notes. Based on the number of votes the issue has, this is a major problem for a lot of people. I can't imagine any reasonably sized build which has not encountered it already. mike On 3/15/07, Carlos Sanchez [EMAIL PROTECTED] wrote: i'm fine for 2.1, for 2.0.6 may be too risky What about this use case for transitive dependencyManagement? has been tested? A - B - C - D C depends on D 1.0 B has D 2.0 in dependencyManagement, no D in dependencies A should get D 2.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pending mx4j 3.0.2 upload to central...
Can someone with central repo skillz please help get the full mx4j 3.0.2 release published to central: http://jira.codehaus.org/browse/MAVENUPLOAD-1220 The Geronimo 1.2 release is blocked waiting for some mx4j 3.0.2 artifacts to be published (only one of the artifacts for this release is currently on central). Can we please get all artifacts published? Thanks, --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] MNG-1577 as the default behavior
Well, obviously I would have no objection. ;-) +1 Ralph Jason van Zyl wrote: Hi, After working with it a little this week I would like to propose to make MNG-1577 behavior introduced the default. Builds are completely and totally unpredictable without this behavior. The behavior in 2.0.5 is fundamentally broken. To are totally prey to any dependency introduced by a dependency which makes no sense and completely counter intuitive. I stabilized a massive build this week simply by using the behavior present in the 2.0.x branch. I don't think we're doing anyone any favors leaving the old behavior in. After watching a disaster be recovered by using this new behavior I feel that the patch should go in as is and become the default behavior. This puts the user in control which is the way it should be. I propose we make this the default behavior. Can anyone think of a case where this degree of control would break an existing build? This patch saved my bacon this week, I think this behavior makes a world of difference to users. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MNG-1577
Question. Has Mike or Patrick updated the documentation yet? I started to update the wiki a couple of months ago but put it off as I didn't want the wiki to reflect something that you couldn't yet use. Plus the behavior changed slightly since then. If they haven't beaten me to it, I'd be happy to do this as I promised (hoping they will review it of course). Ralph Jason van Zyl wrote: Hi, After working with it a little this week I would like to propose to make MNG-1577 behavior introduced the default. Builds are completely and totally unpredictable without this behavior. The behavior in 2.0.5 is fundamentally broken. To are totally prey to any dependency introduced by a dependency which makes no sense and completely counter intuitive. I stabilized a massive build this week simply by using the behavior present in the 2.0.x branch. I don't think we're doing anyone any favors leaving the old behavior in. After watching a disaster be recovered by using this new behavior I feel that the patch should go in as is and become the default behavior. This puts the user in control which is the way it should be. I propose we make this the default behavior. Can anyone think of a case where this degree of control would break an existing build? This patch saved my bacon this week, I think this behavior makes a world of difference to users. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MNG-1577
We haven't done any documentation yet, no. I'll certainly be happy to write some up, help you out, review what you have, etc. Where is the wiki page you were editing? Is it open to anyone, or do I need to submit changes to it through you or Mike? On 3/15/07, Ralph Goers [EMAIL PROTECTED] wrote: Question. Has Mike or Patrick updated the documentation yet? I started to update the wiki a couple of months ago but put it off as I didn't want the wiki to reflect something that you couldn't yet use. Plus the behavior changed slightly since then. If they haven't beaten me to it, I'd be happy to do this as I promised (hoping they will review it of course). Ralph Jason van Zyl wrote: Hi, After working with it a little this week I would like to propose to make MNG-1577 behavior introduced the default. Builds are completely and totally unpredictable without this behavior. The behavior in 2.0.5 is fundamentally broken. To are totally prey to any dependency introduced by a dependency which makes no sense and completely counter intuitive. I stabilized a massive build this week simply by using the behavior present in the 2.0.x branch. I don't think we're doing anyone any favors leaving the old behavior in. After watching a disaster be recovered by using this new behavior I feel that the patch should go in as is and become the default behavior. This puts the user in control which is the way it should be. I propose we make this the default behavior. Can anyone think of a case where this degree of control would break an existing build? This patch saved my bacon this week, I think this behavior makes a world of difference to users. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pending mx4j 3.0.2 upload to central...
i'm keeping an eye on it On 3/15/07, Jason Dillon [EMAIL PROTECTED] wrote: Can someone with central repo skillz please help get the full mx4j 3.0.2 release published to central: http://jira.codehaus.org/browse/MAVENUPLOAD-1220 The Geronimo 1.2 release is blocked waiting for some mx4j 3.0.2 artifacts to be published (only one of the artifacts for this release is currently on central). Can we please get all artifacts published? Thanks, --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: MNG-1577]
I started to edit it but didn't save it. The page that really needs to be updated is http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html. However, I believe the page I was editing is at http://docs.codehaus.org/display/MAVENUSER/Dependency+Mechanism. To edit all you need is to register and log in. Ralph Patrick Schneider wrote: We haven't done any documentation yet, no. I'll certainly be happy to write some up, help you out, review what you have, etc. Where is the wiki page you were editing? Is it open to anyone, or do I need to submit changes to it through you or Mike? On 3/15/07, *Ralph Goers* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Question. Has Mike or Patrick updated the documentation yet? I started to update the wiki a couple of months ago but put it off as I didn't want the wiki to reflect something that you couldn't yet use. Plus the behavior changed slightly since then. If they haven't beaten me to it, I'd be happy to do this as I promised (hoping they will review it of course). Ralph Jason van Zyl wrote: Hi, After working with it a little this week I would like to propose to make MNG-1577 behavior introduced the default. Builds are completely and totally unpredictable without this behavior. The behavior in 2.0.5 is fundamentally broken. To are totally prey to any dependency introduced by a dependency which makes no sense and completely counter intuitive. I stabilized a massive build this week simply by using the behavior present in the 2.0.x branch. I don't think we're doing anyone any favors leaving the old behavior in. After watching a disaster be recovered by using this new behavior I feel that the patch should go in as is and become the default behavior. This puts the user in control which is the way it should be. I propose we make this the default behavior. Can anyone think of a case where this degree of control would break an existing build? This patch saved my bacon this week, I think this behavior makes a world of difference to users. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pending mx4j 3.0.2 upload to central...
What needs to be done to get these published? I commented on the issue regarding the dependencies. I'm not 100% sure what the full dependencies are for these... and I'd rather not guess. --jason On Mar 15, 2007, at 9:51 PM, Carlos Sanchez wrote: i'm keeping an eye on it On 3/15/07, Jason Dillon [EMAIL PROTECTED] wrote: Can someone with central repo skillz please help get the full mx4j 3.0.2 release published to central: http://jira.codehaus.org/browse/MAVENUPLOAD-1220 The Geronimo 1.2 release is blocked waiting for some mx4j 3.0.2 artifacts to be published (only one of the artifacts for this release is currently on central). Can we please get all artifacts published? Thanks, --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-plugin-tools 2.1 (take 2)
I need one more vote... -- Dennis Lundberg Dennis Lundberg wrote: Hi, Trying this vote once more. This time with staging. This release is a preparation for a new release of the maven-plugin-plugin. Changes: - Add support for new annotations: @since for mojos and @implementation for parameters - Remove pluggy. It was only for the bootstrap and is no longer needed. Tag: http://svn.apache.org/repos/asf/maven/shared/tags/maven-plugin-tools-2.1/ Staged at: http://people.apache.org/~dennisl/staging-repository/ The vote will be open for 72 hours. Here is my +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
