[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
[
https://jira.codehaus.org/browse/MASSEMBLY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=345250#comment-345250
]
Kenney Westerhof commented on MASSEMBLY-696:
Awesome, thank you!
Internal Regexp Error with Windows Paths
Key: MASSEMBLY-696
URL: https://jira.codehaus.org/browse/MASSEMBLY-696
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Windows 7
maven-assembly-plugin trunk@e785abb
Reporter: Kenney Westerhof
Assignee: Karl-Heinz Marbaise
Fix For: 2.5
Attachments: MASSEMBLY-696.patch, MASSEMBLY-696.tar.gz
On windows the Assembly plugin shows this error:
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
(default-cli) on project myproject: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
Unexpected internal error near index 1
\
^
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
near index 1
\
^
at java.util.regex.Pattern.error(Pattern.java:1924)
at java.util.regex.Pattern.compile(Pattern.java:1671)
at java.util.regex.Pattern.init(Pattern.java:1337)
at java.util.regex.Pattern.compile(Pattern.java:1022)
at java.lang.String.split(String.java:2313)
at java.lang.String.split(String.java:2355)
at
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
[
https://jira.codehaus.org/browse/MASSEMBLY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=345135#comment-345135
]
Kenney Westerhof edited comment on MASSEMBLY-696 at 4/21/14 8:52 AM:
-
I'm referencing old code because the bug has been in there that long.
I don't understand your question. What do you need the revision for? And what
revision exactly?
The patch will work against any revision after 1073964, when that line of code
was introduced (svn blame/praise/annotate/ann). -And {{trunk}} is a symbolic
name referencing the latest revision in any subversion repository-
{color:grey}my bad, I should have said {{HEAD}}{color} (1588817 at the time of
this writing); I was being sarcastic, my apologies, this doesn't always come
across on digital media!
Also, it's really not necessary to make an integration test for this one. It's
the _unit_ tests for that code that are incomplete as they only check Unix
style pathnames, while the code explicitly attempts to deal with windows style
paths aswell.
In any case, I've concocted an integration test as per your request.
It took me quite a while to figure out what exactly triggers this code. It
occurs when specifying {{unpacktrue/unpack}} dependencies and either
specifying a non-default value for {{lineEnding/}} or {{filtered/}}. I
added some debug to the assembly plugin, and it breaks when {{fixRelativeRefs}}
is called with {{.\log4j-1.2.17.jar/}}. That this doesn't happen more often is
because most code calling {{fixRelativeRefs}} duplicates code from that method
(i.e. stripping {{./}}, {{../}} etc).
was (Author: kenneyw):
I'm referencing old code because the bug has been in there that long.
I don't understand your question. What do you need the revision for? And what
revision exactly?
The patch will work against any revision after 1073964, when that line of code
was introduced (svn blame/praise/annotate/ann). And {{trunk}} is a symbolic
name referencing the latest revision in any subversion repository (1588817 at
the time of this writing); I was being sarcastic, my apologies, this doesn't
always come across on digital media!
Also, it's really not necessary to make an integration test for this one. It's
the _unit_ tests for that code that are incomplete as they only check Unix
style pathnames, while the code explicitly attempts to deal with windows style
paths aswell.
In any case, I've concocted an integration test as per your request.
It took me quite a while to figure out what exactly triggers this code. It
occurs when specifying {{unpacktrue/unpack}} dependencies and either
specifying a non-default value for {{lineEnding/}} or {{filtered/}}. I
added some debug to the assembly plugin, and it breaks when {{fixRelativeRefs}}
is called with {{.\log4j-1.2.17.jar/}}. That this doesn't happen more often is
because most code calling {{fixRelativeRefs}} duplicates code from that method
(i.e. stripping {{./}}, {{../}} etc).
I've never had to do so much work to simply add {{\\}} to an obviously broken
line of code! ;-) I could have commited the fix in svn this myself, but since
I've not been involved in the project recently I though it wise to be polite
and follow the proper channels.
Internal Regexp Error with Windows Paths
Key: MASSEMBLY-696
URL: https://jira.codehaus.org/browse/MASSEMBLY-696
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Windows 7
maven-assembly-plugin trunk@e785abb
Reporter: Kenney Westerhof
Attachments: MASSEMBLY-696.patch, MASSEMBLY-696.tar.gz
On windows the Assembly plugin shows this error:
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
(default-cli) on project myproject: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
Unexpected internal error near index 1
\
^
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
near index 1
\
^
at java.util.regex.Pattern.error(Pattern.java:1924)
at java.util.regex.Pattern.compile(Pattern.java:1671)
at java.util.regex.Pattern.init(Pattern.java:1337)
at java.util.regex.Pattern.compile(Pattern.java:1022)
at java.lang.String.split(String.java:2313)
at java.lang.String.split(String.java:2355)
at
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-697) Make it possible to include the project jar in the 'repository' assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof updated MASSEMBLY-697: --- Summary: Make it possible to include the project jar in the 'repository' assembly (was: Repository assembly does not include project jar) Make it possible to include the project jar in the 'repository' assembly Key: MASSEMBLY-697 URL: https://jira.codehaus.org/browse/MASSEMBLY-697 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.4 Environment: Windows / Any Maven 3.2.1 Reporter: Kenney Westerhof Attachments: MASSEMBLY-697.tar.gz The example on http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html does not produce the advertised results, as it copies the pom into the repository archive, but omits the project .jar. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-697) Repository assembly does not include project jar
[ https://jira.codehaus.org/browse/MASSEMBLY-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=345128#comment-345128 ] Kenney Westerhof commented on MASSEMBLY-697: Hi Karl-Heinz, Thank you for responding! Whether the documentation is correct depends on your definition of 'project'. In my definition, the project archive or artifact is part of the project. Without it, there's no project to use anything. But I agree that the documentation is subject to interpretation. I should have made it more clear that my issue is NOT with the documentation, but with the functionality regarding the repository construction code. Changing a few words on a website doesn't help me out here. ;-) If I make a standard assembly, say, a zip, the project archive _is_ included (depending ofcourse on my settings, but at least it's _possible_). This is somewhat inconsistent in my view: the assembly descriptors for zip etc. allow to specify any custom directory structure to include _all_ project artifacts, whereas the repository format descriptor does not. I'll update the issue to better reflect my meaning. Thanks for pointing this out! Repository assembly does not include project jar Key: MASSEMBLY-697 URL: https://jira.codehaus.org/browse/MASSEMBLY-697 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.4 Environment: Windows / Any Maven 3.2.1 Reporter: Kenney Westerhof Attachments: MASSEMBLY-697.tar.gz The example on http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html does not produce the advertised results, as it copies the pom into the repository archive, but omits the project .jar. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-697) Make it possible to include the project jar in the 'repository' assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof updated MASSEMBLY-697: --- Description: The example on http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html does not include an example of producting a repository artifact which includes the project jar itself, something that is possible (and even standard) in all other assembly formats.produce the advertised results, as it copies the pom into the repository archive, but omits the project .jar. was: The example on http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html does not produce the advertised results, as it copies the pom into the repository archive, but omits the project .jar. Make it possible to include the project jar in the 'repository' assembly Key: MASSEMBLY-697 URL: https://jira.codehaus.org/browse/MASSEMBLY-697 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.4 Environment: Windows / Any Maven 3.2.1 Reporter: Kenney Westerhof Attachments: MASSEMBLY-697.tar.gz The example on http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html does not include an example of producting a repository artifact which includes the project jar itself, something that is possible (and even standard) in all other assembly formats.produce the advertised results, as it copies the pom into the repository archive, but omits the project .jar. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-697) Make it possible to include the project jar in the 'repository' assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof updated MASSEMBLY-697: --- Description: The example on http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html does not include an example of producing a repository artifact which includes the project jar itself, something that is possible (and even standard) in all other assembly formats.. It does however, copy the project pom into the repository structure, which seems inconsistent. was: The example on http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html does not include an example of producting a repository artifact which includes the project jar itself, something that is possible (and even standard) in all other assembly formats.produce the advertised results, as it copies the pom into the repository archive, but omits the project .jar. Make it possible to include the project jar in the 'repository' assembly Key: MASSEMBLY-697 URL: https://jira.codehaus.org/browse/MASSEMBLY-697 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.4 Environment: Windows / Any Maven 3.2.1 Reporter: Kenney Westerhof Attachments: MASSEMBLY-697.tar.gz The example on http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html does not include an example of producing a repository artifact which includes the project jar itself, something that is possible (and even standard) in all other assembly formats.. It does however, copy the project pom into the repository structure, which seems inconsistent. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
[
https://jira.codehaus.org/browse/MASSEMBLY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=345130#comment-345130
]
Kenney Westerhof commented on MASSEMBLY-696:
Certainly, the SVN revision number is 'trunk'; it occurs since all earlier
versions since John added the code:
{quote}
1653fb20 :(John Dennis Casey 2011-02-23 22:05:06 + 509)
parts.addAll( Arrays.asList( value.split( sep ) ) );
{quote}
I'm working on minifying my project to get you a usecase for an integration
test. I think it's due to using {code}${java.home}/lib/tools.jar{code} as a
system dep somewhere. But the use of _any_ windows paths will trigger this bug.
However the code is simply wrong and shouldn't take a usecase to fix. Simply
run this code:
{code}
foo.split( \\ );
{code}
; see the Javadoc on Regular Expressions for more info ;-)
Thanks, merry easter!
Internal Regexp Error with Windows Paths
Key: MASSEMBLY-696
URL: https://jira.codehaus.org/browse/MASSEMBLY-696
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Windows 7
maven-assembly-plugin trunk@e785abb
Reporter: Kenney Westerhof
Attachments: MASSEMBLY-696.patch
On windows the Assembly plugin shows this error:
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
(default-cli) on project myproject: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
Unexpected internal error near index 1
\
^
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
near index 1
\
^
at java.util.regex.Pattern.error(Pattern.java:1924)
at java.util.regex.Pattern.compile(Pattern.java:1671)
at java.util.regex.Pattern.init(Pattern.java:1337)
at java.util.regex.Pattern.compile(Pattern.java:1022)
at java.lang.String.split(String.java:2313)
at java.lang.String.split(String.java:2355)
at
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-697) Make it possible to include the project jar in the 'repository' assembly
[
https://jira.codehaus.org/browse/MASSEMBLY-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=345133#comment-345133
]
Kenney Westerhof commented on MASSEMBLY-697:
Hi Karl-Heinz,
From: https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html :
{quote}
An assembly defines a collection of files usually distributed in an archive
format such as zip, tar, or tar.gz that is generated from a project.
{quote}
However, on that page it also says:
{quote}
This descriptor specifies the type of assembly archive to create, the contents
of the assembly, and the ways in which dependencies or its modules are bundled
with an assembly.
{quote}
which is then wrong, because it also allows to bundle the project's main
artifact (which is neither a dependency or a module). But I hope clears up what
I was referring to with 'specifying the directory structure'. Additionally, the
repository format doesn't obey the quoted definition since the contents of the
assembly cannot be fully specified (because not all project artifacts can be
included in the assembly), as is the case with the other formats. It is the odd
one out.
Prescribing the use of the various assembly formats speaks against them being
configurable, IMHO. I don't see a real reason why the format should dictate
what artifacts are included, as this is configurable with includes and
excludes. What the repository format is used for should be completely up to the
projects. AFAIK Maven doesn't have per-project settings to dictate the location
of the local repository (except perhaps in plugin configurations), but this has
to be specified either in settings.xml or on the commandline. So, being so
strict about the intended use of the repository target because it's structure
is defined by Maven makes litle sense to me.
However, let's assume your use-case. I'd generate a remote repository that
includes _all_ artifacts, including the project pom, _except_ the project jar.
Let's also assume I place that repository on a webserver. I can then not simply
point users to my repository, giving them the artifact identifier of the main
project, because, even while they can successfully download the pom from the
generated repository, aswell as all the dependencies, the main project jar is
missing. I'd then have to distribute the source of the main project separately.
This means I cannot use the repository format to update my local 'remote'
repository tailored to only include my project's dependencies.
Does this make some sense?
Make it possible to include the project jar in the 'repository' assembly
Key: MASSEMBLY-697
URL: https://jira.codehaus.org/browse/MASSEMBLY-697
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows / Any
Maven 3.2.1
Reporter: Kenney Westerhof
Attachments: MASSEMBLY-697.tar.gz
The example on
http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html
does not include an example of producing a repository artifact which
includes the project jar itself, something that is possible (and even
standard) in all other assembly formats..
It does however, copy the project pom into the repository structure, which
seems inconsistent.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
[
https://jira.codehaus.org/browse/MASSEMBLY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=345135#comment-345135
]
Kenney Westerhof commented on MASSEMBLY-696:
I'm referencing old code because the bug has been in there that long.
I don't understand your question. What do you need the revision for? And what
revision exactly?
The patch will work against any revision after 1073964, when that line of code
was introduced (svn blame/praise/annotate/ann). And {{trunk}} is a symbolic
name referencing the latest revision in any subversion repository (1588817 at
the time of this writing); I was being sarcastic, my apologies, this doesn't
always come across on digital media!
Also, it's really not necessary to make an integration test for this one. It's
the _unit_ tests for that code that are incomplete as they only check Unix
style pathnames, while the code explicitly attempts to deal with windows style
paths aswell.
In any case, I've concocted an integration test as per your request.
It took me quite a while to figure out what exactly triggers this code. It
occurs when specifying {{unpacktrue/unpack}} dependencies and either
specifying a non-default value for {{lineEnding/}} or {{filtered/}}. I
added some debug to the assembly plugin, and it breaks when {{fixRelativeRefs}}
is called with {{.\log4j-1.2.17.jar/}}. That this doesn't happen more often is
because most code calling {{fixRelativeRefs}} duplicates code from that method
(i.e. stripping {{./}}, {{../}} etc).
I've never had to do so much work to simply add {{\\}} to an obviously broken
line of code! ;-) I could have commited the fix in svn this myself, but since
I've not been involved in the project recently I though it wise to be polite
and follow the proper channels.
Internal Regexp Error with Windows Paths
Key: MASSEMBLY-696
URL: https://jira.codehaus.org/browse/MASSEMBLY-696
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Windows 7
maven-assembly-plugin trunk@e785abb
Reporter: Kenney Westerhof
Attachments: MASSEMBLY-696.patch
On windows the Assembly plugin shows this error:
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
(default-cli) on project myproject: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
Unexpected internal error near index 1
\
^
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
near index 1
\
^
at java.util.regex.Pattern.error(Pattern.java:1924)
at java.util.regex.Pattern.compile(Pattern.java:1671)
at java.util.regex.Pattern.init(Pattern.java:1337)
at java.util.regex.Pattern.compile(Pattern.java:1022)
at java.lang.String.split(String.java:2313)
at java.lang.String.split(String.java:2355)
at
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
[
https://jira.codehaus.org/browse/MASSEMBLY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MASSEMBLY-696:
---
Attachment: MASSEMBLY-696.tar.gz
tar xvfz MASSEMBLY-696.tar.gz cd MASSEMBLY-696 mvn package
Internal Regexp Error with Windows Paths
Key: MASSEMBLY-696
URL: https://jira.codehaus.org/browse/MASSEMBLY-696
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Windows 7
maven-assembly-plugin trunk@e785abb
Reporter: Kenney Westerhof
Attachments: MASSEMBLY-696.patch, MASSEMBLY-696.tar.gz
On windows the Assembly plugin shows this error:
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
(default-cli) on project myproject: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
Unexpected internal error near index 1
\
^
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
near index 1
\
^
at java.util.regex.Pattern.error(Pattern.java:1924)
at java.util.regex.Pattern.compile(Pattern.java:1671)
at java.util.regex.Pattern.init(Pattern.java:1337)
at java.util.regex.Pattern.compile(Pattern.java:1022)
at java.lang.String.split(String.java:2313)
at java.lang.String.split(String.java:2355)
at
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5604) make it possible to mark a maven module as deprected
[
https://jira.codehaus.org/browse/MNG-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344763#comment-344763
]
Kenney Westerhof commented on MNG-5604:
---
Hi Mirko,
That's pretty much it, although I would not declare A as deprecated using a
rule, since it is not applicable as a rule to project A. I'd make a split in
the configuration to distinguish rules from declarations, for example:
A's pom.xml:
{code:xml}
plugin
artifactIdmaven-enforcer-plugin/artifactId
configuration
declarations
deprecated/deprecated
/
{code}
Similar for B:
{code:xml}
plugin
artifactIdmaven-enforcer-plugin/artifactId
configuration
rules
banDeprecated/
/
{code}
I don't see how this would break the spirit of the enforcer plugin at all. In
project B it operates as usual, enforcing rules. In A it serves to provide
metadata for it's own functioning in dependent projects.
The thing with the POM is that it doesn't change much which severly impedes
adding new functionality like this issue proposes.
This solution still adheres to the idea of specifying project metadata in the
POM (both for building and using such projects), using a standard maven plugin
even, while promoting extension of the metadata provided. A feature such as
this can then be developed independently of the maven core platform and rest on
standard plugin functionality. Once it gains popularity and other plugins start
to use such metadata it can be promoted to become part of the 'static' POM
definition itself, or even be placed in a plugin configuration dedicated to
providing such extended metadata.
make it possible to mark a maven module as deprected
Key: MNG-5604
URL: https://jira.codehaus.org/browse/MNG-5604
Project: Maven 2 3
Issue Type: Wish
Components: Artifacts and Repositories
Affects Versions: 3.2.1
Reporter: Klaus Claszen
Priority: Minor
Labels: build, pom.xml
It would be great if it would be possible to mark a maven module as
'deprecated'. It would help to document that a module is outdated. The
information could be used during build processes to show warnings and guide
the user to a better alternative.
Maybe it could be a pom enhancement linke this
{code:xml}
deprecated
reasonnot maintained anymore/reason
instead
groupIdfoo/groupId
artifactIdbar/artifactId
/instead
/deprecated
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
Kenney Westerhof created MASSEMBLY-696:
--
Summary: Internal Regexp Error with Windows Paths
Key: MASSEMBLY-696
URL: https://jira.codehaus.org/browse/MASSEMBLY-696
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Windows 7
maven-assembly-plugin trunk@e785abb
Reporter: Kenney Westerhof
On windows the Assembly plugin shows this error:
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
(default-cli) on project myproject: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
Unexpected internal error near index 1
\
^
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
near index 1
\
^
at java.util.regex.Pattern.error(Pattern.java:1924)
at java.util.regex.Pattern.compile(Pattern.java:1671)
at java.util.regex.Pattern.init(Pattern.java:1337)
at java.util.regex.Pattern.compile(Pattern.java:1022)
at java.lang.String.split(String.java:2313)
at java.lang.String.split(String.java:2355)
at
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
[
https://jira.codehaus.org/browse/MASSEMBLY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MASSEMBLY-696:
---
Patch Submitted: Yes
Attachment: MASSEMBLY-696.patch
Internal Regexp Error with Windows Paths
Key: MASSEMBLY-696
URL: https://jira.codehaus.org/browse/MASSEMBLY-696
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Windows 7
maven-assembly-plugin trunk@e785abb
Reporter: Kenney Westerhof
Attachments: MASSEMBLY-696.patch
On windows the Assembly plugin shows this error:
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
(default-cli) on project myproject: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
Unexpected internal error near index 1
\
^
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
near index 1
\
^
at java.util.regex.Pattern.error(Pattern.java:1924)
at java.util.regex.Pattern.compile(Pattern.java:1671)
at java.util.regex.Pattern.init(Pattern.java:1337)
at java.util.regex.Pattern.compile(Pattern.java:1022)
at java.lang.String.split(String.java:2313)
at java.lang.String.split(String.java:2355)
at
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
[
https://jira.codehaus.org/browse/MASSEMBLY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MASSEMBLY-696:
---
Attachment: MASSEMBLY-696.patch
Internal Regexp Error with Windows Paths
Key: MASSEMBLY-696
URL: https://jira.codehaus.org/browse/MASSEMBLY-696
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Windows 7
maven-assembly-plugin trunk@e785abb
Reporter: Kenney Westerhof
Attachments: MASSEMBLY-696.patch, MASSEMBLY-696.patch
On windows the Assembly plugin shows this error:
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
(default-cli) on project myproject: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
Unexpected internal error near index 1
\
^
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
near index 1
\
^
at java.util.regex.Pattern.error(Pattern.java:1924)
at java.util.regex.Pattern.compile(Pattern.java:1671)
at java.util.regex.Pattern.init(Pattern.java:1337)
at java.util.regex.Pattern.compile(Pattern.java:1022)
at java.lang.String.split(String.java:2313)
at java.lang.String.split(String.java:2355)
at
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
[
https://jira.codehaus.org/browse/MASSEMBLY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MASSEMBLY-696:
---
Attachment: (was: MASSEMBLY-696.patch)
Internal Regexp Error with Windows Paths
Key: MASSEMBLY-696
URL: https://jira.codehaus.org/browse/MASSEMBLY-696
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Windows 7
maven-assembly-plugin trunk@e785abb
Reporter: Kenney Westerhof
Attachments: MASSEMBLY-696.patch
On windows the Assembly plugin shows this error:
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
(default-cli) on project myproject: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
Unexpected internal error near index 1
\
^
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
near index 1
\
^
at java.util.regex.Pattern.error(Pattern.java:1924)
at java.util.regex.Pattern.compile(Pattern.java:1671)
at java.util.regex.Pattern.init(Pattern.java:1337)
at java.util.regex.Pattern.compile(Pattern.java:1022)
at java.lang.String.split(String.java:2313)
at java.lang.String.split(String.java:2355)
at
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
[
https://jira.codehaus.org/browse/MASSEMBLY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MASSEMBLY-696:
---
Attachment: (was: MASSEMBLY-696.patch)
Internal Regexp Error with Windows Paths
Key: MASSEMBLY-696
URL: https://jira.codehaus.org/browse/MASSEMBLY-696
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Windows 7
maven-assembly-plugin trunk@e785abb
Reporter: Kenney Westerhof
On windows the Assembly plugin shows this error:
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
(default-cli) on project myproject: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
Unexpected internal error near index 1
\
^
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
near index 1
\
^
at java.util.regex.Pattern.error(Pattern.java:1924)
at java.util.regex.Pattern.compile(Pattern.java:1671)
at java.util.regex.Pattern.init(Pattern.java:1337)
at java.util.regex.Pattern.compile(Pattern.java:1022)
at java.lang.String.split(String.java:2313)
at java.lang.String.split(String.java:2355)
at
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
[
https://jira.codehaus.org/browse/MASSEMBLY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MASSEMBLY-696:
---
Attachment: MASSEMBLY-696.patch
Internal Regexp Error with Windows Paths
Key: MASSEMBLY-696
URL: https://jira.codehaus.org/browse/MASSEMBLY-696
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Windows 7
maven-assembly-plugin trunk@e785abb
Reporter: Kenney Westerhof
Attachments: MASSEMBLY-696.patch
On windows the Assembly plugin shows this error:
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
(default-cli) on project myproject: Execution default-cli of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
Unexpected internal error near index 1
\
^
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
near index 1
\
^
at java.util.regex.Pattern.error(Pattern.java:1924)
at java.util.regex.Pattern.compile(Pattern.java:1671)
at java.util.regex.Pattern.init(Pattern.java:1337)
at java.util.regex.Pattern.compile(Pattern.java:1022)
at java.lang.String.split(String.java:2313)
at java.lang.String.split(String.java:2355)
at
org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-697) Repository assembly does not include project jar
Kenney Westerhof created MASSEMBLY-697: -- Summary: Repository assembly does not include project jar Key: MASSEMBLY-697 URL: https://jira.codehaus.org/browse/MASSEMBLY-697 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.4, 2.5 Environment: Windows / Any Maven 3.2.1 Reporter: Kenney Westerhof The example on http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html does not produce the advertised results, as it copies the pom into the repository archive, but omits the project .jar. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-697) Repository assembly does not include project jar
[
https://jira.codehaus.org/browse/MASSEMBLY-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MASSEMBLY-697:
---
Attachment: MASSEMBLY-697.tar.gz
The attachment contains a simple project (pom, assembly descriptor and a
placeholder Java class) that illustrates the bug. Run:
{code}
mvn package
unzip -l target/artifactId-1-SNAPSHOT-repository.jar
{code}
to see that the project .jar is missing.
Repository assembly does not include project jar
Key: MASSEMBLY-697
URL: https://jira.codehaus.org/browse/MASSEMBLY-697
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.4, 2.5
Environment: Windows / Any
Maven 3.2.1
Reporter: Kenney Westerhof
Attachments: MASSEMBLY-697.tar.gz
The example on
http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html
does not produce the advertised results, as it copies the pom into the
repository archive, but omits the project .jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5604) make it possible to mark a maven module as deprected
[
https://jira.codehaus.org/browse/MNG-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344710#comment-344710
]
Kenney Westerhof commented on MNG-5604:
---
Deprecation always requires a reference to the preferred solution, because if
the functionality is not provided by an alternative, the module is still useful.
The idea behind Maven is to have stable builds, producing the same result on
any system, but it does allow for automatic project metadata updates using
version ranges on dependencies.
The relocation functionality was made to cover cases such as projects not
adhering to decent versioning standards and is a different problem. In this
case it can be used to automatically update from log4j 1.2.17 to 2.0 even
though the artifactId has changed.
A project moving away from using one library in favour of another will manage
the change on it's end: by changing the dependencies and updating their code to
conform to the new API. Similarly, using version ranges resulting in an
incompatible dependency being used, either the pom or the code must be changed.
Either way, it requires manual intervention which is a pretty clear message.
That said, nothing is stopping you from adding that XML snippet to the pom, for
instance in a configuration section of a plugin. No-one said that plugin
configuration should be imperative only. My suggestion would be to add a mojo
to the enforcer-plugin which inspects the reactor models for enforcer-plugin
configuration for the deprecation information and display a notice.
This leaves whether or not to receive deprecation warnings up to the projects
using potentially deprecated dependencies, opens the door for more flexibility
without having to rely on the POM to change, and fit's with Maven's design of
providing standardized, extensible project lifecycle management.
make it possible to mark a maven module as deprected
Key: MNG-5604
URL: https://jira.codehaus.org/browse/MNG-5604
Project: Maven 2 3
Issue Type: Wish
Components: Artifacts and Repositories
Affects Versions: 3.2.1
Reporter: Klaus Claszen
Priority: Minor
Labels: build, pom.xml
It would be great if it would be possible to mark a maven module as
'deprecated'. It would help to document that a module is outdated. The
information could be used during build processes to show warnings and guide
the user to a better alternative.
Maybe it could be a pom enhancement linke this
{code:xml}
deprecated
reasonnot maintained anymore/reason
instead
groupIdfoo/groupId
artifactIdbar/artifactId
/instead
/deprecated
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] Closed: (MNG-3118) Test-classes should come before classes in the classpath
[ http://jira.codehaus.org/browse/MNG-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof closed MNG-3118. - Resolution: Fixed Fix Version/s: 2.1-alpha-1 fixed in trunk at r559042 and 2.0.x branch at 559045 Test-classes should come before classes in the classpath Key: MNG-3118 URL: http://jira.codehaus.org/browse/MNG-3118 Project: Maven 2 Issue Type: Improvement Components: General Affects Versions: 2.0.7 Reporter: Paul Gier Fix For: 2.0.8, 2.1-alpha-1 Attachments: MNG-3118-maven-project-r558713.patch Currently maven-project creates the test classpath in the order: classes, tests-classes, dependencies. It would be better if test-classes came first because sometimes it is useful for a test class to replace a main class during testing. The opposite case is not normally true (i.e. one would not want to override a test class with one of the main classes). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MANTRUN-57) merge issue from parent causing executions to be run multiple times
[
http://jira.codehaus.org/browse/MANTRUN-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MANTRUN-57:
Fix Version/s: (was: 1.1)
1.2
update fix version since it's not fixed and 1.1 has been released.
merge issue from parent causing executions to be run multiple times
---
Key: MANTRUN-57
URL: http://jira.codehaus.org/browse/MANTRUN-57
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.1
Environment: Linux Fedora Core 5, SUN JDK 1.5
Reporter: Hung Le
Fix For: 1.2
Attachments: antrun-testcase.zip, epom.xml
Has parent/child project
parent
child1
in parent's pom.xml, define a run
build
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
ide1/id
phasegenerate-sources/phase
configuration
tasks
echo message=ant e1 /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
/plugins
/build
In child,'s pom.xml, define another run
build
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
ide2/id
phasegenerate-sources/phase
configuration
tasks
echo message=ant e2 /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
/plugins
/build
Expect the two declaration to be merged so that during the generate-sources
phase for the child I will see
ant e1
ant e2
what happens right now
[INFO] [antrun:run {execution: e1}]
[INFO] Executing tasks
[echo] ant e1
[INFO] Executed tasks
[INFO] [antrun:run {execution: e2}]
[INFO] Executing tasks
[echo] ant e2
[INFO] Executed tasks
[INFO] [antrun:run {execution: e1}]
[INFO] Executing tasks
[echo] ant e1
[INFO] Executed tasks
[INFO] [antrun:run {execution: e2}]
[INFO] Executing tasks
[echo] ant e2
help:effective-pom shows the merged pom at the child with merge but
duplicated antrun plugin declaration
...
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
ide1/id
phasegenerate-sources/phase
goals
goalrun/goal
/goals
configuration
tasks
echo message=ant e1/echo
/tasks
/configuration
/execution
execution
ide2/id
phasegenerate-sources/phase
goals
goalrun/goal
/goals
configuration
tasks
echo message=ant e2/echo
/tasks
/configuration
/execution
/executions
/plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
ide1/id
phasegenerate-sources/phase
goals
goalrun/goal
/goals
configuration
tasks
echo message=ant e1/echo
/tasks
/configuration
/execution
execution
ide2/id
phasegenerate-sources/phase
goals
goalrun/goal
/goals
configuration
tasks
echo message=ant e2/echo
/tasks
/configuration
/execution
/executions
/plugin
..
Attached please find
. *.zip has a sample parent/child example, you can go to child1 and do
mvn compile
. epom.xml is the output of 'mvn help:effective-pom' for the child project
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2339) ${project.*} are interpreted in the wrong place
[
http://jira.codehaus.org/browse/MNG-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100325
]
Kenney Westerhof commented on MNG-2339:
---
Comitted fix in r549786 on trunk (2.1).
It produces lots of warnings - i'm not sure we want exactly that behaviour in
2.0.
See http://docs.codehaus.org/display/MAVEN/Refactoring+Interpolation
${project.*} are interpreted in the wrong place
---
Key: MNG-2339
URL: http://jira.codehaus.org/browse/MNG-2339
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Reporter: Emmanuel Venisse
Assignee: Kenney Westerhof
Priority: Critical
Fix For: 2.0.8
If a plugin use ${project.version}, this parameter is interpreted with the
version of the current project and not the plugin version. I think we have
the same pb with dependencies and other ${project.*}
For a plugin in version 2.0 used in a project in version 1.0-SNAPSHOT,
${project.version} used in the plugin will be interpreted as 1.0-SNAPSHOT
instead of 2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1916) Making it possible for plug-in to add modules to the reactor programatically
[
http://jira.codehaus.org/browse/MNG-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100390
]
Kenney Westerhof commented on MNG-1916:
---
Are you talking about just adding modules (maven 2 projects) to the reactor, or
are you talking about maven2 plugins?
For now I'll assume that 'plug-ins included in the reactor' means 'modules
included in the reactor'.
So, what's the problem with adding module sections for your modules manually?
Can't profile's be used, activating on the existence of a file, and adding a
module there? You'd have to specify 1 profile per module though.
solution 3: write a replacement component for the core and put it in
$M2_HOME/extensions, that'll do a workspace scan for your files and add the
modules
to the proper pom, or just add them to the reactor.
solution 4: write a plugin, and create a pom that uses that plugin. The plugin
will fork a new maven build with whatever set of projects you like.
Take a look at the maven-it-plugin in the sandbox, it basically does the same
thing: it runs src/it/*/pom.xml.
I think having modules*//modules will cause too much problems. Right now,
m2 will quit if you specify a module dir that doesn't have a pom.xml,
so that behaviour must change. Further, i think you only want to add
directories as modules that contain a certain file. That would require an
extensive
change to the pom. Even extensions won't work here, since you cannot alter the
reactor once it's running.
Making it possible for plug-in to add modules to the reactor programatically
Key: MNG-1916
URL: http://jira.codehaus.org/browse/MNG-1916
Project: Maven 2
Issue Type: Improvement
Components: Plugin API, Reactor and workspace
Reporter: Nils Fredrik Gjerull
Fix For: 2.1.x
I would like to be able to specify a number of directories as plug-in
directories, automatically discover every plug-in in those directories and
include them in the reactor. As I understands it the reactor with it's
modules ({{org.apache.maven.execution.ReactorManager}}) is created in
{{org.apache.maven.DefaultMaven}}. If I understands this correctly maven
plug-ins can't add projects to the reactor programatically.
My proposition to solve this is to add a phase which will be executed after
the pom.xml is parsed, but before the information stored in
Model/MavenProject is used, and most importantly before the {{ReactorManager
is created}}. Then you can add information to the MavenProject
programatically, increasing the flexibility for plug-ins.
I am not fluent in the maven2 code base, but it seems to me that this require
quite a lot of changes to the code. As I understands it the life cycle starts
after the {{ReactorManager}} is made, and therefore after the information in
Model have started to be used.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2580) UNC in MAVEN_HOME not working
[ http://jira.codehaus.org/browse/MNG-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof updated MNG-2580: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x UNC in MAVEN_HOME not working - Key: MNG-2580 URL: http://jira.codehaus.org/browse/MNG-2580 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.4 Environment: Windows XP Reporter: Remy COQUEUGNIOT Priority: Blocker Fix For: 2.0.x Maven2 is installed in a corporate server : SERVER From my computer, this installation is accesible on a network share : \\SERVER\MAVEN2 From a command line I setup MAVEN_HOME with this UNC: set MAVEN_HOME=\\SERVER\MAVEN2 And put it in the PATH set PATH=%MAVEN_HOME%\bin;%PATH% When I try to build any projects, maven is unable to acces my global settings which is stored in %MAVEN_HOME%\conf\settings.xml But when I mount a network share to this UNC: net use Z: \\SERVER\MAVEN2 ...Setup MAVEN_HOME ... set MAVEN_HOME=Z:\ ...And put it in the PATH ... set PATH=%MAVEN_HOME%\bin;%PATH% The global settings.xml is read. This useCase seems OK with Maven 1. mvn -X doesn't give too any informations about the final %MAVEN_HOME%\conf which is used. But it prints the plugin-registry.xml locations which are based on the %MAVEN_HOME% In this case \\SERVER\MAVEN2 is badly transformed in C:\SERVER\MAVEN2 : set MAVEN_HOME=\\frmlefsi20\inet_dev\DEVPLATFORM\maven-2.0.4 mvn clean -X (...) [DEBUG] Building Maven global-level plugin registry from: 'C:\frmlefsi20\inet_dev\DEVPLATFORM\maven-2.0.4\bin\..\conf\plugin-registry.xml' (...) Thanks for your support and this great tool ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3001) Maven2 does not resolve version ranges correctly [PATCH INCLUDED]
[ http://jira.codehaus.org/browse/MNG-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99664 ] Kenney Westerhof commented on MNG-3001: --- I think the specificiation is wrong. [1.0,) should resolve to 1.0, 1.0.1-SNAPSHOT, 1.1-SNAPSHOT, 1.1 and higher (but not 1.0-SNAPSHOT). Wheter snapshots are included in resolution shouldn't be specified in the version range, but wheter a snapshot repository is declared or not. [1.0,) is a minimum version requirement, so this states that any version higher than or equal to 1.0 should work. [1.0,) cannot resolve to 1.0-SNAPSHOT. I added 2 tests in trunk to verify that. Maven2 does not resolve version ranges correctly [PATCH INCLUDED] - Key: MNG-3001 URL: http://jira.codehaus.org/browse/MNG-3001 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4, 2.0.6 Environment: Windows. Affects versions 2.04 2.06 minimum. Reporter: David Hoffer Assignee: Jason van Zyl Priority: Blocker Fix For: Reviewed Pending Version Assignment Attachments: VersionRangeSnapshotFix.patch Maven does not properly handle version ranges when the high end is unbounded. The spec clearly states that it should not resolve to a SNAPSHOT unless included as an explicit boundary. Currently maven2 does resolve to a SNAPSHOT which makes usage of version ranges to control versions of dependencies unworkable. (We currently use a local build of maven with this fix else we could not use version ranges. This is a major issue can you please include in the next release?) Code fix and unit tests are included. Example: dependency groupIdmyGroup/groupId artifactIdmyArtifact/artifactId version[1.0,)/version /dependency This version range can resolve to the latest development 1.0-SNAPSHOT. All artifact dependencies should ignore SNAPSHOTS as that is not intended by the unbounded high end of the version range. This should resolve to any released version of 1.1 or higher. This document: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges addressed the requirements for version ranges and stated that Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. I think this requirement was forgotten when version ranges were implemented. I have included a patch for this bug. The fix is in the containsVersion method of VersionRange. I have added tests in VersionRangeTest and DefaultArtifactCollectorTest. All tests in maven pass with this fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-78) Dependencies listed as version ${project.version} in maven-archetype prevent the use of archetypes
[
http://jira.codehaus.org/browse/ARCHETYPE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99666
]
Kenney Westerhof commented on ARCHETYPE-78:
---
This is caused by the fact that -Dversion=0.1 is provided on the commandline.
The archetype poms specify ${project.version}.
RegexBasedModelInterpolator strips off the leading project. (or pom. or env.)
and checks the context object for 'version', which it contains since -Dversion
was specified.
So in this case 0.1 is used for dependencies.
this will break with ALL maven builds that have a ${project.version} somewhere
and -Dversion is specified.
Dependencies listed as version ${project.version} in maven-archetype prevent
the use of archetypes
--
Key: ARCHETYPE-78
URL: http://jira.codehaus.org/browse/ARCHETYPE-78
Project: Maven Archetype
Issue Type: Bug
Affects Versions: 1.0-alpha-4
Reporter: Wayne Fay
Priority: Critical
Dependencies are listed as ${project.version} in deployed POM.
dependencyManagement
dependencies
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-model/artifactId
version${project.version}/version
/dependency
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-core/artifactId
version${project.version}/version
/dependency
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-creator/artifactId
version${project.version}/version
/dependency
/dependencies
/dependencyManagement
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2653) using ${version} for subproject dependencies doesn't work (maven uses 2.4.1 version instead)
[
http://jira.codehaus.org/browse/MNG-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99667
]
Kenney Westerhof commented on MNG-2653:
---
I'm tempted to 'close - won't fix'.
${version} is evaluated to either a system prop or a -Dversion=..., so this is
expected.
However, ${pom.version} _should_ be evaluated to the pom's version tag. But
that's a different issue alltogether.
using ${version} for subproject dependencies doesn't work (maven uses 2.4.1
version instead)
Key: MNG-2653
URL: http://jira.codehaus.org/browse/MNG-2653
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Environment: win xp, maven 2.0.1, eclipse plugin 0.0.3, eclipse 3.1
Reporter: Michal Stochmialek
Assignee: Jason van Zyl
Fix For: Reviewed Pending Version Assignment
Attachments: mngeclipse20-trigger.jpg, mvn-multiproject.zip,
org.maven.ide.eclipse-MNGECLIPSE-20-patch.txt
My project is a ear multiproject. It has 5 modules, that have internal
dependencies. For example web module needs app and type modules.
I usually use following declaration for this kind of dependencies. Note that
I'm using ${version} in dependency. In result I'm requesting foo-type jar of
the same version as current project.
project
modelVersion4.0.0/modelVersion
parent
groupIdfoo/groupId
artifactIdfoo/artifactId
version0.0.1-SNAPSHOT/version
/parent
artifactIdfoo-app/artifactId
dependencies
dependency
groupIdfoo/groupId
artifactIdfoo-type/artifactId
version${version}/version
/dependency
/dependencies
/project
This works from commandline, but doesn't work in eclipse plugin. I get
following message:
Unable to download the artifact from any repository foo:foo-type-2.4.1.jar
Maven (or maven plugin) tries to download foo-type module in very strange
version (instead 0.0.1-SNAPSHOT)!
I've attached simple multimodule project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-2339) ${project.*} are interpreted in the wrong place
[
http://jira.codehaus.org/browse/MNG-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof reopened MNG-2339:
---
this is not fixed.
${project.*} are interpreted in the wrong place
---
Key: MNG-2339
URL: http://jira.codehaus.org/browse/MNG-2339
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Reporter: Emmanuel Venisse
Assignee: Kenney Westerhof
Priority: Critical
Fix For: 2.0.6
If a plugin use ${project.version}, this parameter is interpreted with the
version of the current project and not the plugin version. I think we have
the same pb with dependencies and other ${project.*}
For a plugin in version 2.0 used in a project in version 1.0-SNAPSHOT,
${project.version} used in the plugin will be interpreted as 1.0-SNAPSHOT
instead of 2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2339) ${project.*} are interpreted in the wrong place
[
http://jira.codehaus.org/browse/MNG-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MNG-2339:
--
Fix Version/s: (was: 2.0.6)
2.0.8
${project.*} are interpreted in the wrong place
---
Key: MNG-2339
URL: http://jira.codehaus.org/browse/MNG-2339
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Reporter: Emmanuel Venisse
Assignee: Kenney Westerhof
Priority: Critical
Fix For: 2.0.8
If a plugin use ${project.version}, this parameter is interpreted with the
version of the current project and not the plugin version. I think we have
the same pb with dependencies and other ${project.*}
For a plugin in version 2.0 used in a project in version 1.0-SNAPSHOT,
${project.version} used in the plugin will be interpreted as 1.0-SNAPSHOT
instead of 2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-78) Dependencies listed as version ${project.version} in maven-archetype prevent the use of archetypes
[
http://jira.codehaus.org/browse/ARCHETYPE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed ARCHETYPE-78.
-
Resolution: Fixed
Fix Version/s: 1.0
Dupe of MNG-2339.
Fixed by removing ${project.version} in the poms and replacing it by the real
version string.
Dependencies listed as version ${project.version} in maven-archetype prevent
the use of archetypes
--
Key: ARCHETYPE-78
URL: http://jira.codehaus.org/browse/ARCHETYPE-78
Project: Maven Archetype
Issue Type: Bug
Affects Versions: 1.0-alpha-4
Reporter: Wayne Fay
Assignee: Kenney Westerhof
Priority: Critical
Fix For: 1.0
Dependencies are listed as ${project.version} in deployed POM.
dependencyManagement
dependencies
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-model/artifactId
version${project.version}/version
/dependency
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-core/artifactId
version${project.version}/version
/dependency
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-creator/artifactId
version${project.version}/version
/dependency
/dependencies
/dependencyManagement
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2651) POM interpolator treats ${pom.something} like ${something} and prefers system properties
[
http://jira.codehaus.org/browse/MNG-2651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2651.
-
Resolution: Duplicate
POM interpolator treats ${pom.something} like ${something} and prefers system
properties
Key: MNG-2651
URL: http://jira.codehaus.org/browse/MNG-2651
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.4
Reporter: Daniel Schulz
Assignee: Kenney Westerhof
Fix For: Reviewed Pending Version Assignment
The POM interpolator (RegexBasedModelInterpolator) removes all leading
pom., project. and env. portions of an expression before evaluating it.
then searching for values happens in the following order: system properties,
project properties, pom bean properties.
An example: Although ${pom.version} is more specific than ${version}, version
wins. That's the problem in MNGECLIPSE-20.
IMHO the interpolation strategy should be changed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2653) using ${version} for subproject dependencies doesn't work (maven uses 2.4.1 version instead)
[
http://jira.codehaus.org/browse/MNG-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2653.
-
Assignee: Kenney Westerhof (was: Jason van Zyl)
Resolution: Duplicate
using ${version} for subproject dependencies doesn't work (maven uses 2.4.1
version instead)
Key: MNG-2653
URL: http://jira.codehaus.org/browse/MNG-2653
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Environment: win xp, maven 2.0.1, eclipse plugin 0.0.3, eclipse 3.1
Reporter: Michal Stochmialek
Assignee: Kenney Westerhof
Fix For: Reviewed Pending Version Assignment
Attachments: mngeclipse20-trigger.jpg, mvn-multiproject.zip,
org.maven.ide.eclipse-MNGECLIPSE-20-patch.txt
My project is a ear multiproject. It has 5 modules, that have internal
dependencies. For example web module needs app and type modules.
I usually use following declaration for this kind of dependencies. Note that
I'm using ${version} in dependency. In result I'm requesting foo-type jar of
the same version as current project.
project
modelVersion4.0.0/modelVersion
parent
groupIdfoo/groupId
artifactIdfoo/artifactId
version0.0.1-SNAPSHOT/version
/parent
artifactIdfoo-app/artifactId
dependencies
dependency
groupIdfoo/groupId
artifactIdfoo-type/artifactId
version${version}/version
/dependency
/dependencies
/project
This works from commandline, but doesn't work in eclipse plugin. I get
following message:
Unable to download the artifact from any repository foo:foo-type-2.4.1.jar
Maven (or maven plugin) tries to download foo-type module in very strange
version (instead 0.0.1-SNAPSHOT)!
I've attached simple multimodule project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2782) Version property in dependencies is not expanded correctly
[
http://jira.codehaus.org/browse/MNG-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2782.
-
Resolution: Duplicate
Version property in dependencies is not expanded correctly
--
Key: MNG-2782
URL: http://jira.codehaus.org/browse/MNG-2782
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Reporter: Carsten Ziegeler
Fix For: Reviewed Pending Version Assignment
The Spring poms, for example spring-beans, version 2.0.2 use the following
dependencies:
dependency
groupId${project.groupId}/groupId
artifactIdspring-core/artifactId
version${project.version}/version
/dependency
Which means, they are using variables in the poms. In some cases, these
variables are resolved correctly, but in some cases however they are not,
causing problems.
Imho, it would be better to resolve variables for released poms to avoid any
problems (or if variables are allowed, this is a maven bug then)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2796) Yet another snapshot/timestamp version resolution problem
[
http://jira.codehaus.org/browse/MNG-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2796.
-
Resolution: Duplicate
Yet another snapshot/timestamp version resolution problem
-
Key: MNG-2796
URL: http://jira.codehaus.org/browse/MNG-2796
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories, Inheritance and Interpolation
Affects Versions: 2.0.4
Reporter: David Jencks
Fix For: Reviewed Pending Version Assignment
In the geronimo openejb3 integration we've encountered yet another problem
with broken version resolution. It would be great if the maven team could
fix these problems soon: I think that the geronimo and openejb developers
have now spent several weeks trying to understand bizarre version resolution
errors and trying to find workarounds for them.
Here's what we think the relevant project details are. Reproducing this
problem requires deploying snapshots at different revision numbers so I don't
really see how to provide a test project.
openejb project structure:
base openejb pom
openejb container pom, parent is openejb pom. Snapshot deployed with a
timestamped version 3.0-incubating-20070126.103431-21
openejb server pom, parent is openejb pom. Snapshot deployed with a
timestamped version 3.0-incubating-20070126.103431-20
server pom has a dependency on container pom, using this:
dependencies
dependency
groupIdorg.apache.openejb/groupId
artifactIdcontainer/artifactId
version${pom.version}/version
typepom/type
scopecompile/scope
/dependency
/dependencies
Subproject server/openejb-ejbd, parent pom is server.pom. Snapshot deployed
at 3.0-incubating-20070126.103431-20
Both container and server are pom-packaged projects, i.e. they have no code
of their own.
Openejb builds and deploys fine by itself, and the timestamped versions are
as indicated above.
geronimo-openejb module has a dependency
dependency
groupIdorg.apache.openejb/groupId
artifactIdopenejb-ejbd/artifactId
/dependency
whose version is supplied in an ancestor dependencyManagement section:
dependency
groupIdorg.apache.openejb/groupId
artifactIdopenejb-ejbd/artifactId
version${openejbVersion}/version
/dependency
where
openejbVersion3.0-incubating-SNAPSHOT/openejbVersion
When we build the geronimo-openejb module in geronimo the build breaks
because the incorrect version of openejb container is resolved:
This appears to be the relevant section of the -X trace, note that after the
incorrect non-resolution at -20 container is correctly resolved at -21 a few
lines later:
[DEBUG] openejb-client: resolved to version 3.0-incubating-20070126.103431-20
from repository apache.snapshots
[DEBUG] Retrieving parent-POM:
org.apache.openejb:server::3.0-incubating-SNAPSHOT for project:
null:openejb-client:jar:3.0-incubating-20070126.103431-20 from the repository.
[DEBUG] server: resolved to version 3.0-incubating-20070126.103431-20 from
repository apache.snapshots
[DEBUG] Retrieving parent-POM:
org.apache.openejb:openejb::3.0-incubating-SNAPSHOT for project:
null:server:pom:null from the repository.
[DEBUG] openejb: resolved to version 3.0-incubating-20070126.103431-22 from
repository apache.snapshots
[DEBUG] Retrieving parent-POM: org.apache:apache::3 for project:
org.apache.openejb:openejb:pom:3.0-incubating-SNAPSHOT from the repository.
[DEBUG]
org.apache.openejb:openejb-client:jar:3.0-incubating-SNAPSHOT:compile
(selected for compile)
[DEBUG] Retrieving parent-POM: org.apache.geronimo.specs:specs::1.2 for
project: null:geronimo-ejb_3.0_spec:jar:1.0-M1 from the repository.
[DEBUG] Retrieving parent-POM:
org.apache.geronimo.genesis.config:project-config::1.1 for project:
org.apache.geronimo.specs:specs:pom:1.2 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.geronimo.genesis.config:config::1.1
for project: null:project-config:pom:null from the repository.
[DEBUG] Retrieving parent-POM: org.apache.geronimo.genesis:genesis::1.1 for
project: org.apache.geronimo.genesis.config:config:pom:null from the
repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::3 for project:
org.apache.geronimo.genesis:genesis:pom:1.1 from the repository.
[DEBUG]
org.apache.geronimo.specs:geronimo-ejb_3.0_spec:jar:1.0-M1:compile (removed -
nearer found: 1.0)
[DEBUG] Artifact not found - using stub model: System is offline.
org.apache.openejb:container:pom:3.0-incubating-20070126.103431-20
[DEBUG] Using defaults for missing POM
org.apache.openejb:container:pom:3.0-incubating-SNAPSHOT:compile
[DEBUG]
[jira] Closed: (MNG-2647) Version not inherited for SNAPSHOT version
[
http://jira.codehaus.org/browse/MNG-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2647.
-
Resolution: Duplicate
Version not inherited for SNAPSHOT version
--
Key: MNG-2647
URL: http://jira.codehaus.org/browse/MNG-2647
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation, POM
Affects Versions: 2.0.4
Environment: Windows 2000
Reporter: Stéphane Veyret
Fix For: Reviewed Pending Version Assignment
Attachments: module1.pom, parent.pom
I have the parent module which defines 2 modules. In the modules, the version
is inherited from the parent. If I am working on a SNAPSHOT version, the
child modules get the timestamp version instead of what was given to parent.
If you have a look at the attachements, the problem is that module1 version
in deployed pom will be something like 1234567.123456-7 and when searching
for dependent module2 version, will fail because it will try to download a
released version 1234567.123456-7 of module 2.
Only this seem to be a bug to me, but this is even stranger considering the
version of module2 is defined in dependecyManagement of parent pom with
${project.version}. This project.version is correct (3.4.0_SNAPSHOT) in
parent pom !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2339) ${project.*} are interpreted in the wrong place
[
http://jira.codehaus.org/browse/MNG-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99673
]
Kenney Westerhof commented on MNG-2339:
---
This issue deals with ${project.version}, or ${version}, or ${xxx.version} for
that matter, all being treated like ${version}.
commandline arguments like -Dversion=foo will have effect on the dependencies
or wherever one of the expressions above is used.
${project.version} and ${pom.version} should ALWAYS resolve to a version tag
in the pom.
RegexBasedModelInterpolator strips off the first part (project.) and then
checks the context for the value. This is wrong.
Issue MNG-2486 is different - that one deals with the fact that SNAPSHOT
version expressions, which are correctly interpolated from the pom and not from
external properties,
are evaluated to the timestamped version instead of the string present in the
model.
${project.*} are interpreted in the wrong place
---
Key: MNG-2339
URL: http://jira.codehaus.org/browse/MNG-2339
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Reporter: Emmanuel Venisse
Assignee: Kenney Westerhof
Priority: Critical
Fix For: 2.0.8
If a plugin use ${project.version}, this parameter is interpreted with the
version of the current project and not the plugin version. I think we have
the same pb with dependencies and other ${project.*}
For a plugin in version 2.0 used in a project in version 1.0-SNAPSHOT,
${project.version} used in the plugin will be interpreted as 1.0-SNAPSHOT
instead of 2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT
[
http://jira.codehaus.org/browse/MNG-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MNG-2486:
--
Assignee: (was: Kenney Westerhof)
Affects Version/s: 2.1-alpha-1
2.0.7
2.0.5
2.0.6
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1-alpha-1
2.0.8
Issue Type: Bug (was: Improvement)
Summary: ${project.version} evaluated to timestamped version if
referring to SNAPSHOT (was: disallow use of ${project.version} in dependency
versions)
${project.version} evaluated to timestamped version if referring to SNAPSHOT
Key: MNG-2486
URL: http://jira.codehaus.org/browse/MNG-2486
Project: Maven 2
Issue Type: Bug
Components: Dependencies, Inheritance and Interpolation, POM
Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1-alpha-1
Reporter: John Casey
Priority: Critical
Fix For: 2.0.8, 2.1-alpha-1
when projects specify dependencyManagement sections with a shorthand version
notation using the current project version (using ${project.version}) the
version resolved will be that of the POM in which the dependencyManagement
section is specified. If this POM is a snapshot, these dependency
specifications will get the timestamp/buildnumber of that POM, instead of the
actual one used when the dependency it references gets deployed.
We should look at strategies for limiting or eliminating this practice, or
else (somehow) pulling the real timestamp/buildnumber for that artifact from
the reactor...in order to make these deps transitively resolvable for users.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT
[
http://jira.codehaus.org/browse/MNG-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99676
]
Kenney Westerhof commented on MNG-2486:
---
This issue deals with the fact that whenever ${project.version} or
${pom.version} is evaluated to a POM version tag (be it parent,
or project, present in a dependency or dependencyManagement or anywhere else in
the POM),
and that version is a SNAPSHOT version, then the timestamped version is used,
instead of the literal string.
This causes problems with multimodule builds that share versions but aren't
always deployed as a whole.
Even if they are deployed as a whole, this could cause problems since the
timestamps might not be the same for all artifacts.
${project.version} evaluated to timestamped version if referring to SNAPSHOT
Key: MNG-2486
URL: http://jira.codehaus.org/browse/MNG-2486
Project: Maven 2
Issue Type: Bug
Components: Dependencies, Inheritance and Interpolation, POM
Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1-alpha-1
Reporter: John Casey
Priority: Critical
Fix For: 2.0.8, 2.1-alpha-1
when projects specify dependencyManagement sections with a shorthand version
notation using the current project version (using ${project.version}) the
version resolved will be that of the POM in which the dependencyManagement
section is specified. If this POM is a snapshot, these dependency
specifications will get the timestamp/buildnumber of that POM, instead of the
actual one used when the dependency it references gets deployed.
We should look at strategies for limiting or eliminating this practice, or
else (somehow) pulling the real timestamp/buildnumber for that artifact from
the reactor...in order to make these deps transitively resolvable for users.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2569) Expressions not evaluated inside parent
[ http://jira.codehaus.org/browse/MNG-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof updated MNG-2569: -- Summary: Expressions not evaluated inside parent (was: The version tag within the parrent block does not evaluate properties.) Expressions not evaluated inside parent - Key: MNG-2569 URL: http://jira.codehaus.org/browse/MNG-2569 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation, POM, Reactor and workspace Affects Versions: 2.0.4 Environment: WinXP Java 1.5_08 Maven 2.04 Reporter: Thomas Minor Priority: Minor Fix For: Reviewed Pending Version Assignment The version tag within the parrent block does not evaluate properties. If I put a Version String directly in there, it works. A correctly defined property doesn't. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3009) Maven 2.0.5+ fails to resolve ${project.version} on deployment
[
http://jira.codehaus.org/browse/MNG-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-3009.
-
Resolution: Duplicate
Maven 2.0.5+ fails to resolve ${project.version} on deployment
--
Key: MNG-3009
URL: http://jira.codehaus.org/browse/MNG-3009
Project: Maven 2
Issue Type: Bug
Components: Deployment
Affects Versions: 2.0.5, 2.0.6
Reporter: Stefan Behnel
Priority: Blocker
Fix For: Reviewed Pending Version Assignment
Starting with version 2.0.5, Maven fails to resolve the ${project.version}
variable in poms on (SNAPSHOT?) deployment. This results in corrupted
repositories, as Maven will (sporadically) fail to resolve transitive
dependencies that involve these references.
The symptom is that Maven will start searching for a magical version 2.4.1
of an artifact, although such a version never existed and was never written
in any POM. Dependent builds therefor fail as this version cannot be resolved.
The deploy plugin should *always* resolve all involved versions when it
uploads POMs.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2745) Do not allow System properties to be interpolated in the POM
[
http://jira.codehaus.org/browse/MNG-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2745.
-
Resolution: Duplicate
Do not allow System properties to be interpolated in the POM
Key: MNG-2745
URL: http://jira.codehaus.org/browse/MNG-2745
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.4
Environment: Windows using JDK 1.4.2
Reporter: Jason van Zyl
Assignee: Jason van Zyl
Fix For: 2.1.x
There is an XML library which is inserting a property version=2.4.1 and it is
completely screwing up the interpolation of ${version} in any POM.
1) We should force fully qualified references anyway so ${pom.version} and
not allow ${version}
2) Totally shut out System properties from all internal operations. We can
still take -D from the command line and turn them into execution properties
but we should just ignore all Sytem properties in the core.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2199) Version ranges not supported for parent artifacts
[
http://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99678
]
Kenney Westerhof commented on MNG-2199:
---
tempting to 'close - won't fix'.
Whatever parent pom is present in the local repo will be used, resulting in a
different effective pom on different systems.
This'll be the cause of all sorts of problems.
Version ranges not supported for parent artifacts
-
Key: MNG-2199
URL: http://jira.codehaus.org/browse/MNG-2199
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
Fix For: 2.1.x
It would be great if Maven supports version ranges when specifying parent
artifacts in a multi-module build. Currently this does not work.
parent
artifactIdartifactId/artifactId
groupIdgroupId/groupId
version[2.0, 2.0.1]/version
/parent
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
2.0.1]/artifactId-[2.0, 2.0.1].pom
Additionally it would be great if this
parent
artifactIdartifactId/artifactId
groupIdgroupId/groupId
version[2.0, ${pom.version}]/version
/parent
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
${pom.version}]/artifactId-[2.0, ${pom.version}].pom
would also work, if the version is specified in the same pom.xml which
defines this parent definition.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2915) No way to avoid adding artifactId to site urls
[
http://jira.codehaus.org/browse/MNG-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99680
]
Kenney Westerhof commented on MNG-2915:
---
Place to fix:
maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
perhaps check wheter the parentpath already contains an expression for
artifactId, or maybe add a decision
whether to append based on the path ending in a slash or not.
No way to avoid adding artifactId to site urls
--
Key: MNG-2915
URL: http://jira.codehaus.org/browse/MNG-2915
Project: Maven 2
Issue Type: Improvement
Components: Sites Reporting
Affects Versions: 2.0.5
Reporter: Richard van der Hoff
Priority: Minor
Fix For: Reviewed Pending Version Assignment
Currently, whenever a child pom inherits from a parent (and doesn't override
the relevant settings), both project.url and
project.distributionManagement.site.url have the name of the child artifact
appended.
It would be nice to be able to have something like
:code:
urlscpexe://host/blah/${project.artifactId}/${project.version}/url
:code:
and have this inherited to all child poms in the obvious way.
My usecase for this is that we have a single parent pom for all our projects,
with useful settings such as distributionManagement, and I'd like to be able
to deploy their sites to a single directory and have Apache generate me a
directory listing for all the child projects. However, I curently have no way
of releasing the parent project without obliterating the list of child
projects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2915) No way to avoid adding artifactId to site urls
[
http://jira.codehaus.org/browse/MNG-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MNG-2915:
--
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1-alpha-1
No way to avoid adding artifactId to site urls
--
Key: MNG-2915
URL: http://jira.codehaus.org/browse/MNG-2915
Project: Maven 2
Issue Type: Improvement
Components: Sites Reporting
Affects Versions: 2.0.5
Reporter: Richard van der Hoff
Priority: Minor
Fix For: 2.1-alpha-1
Currently, whenever a child pom inherits from a parent (and doesn't override
the relevant settings), both project.url and
project.distributionManagement.site.url have the name of the child artifact
appended.
It would be nice to be able to have something like
:code:
urlscpexe://host/blah/${project.artifactId}/${project.version}/url
:code:
and have this inherited to all child poms in the obvious way.
My usecase for this is that we have a single parent pom for all our projects,
with useful settings such as distributionManagement, and I'd like to be able
to deploy their sites to a single directory and have Apache generate me a
directory listing for all the child projects. However, I curently have no way
of releasing the parent project without obliterating the list of child
projects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2241) Versions are required when it shouldn't with multi-modules projects and war dependencies
[
http://jira.codehaus.org/browse/MNG-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99681
]
Kenney Westerhof commented on MNG-2241:
---
Specifying type in the dependencies in depMgt for deps that aren't
packagingjar should solve this.
However this needs to be fixed. A more strict separation between packaging,
types, and classifiers should be enforced.
The default of typejar/type in a dependency is bogus - it needs to be the
same as the packaging from the pom for that artifact/dependency.
Specifing, for instance, a test-jar dependency, you can say
typetest-jar/type. Since this is not a derived artifact, classifiers don't
apply here.
It's an alternative packaging, so typetest-jar/type is correct. Classifiers
shouldn't apply here.
The same goes for attached assemblies.
Are Javadoc and source jars considered derived or alternative? Since the source
_could_ theoretically be derived from the main artifact, it could be a
classifier,
though you'd miss the javadoc, so I think these are alternatives, and a type
is wise here.
For war and ear artifacts, the packaging _is_ the main type; it's not an
attachment, either derived or alternative, so type shouldn't be needed
in dependencies or dependencyManagement.
Also, i've never seen multiple classifiers for one type, where the type is not
the main type.
Anyway, since this (typejar/type being the default for dependencies) is
documented, this should be a closed-won't fix, though since I disagree with
the spec/documentation I'll leave this open.
Versions are required when it shouldn't with multi-modules projects and war
dependencies
Key: MNG-2241
URL: http://jira.codehaus.org/browse/MNG-2241
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.4
Environment: Maven 2.0.4, Java 5, Windows XP
Reporter: Celso Gomes Barreto Junior
Fix For: 2.1.x
In a multi-project with a parent pom which should enforces modules's versions
in dependencyManagement element, when I use a war dependnecy it starts to
require the version declaration in child pom's dependencies. When I use jar
dependencies, it works fine.
Project structure:
parent project
|_ web (war)
|_ commons (jar)
|_ webcommons (war)
--
parent project pom:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
nameProcdev - Referência/name
groupIdglobo/groupId
artifactIdprocdevref/artifactId
packagingpom/packaging
version0.0.1/version
descriptionno/description
modules
moduleweb/module
modulecommons/module
modulewebcommons/module
/modules
dependencyManagement
dependencies
dependency
groupIdglobo/groupId
artifactIdprocdevref-web/artifactId
version${project.version}/version
/dependency
dependency
groupIdglobo/groupId
artifactIdprocdevref-commons/artifactId
version${project.version}/version
/dependency
dependency
groupIdglobo/groupId
artifactIdprocdevref-webcommons/artifactId
version${project.version}/version
/dependency
/dependencies
/dependencyManagement
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
/project
--
web project pom:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
parent
groupIdglobo/groupId
artifactIdprocdevref/artifactId
version0.0.1/version
/parent
nameProcdev Web/name
artifactIdprocdevref-web/artifactId
packagingwar/packaging
version0.0.1/version
descriptionno/description
dependencies
dependency
groupIdglobo/groupId
artifactIdprocdevref-webcommons/artifactId
typewar/type
/dependency
dependency
groupIdglobo/groupId
artifactIdprocdevref-commons/artifactId
/dependency
dependency
groupIdjstl/groupId
artifactIdjstl/artifactId
version[1.1.2,]/version
/dependency
dependency
groupIdtaglibs/groupId
artifactIdstandard/artifactId
version[1.1.2,]/version
/dependency
/dependencies
/project
--
webcommons project pom:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
parent
groupIdglobo/groupId
artifactIdprocdevref/artifactId
version0.0.1/version
/parent
nameProcdev Web Commons/name
artifactIdprocdevref-webcommons/artifactId
packagingwar/packaging
[jira] Commented: (MNG-2340) Incorrect dependency version downloaded
[
http://jira.codehaus.org/browse/MNG-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99682
]
Kenney Westerhof commented on MNG-2340:
---
Maven 2.0.6 and 2.0.7 do it like this:
- depMgt provides defaults; so if a child pom declares a dependency present in
depMgt, with a different version, the version from the child pom is used.
Maven 2.0.4 and 2.0.5 do it like this:
- depMgt provides OVERRIDES, so if a child pom declares a dependency present in
depMgt, with a different version, the version from depMgt is used.
The difference probably is that you use the commandline version of maven, 2.0.4
or 2.0.5, and in eclipse you use the embedder which is based
on 2.1, and uses the same approach as 2.0.6 and 2.0.7.
I think that when you use the commandline version 2.0.6 or newer, you'll see
that m2eclipse and maven commandline both use the same approach.
Incorrect dependency version downloaded
---
Key: MNG-2340
URL: http://jira.codehaus.org/browse/MNG-2340
Project: Maven 2
Issue Type: Bug
Components: Embedding
Affects Versions: 2.0.4
Reporter: Adrian
Priority: Critical
Fix For: 2.1.x
Attachments: MNGECLIPSE-131.zip
I have a parent pom with a dependency management section specifying the
version of an artifact to use. In the child project, I override this version.
The maven plugin ignores the overriding version and downloads the version
specified by the parent pom.
For example, in the parent pom
{code}
dependency
groupIdlucene/groupId
artifactIdlucene/artifactId
version1.4.3/version
/dependency
{code}
in the project pom, inheriting the parent pom
{code}
dependency
groupIdlucene/groupId
artifactIdlucene/artifactId
version2.0/version
/dependency
{code}
The maven eclipse plugin downloads version 1.4.3 for my project
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2826) Integration-test target runs integration tests twice
[
http://jira.codehaus.org/browse/MNG-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2826.
-
Resolution: Won't Fix
This is not a bug nor an issue; this should've been asked on the users list.
what you're doing is declaring the surefire plugin's test goal again, when it
is already defined
implicitly in the test phase.
If you have tests you do not want to execute during the normal test phase, you
should exclude them
from the execution;
Define an execution, phase test, goal test, outside of the profile.
Add excludes to **/*ITest.java (inside a configuration tag in the execution
tag) or whatever your integration test classes are.
Then update the execution for the integration test profile and add an includes
there for **/*ITest.
Surefire will run twice, once in the test phase, once in the integration-test
phase, but executing different
tests.
Integration-test target runs integration tests twice
Key: MNG-2826
URL: http://jira.codehaus.org/browse/MNG-2826
Project: Maven 2
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 2.0.4
Environment: Win XP
Reporter: EJ Ciramella
Fix For: Reviewed Pending Version Assignment
So we have two types of tests, unit and integration.
What we've attempted to do is bind the integration-test lifecycle to the
test phase but ONLY run the *Utest.java tests when integration-test
was specified.
What happens is, by default, the test goal works fine, but when you
specify integration-test it runs the *Utest.java tests twice.
I'll attach the logs shortly...
Here's the important part from the log:
[INFO]
[INFO] Building Reward Engine
[INFO]task-segment: [integration-test]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] Surefire report directory:
E:\work\LTY-P39\rewardEngine\..\reportsdirectory
---
T E S T S
---
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
E:\work\LTY-P39\rewardEngine\target\rewardEngine-1.0-SNAPSHOT.jar
[INFO] Preparing javadoc:javadoc
[WARNING] Removing: javadoc from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] [javadoc:javadoc {execution: default}]
39 warnings
[INFO] [surefire:test {execution: surefire-iTest}]
[INFO] Surefire report directory:
E:\work\LTY-P39\rewardEngine\..\reportsdirectory
---
T E S T S
---
Running com.upromise.common.reward.RewardEngineITest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 24.123
sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] [surefire:test {execution: surefire-iTest}]
[INFO] Surefire report directory:
E:\work\LTY-P39\rewardEngine\..\reportsdirectory
---
T E S T S
---
Running com.upromise.common.reward.RewardEngineITest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 25.23
sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
Here are the details of my pom:
I'm having a problem binding our integration tests to the
integration-test lifecycle goal.
Can anyone explain why this would happen twice?
Here's my pom:
?xml version=1.0 encoding=ISO-8859-1?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
parent
groupIdlty/groupId
artifactIdapp/artifactId
version1.0-SNAPSHOT/version
/parent
artifactIdrewardEngine/artifactId
packagingjar/packaging
version1.0-SNAPSHOT/version
descriptionModule to calculate rewards/description
nameReward Engine/name
urlhttp://www.upromise.com/url
build
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
/resource
/resources
plugins
plugin
[jira] Closed: (MNG-2448) Can not exclude a dependency from a plugin
[ http://jira.codehaus.org/browse/MNG-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof closed MNG-2448. - Resolution: Won't Fix Just redeclare the dependency as you normally do inside plugindependencies. Since maven 2.0.5, (or possibly 2.0.6) that declaration will override the one from the plugin itself. Can not exclude a dependency from a plugin -- Key: MNG-2448 URL: http://jira.codehaus.org/browse/MNG-2448 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Dain Sundstrom Fix For: Reviewed Pending Version Assignment I need to be able to exclude a dependency that a plugin included so I can replace it with a different dependency. In this exact case I'm attempting to use the com.sun.tools.xjc.maven2:maven-jaxb-plugin:1.0 plugin and it depends on the non-public jsr173 jar. I would like to exclude that jar so I can include public stax one. I know this will be fixed by implementing the spec resolution feature, but excluding bad dependencies from a plugin is a general problem. The following snippit will demonstrate the download problem assuming you don't have the jsr173 jar available: plugin groupIdcom.sun.tools.xjc.maven2/groupId artifactIdmaven-jaxb-plugin/artifactId version1.0/version executions execution goals goalgenerate/goal /goals /execution /executions configuration generatePackageorg.apache.xbean.jaxb.schema/generatePackage /configuration /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2434) Local snapshots should be preferred over remote ones
[ http://jira.codehaus.org/browse/MNG-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99688 ] Kenney Westerhof commented on MNG-2434: --- Could this be tested again with 2.0.6? I think there's a fix for another issue that may solve this one as a side-effect. Local snapshots should be preferred over remote ones Key: MNG-2434 URL: http://jira.codehaus.org/browse/MNG-2434 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Carsten Ziegeler Fix For: Reviewed Pending Version Assignment If you're build a project with snapshots, m2 tries to download the newest versions of the snapshots even if the local ones are newer. Interestingly later on, the local versions are used. So the download is useless. A complex test case for this is the Cocoon project where nearly all modules are snapshot and locally build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2434) Local snapshots should be preferred over remote ones
[ http://jira.codehaus.org/browse/MNG-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99698 ] Kenney Westerhof commented on MNG-2434: --- Thanks for testing! Marking this closed and fixed in 2.0.6. Local snapshots should be preferred over remote ones Key: MNG-2434 URL: http://jira.codehaus.org/browse/MNG-2434 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Carsten Ziegeler Fix For: 2.0.6 If you're build a project with snapshots, m2 tries to download the newest versions of the snapshots even if the local ones are newer. Interestingly later on, the local versions are used. So the download is useless. A complex test case for this is the Cocoon project where nearly all modules are snapshot and locally build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2434) Local snapshots should be preferred over remote ones
[ http://jira.codehaus.org/browse/MNG-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof closed MNG-2434. - Resolution: Fixed Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.6 Local snapshots should be preferred over remote ones Key: MNG-2434 URL: http://jira.codehaus.org/browse/MNG-2434 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Carsten Ziegeler Fix For: 2.0.6 If you're build a project with snapshots, m2 tries to download the newest versions of the snapshots even if the local ones are newer. Interestingly later on, the local versions are used. So the download is useless. A complex test case for this is the Cocoon project where nearly all modules are snapshot and locally build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1378) Make dependencies of test-jars transitive
[ http://jira.codehaus.org/browse/MNG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof updated MNG-1378: -- Summary: Make dependencies of test-jars transitive (was: Make test dependencies transitive) changed the title as 'Make test dependencies transitive' is incorrect. Test dependencies are dependencies with scope test. test-jar dependencies are something totally different, and they can have scope compile. Make dependencies of test-jars transitive - Key: MNG-1378 URL: http://jira.codehaus.org/browse/MNG-1378 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0 Reporter: Mark Hobson Fix For: 2.1.x test-jar transitive dependencies are calculated as per compile scope rather than test scope. The situation is demonstrated nicely in it0077: * module sub1 has a test-scoped dependency of commons-lang * module sub2 has a test-scoped dependency of sub1 test-jar sub2 tests should inherit the commons-lang transitive dependency. For example: Index: maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java === --- maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java (revision 328307) +++ maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java (working copy) @@ -1,6 +1,7 @@ package org.apache.maven.it0077; import junit.framework.TestCase; +import org.apache.commons.lang.BooleanUtils; public class PersonTwoTest extends PersonTest Results in: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31] package org.apache.commons.lang does not exist -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3043) Allow 'mvn test' to work with test-jar dependencies in a reactor
Allow 'mvn test' to work with test-jar dependencies in a reactor Key: MNG-3043 URL: http://jira.codehaus.org/browse/MNG-3043 Project: Maven 2 Issue Type: Bug Components: Dependencies, Reactor and workspace Affects Versions: 2.0.6, 2.0.7, 2.1 Reporter: Kenney Westerhof Basically the issue is demonstrated by MNG-2045, but instead of running 'mvn install', you run 'mvn test'. Test classes of dependencies should be resolved from the reactor, just as main classes, if there's no archive available. I'm not sure how to go about this. Specifying a dependency on something with typetest-jar/type, and having that dependency declare the maven-jar-plugin with the 'test-jar' goal is insufficient. Perhaps we can just add a standard classifier that maven is aware of, in this case 'tests'. The jar packaging would export this as a known classifier, and tells maven how it contributes to what classpath. Since test sources are a first class citizen, just as main sources are (they have the same phases, same elements in the pom (but differently named)). It seems logical to me that somehow the test classes should be made available to dependencies, if they declare a dependency with classifier 'tests'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2010) Add new lifecycle phases for IT
[ http://jira.codehaus.org/browse/MNG-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98190 ] Kenney Westerhof commented on MNG-2010: --- I have to agree with jason and john - keep the lifecycle small. About a year ago I started the maven-it-plugin, with the idea of using any standard lifecycle as a 'forked' sub-lifecycle. the 'integration-test' phase would run maven (embedded) on src/it/*/pom.xml, where each project could run any lifecycle they wish - by specifying a packaging. Normally you'd just have some tests in src/test/ which get executed. This way you can run multiple integration tests, without separate modules (unless you see src/it/* as modules). I think this, or something similar, is the way to go. We cannot simply grow the main lifecycle any time another usecase comes up. it's already too big - there should be just one integration-test phase; i don't even see the need for the pre- and post- phases there. It should be a hook to run a new lifecycle, like a subroutine. That should be flexible enough for anybody. Add new lifecycle phases for IT --- Key: MNG-2010 URL: http://jira.codehaus.org/browse/MNG-2010 Project: Maven 2 Issue Type: Task Components: integration tests, Plugins and Lifecycle Reporter: Vincent Massol Fix For: 2.0.x Attachments: MNG-2010-maven-lifecycle.patch, MNG-2010-site.patch Namely: * generate-integration-test-sources * process-integration-test-sources * generate-integration-test-resources * process-integration-test-resources * integration-test-compile and possibly a: * integration-test-package -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2771) Provide a means of loading custom substitute components instead of default Maven components
[ http://jira.codehaus.org/browse/MNG-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98192 ] Kenney Westerhof commented on MNG-2771: --- I don't think this'll be available in 2.0.x, as it uses some heavily refactored code in 2.1. It should now all work in 2.1-snapshot; the extensions is not mentioned in the m2.conf because it needs special treatment. The embedder/cli will check if M2_HOME/extensions exists and process it's contents during startup. The reason it's not in m2.conf is that m2.conf is for the classworlds booter and contains no maven specific configuration whatsoever. The extensions are maven specific. m2.conf should actually be called 'classworlds.conf' since it's unrelated to maven itself. Provide a means of loading custom substitute components instead of default Maven components --- Key: MNG-2771 URL: http://jira.codehaus.org/browse/MNG-2771 Project: Maven 2 Issue Type: New Feature Components: General Affects Versions: 2.0.4 Reporter: John Casey Assignee: Kenney Westerhof Fix For: 2.1-alpha-1 At times, it is necessary to use different mechanisms for resolving artifacts, building projects, etc. Since Maven is built on component-oriented technology, it should be possible to substitute the component implementation used for these tasks. Yet this is currently impossible. We need a mechanism for specifying, resolving, loading, and using custom components during the build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-61) Incorrect classpath ordering
[ http://jira.codehaus.org/browse/SUREFIRE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof updated SUREFIRE-61: - Description: Surefire incorrectly interprets classpath ordering. Steps to reproduce: 1. unzip my-app.zip - it's a simple mvn project created with mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app and lightly patched 2. mvn test in my case, it prints out jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties which is incorrect. log4j.properties is located both in jxta.jar and src/test/resources, but I think that src/test/resources takes precedence over jxta. This ordering is set correctly in surefire36745tmp file I think, but surefire seems to ignore the ordering. was: Surefire incorrectly interprets classpath ordering. Steps to reproduce: 1. unzip my-app.zip - it's a simple mvn project created with mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app and lightly patched 2. mvn test in my case, it prints out jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties which is incorrect. log4j.properties is located both in jxta.jar and src/test/resources, but I think that src/test/resources takes precedence over jxta. This ordering is set correctly in surefire36745tmp file I think, but surefire seems to ignore the ordering. Testcase included: (was: yes) Complexity: (was: Intermediate) Cannot reproduce with surefire 2.4-snapshot from trunk. The classpath seems ok: - first target/test-classes - then target/classes - then dependencies It prints out the path to the target/test-classes/log4j.properties. There's no 'sort' anywhere in the surefire sources. Can you please check this again with the latest surefire snapshots to see if it's solved? Incorrect classpath ordering Key: SUREFIRE-61 URL: http://jira.codehaus.org/browse/SUREFIRE-61 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.0 (2.2 plugin) Environment: maven2.0.4, sun-jdk-1.5.0.09, maven-surefire-plugin 2.2, surefire 2.0, gentoo linux x86 Reporter: Martin Vysny Priority: Critical Fix For: 2.4 Attachments: my-app.zip, SUREFIRE61_barrettas_surefire_surefire-booter_for_rev_489098.patch Surefire incorrectly interprets classpath ordering. Steps to reproduce: 1. unzip my-app.zip - it's a simple mvn project created with mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app and lightly patched 2. mvn test in my case, it prints out jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties which is incorrect. log4j.properties is located both in jxta.jar and src/test/resources, but I think that src/test/resources takes precedence over jxta. This ordering is set correctly in surefire36745tmp file I think, but surefire seems to ignore the ordering. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-42) TestListenerInvocationHandler incorrectly assumes getName()
[ http://jira.codehaus.org/browse/SUREFIRE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof updated SUREFIRE-42: - Description: I'm running test cases that extend our own custom base test case. If one of the tests fails, Surefire itself fails: org.apache.maven.surefire.booter.SurefireExecutionException: com.cerner.system.util.CalendarsTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: com.cerner.system.util.CalendarsTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null org.apache.maven.surefire.testset.TestSetFailedException: com.cerner.system.util.CalendarsTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null java.lang.reflect.UndeclaredThrowableException at $Proxy0.addError(Unknown Source) at junit.framework.TestResult.addError(TestResult.java:36) ... Caused by: java.lang.NoSuchMethodException: com.cerner.junit.madhatter.classreloader.ReloadedTestCaseDecorator.getName() at java.lang.Class.getMethod(Class.java:986) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.getStackTraceWriter(TestListenerInvocationHandler.java:171) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAddError(TestListenerInvocationHandler.java:160) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke(TestListenerInvocationHandler.java:134) ... 23 more At TestListenerInvocationHandler:171, I see that it's trying to reflect to a method called getName(). This seems like a very poor assumption, given that nothing on the Test or TestListener interfaces guarantees that there'll be a method called getName(). At the very least, shouldn't the NoSuchMethodException be caught and handled somewhere? See: http://www.junit.org/junit/javadoc/3.8.1/index.htm was: I'm running test cases that extend our own custom base test case. If one of the tests fails, Surefire itself fails: org.apache.maven.surefire.booter.SurefireExecutionException: com.cerner.system.util.CalendarsTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: com.cerner.system.util.CalendarsTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null org.apache.maven.surefire.testset.TestSetFailedException: com.cerner.system.util.CalendarsTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null java.lang.reflect.UndeclaredThrowableException at $Proxy0.addError(Unknown Source) at junit.framework.TestResult.addError(TestResult.java:36) ... Caused by: java.lang.NoSuchMethodException: com.cerner.junit.madhatter.classreloader.ReloadedTestCaseDecorator.getName() at java.lang.Class.getMethod(Class.java:986) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.getStackTraceWriter(TestListenerInvocationHandler.java:171) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAddError(TestListenerInvocationHandler.java:160) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke(TestListenerInvocationHandler.java:134) ... 23 more At TestListenerInvocationHandler:171, I see that it's trying to reflect to a method called getName(). This seems like a very poor assumption, given that nothing on the Test or TestListener interfaces guarantees that there'll be a method called getName(). At the very least, shouldn't the NoSuchMethodException be caught and handled somewhere? See: http://www.junit.org/junit/javadoc/3.8.1/index.htm Complexity: (was: Intermediate) I think I already fixed this bug a while ago; is it still a problem? TestListenerInvocationHandler incorrectly assumes getName() --- Key: SUREFIRE-42 URL: http://jira.codehaus.org/browse/SUREFIRE-42 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Reporter: Matthew Beermann Fix For: 2.4 Attachments: patch.txt, SUREFIRE-42-surefire-junit.patch I'm running test cases that extend our own custom base test case. If one of the tests fails, Surefire itself fails: org.apache.maven.surefire.booter.SurefireExecutionException: com.cerner.system.util.CalendarsTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: com.cerner.system.util.CalendarsTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null org.apache.maven.surefire.testset.TestSetFailedException: com.cerner.system.util.CalendarsTest; nested exception is
[jira] Commented: (SUREFIRE-117) ability to add dependency to jvm's classpath rather in surefirebooter classloader
[ http://jira.codehaus.org/browse/SUREFIRE-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97741 ] Kenney Westerhof commented on SUREFIRE-117: --- It works perfectly here, but it may be a windows issue. Could you please provide a testcase I can run here? ability to add dependency to jvm's classpath rather in surefirebooter classloader - Key: SUREFIRE-117 URL: http://jira.codehaus.org/browse/SUREFIRE-117 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Environment: xp Reporter: Dan Tran Assignee: Kenney Westerhof Fix For: 2.4 Attachments: MSUREFIRE-121-booter.patch, MSUREFIRE-121.plugin.patch, MSUREFIRE-121.plugin.patch2, MSUREFIRE-121.plugin.patch3 I have a usecase where i have a jar file got loaded by -Xbootclasspath, that jar file then loads classes from another jar ( my dependency) expected in the classpath. The problem is that surefire plugin does not add my dependencies at JVM commanline thru -classpath option, but after the JVM starts -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-80) Attempt to use proxySettings even when nonProxyHosts is defined
[ http://jira.codehaus.org/browse/WAGON-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91885 ] Kenney Westerhof commented on WAGON-80: --- According to 'grep -ri nonProxyHosts wagon/' only the lightweight http wagon provider honors the nonproxyhosts. Attempt to use proxySettings even when nonProxyHosts is defined --- Key: WAGON-80 URL: http://jira.codehaus.org/browse/WAGON-80 Project: wagon Issue Type: Bug Components: wagon-file, wagon-ftp, wagon-http, wagon-provider-api, wagon-provider-test, wagon-scm, wagon-ssh, wagon-ssh-external, wagon-webdav Environment: Maven 2.0.5 or maven 2.0.6, this report is based on 2.0.6 Reporter: David J. M. Karlsen site-deploy hangs because of proxy-settings: [INFO] Generate Project Team report. [DEBUG] Generating /tmp/mobilebank/mobilebank-ear/target/site/project-info.html [DEBUG] Generating /tmp/mobilebank/mobilebank-ear/target/site/project-reports.html [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:deploy' -- [DEBUG] (f) inputDirectory = /tmp/mobilebank/mobilebank-ear/target/site [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) settings = [EMAIL PROTECTED] [DEBUG] -- end configuration -- [INFO] [site:deploy] If I remove the proxies/proxy element[s] from my settings.xml it works. Scp is used for deployment. mvn -X site-deply|grep -i wagon gives: [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5 [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected for runtime) [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected for runtime) [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected for runtime) [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6 [DEBUG] org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-6 [DEBUG] org.apache.maven.wagon:wagon-ssh-external:jar:1.0-alpha-6 [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-6 [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-6 [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected for runtime) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface
[
http://jira.codehaus.org/browse/MNG-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89690
]
Kenney Westerhof commented on MNG-2293:
---
Added a comment to MWEBSTART-18. I think the invalid use of
'implementation=${} is what's causing this error.
As far as I can see, the implementation attribute works properly in 2.0.5.
maven-plugin-descriptor: Not possible to define a default implementation for
a field defined by its interface
-
Key: MNG-2293
URL: http://jira.codehaus.org/browse/MNG-2293
Project: Maven 2
Issue Type: New Feature
Components: Plugin Creation Tools
Affects Versions: 2.0.4
Reporter: Jerome Lacoste
Assigned To: Kenney Westerhof
Priority: Critical
Fix For: 2.0.5, 2.1
Attachments: dependency-mistery.log, it0106.tar.bz2,
MNG-2293-plugins.diff, MNG-2293.diff, MNG-2293.diff,
patch-MNG-2293-source2.tar.bz2, patch-MNG-2293.diff
MOJO-393 is about letting the user define an alternate configuration element,
thus changing the way the webstart plugin works.
For that the idea was to make the mojo field an interface, provide a default
implementation in the plugin and let the user use plexus to instanciate a new
implemenation.
so for most users we would have:
configuration
bla
/bla
/configuration
and for some:
configuration
bla implementation=combla
/bla
/configuration
Unfortunately, today I am forced to specify the implementation in both cases.
There's no way to inform the plugin to use the default implementation.
The plugin.xml contains:
parameter
namebla/name
type...BlaInterface/type !-- that will fail --
...
/parameter
I tried to use
/[EMAIL PROTECTED] implementation=...BlaImplementation*/
BlaInterface bla;
but that fails as well.
Marking critical because it doesn't allow me add new features to the plugin
without breaking the config.xml.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2771) Provide a means of loading custom substitute components instead of default Maven components
[ http://jira.codehaus.org/browse/MNG-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89691 ] Kenney Westerhof commented on MNG-2771: --- There are currently 3 ways this works in 2.1-SNAPSHOT. The first way is to place extension jars in $M2_HOME/extensions/. The jars there, and the component.xml's will override previous declarations. It's also possible to just edit/create the file $M2_HOME/extensions/META-INF/plexus/components.xml, and put jars in $M2_HOME/lib/. The second mechanism involves the extensions tag in the pom. Components defined in dependencies there will also override previous declarations. The problem with this right now is that they override the components for the entire reactor, while they should only override them for the duration of the build of that specific project. The third mechanism involves adding dependencies to plugin declarations in a pom. Components defined there will override both components in the plugin, and in the core, but only when they're looked up within the plugin context, so their scope is properly confined. More elaborate systems could ofcourse be deviced, but I think the current solutions provide for everything needed, once the 2nd approach is fixed. You'll have the 3 options above: - maven global overrides - per project overrides - per plugin overrides. Provide a means of loading custom substitute components instead of default Maven components --- Key: MNG-2771 URL: http://jira.codehaus.org/browse/MNG-2771 Project: Maven 2 Issue Type: New Feature Components: General Affects Versions: 2.0.4 Reporter: John Casey Assigned To: Kenney Westerhof Fix For: 2.1-alpha-1 At times, it is necessary to use different mechanisms for resolving artifacts, building projects, etc. Since Maven is built on component-oriented technology, it should be possible to substitute the component implementation used for these tasks. Yet this is currently impossible. We need a mechanism for specifying, resolving, loading, and using custom components during the build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2410) adding a method in AbstractMavenReport to obtain newSink()
[ http://jira.codehaus.org/browse/MNG-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof closed MNG-2410. - Resolution: Fixed Fix Version/s: (was: 2.1.x) 2.1-alpha-1 This has been fixed months ago. Maven-reporting-api contains an interface MavenMultiPageReport, and maven-reporting-impl in shared, and the site plugin already check for this. If the interface is implemented, the new api method (with a SinkFactory parameter) is called, otherwise the legacy API is called. adding a method in AbstractMavenReport to obtain newSink() -- Key: MNG-2410 URL: http://jira.codehaus.org/browse/MNG-2410 Project: Maven 2 Issue Type: New Feature Components: Sites Reporting Affects Versions: 2.0.4 Environment: all Reporter: Olivier Lamy Assigned To: Kenney Westerhof Fix For: 2.1-alpha-1 Actually when extending AbstractMavenReport, I can get a Sink for write only one page. For report, I need to create some pages. I like to have a new method called newSink(FileWriter) to write some other pages. Or could we have a SinkFactory object injected in AbstractMavenReport ? Note, I need a Sink with the current site skin. Thanks, -- Olivier -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2811) issue description: 'Plugin dependencies override maven core artifacts causing NoClassDefFoundErrors'
[
http://jira.codehaus.org/browse/MNG-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86956
]
Kenney Westerhof commented on MNG-2811:
---
It looks like the dependencies brought in by the plugin (maven-model,
plexus-utils) are not filtered out the plugin's classrealm.
Since the conflict resolution in 2.0.4 bugs ('nearer found' is reported even
for dependencies at the same level, sometimes
causing older versions to replace newer onces), older versions of maven-model
etc. could be used, but these should've
been filtered out using the artifact filters since they're core artifacts.
This normally works but maybe the downloading of plugins disrupts this.
issue description: 'Plugin dependencies override maven core artifacts
causing NoClassDefFoundErrors'
-
Key: MNG-2811
URL: http://jira.codehaus.org/browse/MNG-2811
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.4
Environment: OS agnostic, maven 2.0.4, jdk1.5
Reporter: David J. M. Karlsen
Priority: Blocker
Attachments: 17artifactmultibulid.run1.log, 4artifact.filtered.log
Usecase:
wipe the local .m2 repo totally away. (rm -rf ~/.m2/repository)
do a:
mvn -X clean deploy site-deploy.
Attached is the output from two different projects (one is a 4 artifact
project - including the top pom, the other is a multibuild of 17 artifacts,
also including top-pom).
If I just re-run the mvn -X clean deploy site-deploy the builds will
eventually succeed.
I'll try to narrow down the pom's to pin down the failure with as little
dependencies and plugins in action as possible - but this will take some time.
I can be pinged at [EMAIL PROTECTED] or [EMAIL PROTECTED] for re-running
builds if needed.
The logs are a little anonymized.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2056) Exception when starting new page with AbstractMavenMultiPageReport
[ http://jira.codehaus.org/browse/MNG-2056?page=all ] Kenney Westerhof closed MNG-2056. - Assignee: Kenney Westerhof Resolution: Won't Fix The AbstractMavenMultiPage report has never worked and no longer exists. Instead, use the latest maven-site-plugin (maybe even a snapshot), and add a dependency on maven-reporting-api 2.1-SNAPSHOT (or the maven-site-plugin, a dirty hack). Then let your report implement the MavenMultiPageReport interface. In the new generate method there's a SinkFactory parameter you can use to create additional sinks. Exception when starting new page with AbstractMavenMultiPageReport -- Key: MNG-2056 URL: http://jira.codehaus.org/browse/MNG-2056 Project: Maven 2 Issue Type: Bug Components: Sites Reporting Affects Versions: 2.0.2 Environment: OS X 10.3.4. running JDK 1.5 (1.5.0_06-93) Reporter: Adam Winer Assigned To: Kenney Westerhof Fix For: 2.0.x Attempts to call AbstractMavenMultiPageReport.startPage() from a custom report result in the following exception: Caused by: java.io.EOFException: input contained no data at org.codehaus.plexus.util.xml.pull.MXParser.fillBuf(MXParser.java:2979) at org.codehaus.plexus.util.xml.pull.MXParser.more(MXParser.java:3022) at org.codehaus.plexus.util.xml.pull.MXParser.parseProlog(MXParser.java:1407) at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1392) at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1090) at org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:172) at org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:83) at org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:48) at org.codehaus.doxia.module.xhtml.decoration.model.DecorationModelReader.createNavigation(DecorationModelReader.java:30) at org.codehaus.doxia.site.renderer.DefaultSiteRenderer.createSink(DefaultSiteRenderer.java:244) at org.apache.maven.reporting.sink.SinkFactory.getSink(SinkFactory.java:76) at org.apache.maven.reporting.AbstractMavenMultiPageReport.getSink(AbstractMavenMultiPageReport.java:79) at org.apache.maven.reporting.AbstractMavenMultiPageReport.startPage(AbstractMavenMultiPageReport.java:85) FYI, I'm creating the SinkFactory for the multipage report using: SinkFactory factory = new SinkFactory(); factory.setSiteRenderer(getSiteRenderer()); factory.setSiteDirectory(getOutputDirectory()); setSinkFactory(factory); Without this code, you just get a NullPointerException in AbstractMavenMultiPageReport.getSink(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1922) Rename maven-it-plugin plugin as its name implies it is for performing integration tests in general
[ http://jira.codehaus.org/browse/MNG-1922?page=comments#action_85444 ] Kenney Westerhof commented on MNG-1922: --- You may be right - it can only execute maven projects, embedded (that's where most original embedder code came from actually ;)). this plugin actually abuses the maven build lifecycle, using a pom to configure it, to set up pre- and post- test hooks, in order to set up and tear down the integration environment. This can be done using maven plugins to, for instance, deploy your artifact (that's why it uses maven projects so it knows about your artifact), start a container, and later turn it off. This can all be done in code too, but this approach leverages all of maven and maven's plugins to ease the work. I think it's just a matter of properly documenting it. Btw, it doesn't affect any maven version so this should probably be moved to some other project. Anyway, the host of all it/test plugins out there is currently undergoing discussion to delete/merge them, so we better wait what happens with that. Rename maven-it-plugin plugin as its name implies it is for performing integration tests in general --- Key: MNG-1922 URL: http://jira.codehaus.org/browse/MNG-1922 Project: Maven 2 Issue Type: Task Components: integration tests Affects Versions: 2.0.1 Reporter: Vincent Massol Fix For: 2.0.x The it plugin is really meant to perform functional tests of plugins and as such should be renamed. Ideas: * maven-plugin-it-plugin * maven-test-plugin-plugin *Another idea is to include its feature in the plugin plugin under a plugin:test mojo.* -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-900) snapshots without metadata are not resolved
[ http://jira.codehaus.org/browse/MNG-900?page=comments#action_85446 ] Kenney Westerhof commented on MNG-900: -- This issue has regressed again at 2.1-snap. snapshots without metadata are not resolved --- Key: MNG-900 URL: http://jira.codehaus.org/browse/MNG-900 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0-beta-1 Reporter: Brett Porter Assigned To: John Casey Fix For: 2.0-beta-2 Attachments: MNG-900.diff Original Estimate: 2 hours Time Spent: 1 hour Remaining Estimate: 0 minutes in particular, this is a problem for using legacy repositories built by m1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2773) Plugin repositories are chekced for SNAPSHOTS on every run in the 2.0.5 candidate
[ http://jira.codehaus.org/browse/MNG-2773?page=all ]
Kenney Westerhof closed MNG-2773.
-
Resolution: Duplicate
Plugin repositories are chekced for SNAPSHOTS on every run in the 2.0.5
candidate
-
Key: MNG-2773
URL: http://jira.codehaus.org/browse/MNG-2773
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories, Repositories
Affects Versions: 2.0.5
Reporter: Trygve Laugstol
Assigned To: Kenney Westerhof
Fix For: 2.0.5
Trussing the mvn process shows that Maven tries to connect to the plugin
repository on every run, instead of the daily check.
{code}
[16:38:[EMAIL PROTECTED]:monitor-core]$ truss -t connect mvn
-Dmaven.test.skip=true install
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - no.java.monitor:monitor-core:jar:1.0-SNAPSHOT
[INFO]task-segment: [install]
[INFO]
[INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for
updates from codehaus-snapshots
/1: connect(8, 0xFFBFBAF4, 16, SOV_DEFAULT) = 0
/1: connect(7, 0xFFBFBD98, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for
updates from codehaus-snapshots
/1: connect(7, 0xFFBFBD80, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for
updates from codehaus-snapshots
/1: connect(9, 0xFFBFBD98, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-jar-plugin: checking for
updates from codehaus-snapshots
/1: connect(7, 0xFFBFBD80, 16, SOV_DEFAULT) = 0
[INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking for
updates from codehaus-snapshots
[INFO] [plexus:descriptor {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[WARNING]
Artifact junit:junit:jar:3.8.1:test retains local scope 'test'
overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or remove the
local scope.
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-2712) update policy 'daily' not honored
[ http://jira.codehaus.org/browse/MNG-2712?page=all ] Kenney Westerhof reopened MNG-2712: --- This is also a bug in 2.0.x, reopening. update policy 'daily' not honored - Key: MNG-2712 URL: http://jira.codehaus.org/browse/MNG-2712 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.5, 2.1.x Reporter: Kenney Westerhof Assigned To: Kenney Westerhof Fix For: 2.1, 2.0.5, 2.0.x under certain circumstances, the 'updatePolicydaily/updatePolicy' isn't honored. This is the case where the remote metadata file doesn't exist, or contains versionRELEASE/LATEST (which should never happen).. The timestamp used to compare for the update is 0L, because the local file doesn't exist. Then the remote file is retrieved, which also doesn't exist, and no metadatafile is created. The next time an up2date check is done, again against timestamp 0 for a non-existent file. This means that if you define a custom snapshot repo in settings.xml or a pom, and you have 500 transitive deps, the repo's that don't have that artifact are consulted 500 times for each mvn invocation. A build that normally takes about 20 seconds takes more than 10 minutes because of this bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2712) update policy 'daily' not honored
[ http://jira.codehaus.org/browse/MNG-2712?page=all ] Kenney Westerhof updated MNG-2712: -- Affects Version/s: 2.1.x 2.0.5 Fix Version/s: 2.0.5 2.0.x update policy 'daily' not honored - Key: MNG-2712 URL: http://jira.codehaus.org/browse/MNG-2712 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.5, 2.1.x Reporter: Kenney Westerhof Assigned To: Kenney Westerhof Fix For: 2.1, 2.0.5, 2.0.x under certain circumstances, the 'updatePolicydaily/updatePolicy' isn't honored. This is the case where the remote metadata file doesn't exist, or contains versionRELEASE/LATEST (which should never happen).. The timestamp used to compare for the update is 0L, because the local file doesn't exist. Then the remote file is retrieved, which also doesn't exist, and no metadatafile is created. The next time an up2date check is done, again against timestamp 0 for a non-existent file. This means that if you define a custom snapshot repo in settings.xml or a pom, and you have 500 transitive deps, the repo's that don't have that artifact are consulted 500 times for each mvn invocation. A build that normally takes about 20 seconds takes more than 10 minutes because of this bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2712) update policy 'daily' not honored
[ http://jira.codehaus.org/browse/MNG-2712?page=all ] Kenney Westerhof closed MNG-2712. - Resolution: Fixed Fix Version/s: (was: 2.1) 2.1-alpha-1 2.1.x Merged in revision 496443. update policy 'daily' not honored - Key: MNG-2712 URL: http://jira.codehaus.org/browse/MNG-2712 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.5, 2.1.x Reporter: Kenney Westerhof Assigned To: Kenney Westerhof Fix For: 2.0.x, 2.0.5, 2.1.x, 2.1-alpha-1 under certain circumstances, the 'updatePolicydaily/updatePolicy' isn't honored. This is the case where the remote metadata file doesn't exist, or contains versionRELEASE/LATEST (which should never happen).. The timestamp used to compare for the update is 0L, because the local file doesn't exist. Then the remote file is retrieved, which also doesn't exist, and no metadatafile is created. The next time an up2date check is done, again against timestamp 0 for a non-existent file. This means that if you define a custom snapshot repo in settings.xml or a pom, and you have 500 transitive deps, the repo's that don't have that artifact are consulted 500 times for each mvn invocation. A build that normally takes about 20 seconds takes more than 10 minutes because of this bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1320) Build failed due to an empty or corrupt metadata file in the repository
[ http://jira.codehaus.org/browse/MNG-1320?page=comments#action_85082 ] Kenney Westerhof commented on MNG-1320: --- The handling for the 404 deletes the file from the local repository. My fix for MNG-2712 extends the behaviour a bit: if there's a transferfailed, and the file does not already exist, then an empty metadata file (with defaults) is written, to mark the error timestamp. This way, on consecutive builds, the repo isn't checked again numerous times. This is because wagon doesn't always throw a ResourceDoesNotExistException if there's a 404, it sometimes also throws it's superclass. Now errors are marked, and the next day (or on force), an attempt is made to retrieve the metata again. Build failed due to an empty or corrupt metadata file in the repository --- Key: MNG-1320 URL: http://jira.codehaus.org/browse/MNG-1320 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0 Reporter: Adrian Assigned To: John Casey Fix For: 2.0.1 Original Estimate: 1 hour Time Spent: 1 hour Remaining Estimate: 0 minutes Build failed due to an empty or corrupt metadata file in the repository. Possibly had a network error whilst downloading the metadata file. The stack trace that occurred when the error was encountered was as follows. + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building Maven Ear plugin [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1124) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1356) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:896) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:862) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.version.PluginVersionNotFoundException: The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:225) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:87) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:158) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1095) ... 18 more [INFO] [INFO] Total time: 1 second [INFO]
[jira] Created: (MNG-2743) Dependency poms not timely merged with parents
Dependency poms not timely merged with parents
--
Key: MNG-2743
URL: http://jira.codehaus.org/browse/MNG-2743
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.4
Reporter: Kenney Westerhof
Priority: Blocker
POM's of dependencies are not properly merged with their parents.
It could be that they're not merged at all, or only partly. Since the code to
merge poms is the same
everywhere, and repository tags are merged for local poms, I fear that
they're not merged at all.
With this setup:
* local workspace:
** project A
*** depends on remote artifact B, residing in 'central'
* repository central:
** artifact B (cocoon-core)
*** has parent P (cocoon), also here at central
*** declares a dependency on D, residing in repo R (not a standard repository)
** pom P, declares repository R
* repository R:
** artifact D (avalon-framework-impl)
*** declares dependency on lib L, also here at repository R
** artifact L (avalon-framework-api)
When running mvn install on local project A, observe the following log:
{nopaste}
// cocoon-core has been resolved, now it's dependency poms are resolved:
[DEBUG] Trying repository central
Downloading:
http://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-impl/4.3/avalon-framework-impl-4.3.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[DEBUG] Artifact not found - using stub model: Unable to download the artifact
from any repository
org.apache.avalon.framework:avalon-framework-impl:pom:4.3
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
[DEBUG] Using defaults for missing POM
org.apache.avalon.framework:avalon-framework-impl:pom:4.3:compile
// note: above, the parent of cocoon-core (B) (which is cocoon (P)), is not
merged, as the repo R is not
// visible in B to resolve D
// now, the artifacts themselves are downloaded
[DEBUG] Trying repository central
Downloading:
http://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-impl/4.3/avalon-framework-impl-4.3.jar
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
// Here, repo R _is_ used to search, which means that the parent P is merged
with B and the repo is available
[DEBUG] Trying repository apache.snapshot
Downloading:
http://people.apache.org/maven-snapshot-repository/org/apache/avalon/framework/avalon-framework-impl/4.3/avalon-framework
-impl-4.3.jar
2/56K^M3/56K^M7/56K^M8/56K^M9/56K^M13/56K^M17/56K^M19/56K^M20/56K^M24/56K^M28/56K^M32/56K^M36/56K^M40/56K^M42/56K^M43/56K^M44/56K^M46/
56K^M47/56K^M49/56K^M50/56K^M52/56K^M53/56K^M54/56K^M56/56K^M56K downloaded
[DEBUG] Artifact resolved
{nopaste}
The problem here is that the jar is now available in the local repo, but the
pom is not, and the dependencies of D aren't downloaded.
It seems pom B is only merged with P _after_ all dependency poms for B have
been resolved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2743) Dependency poms not timely merged with parents
[ http://jira.codehaus.org/browse/MNG-2743?page=all ]
Kenney Westerhof updated MNG-2743:
--
Description:
POM's of dependencies are not properly merged with their parents.
It could be that they're not merged at all, or only partly. Since the code to
merge poms is the same
everywhere, and repository tags are merged for local poms, I fear that
they're not merged at all.
With this setup:
* local workspace:
** project A
*** depends on remote artifact B, residing in 'central'
* repository central:
** artifact B (cocoon-core)
*** has parent P (cocoon), also here at central
*** declares a dependency on D, residing in repo R (not a standard repository)
** pom P, declares repository R
* repository R:
** artifact D (avalon-framework-impl)
*** declares dependency on lib L, also here at repository R
** artifact L (avalon-framework-api)
When running mvn install on local project A, observe the following log:
{noformat}
// cocoon-core has been resolved, now it's dependency poms are resolved:
[DEBUG] Trying repository central
Downloading:
http://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-impl/4.3/avalon-framework-impl-4.3.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[DEBUG] Artifact not found - using stub model: Unable to download the artifact
from any repository
org.apache.avalon.framework:avalon-framework-impl:pom:4.3
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
[DEBUG] Using defaults for missing POM
org.apache.avalon.framework:avalon-framework-impl:pom:4.3:compile
// note: above, the parent of cocoon-core (B) (which is cocoon (P)), is not
merged, as the repo R is not
// visible in B to resolve D
// now, the artifacts themselves are downloaded
[DEBUG] Trying repository central
Downloading:
http://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-impl/4.3/avalon-framework-impl-4.3.jar
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
// Here, repo R _is_ used to search, which means that the parent P is merged
with B and the repo is available
[DEBUG] Trying repository apache.snapshot
Downloading:
http://people.apache.org/maven-snapshot-repository/org/apache/avalon/framework/avalon-framework-impl/4.3/avalon-framework
-impl-4.3.jar
2/56K^M3/56K^M7/56K^M8/56K^M9/56K^M13/56K^M17/56K^M19/56K^M20/56K^M24/56K^M28/56K^M32/56K^M36/56K^M40/56K^M42/56K^M43/56K^M44/56K^M46/
56K^M47/56K^M49/56K^M50/56K^M52/56K^M53/56K^M54/56K^M56/56K^M56K downloaded
[DEBUG] Artifact resolved
{noformat}
The problem here is that the jar is now available in the local repo, but the
pom is not, and the dependencies of D aren't downloaded.
It seems pom B is only merged with P _after_ all dependency poms for B have
been resolved.
was:
POM's of dependencies are not properly merged with their parents.
It could be that they're not merged at all, or only partly. Since the code to
merge poms is the same
everywhere, and repository tags are merged for local poms, I fear that
they're not merged at all.
With this setup:
* local workspace:
** project A
*** depends on remote artifact B, residing in 'central'
* repository central:
** artifact B (cocoon-core)
*** has parent P (cocoon), also here at central
*** declares a dependency on D, residing in repo R (not a standard repository)
** pom P, declares repository R
* repository R:
** artifact D (avalon-framework-impl)
*** declares dependency on lib L, also here at repository R
** artifact L (avalon-framework-api)
When running mvn install on local project A, observe the following log:
{nopaste}
// cocoon-core has been resolved, now it's dependency poms are resolved:
[DEBUG] Trying repository central
Downloading:
http://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-impl/4.3/avalon-framework-impl-4.3.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[DEBUG] Artifact not found - using stub model: Unable to download the artifact
from any repository
org.apache.avalon.framework:avalon-framework-impl:pom:4.3
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
[DEBUG] Using defaults for missing POM
org.apache.avalon.framework:avalon-framework-impl:pom:4.3:compile
// note: above, the parent of cocoon-core (B) (which is cocoon (P)), is not
merged, as the repo R is not
// visible in B to resolve D
// now, the artifacts themselves are downloaded
[DEBUG] Trying repository central
Downloading:
http://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-impl/4.3/avalon-framework-impl-4.3.jar
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
// Here, repo R _is_ used to search, which means that the parent P is merged
with B and the repo is available
[DEBUG] Trying repository apache.snapshot
[jira] Created: (MNG-2738) 1-char profile names cannot be activated with -P
1-char profile names cannot be activated with -P
Key: MNG-2738
URL: http://jira.codehaus.org/browse/MNG-2738
Project: Maven 2
Issue Type: Bug
Components: Command Line
Affects Versions: 2.1
Reporter: Kenney Westerhof
Priority: Minor
'mvn install -Uc' gives;
{noformat}
Unable to parse command line options: no argument for:P
usage: mvn [options] [goal(s)] [phase(s)]
Options:
...etc...
{noformat}
(same for mvn -Pc [whatever])
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-118) assembly files uses maven parent relative path and not the modules relative path
[ http://jira.codehaus.org/browse/MASSEMBLY-118?page=all ]
Kenney Westerhof closed MASSEMBLY-118.
--
Resolution: Fixed
with the latest HEAD of the assembly plugin, this problem cannot be reproduced.
I recognize that it indeed
was a problem, that why it's not 'closed - cannot reproduce'.
Committed the JUnit tests patch (with attribution) in revision 489633.
(Minor change: removed the unused imports).
assembly files uses maven parent relative path and not the modules relative
path
--
Key: MASSEMBLY-118
URL: http://jira.codehaus.org/browse/MASSEMBLY-118
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Baerrach bonDierne
Assigned To: Kenney Westerhof
Fix For: 2.2
Attachments: MASSEMBLY-118-patch.txt, MASSEMBLY-118-patch.txt,
MASSEMBLY-118-patch.txt, MASSEMBLY-118-patch.txt, Maven Assembly Bug.zip
In mvn 2.0.4 if I have an assemly descriptor that has the following:
files
file
sourcesrc/site/apt/index.apt/source
outputDirectory/outputDirectory
destNameREADME.txt/destName
/file
/files
and a maven project that looks like:
Maven Assembly Bug
- pom.xml
- assembly-bug-module
- pom.xml
- src/site/apt/index.apt
with the assembly:assembly bound to the package phase inside
assembly-bug-module/pom.xml as
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
executions
execution
idpackage-assembly/id
phasepackage/phase
goals
goalassembly/goal
/goals
configuration
descriptors
descriptor
src/main/assembly/bin.xml
/descriptor
/descriptors
/configuration
/execution
/executions
/plugin
then when I run mvn install inside assembly-bug-module:
assembly-bug-module mvn install
the command works fine
When I run mvn install inside the Maven Assembly Bug directory the command
will fail
Maven Assembly Bug mvn install
[INFO] [assembly:assembly {execution: package-assembly}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error adding file to archive: path\Maven Assembly
Bug\src\site\apt\index.apt isn't a file.
Example project is attached as a zip file.
Trying to change the descriptor to use ${project.build.sourceDirectory} does
not work as this is not resoolved.
[INFO] Error adding file to archive: path\Maven Assembly
Bug\assembly-bug-module\${project.build.sourceDirectory}
\site\apt\index.apt isn't a file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2225) Classloader problem when adding jars to M2_HOME
[ http://jira.codehaus.org/browse/MNG-2225?page=comments#action_83247 ]
Kenney Westerhof commented on MNG-2225:
---
It would be better if mojo dependencies took precedence over those in the core
realm, especially with all the plexus-utils problems.
Mojo's should be able to use any component version they desire. Only core
components api's that are already used by the maven
core should take precedence; in this case only maven-project, maven-plugin-api
and possibly maven-artifact; the rest is not needed
and can be replaced by custom versions used by mojo's.
it comes down to limiting items in mojo's parent classloader to ONLY the
interfaces/instances that maven core uses and cannot
be replaced. These are: (amongst others):
* MavenProject
* ArtifactFactory
* ArtifactResolution stuff
this list should be as small as possible - no implementations whatsoever should
be exported to mojo's.
Here's the current list:
|| Loc || Artifact || Export to Mojo ||
| core/ |plexus-component-api-1.0-alpha-13.jar | (-) |
| core/ |plexus-container-default-1.0-alpha-14.jar| (-) |
| core/ |plexus-utils-1.1.jar| (-) |
| core/boot | plexus-classworlds-1.2-alpha-5.jar| (-) |
| lib/ |commons-cli-1.0.jar | (-) |
| lib/ |doxia-sink-api-1.0-alpha-9-20061107.221350-3.jar | (-) |
| lib/ |jsch-0.1.27.jar | (-) |
| lib/ |jtidy-4aug2000r7-dev.jar | (-) |
| lib/ |maven-artifact-2.1-SNAPSHOT.jar | (-) |
| lib/ |maven-artifact-manager-2.1-SNAPSHOT.jar | (-) |
| lib/ |maven-cli-2.1-SNAPSHOT.jar | (-) |
| lib/ |maven-core-2.1-SNAPSHOT.jar | (-) |
| lib/ |maven-embedder-2.1-SNAPSHOT.jar | (-) |
| lib/ |maven-error-diagnostics-2.1-SNAPSHOT.jar | (-) |
| lib/ |maven-model-2.1-SNAPSHOT.jar | (+) |
| lib/ |maven-monitor-2.1-SNAPSHOT.jar | (-) |
| lib/ |maven-plugin-api-2.1-SNAPSHOT.jar | (+) |
| lib/ |maven-plugin-descriptor-2.1-SNAPSHOT.jar | (-) |
| lib/ |maven-plugin-parameter-documenter-2.1-SNAPSHOT.jar | (-) |
| lib/ |maven-plugin-registry-2.1-SNAPSHOT.jar | (?) |
| lib/ |maven-profile-2.1-SNAPSHOT.jar | (?) |
| lib/ |maven-project-2.1-SNAPSHOT.jar | (+) |
| lib/ |maven-reporting-api-2.1-SNAPSHOT.jar | (+) |
| lib/ |maven-repository-metadata-2.1-SNAPSHOT.jar | (-) |
| lib/ |maven-settings-2.1-SNAPSHOT.jar | (?) |
| lib/ |maven-tools-2.1-SNAPSHOT.jar | (?) |
| lib/ |plexus-interactivity-api-1.0-alpha-4.jar | (-) |
| lib/ |wagon-file-1.0-beta-2.jar | (-) |
| lib/ |wagon-http-lightweight-1.0-beta-2.jar | (-) |
| lib/ |wagon-http-shared-1.0-beta-2.jar | (-) |
| lib/ |wagon-provider-api-1.0-beta-2.jar | (?) |
| lib/ |wagon-ssh-1.0-beta-2.jar | (-) |
| lib/ |wagon-ssh-common-1.0-beta-2.jar | (-) |
| lib/ |wagon-ssh-external-1.0-beta-2.jar | (-) |
| lib/ |xml-apis-1.0.b2.jar | (-) |
So basically everything that's maven-version specific - only APIs, modello
models and in this case also MavenProject since it
contains the runtime project representation.
I think this is easily solved by updating the m2.conf and add another
classloader.
Classloader problem when adding jars to M2_HOME
---
Key: MNG-2225
URL: http://jira.codehaus.org/browse/MNG-2225
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.4
Reporter: Carlos Sanchez
Priority: Critical
Fix For: 2.1
Attachments: testwagonscm.tgz
Added these jars to M2_HOME/custom to allow using scm based remote repos
http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-api/1.0-beta-2/maven-scm-api-1.0-beta-2.jar
http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-manager-plexus/1.0-beta-2/maven-scm-manager-plexus-1.0-beta-2.jar
http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-provider-svn/1.0-beta-2/maven-scm-provider-svn-1.0-beta-2.jar
http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/wagon/wagon-scm/1.0-alpha-7-SNAPSHOT/wagon-scm-1.0-alpha-7-20060308.183410-3.jar
bin/m2.conf
main is org.apache.maven.cli.MavenCli from plexus.core.maven
set maven.home default ${user.home}/m2
[plexus.core]
load ${maven.home}/core/*.jar
[plexus.core.maven]
load ${maven.home}/custom/*.jar
load ${maven.home}/lib/*.jar
When running mvn install and mvn testwagonscm:test in the attached test
case you get a ClassCastException although the Class to assign to and the
assigned one are the same. The problem seems to be that they come from
different classloaders. This problem makes the project-info-report:scm goal
fail.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPH-20) help:dependencies not consistent with maven core's dependency tree
help:dependencies not consistent with maven core's dependency tree
--
Key: MPH-20
URL: http://jira.codehaus.org/browse/MPH-20
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Kenney Westerhof
This plugin applies dependencyManagement to transitive dependencies (which is
really what I want),
but maven itself does not.
For instance, mvn help:dependencies on sandbox/maven-plug-it-plugin lists:
{noformat}
[INFO] org.apache.maven.plugins:maven-plug-it-plugin:maven-plugin:1.0-SNAPSHOT
[INFO]junit:junit:jar:3.8.1:test
[INFO]org.apache.maven.shared:file-management:jar:1.1:compile
[INFO] org.apache.maven.shared:maven-shared-io:jar:1.0:compile
[INFO]org.apache.maven:maven-settings:jar:2.0:compile
[INFO]org.apache.maven:maven-plugin-api:jar:2.0.4:compile
[INFO]
org.apache.maven.shared:maven-test-tools:jar:1.0-20061102.004837-1:test
[INFO] easymock:easymock:jar:1.2_Java1.3:test
[INFO]org.codehaus.plexus:plexus-velocity:jar:1.1.3:compile
[INFO]
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile
[INFO] commons-collections:commons-collections:jar:2.0:compile
[INFO] velocity:velocity:jar:1.4:compile
[INFO] velocity:velocity-dep:jar:1.4:runtime
[INFO]
org.apache.maven.shared:maven-plugin-testing-tools:jar:1.0-alpha-2-20061221.044609-6:compile
[INFO] org.apache.maven:maven-model:jar:2.0:compile
[INFO]
org.apache.maven.shared:maven-repository-builder:jar:1.0-alpha-1:compile
[INFO] org.apache.maven:maven-artifact-manager:jar:2.0:compile
[INFO] org.apache.maven:maven-project:jar:2.0:compile
[INFO]
org.apache.maven.shared:maven-common-artifact-filters:jar:1.0-alpha-1:compile
[INFO] org.apache.maven:maven-artifact:jar:2.0:compile
[INFO] org.apache.maven.shared:maven-invoker:jar:2.0.5:compile
[INFO] org.codehaus.plexus:plexus-utils:jar:1.0.4:compile
[INFO] org.apache.maven:maven-monitor:jar:2.0:compile
{noformat}
Adding 'dependencyManagement' for plexus-utils to force it to 1.1 (which
doesn't work in m2 itself), it lists:
{noformat}
[INFO] org.apache.maven.plugins:maven-plug-it-plugin:maven-plugin:1.0-SNAPSHOT
[INFO]junit:junit:jar:3.8.1:test
[INFO]org.apache.maven.shared:file-management:jar:1.1:compile
[INFO] org.codehaus.plexus:plexus-utils:jar:1.1:compile
[INFO] org.apache.maven.shared:maven-shared-io:jar:1.0:compile
[INFO]org.apache.maven:maven-settings:jar:2.0:compile
[INFO]org.apache.maven:maven-plugin-api:jar:2.0.4:compile
[INFO]
org.apache.maven.shared:maven-test-tools:jar:1.0-20061102.004837-1:test
[INFO] easymock:easymock:jar:1.2_Java1.3:test
[INFO]org.codehaus.plexus:plexus-velocity:jar:1.1.3:compile
[INFO]
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile
[INFO] commons-collections:commons-collections:jar:2.0:compile
[INFO] velocity:velocity:jar:1.4:compile
[INFO] velocity:velocity-dep:jar:1.4:runtime
[INFO]
org.apache.maven.shared:maven-plugin-testing-tools:jar:1.0-alpha-2-20061221.044609-6:compile
[INFO] org.apache.maven:maven-model:jar:2.0:compile
[INFO]
org.apache.maven.shared:maven-repository-builder:jar:1.0-alpha-1:compile
[INFO] org.apache.maven:maven-artifact-manager:jar:2.0:compile
[INFO] org.apache.maven:maven-project:jar:2.0:compile
[INFO]
org.apache.maven.shared:maven-common-artifact-filters:jar:1.0-alpha-1:compile
[INFO] org.apache.maven:maven-artifact:jar:2.0:compile
[INFO] org.apache.maven.shared:maven-invoker:jar:2.0.5:compile
[INFO] org.apache.maven:maven-monitor:jar:2.0:compile
{noformat}
Either we say this is the desired behavior (+1), or MNG-1577 should be fixed.
The problem here is that if MNG-1577 is going for the
if-pom-version-is-this-then-do-that-otherwise-do-that,
this plugin should exhibit the same behaviour.
I'd like both maven core and this plugin to use the same dependency resolution
code, or drop
the dependency-tree code and use maven's internal dependency graph (which
doesn't exist yet).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-171) Fix / speedup integration tests
Fix / speedup integration tests
---
Key: MASSEMBLY-171
URL: http://jira.codehaus.org/browse/MASSEMBLY-171
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Kenney Westerhof
Priority: Blocker
After hacking for quite a while in other projects to get the it's to run,
(fixing sandbox/plugins/maven-plug-it-plugin, shared/maven-plugin-testing-tools
and components/maven-settings)
I found, after 9 minutes, this:
{noformat}
---
Execution Summary:
Builds Passing: 24
Builds Failing: 14
---
The following builds failed:
* multimodule/twoLevel-includeSubModules-excludeSubModuleSourceDirs/pom.xml
* multimodule/two-level-multimodule-dontIncludeSubModules/pom.xml
* multimodule/two-level-multimodule/pom.xml
* multimodule/two-levels-includeBaseDirectory-withSources/pom.xml
* multimodule/twoLevel-dontIncludeSubModules-artifactIdExprOutDir/pom.xml
* multimodule/two-levels-includeBaseDirectory-withBinaries/pom.xml
* mojo-tests/single-twice-in-multimodule-hierarchy/pom.xml
* mojo-tests/single-in-one-project-hierarchy/pom.xml
* mojo-tests/single-twice-in-one-project-hierarchy/pom.xml
* basic-features/outputFileNameMapping-withArtifactBaseVersion/pom.xml
* basic-features/outputFileNameMapping-simple/pom.xml
* repository-assembly/pom.xml
* descriptor-refs/jar-with-dependencies/component-descriptors-merged/pom.xml
* file-sets/same-source-name-different-output/pom.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] : [EMAIL PROTECTED]
One or more builds failed.
14 builds failed.
[INFO]
[INFO] Total time: 8 minutes 58 seconds
[INFO] Finished at: Fri Dec 22 18:25:56 CET 2006
[INFO] Final Memory: 22M/57M
[INFO]
FATAL ERROR: Unable to configure the Maven application
For more information, run with the -e flag
{noformat}
Most failed builds had this in the build.log:
{noformat}
url = http://snapshots.repository.codehaus.org
Downloading:
http://snapshots.repository.codehaus.org/org/apache/maven/plugins/maven-plugins/4-SNAPSHOT/maven-plugins-4-SNAPSHOT.pom
[WARNING] Unable to get resource
'org.apache.maven.plugins:maven-plugins:pom:4-SNAPSHOT' from repository
codehaus.org (http://snapshots.repository.codehaus.org)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: org.apache.maven.plugins
ArtifactId: maven-plugins
Version: 4-SNAPSHOT
Reason: Unable to download the artifact from any repository
org.apache.maven.plugins:maven-plugins:pom:4-SNAPSHOT
from the specified remote repositories:
codehaus.org (http://snapshots.repository.codehaus.org),
central (http://repo1.maven.org/maven2)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Fri Dec 22 18:18:25 CET 2006
[INFO] Final Memory: 2M/6M
[INFO]
FATAL ERROR: Unable to configure the Maven application
For more information, run with the -e flag
{noformat}
That repo isn't used anymore, plus 4-SNAPSHOT is in my local repo already.
I think repo isolation is good but the builds takes very very long because it
tries to download
artifacts 71 times (only 57 are succesfully downloaded), using the wrong repo.
Can't the local repo serve as a fallback, or at least serve non-snapshots, so
we can't install
the test plugin?
Reasoning; in order to test the current plugin, it must be available in a local
repository
structure for maven to find it, due to a bug in maven (MNG-2677).
This requires a new local repo, initially empty. The plugin is added there.
But Maven can only handle 1 local repo at a time, so all the cached data there
is not used.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1050) [2.0,) should not select 3.0 and above by default
[ http://jira.codehaus.org/browse/MNG-1050?page=comments#action_83259 ] Kenney Westerhof commented on MNG-1050: --- If you want 2.*, you should write [2, 3) (or [2.0, 3.0) ); I think this is perfectly legal. If you want the latest version, whatever that is, you could use [0,) Leaving the high-end limit out means unlimited, just as in the math notation, so I say leave it like this. There's a discussion about versioning and a wiki page in the 2.1 design documents where we need to address this. I think version ranges are flexible enough as is to support any scheme or any version range people want. If you were to limit [2.0,) to [2.0,3.0), how would you specify 2.0 or higher, even including 10.0? Also, linux kernels use a different scheme, where 2.x.* is compatible with 2.(x+1).*, where odd-x'es are comparable to 'alpha'. (so 2.5.10 is actually an alpha for 2.6.0). I opt for close won't fix. [2.0,) should not select 3.0 and above by default - Key: MNG-1050 URL: http://jira.codehaus.org/browse/MNG-1050 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Reporter: Brett Porter Fix For: 2.1 I think that we need to assume major versions are incompatible as it is easier to later state compatibility than fix it when broken. This might just be a default compatibility scheme, but a project can define its own (eg, compatible-since 2.1). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2712) update policy 'daily' not honored
[ http://jira.codehaus.org/browse/MNG-2712?page=all ] Kenney Westerhof closed MNG-2712. - Resolution: Fixed Fix Version/s: 2.1 Fixed in revision 489724. Also updated unit test to test that the files ARE written, even if the metadata contains LATEST/RELEASE, but without the version tag. Ran integration tests on the core, and there don't seem to be any problems with this. update policy 'daily' not honored - Key: MNG-2712 URL: http://jira.codehaus.org/browse/MNG-2712 Project: Maven 2 Issue Type: Bug Reporter: Kenney Westerhof Assigned To: Kenney Westerhof Fix For: 2.1 under certain circumstances, the 'updatePolicydaily/updatePolicy' isn't honored. This is the case where the remote metadata file doesn't exist, or contains versionRELEASE/LATEST (which should never happen).. The timestamp used to compare for the update is 0L, because the local file doesn't exist. Then the remote file is retrieved, which also doesn't exist, and no metadatafile is created. The next time an up2date check is done, again against timestamp 0 for a non-existent file. This means that if you define a custom snapshot repo in settings.xml or a pom, and you have 500 transitive deps, the repo's that don't have that artifact are consulted 500 times for each mvn invocation. A build that normally takes about 20 seconds takes more than 10 minutes because of this bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2565) plugin version aren't taken from pluginManagement in a sub-sub-modules
[ http://jira.codehaus.org/browse/MNG-2565?page=comments#action_83054 ]
Kenney Westerhof commented on MNG-2565:
---
I didn't find that - running mvn eclipse:eclipse in maven-trunks/continuum
works,
but running mvn eclipse:eclipse in maven-trunks (where I added a grouping pom
with modulecontinuum/module)
yields this:
{noformat}
[INFO] Building Continuum Model
[INFO]task-segment: [eclipse:clean, eclipse:eclipse]
[INFO]
[INFO] [eclipse:clean]
[INFO] Deleting .project file...
[INFO] Deleting .classpath file...
[INFO] Deleting .wtpmodules file...
[INFO] Deleting .component file...
[INFO] Deleting org.eclipse.wst.common.project.facet.core.xml file...
[INFO] Preparing eclipse:eclipse
Downloading:
http://repo1.maven.org/maven2/org/codehaus/modello/modello-maven-plugin/1.0-alpha-13/modello-maven-plugin-1.0-alpha-13.pom
2K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/modello/modello/1.0-alpha-13/modello-1.0-alpha-13.pom
9K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/modello/modello-maven-plugin/1.0-alpha-13/modello-maven-plugin-1.0-alpha-13.jar
13K downloaded
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Goal 'jpox-metadata-class' was specified in an execution, but not found
in plugin org.codehaus.modello:modello-maven-plugin:1.0-alpha-8
{noformat}
Note the alpha-13 is downloaded but alpha-8 is used.
This is because the wrong parent-pom is used from the local repo. When i remove
continuum-parent from the local repo,
and run from:
* continuum: works.
* continuum/continuum-security: (leaf) works
* continuum/continuum-notifiers: (packaging pom, has modules) fails during
scanning for projects; cannot find continuum-parent (for one of
continuum/continuum-notifiers' children, but the error doesn't say which one)
* . (maven-trunks, packaging pom, modules): reactor construction works, but
build fails on eclipse:eclipse while creating a forked lifecycle for
generate-sources (i think, logs don't say).
plugin version aren't taken from pluginManagement in a sub-sub-modules
--
Key: MNG-2565
URL: http://jira.codehaus.org/browse/MNG-2565
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.5
Reporter: Emmanuel Venisse
Priority: Critical
It works only for the first inheritence level
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2565) plugin version aren't taken from pluginManagement in a sub-sub-modules
[ http://jira.codehaus.org/browse/MNG-2565?page=comments#action_83055 ] Kenney Westerhof commented on MNG-2565: --- I explicitly set the version for modello to 1.0-alpha-13 in the continuum-model/pom.xml, and it still used 1.0-alpha-8. I think this is a different issue alltogether: there can be no 2 different plugin versions used in 1 reactor. If some other project uses an older version of a plugin, then that one is used on the second instance too. That would explain why running from top level doesn't work - there's probably another project under top level that uses another version of the plugin. my 3rd point above is another issue though. plugin version aren't taken from pluginManagement in a sub-sub-modules -- Key: MNG-2565 URL: http://jira.codehaus.org/browse/MNG-2565 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.0.5 Reporter: Emmanuel Venisse Priority: Critical It works only for the first inheritence level -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-38) The archetype is using user.dir which prohibits clean embedding
[ http://jira.codehaus.org/browse/ARCHETYPE-38?page=all ] Kenney Westerhof closed ARCHETYPE-38. - Resolution: Fixed Fix Version/s: 1.0 Didn't apply patch since it breaks the current behavior. Fixed in revision 488162. The archetype is using user.dir which prohibits clean embedding --- Key: ARCHETYPE-38 URL: http://jira.codehaus.org/browse/ARCHETYPE-38 Project: Maven Archetype Issue Type: New Feature Affects Versions: 1.1-alpha-1 Reporter: Philip Dodds Assigned To: Kenney Westerhof Fix For: 1.0 Attachments: basedir.patch When using the archetype from an embedded maven (in this case within Eclipse to create new project templates) the archetype plugin is using the user.dir as the base for creating the project. If it were to use the basedir you would be able to re-locate the archetype. Attached is a patch for maven-archetype-plugin P -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-201) ${modules} renders as [] causing parse error
${modules} renders as [] causing parse error
Key: MSITE-201
URL: http://jira.codehaus.org/browse/MSITE-201
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Kenney Westerhof
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-202) Language bundle not found for empty pom project
Language bundle not found for empty pom project --- Key: MSITE-202 URL: http://jira.codehaus.org/browse/MSITE-202 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Kenney Westerhof for a POM project, no modules, no src/site, the following error is generated: Added 'maven-site-plugin/src/test/projects/site-plugin-test13/'. [INFO] Scanning for projects... [INFO] [INFO] Building Unnamed - org.apache.maven.plugins.site-plugin-test:site-plugin-test12:pom:1.0 [INFO]task-segment: [site] [INFO] [WARNING] Unable to get resource 'org.apache.maven.plugins:maven-plugins:pom:4-SNAPSHOT' from repository java.net (https://maven-repository.dev.java.net/nonav/repository/) [WARNING] POM for 'commons-collections:commons-collections:pom:3.1:runtime' is invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 POM. [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] Setting property: resource.manager.logwhenfound = 'false'. [INFO] [site:site] [INFO] artifact org.apache.maven.skins:maven-default-skin: checking for updates from java.net [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Can't find bundle for base name site-plugin, locale en [INFO] [INFO] Trace java.util.MissingResourceException: Can't find bundle for base name site-plugin, locale en at org.codehaus.plexus.i18n.DefaultI18N.cacheBundle(DefaultI18N.java:394) at org.codehaus.plexus.i18n.DefaultI18N.getBundle(DefaultI18N.java:157) at org.codehaus.plexus.i18n.DefaultI18N.getString(DefaultI18N.java:206) at org.apache.maven.plugins.site.AbstractSiteMojo.populateReportsMenu(AbstractSiteMojo.java:412) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.locateDocuments(AbstractSiteRenderingMojo.java:608) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:116) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:95) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:435) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:391) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:178) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:797) at org.apache.maven.cli.MavenCli.main(MavenCli.java:404) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) [INFO] [INFO] Total time: 11 seconds [INFO] Finished at: Mon Dec 18 10:50:53 CET 2006 [INFO] Final Memory: 15M/38M [INFO] FATAL ERROR: Unable to configure the Maven application For more information, run with the -e flag -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-201) ${modules} renders as [] causing parse error
[ http://jira.codehaus.org/browse/MSITE-201?page=comments#action_82850 ]
Kenney Westerhof commented on MSITE-201:
Added maven-site-plugin/src/test/projects/site-plugin-test12.
${modules} renders as [] causing parse error
Key: MSITE-201
URL: http://jira.codehaus.org/browse/MSITE-201
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Kenney Westerhof
Fix For: 2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-201) ${modules} renders as [] causing parse error
[ http://jira.codehaus.org/browse/MSITE-201?page=all ]
Kenney Westerhof updated MSITE-201:
---
Testcase included: yes
Fix Version/s: 2.0
${modules} renders as [] causing parse error
Key: MSITE-201
URL: http://jira.codehaus.org/browse/MSITE-201
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Kenney Westerhof
Fix For: 2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-161) VM Forking manifests itself behind HTTP proxy
[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=comments#action_82918 ] Kenney Westerhof commented on MSUREFIRE-161: Removed links to other issues, as this is not a classloading issue. The error is 'unknownknostexception: www.springframework.org'. This has something to do with DNS and proxies, not with classloading. My guess is that you've set some HTTP_PROXY env var that's available to maven/the jvm running maven, but isn't to the forked unit test. What's your exact setup? Unless org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:66) uses some resource file to feed the dns (impossible) or configure a proxy, I don't see the classloading issue here. Could you try to insert a typo in the DTD location, for instance 'xxx.springframework.org', and run the test without forking, to see what kind of stacktrace you get? It should be different from this one. VM Forking manifests itself behind HTTP proxy - Key: MSUREFIRE-161 URL: http://jira.codehaus.org/browse/MSUREFIRE-161 Project: Maven 2.x Surefire Plugin Issue Type: Bug Components: classloading Affects Versions: 2.3 Environment: win2k, java 1.5 Reporter: Ben Hood Fix For: 2.3 Attachments: mvn_trace.txt I have reason to believe that the forking behaviour of the surefire execution has adverse effects when executed behind an HTTP proxy in combination with DTD resolution (e.g. the loading of Spring beans). Whilst using surefire to test a project (the acegi module from the mule project, svn respo : http://svn.codehaus.org/mule/trunk/mule/modules/acegi , revision 2859) I was getting DTD resolution errors (see attached trace). I orginally posted this over at Spring: http://opensource.atlassian.com/projects/spring/browse/SPR-2466. Trying to get Eclipse to attach to the Maven debug process I set up (i.e. running maven with MAVEN_OPTS=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8787), I found out that this won't work because the plugin executing the code forks a new VM. After telling the maven surefire-plugin not to fork with this setting: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration forkModenever/forkMode /configuration /plugin /plugins /build the problem with the DTD resolution from Spring went away. Under normal circumstances, the DTD should get resolved from within the classpath, as it is bundled in the jar. So therefore I conclude that it is indeed a maven classloading / VM issue and not a Spring issue as first thought. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSUREFIRE-115) Classloading problem for getting a resource
[ http://jira.codehaus.org/browse/MSUREFIRE-115?page=all ] Kenney Westerhof closed MSUREFIRE-115. -- Assignee: Kenney Westerhof Resolution: Fixed Fixed in revision 488508. Added useSystemClassloader parameter that puts ALL test classpath elements in the system classloader. This is the only safe way to do it. Classloading problem for getting a resource --- Key: MSUREFIRE-115 URL: http://jira.codehaus.org/browse/MSUREFIRE-115 Project: Maven 2.x Surefire Plugin Issue Type: Bug Affects Versions: 2.2, 2.1.3 Environment: Maven 2.0.4 Windows XP Reporter: Wim Deblauwe Assigned To: Kenney Westerhof Priority: Blocker Fix For: 2.3 Attachments: maven-surefire-plugin-2.2-UseSystemClassLoader.patch, surefire-2.0-UseSystemClassLoader.patch, surefire-test.zip, workaround-for-fork.zip We are using Betwixt and some of our unit tests fail when run using surefire, but run fine in IntelliJ or Maven 1. Betwixt looks for descriptors with the name of the class + .betwixt to control how something is written out in XML. It uses the construct: myClass.getResource() to find the .betwixt file. E.g. com.mycomp.MyClass - com/mycomp/MyClass.betwixt We have a betwixt file for the java.util.Date class. However, betwixt seems to be unable to pick it up when using surefire. I have created a small test that shows the problem and have attached it. I tried with version 2.2 using different configurations (never, once, pertest) and with version 2.1.3 (default configuration) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSUREFIRE-121) ability to add dependency to jvm's classpath rather in surefirebooter classloader
[ http://jira.codehaus.org/browse/MSUREFIRE-121?page=all ] Kenney Westerhof closed MSUREFIRE-121. -- Assignee: Kenney Westerhof Resolution: Fixed Fixed in revision 488508. Added useSystemClassloader parameter that puts ALL test classpath elements in the system classloader. This is the only safe way to do it. ability to add dependency to jvm's classpath rather in surefirebooter classloader - Key: MSUREFIRE-121 URL: http://jira.codehaus.org/browse/MSUREFIRE-121 Project: Maven 2.x Surefire Plugin Issue Type: Bug Affects Versions: 2.2 Environment: xp Reporter: Dan Tran Assigned To: Kenney Westerhof Fix For: 2.3 Attachments: MSUREFIRE-121-booter.patch, MSUREFIRE-121.plugin.patch, MSUREFIRE-121.plugin.patch2, MSUREFIRE-121.plugin.patch3 I have a usecase where i have a jar file got loaded by -Xbootclasspath, that jar file then loads classes from another jar ( my dependency) expected in the classpath. The problem is that surefire plugin does not add my dependencies at JVM commanline thru -classpath option, but after the JVM starts -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSUREFIRE-151) Surefire plugin fails if JUnit is not available
[ http://jira.codehaus.org/browse/MSUREFIRE-151?page=all ] Kenney Westerhof closed MSUREFIRE-151. -- Assignee: Kenney Westerhof Resolution: Fixed Fixed in revision 488511 - fallback to surefire's JUnit provider which has POJO support. TODO: split off the pojo support from the junit provider. Surefire plugin fails if JUnit is not available --- Key: MSUREFIRE-151 URL: http://jira.codehaus.org/browse/MSUREFIRE-151 Project: Maven 2.x Surefire Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Simon Kepp Nielsen Assigned To: Kenney Westerhof Priority: Critical Fix For: 2.3 Attachments: error.txt, no-test-framework-patch.txt The Surefire Plugin fails with the following message, if JUnit is not available on the test classpath: [INFO] No Java test frameworks found This means, that you have to include JUnit in the classpath, even for projects that do not have any unit-tests (e.g. ressource projects or your first Hello World project). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSUREFIRE-119) Surefire plugin throws NoSuchMethodException when errors occur during TestSetup decorator
[ http://jira.codehaus.org/browse/MSUREFIRE-119?page=all ] Kenney Westerhof closed MSUREFIRE-119. -- Assignee: Kenney Westerhof Resolution: Fixed Fixed in revision 488512. Surefire plugin throws NoSuchMethodException when errors occur during TestSetup decorator - Key: MSUREFIRE-119 URL: http://jira.codehaus.org/browse/MSUREFIRE-119 Project: Maven 2.x Surefire Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Dan Fabulich Assigned To: Kenney Westerhof Fix For: 2.3 Attachments: setup-bug.zip I've included an example maven project, setup-bug.zip. It was created by doing mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=setup-bug and then modifying AppTest.java to use a TestSetup decorator. Normally JUnit runs your setUp()/tearDown() methods once for every test method... so if you've got a TestCase with methods testFoo and testBar, JUnit will normally run like this: setUp testFoo tearDown setUp testBar tearDown. You can use a TestSetup decorator to run your setUp function just once for the class: TestSetup.setUp testFoo testBar TestSetup.tearDown. In the example given, the test's setup method throws a RuntimeException (as tests sometimes do). Instead of handling this gracefully, Maven Surefire throws a NoSuchMethodException as it attempts to call .getName() on the TestSetup object (which isn't guaranteed to have a name). Running com.mycompany.app.AppTest org.apache.maven.surefire.booter.SurefireExecutionException: com.mycompany.app.AppTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: com.mycompany.app.AppTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null org.apache.maven.surefire.testset.TestSetFailedException: com.mycompany.app.AppTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null java.lang.reflect.UndeclaredThrowableException at $Proxy0.addError(Unknown Source) at junit.framework.TestResult.addError(TestResult.java:36) at junit.framework.TestResult.runProtected(TestResult.java:133) at junit.extensions.TestSetup.run(TestSetup.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) Caused by: java.lang.NoSuchMethodException: com.mycompany.app.AppTest$AppTestSetup.getName() at java.lang.Class.getMethod(Class.java:986) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.getStackTraceWriter(TestListenerInvocationHandler.java:171) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAddError(TestListenerInvocationHandler.java:160) at org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke(TestListenerInvocationHandler.java:134) ... 18 more [INFO] [ERROR] BUILD FAILURE [INFO] You can workaround this by hardcoding a public String getName() method on the TestSetup object and ensuring that it's public. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2348) add a simple command line alias for -Dmaven.test.skip=true as I find myself typing it very very often
[ http://jira.codehaus.org/browse/MNG-2348?page=comments#action_82344 ] Kenney Westerhof commented on MNG-2348: --- how about: export NT=-Dmaven.test.skip=true in you shell startup script, and then mvn $NT install same amount of characters.. add a simple command line alias for -Dmaven.test.skip=true as I find myself typing it very very often - Key: MNG-2348 URL: http://jira.codehaus.org/browse/MNG-2348 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.4 Reporter: james strachan Fix For: 2.1 Could we have some simple alias on the command line to disable unit tests just like we have maven -o for offline. Don't much mind what it is - how about... -nt --no-testsDisables the junit tests in this build so to do a build without unit tests mvn -nt install -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2695) -o makes build fail for snapshot plugins
-o makes build fail for snapshot plugins
Key: MNG-2695
URL: http://jira.codehaus.org/browse/MNG-2695
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.1
Reporter: Kenney Westerhof
I've set the maven-eclipse-plugin version to 2.3-SNAPSHOT in my root pom.
When I run without -o, the build works fine. All 100 non-deployed snapshot
artifacts are resolved 100 times from all of my 10 remote repo's so the
build takes ages.
After a succesful build, I run with -o and the build fails:
{noformat}
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: org.apache.maven.plugins
ArtifactId: maven-eclipse-plugin
Version: 2.3-SNAPSHOT
Reason: System is offline.
org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
NOTE: Maven is executing in offline mode. Any artifacts not already in your
local
repository will be inaccessible.
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build project
for plugin 'org.apache.maven.plugins:maven-eclipse-plugin': POM
'org.apache.maven.
plugins:maven-eclipse-plugin' not found in repository: System is offline.
org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1269)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:381)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:135)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182)
at
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:746)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:394)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.InvalidPluginException: Unable to build
project for plugin 'org.apache.maven.plugins:maven-eclipse-plugin': POM
'org.apache.mav
en.plugins:maven-eclipse-plugin' not found in repository: System is offline.
org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
at
org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:266)
at
org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:184)
at
org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:164)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252)
... 15 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM
'org.apache.maven.plugins:maven-eclipse-plugin' not found in repository: System
is offline.
org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:522)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:227)
at
org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:250)
... 18 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: System
is offline.
org.apache.maven.plugins:maven-eclipse-plugin:pom:2.3-SNAPSHOT
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:140)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:65)
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:476)
... 20 more
[INFO]
[INFO] Total time: 5 seconds
[INFO] Finished at: Mon Dec 11 12:11:50 CET 2006
[INFO] Final Memory: 6M/15M
[INFO]
[jira] Commented: (MNG-870) Make plugin discovery reactor aware
[ http://jira.codehaus.org/browse/MNG-870?page=comments#action_80983 ] Kenney Westerhof commented on MNG-870: -- Hm, stupid jira.. ;) I've created a new issue at MNG-2677. Make plugin discovery reactor aware --- Key: MNG-870 URL: http://jira.codehaus.org/browse/MNG-870 Project: Maven 2 Issue Type: New Feature Components: Plugins and Lifecycle Reporter: Kenney Westerhof Assigned To: Brett Porter Fix For: 2.0-beta-2 Attachments: MNG-870.diff Original Estimate: 1 hour Time Spent: 1 hour Remaining Estimate: 0 minutes If plugin discovery is reactor aware, plugins that are part of a reactor build and are used to aid the build can be used in one go. Else first the plugin should be installed, and then the rest of the project can be built. But mainly this aids in integration testing for plugins: the maven-it-plugin in sandbox can't add the current plugin + artifact to the lifecycle without making some methods public. If the plugin were to be discovered using the reactor, those methods can remain private. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2677) Plugin discovery not reactor aware
Plugin discovery not reactor aware -- Key: MNG-2677 URL: http://jira.codehaus.org/browse/MNG-2677 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle, Reactor and workspace Affects Versions: 2.0.4 Reporter: Kenney Westerhof Regression of MNG-870 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-139) Eclipse plugin cannot handle Java source files in resource directories
[ http://jira.codehaus.org/browse/MECLIPSE-139?page=comments#action_79517 ] Kenney Westerhof commented on MECLIPSE-139: --- I just realized I pretty much did the same work you did, by adding the launch stuff (i did it from scratch so I didn't use your code). I just applied portions of your patch to improve my solution, but I left out some things; - the forcePomgeneration param (don't do 2 new features in 1 patch - still very useful but will be applied for another jira issue). - the test cases; they didn't match with the current codebase. - the ability to specify how to handle the java resources. This should be handled in a default way. right now it's still ignoring (i already fixed the resource copying in another way a while back by adding excludes for **/*.java). A TODO is to also create an ant buildfile for this (merged with a possible other build file to fix nested output dirs). - the AntProjectWriter; i already had that code embedded somewhere. It still needs to be refactored out but your class was too specific; so i postponed this until a more structured way is being implemented. Eclipse plugin cannot handle Java source files in resource directories -- Key: MECLIPSE-139 URL: http://jira.codehaus.org/browse/MECLIPSE-139 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Jochen Kuhnle Assigned To: Kenney Westerhof Fix For: 2.3 Attachments: MECLIPSE-139-java-resources.patch, MECLIPSE-139-java-resources.patch, MECLIPSE-139-java-resources.patch The eclipse plugin cannot handle Java source files in resource directories: The resulting Eclipse configuration compiles the Java files, so the target directory contains the class files, but not the java sources. This is often troublesome in unit tests or when you need to use code templates, because you often get compile errors in the Workbench. The attached plugin allows to handle this situation in the following ways: 1. Default behavior: Work just as the plugin did before 2. Exclude Java files from resource dirs 3. Use an Ant builder to copy Java sources As a sideeffect, the patch also extends the handling of custom builders: Instead of just specifying a name, you can also specify the triggers and arguments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2539) Transitive dependencies referenced by a plugin are searched only in the plugin-repositories
[ http://jira.codehaus.org/browse/MNG-2539?page=all ] Kenney Westerhof updated MNG-2539: -- Fix Version/s: 2.0.5 Confirmed. This is about specifying dependencies within a plugin tag. Only pluginRepositories from the pom are used, not the normal repository definitions. Transitive dependencies referenced by a plugin are searched only in the plugin-repositories --- Key: MNG-2539 URL: http://jira.codehaus.org/browse/MNG-2539 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle, Dependencies Affects Versions: 2.0.4 Environment: WinXP, JDK 1.5_08 Reporter: Thomas Minor Fix For: 2.0.5 Transitive dependencies referenced by a plugin are searched only in the plugin-repositories In my case, the axis plugin references th javax.activation artifact. this artifact is keep at our site in a 3rd-party repo. If this repo is only addressed in the Repositories, the build fails.If it is also refereced in the pluginRepositories everything works fine. Is this the intended practice? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2117) Update doap file descriptor
[ http://jira.codehaus.org/browse/MNG-2117?page=all ] Kenney Westerhof updated MNG-2117: -- Fix Version/s: (was: 2.0.5) 2.0.6 Update doap file descriptor --- Key: MNG-2117 URL: http://jira.codehaus.org/browse/MNG-2117 Project: Maven 2 Issue Type: Task Components: Sites Reporting Affects Versions: 2.0.3 Reporter: Emmanuel Venisse Fix For: 2.0.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
