[jira] [Commented] (MNGSITE-370) Site: Dead link to wiki

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839700#comment-16839700
 ] 

Paul Benedict commented on MNGSITE-370:
---

I meant to log this issue in the MRELEASE project. Please move it there. Thank 
you.

> Site: Dead link to wiki
> ---
>
> Key: MNGSITE-370
> URL: https://issues.apache.org/jira/browse/MNGSITE-370
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Paul Benedict
>Priority: Trivial
>
> Home page > Usage section > 1st paragraph > Link "plugin's wiki page"
> This is a dead link. It points to the decommissioned Codehaus site. If the 
> content has moved elsewhere, link should be updated.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MNGSITE-370) Site: Dead link to wiki

[Paul Benedict (JIRA)]

Paul Benedict created MNGSITE-370:
-

 Summary: Site: Dead link to wiki
 Key: MNGSITE-370
 URL: https://issues.apache.org/jira/browse/MNGSITE-370
 Project: Maven Project Web Site
  Issue Type: Task
Reporter: Paul Benedict


Home page > Usage section > 1st paragraph > Link "plugin's wiki page"

This is a dead link. It points to the decommissioned Codehaus site. If the 
content has moved elsewhere, link should be updated.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNGSITE-365) EOL page surprisingly links to current M3 plugins

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814570#comment-16814570
 ] 

Paul Benedict commented on MNGSITE-365:
---

Yes.

> EOL page surprisingly links to current M3 plugins
> -
>
> Key: MNGSITE-365
> URL: https://issues.apache.org/jira/browse/MNGSITE-365
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Trivial
>
> The EOL page has links on "Plugin" and "Version" columns. The former links to 
> the current plugin sites; the second links to the last M2 versions, 
> respectively.
> An unsuspecting user (like me!) was clicking through the "Plugin" column, and 
> didn't realize it was the current documentation. This is a small usability 
> issue, but one I believe should be fixed. I am supporting ancient M2 stuff so 
> I come to the page often. The links are too good of a trap.
> Recommendation:
>  # Set the "Plugin" links to their EOL versions.
>  # Amend the "Plugin" values to include the V of the GAV (to make explicit 
> the connection between the two columns). Example: {{clean:2.6.1}}
>  # Remove the "Version" links.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MNGSITE-365) EOL page surprisingly links to current M3 plugins

[Paul Benedict (JIRA)]

Paul Benedict created MNGSITE-365:
-

 Summary: EOL page surprisingly links to current M3 plugins
 Key: MNGSITE-365
 URL: https://issues.apache.org/jira/browse/MNGSITE-365
 Project: Maven Project Web Site
  Issue Type: Improvement
Reporter: Paul Benedict
Assignee: Paul Benedict


The EOL page has links on "Plugin" and "Version" columns. The former links to 
the current plugin sites; the second links to the last M2 versions, 
respectively.

An unsuspecting user (like me!) was clicking through the "Plugin" column, and 
didn't realize it was the current documentation. This is a small usability 
issue, but one I believe should be fixed. I am supporting ancient M2 stuff so I 
come to the page often. The links are too good of a trap.

Recommendation:
 # Set the "Plugin" links to their EOL versions.
 # Amend the "Plugin" values to include the V of the GAV (to make explicit the 
connection between the two columns). Example: {{clean:2.6.1}}
 # Remove the "Version" links.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6606) Allow installation-wide parameter customization

[Paul Benedict (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-6606:
---
Description: 
In my use case, I would like to always print the version of Maven at every 
execution. I am not interested in a per-project case basis; nor interested in 
modifying the startup batch scripts. I want to drop in a standard configuration 
file to control all my Maven installations in the same manner.

My request is to make {{/.mvn/maven.config}} and {{./mvn/}}{{mavenrc}} to also 
be recognized in the Maven installation root. I am not explicitly asking for 
{{${maven.root}/.mvn}} to be *the* solution, but it's the right place to start 
the problem solving.

  was:
In my use case, I would like to always print the version of Maven at every 
execution. I am not interested in a per-project case basis; nor interested in 
modifying the startup batch scripts. I want to drop in a standard configuration 
file to control all my Maven installations in the same manner.

My request is to make {{/.mvn/maven.config}} and {{./mvn/}}{{mavenrc}} to be 
put in the Maven root itself. I am not explicitly asking for 
{{${maven.root}/.mvn}} to be *the* solution, but it's the right place to start 
the problem solving.


> Allow installation-wide parameter customization
> ---
>
> Key: MNG-6606
> URL: https://issues.apache.org/jira/browse/MNG-6606
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.1.1
>Reporter: Paul Benedict
>Priority: Major
>
> In my use case, I would like to always print the version of Maven at every 
> execution. I am not interested in a per-project case basis; nor interested in 
> modifying the startup batch scripts. I want to drop in a standard 
> configuration file to control all my Maven installations in the same manner.
> My request is to make {{/.mvn/maven.config}} and {{./mvn/}}{{mavenrc}} to 
> also be recognized in the Maven installation root. I am not explicitly asking 
> for {{${maven.root}/.mvn}} to be *the* solution, but it's the right place to 
> start the problem solving.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6606) Allow installation-wide parameter customization

[Paul Benedict (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-6606:
---
Description: 
In my use case, I would like to always print the version of Maven at every 
execution. I am not interested in a per-project case basis; nor interested in 
modifying the startup batch scripts. I want to drop in a standard configuration 
file to control all my Maven installations in the same manner.

My request is to make {{/.mvn/maven.config}} and {{./mvn/}}{{mavenrc}} to be 
put in the Maven root itself. I am not explicitly asking for 
{{${maven.root}/.mvn}} to be *the* solution, but it's the right place to start 
the problem solving.

  was:
In my use case, I would like to always print the version of Maven at every 
execution. I am not interested in a per-project case basis; nor interested in 
modifying the startup batch scripts. I want to drop in a standard configuration 
file to control all my Maven installations in the same manner.

My request is to make {{/.mvn/maven.config}} and {{./mvn/bashrc}} to be put in 
the Maven root itself. I am not explicitly asking for {{${maven.root}/.mvn}} to 
be *the* solution, but it's the right place to start the problem solving.


> Allow installation-wide parameter customization
> ---
>
> Key: MNG-6606
> URL: https://issues.apache.org/jira/browse/MNG-6606
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.1.1
>Reporter: Paul Benedict
>Priority: Major
>
> In my use case, I would like to always print the version of Maven at every 
> execution. I am not interested in a per-project case basis; nor interested in 
> modifying the startup batch scripts. I want to drop in a standard 
> configuration file to control all my Maven installations in the same manner.
> My request is to make {{/.mvn/maven.config}} and {{./mvn/}}{{mavenrc}} to be 
> put in the Maven root itself. I am not explicitly asking for 
> {{${maven.root}/.mvn}} to be *the* solution, but it's the right place to 
> start the problem solving.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6606) Allow installation-wide parameter customization

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791844#comment-16791844
 ] 

Paul Benedict commented on MNG-6606:


Thanks Michael. I corrected the description with {{mavenrc}}

> Allow installation-wide parameter customization
> ---
>
> Key: MNG-6606
> URL: https://issues.apache.org/jira/browse/MNG-6606
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.1.1
>Reporter: Paul Benedict
>Priority: Major
>
> In my use case, I would like to always print the version of Maven at every 
> execution. I am not interested in a per-project case basis; nor interested in 
> modifying the startup batch scripts. I want to drop in a standard 
> configuration file to control all my Maven installations in the same manner.
> My request is to make {{/.mvn/maven.config}} and {{./mvn/}}{{mavenrc}} to be 
> put in the Maven root itself. I am not explicitly asking for 
> {{${maven.root}/.mvn}} to be *the* solution, but it's the right place to 
> start the problem solving.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MNG-6606) Allow installation-wide parameter customization

[Paul Benedict (JIRA)]

Paul Benedict created MNG-6606:
--

 Summary: Allow installation-wide parameter customization
 Key: MNG-6606
 URL: https://issues.apache.org/jira/browse/MNG-6606
 Project: Maven
  Issue Type: Improvement
  Components: core
Affects Versions: 3.1.1
Reporter: Paul Benedict


In my use case, I would like to always print the version of Maven at every 
execution. I am not interested in a per-project case basis; nor interested in 
modifying the startup batch scripts. I want to drop in a standard configuration 
file to control all my Maven installations in the same manner.

My request is to make {{/.mvn/maven.config}} and {{./mvn/bashrc}} to be put in 
the Maven root itself. I am not explicitly asking for {{${maven.root}/.mvn}} to 
be *the* solution, but it's the right place to start the problem solving.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MNG-3508) Allow 'once' configuration item on plugin execution

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1218#comment-1218
 ] 

Paul Benedict edited comment on MNG-3508 at 10/27/18 9:37 PM:
--

I am reopening this ticket. This request seems perfectly reasonable. As 
evidenced by the many "how to" questions on the web, it is a frequently 
encountered problem without a perfect solution. Prime example is from [Brian's 
Sonatype blog 
post|https://blog.sonatype.com/2009/05/how-to-make-a-plugin-run-once-during-a-build/],
 and there are others I could cite (lots on Stack Overflow), but please see for 
yourself by searching "maven plugin run once".

Here is my use case. This is a real example from a custom plugin:
 # Plugin manages an external resource.
 # Plugin gets management configuration from the session (somewhere in the 
project hierarchy) in the form of properties.
 # Plugin must validly operate when bound to a phase.
 # Plugin must validly operate when directly executed from CLI.
 # Plugin must validly operate from any execution root in a multi-module build.
 # Plugin must execute only once per build (especially important in conjunction 
with #5).

At this moment only custom solutions exist – code yourself a workaround/hack. 
An official solution would be welcomed.

PS: It doesn't seem {{@Mojo(executionStrategy = "once-per-session")}} 
accomplishes this. That's surprising to me because, at least on its face, the 
attribute name seems to suggest it? Since my plugin runs in every project of a 
multi-module build, I suppose that means each project gets a new session?


was (Author: paul4christ79):
I am reopening this ticket. This request seems perfectly reasonable. As 
evidenced by the many "how to" questions on the web, it is a frequently 
encountered problem without a perfect solution. Prime example is from [Brian's 
Sonatype blog 
post|https://blog.sonatype.com/2009/05/how-to-make-a-plugin-run-once-during-a-build/],
 and there are others I could site (lots on Stack Overflow). but please see for 
yourself by searching "maven plugin run once".

Here is my use case. This is a real example from a custom plugin:
 # Plugin manages an external resource.
 # Plugin gets management configuration from the session (somewhere in the 
project hierarchy) in the form of properties.
 # Plugin must validly operate when bound to a phase.
 # Plugin must validly operate when directly executed from CLI.
 # Plugin must validly operate from any execution root in a multi-module build.
 # Plugin must execute only once per build (especially important in conjunction 
with #5).

At this moment only custom solutions exist – code yourself a workaround/hack. 
An official solution would be welcomed.

PS: It doesn't seem {{@Mojo(executionStrategy = "once-per-session")}} 
accomplishes this. That's surprising to me because, at least on its face, the 
attribute name seems to suggest it? Since my plugin runs in every project of a 
multi-module build, I suppose that means each project gets a new session?

> Allow 'once' configuration item on plugin execution
> ---
>
> Key: MNG-3508
> URL: https://issues.apache.org/jira/browse/MNG-3508
> Project: Maven
>  Issue Type: New Feature
>Reporter: Ittay Dror
>Priority: Major
>
> Scenario:
> - parent pom defines modules A, B 
> - it also defines a plugin with some execution
> - when it runs, the plugin runs 3 times (for parent, A, B)
> Now, I can set 'inherited' to false, but then if I just run 'A', the plugin 
> won't execute. 
> What I'd like is to be able to configure the execution to run 'once' in the 
> lifecycle. This is useful mainly for plugins that do some kind of setup, 
> initialization or validation, which in many cases need to be done once per 
> execution.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (MNG-3508) Allow 'once' configuration item on plugin execution

[Paul Benedict (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict reopened MNG-3508:


I am reopening this ticket. This request seems perfectly reasonable. As 
evidenced by the many "how to" questions on the web, it is a frequently 
encountered problem without a perfect solution. Prime example is from [Brian's 
Sonatype blog 
post|https://blog.sonatype.com/2009/05/how-to-make-a-plugin-run-once-during-a-build/],
 and there are others I could site (lots on Stack Overflow). but please see for 
yourself by searching "maven plugin run once".

Here is my use case. This is a real example from a custom plugin:
 # Plugin manages an external resource.
 # Plugin gets management configuration from the session (somewhere in the 
project hierarchy) in the form of properties.
 # Plugin must validly operate when bound to a phase.
 # Plugin must validly operate when directly executed from CLI.
 # Plugin must validly operate from any execution root in a multi-module build.
 # Plugin must execute only once per build (especially important in conjunction 
with #5).

At this moment only custom solutions exist – code yourself a workaround/hack. 
An official solution would be welcomed.

PS: It doesn't seem {{@Mojo(executionStrategy = "once-per-session")}} 
accomplishes this. That's surprising to me because, at least on its face, the 
attribute name seems to suggest it? Since my plugin runs in every project of a 
multi-module build, I suppose that means each project gets a new session?

> Allow 'once' configuration item on plugin execution
> ---
>
> Key: MNG-3508
> URL: https://issues.apache.org/jira/browse/MNG-3508
> Project: Maven
>  Issue Type: New Feature
>Reporter: Ittay Dror
>Priority: Major
>
> Scenario:
> - parent pom defines modules A, B 
> - it also defines a plugin with some execution
> - when it runs, the plugin runs 3 times (for parent, A, B)
> Now, I can set 'inherited' to false, but then if I just run 'A', the plugin 
> won't execute. 
> What I'd like is to be able to configure the execution to run 'once' in the 
> lifecycle. This is useful mainly for plugins that do some kind of setup, 
> initialization or validation, which in many cases need to be done once per 
> execution.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MPH-152) Enhance console output of "evaluate" goal to indicate result

[Paul Benedict (JIRA)]

Paul Benedict created MPH-152:
-

 Summary: Enhance console output of "evaluate" goal to indicate 
result
 Key: MPH-152
 URL: https://issues.apache.org/jira/browse/MPH-152
 Project: Maven Help Plugin
  Issue Type: Improvement
  Components: evaluate
Affects Versions: 3.0.1
Reporter: Paul Benedict


I have two requirements for consideration:
 # Scripts should be able to easily get the resolution status.
 # Scripts should be able to easily get the resolved expression value.

When evaluating an expression, the output does not have a good marker to help 
scripts identity the resolution. Current plugin behavior prints the value 
(practically buried among Maven's logging) or "null object or invalid 
expression" message.

The {{-o}} option could be used, of course, but file creation is more overhead 
than necessary. But what is good about the {{-o}} option is that it prints a 
clear marker:
{code:none}
> mvn help:evaluate -Dexpression=settings.localRepository -Doutput=out.txt
[INFO] Scanning for projects...
. . .
[INFO] Result of evaluation written to: c:\proj\out.txt{code}
Can you consider something similar for the console?

Example possible solutions:
{code:none}
> mvn help:evaluate -Dexpression=settings.localRepository
[INFO] Scanning for projects...
. . .
[INFO] Result of evaluation: /home/joeuser/.m2/repository{code}
And again:
{code:none}
> mvn help:evaluate -Dexpression=zzz
[INFO] Scanning for projects...
. . .
[INFO] Result of evaluation: null{code}
PS: If you think current behavior should be preserved, a new plugin option can 
be introduced. However, as [shown by this 
link|https://stackoverflow.com/questions/5916157/how-to-get-the-maven-local-repo-location],
 I think people have a difficult time clobbering together an answer to parse 
reliably. There are other examples on that site if you're interested. So I 
don't think any effort should be taken with introducing a new option. Just my 2 
cents. Since the fragility already exists, just provide an "official" solution 
to remediate it. 

Thank you.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MANTRUN-197) Can't use ant import task in target xml

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MANTRUN-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16355760#comment-16355760
 ] 

Paul Benedict edited comment on MANTRUN-197 at 2/7/18 5:29 PM:
---

Please add the support. I also have this problem when using the 
{{maven-script-ant}} scripting component. Maven doesn't know where to find the 
import because, evidently, the main build file was extracted into my operating 
system's temp directory.


was (Author: paul4christ79):
Please add the support. I also have this problem when using the 
`maven-script-ant` scripting component. Maven doesn't know where to find the 
import because, evidently, the main build file was extracted into my operating 
system's temp directory.

> Can't use ant import task in target xml
> ---
>
> Key: MANTRUN-197
> URL: https://issues.apache.org/jira/browse/MANTRUN-197
> Project: Maven Antrun Plugin
>  Issue Type: Wish
>Affects Versions: 1.8
>Reporter: Christoph Dittberner
>Priority: Major
>
> I want to externalize a macrodef to include it in different ant excecutions. 
> But using the ant import task throws an exception because the import task has 
> be defined *outside* of a target definition. There seems no way to specify 
> markup outside of or before the autogenerated main target tag to include the 
> import statement in the generated target/ant-run/build-main.xml.
> example to illustrate the problem:
> {code:title=src/ant/macrodef.xml|xml}
> 
> 
> 
> 
> hello world.
> 
> 
> 
> {code}
> {code:title=pom.xml|xml}
> ...
> 
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
> 
> 
> call-macrodef-1st
> process-sources
> 
> run
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> call-macrodef-2nd
> process-sources
> 
> run
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ...
> 
> 
> ...
> {code}
> {code:title=stacktrace}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run 
> (generate-launchers-server) on project project.build.dist: An Ant 
> BuildException has occured: import only allowed as a top-level task
> around Ant part ... file="n:\project.build.dist/src/ant/macrodef.xml"/>... @ 4:61 in 
> n:\project.build.dist\target\antrun\build-main.xml
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: An Ant 
> BuildException has occured: import only allowed as a top-level task
> around Ant part ... 

[jira] [Commented] (MANTRUN-197) Can't use ant import task in target xml

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MANTRUN-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16355760#comment-16355760
 ] 

Paul Benedict commented on MANTRUN-197:
---

Please add the support. I also have this problem when using the 
`maven-script-ant` scripting component. Maven doesn't know where to find the 
import because, evidently, the main build file was extracted into my operating 
system's temp directory.

> Can't use ant import task in target xml
> ---
>
> Key: MANTRUN-197
> URL: https://issues.apache.org/jira/browse/MANTRUN-197
> Project: Maven Antrun Plugin
>  Issue Type: Wish
>Affects Versions: 1.8
>Reporter: Christoph Dittberner
>Priority: Major
>
> I want to externalize a macrodef to include it in different ant excecutions. 
> But using the ant import task throws an exception because the import task has 
> be defined *outside* of a target definition. There seems no way to specify 
> markup outside of or before the autogenerated main target tag to include the 
> import statement in the generated target/ant-run/build-main.xml.
> example to illustrate the problem:
> {code:title=src/ant/macrodef.xml|xml}
> 
> 
> 
> 
> hello world.
> 
> 
> 
> {code}
> {code:title=pom.xml|xml}
> ...
> 
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
> 
> 
> call-macrodef-1st
> process-sources
> 
> run
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> call-macrodef-2nd
> process-sources
> 
> run
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ...
> 
> 
> ...
> {code}
> {code:title=stacktrace}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run 
> (generate-launchers-server) on project project.build.dist: An Ant 
> BuildException has occured: import only allowed as a top-level task
> around Ant part ... file="n:\project.build.dist/src/ant/macrodef.xml"/>... @ 4:61 in 
> n:\project.build.dist\target\antrun\build-main.xml
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: An Ant 
> BuildException has occured: import only allowed as a top-level task
> around Ant part ... file="n:\project.build.dist/src/ant/macrodef.xml"/>... @ 4:61 in 
> n:\project.build.dist\target\antrun\build-main.xml
> at 
> org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:342)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at 
> 

[jira] [Commented] (MPLUGIN-313) Error injecting JavaAnnotationsMojoDescriptorExtractor

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446275#comment-15446275
 ] 

Paul Benedict commented on MPLUGIN-313:
---

I went to a new machine and retried my project. The POM error gone away so I 
believe your theory of a corrupt local repository is correct. However, I am not 
out of the woods yet because something else is stopping me (but that is 
unrelated to this issue)...

Of curious note:
My use of {{mvn --update-plugins}} never solved the corrupted metadata issue. I 
ran that several times on my other machine hoping the metadata would be 
re-downloaded, but it did not. Don't you think it should? If a file is invalid, 
an update attempt should (in my expectation) see if it can be fixed by 
retrieving a new copy -- or at least retrieving a new copy of the hash as a 
smoke test. Perhaps I should move this ticket to project MNG because it sounds 
like Maven could do more to solve this problem automatically. WDYT?

> Error injecting JavaAnnotationsMojoDescriptorExtractor
> --
>
> Key: MPLUGIN-313
> URL: https://issues.apache.org/jira/browse/MPLUGIN-313
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: API
>Affects Versions: 3.5
>Reporter: Paul Benedict
>Priority: Blocker
>
> In the latest 3.5 snapshot, an exception prevents the building of a Mojo. I 
> tagged this as a "blocker" because I cannot find a workaround.
> Messages and stack trace:
> {code}
> [WARNING] The POM for 
> org.apache.maven.plugin-tools:maven-plugin-tools-annotations:jar:3.5-20160826.210808-25
>  is invalid, transitive dependencies (if any) will not be available, enable 
> debug logging for more details
> [INFO] java-javadoc mojo extractor found 0 mojo descriptor.
> [WARNING] Error injecting: 
> org.apache.maven.tools.plugin.extractor.annotations.JavaAnnotationsMojoDescriptorExtractor
> java.lang.NoClassDefFoundError: 
> org/codehaus/plexus/archiver/manager/NoSuchArchiverException
>   at java.lang.Class.getDeclaredConstructors0(Native Method)
>   at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
>   at java.lang.Class.getDeclaredConstructors(Class.java:2020)
>   at 
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
>   at 
> com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
>   at 
> com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:657)
>   at 
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:875)
>   at 
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:798)
>   at 
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:281)
>   at 
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:213)
>   at 
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:998)
>   at 
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1031)
>   at 
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:994)
>   at 
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1044)
>   at 
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
>   at 
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
>   at 
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:54)
>   at 
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
>   at 
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
>   at 
> org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
>   at 
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
>   at 
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
>   at 
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
>   at 
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:46)
>   at 
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
>   at 
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1066)
>   at 
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
>   at 
> 

[jira] [Created] (MPLUGIN-313) Error injecting JavaAnnotationsMojoDescriptorExtractor

[Paul Benedict (JIRA)]

Paul Benedict created MPLUGIN-313:
-

 Summary: Error injecting JavaAnnotationsMojoDescriptorExtractor
 Key: MPLUGIN-313
 URL: https://issues.apache.org/jira/browse/MPLUGIN-313
 Project: Maven Plugin Tools
  Issue Type: Bug
  Components: API
Affects Versions: 3.5
Reporter: Paul Benedict
Priority: Blocker


In the latest 3.5 snapshot, an exception prevents the building of a Mojo. I 
tagged this as a "blocker" because I cannot find a workaround.

Messages and stack trace:
{code}
[WARNING] The POM for 
org.apache.maven.plugin-tools:maven-plugin-tools-annotations:jar:3.5-20160826.210808-25
 is invalid, transitive dependencies (if any) will not be available, enable 
debug logging for more details
[INFO] java-javadoc mojo extractor found 0 mojo descriptor.
[WARNING] Error injecting: 
org.apache.maven.tools.plugin.extractor.annotations.JavaAnnotationsMojoDescriptorExtractor
java.lang.NoClassDefFoundError: 
org/codehaus/plexus/archiver/manager/NoSuchArchiverException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
at java.lang.Class.getDeclaredConstructors(Class.java:2020)
at 
com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
at 
com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
at 
com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:657)
at 
com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:875)
at 
com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:798)
at 
com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:281)
at 
com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:213)
at 
com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:998)
at 
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1031)
at 
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:994)
at 
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1044)
at 
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at 
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
at 
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:54)
at 
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at 
org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
at 
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at 
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
at 
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:46)
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1066)
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at 
com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:36)
at 
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at 
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1009)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1059)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1005)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
at 
org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at java.util.AbstractMap.get(AbstractMap.java:187)
at 
org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:87)
at 
org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:245)
at 
org.apache.maven.plugin.plugin.DescriptorGeneratorMojo.execute(DescriptorGeneratorMojo.java:90)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at 

[jira] [Commented] (MNG-6080) New scope for non-functional dependencies

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15424851#comment-15424851
 ] 

Paul Benedict commented on MNG-6080:


In a WAR project, yes, using {{provided}} would work because the ZIP would be 
consumed directly by the WAR. The transitive nature of {{provided}} wouldn't 
matter here. You are correct. Yet, I want to be careful in my analysis and make 
sure my use case isn't the wrong measuring stick for this new scope. 

> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
>  Issue Type: New Feature
>  Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the 
> classpath. The classpath is the path that the Java Runtime Environment (JRE) 
> searches for classes and other resource files. Given that the classpath is 
> Java specific, this feature request can be generalized to accommodate 
> artifacts that are not code related (directly or indirectly). It is neither 
> code that executes (like a .class file = "directly") nor a resource file 
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that 
> contains common look-and-feel elements to brand all their web applications. 
> This project could be a ZIP archive to be included in downstream projects, in 
> which each build explodes the archive into their respective web application 
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}. 
> They are nearly equal but have a different slight emphasis. The {{"asset"}} 
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes 
> purpose within the build. The Maven Team should decide among these two or 
> propose a third. 
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6080) New scope for non-functional dependencies

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422889#comment-15422889
 ] 

Paul Benedict commented on MNG-6080:


How about a little of both? It needs to be not in the output like {{provided}} 
but transitive like {{compile}}.

> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
>  Issue Type: New Feature
>  Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the 
> classpath. The classpath is the path that the Java Runtime Environment (JRE) 
> searches for classes and other resource files. Given that the classpath is 
> Java specific, this feature request can be generalized to accommodate 
> artifacts that are not code related (directly or indirectly). It is neither 
> code that executes (like a .class file = "directly") nor a resource file 
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that 
> contains common look-and-feel elements to brand all their web applications. 
> This project could be a ZIP archive to be included in downstream projects, in 
> which each build explodes the archive into their respective web application 
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}. 
> They are nearly equal but have a different slight emphasis. The {{"asset"}} 
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes 
> purpose within the build. The Maven Team should decide among these two or 
> propose a third. 
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6080) New scope for non-functional dependencies

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15421659#comment-15421659
 ] 

Paul Benedict commented on MNG-6080:


Michael, you are right that ZIP files are treated as first-class citizens on 
the classpath. Just for the sake of quoting something official to backup your 
point, here's a good line from Java documentation: ["Class path entries that 
are neither directories nor archives (.zip or JAR files) nor the asterisk (*) 
wildcard character are 
ignored."|https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html]

Regarding your first question, I am only proposing one scope. The two names are 
just potential choices ... with some philosophical waxing by me on the 
meanings/suggestions/implications behind the words. I hope that whatever name 
is chosen, it best captures the purpose of the scope.

Regarding your second question, the new scope should act like "compile" except 
it has no classpath entry. Plugins should not attempt to add it to any language 
execution environment. 

> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
>  Issue Type: New Feature
>  Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the 
> classpath. The classpath is the path that the Java Runtime Environment (JRE) 
> searches for classes and other resource files. Given that the classpath is 
> Java specific, this feature request can be generalized to accommodate 
> artifacts that are not code related (directly or indirectly). It is neither 
> code that executes (like a .class file = "directly") nor a resource file 
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that 
> contains common look-and-feel elements to brand all their web applications. 
> This project could be a ZIP archive to be included in downstream projects, in 
> which each build explodes the archive into their respective web application 
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}. 
> They are nearly equal but have a different slight emphasis. The {{"asset"}} 
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes 
> purpose within the build. The Maven Team should decide among these two or 
> propose a third. 
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MNG-6080) New scope for non-functional dependencies

[Paul Benedict (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-6080:
---
Summary: New scope for non-functional dependencies  (was: New scope for 
non-functional resources)

> New scope for non-functional dependencies
> -
>
> Key: MNG-6080
> URL: https://issues.apache.org/jira/browse/MNG-6080
> Project: Maven
>  Issue Type: New Feature
>  Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Critical
>
> Maven currently lacks a scope for artifacts that should not be part of the 
> classpath. The classpath is the path that the Java Runtime Environment (JRE) 
> searches for classes and other resource files. Given that the classpath is 
> Java specific, this feature request can be generalized to accommodate 
> artifacts that are not code related (directly or indirectly). It is neither 
> code that executes (like a .class file = "directly") nor a resource file 
> intimately linked to executable code (like a .properties file = "indirectly").
> For example, an organization may with to establish a Maven project that 
> contains common look-and-feel elements to brand all their web applications. 
> This project could be a ZIP archive to be included in downstream projects, in 
> which each build explodes the archive into their respective web application 
> context roots.
> Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}. 
> They are nearly equal but have a different slight emphasis. The {{"asset"}} 
> name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes 
> purpose within the build. The Maven Team should decide among these two or 
> propose a third. 
> Thread where discussion originated:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MNG-6080) New scope for non-functional resources

[Paul Benedict (JIRA)]

Paul Benedict created MNG-6080:
--

 Summary: New scope for non-functional resources
 Key: MNG-6080
 URL: https://issues.apache.org/jira/browse/MNG-6080
 Project: Maven
  Issue Type: New Feature
  Components: Dependencies
Affects Versions: 3.3.9
Reporter: Paul Benedict
Assignee: Paul Benedict
Priority: Critical


Maven currently lacks a scope for artifacts that should not be part of the 
classpath. The classpath is the path that the Java Runtime Environment (JRE) 
searches for classes and other resource files. Given that the classpath is Java 
specific, this feature request can be generalized to accommodate artifacts that 
are not code related (directly or indirectly). It is neither code that executes 
(like a .class file = "directly") nor a resource file intimately linked to 
executable code (like a .properties file = "indirectly").

For example, an organization may with to establish a Maven project that 
contains common look-and-feel elements to brand all their web applications. 
This project could be a ZIP archive to be included in downstream projects, in 
which each build explodes the archive into their respective web application 
context roots.

Two names in the running for the new scope are {{"asset"}} and {{"reactor"}}. 
They are nearly equal but have a different slight emphasis. The {{"asset"}} 
name emphasizes purpose of artifact. The {{"reactor"}} name emphasizes purpose 
within the build. The Maven Team should decide among these two or propose a 
third. 

Thread where discussion originated:
http://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/%3CCABLGb9x5e3fE25Qj9DwvCsCSa1Dwe_e6%2BOmWjL0ZbQ07HLEm8g%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MPLUGIN-305) MojoAnnotationsScanner should have better control over dependency scanning

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15417641#comment-15417641
 ] 

Paul Benedict commented on MPLUGIN-305:
---

Recommendation to update this page:
http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html

Addition to this sentence in bold: "Provided that the super class also uses 
annotations, it can now come from reactor projects or external dependencies. 
*You specify these dependencies by using the {{mojoDependencies}} property.*"

> MojoAnnotationsScanner should have better control over dependency scanning
> --
>
> Key: MPLUGIN-305
> URL: https://issues.apache.org/jira/browse/MPLUGIN-305
> Project: Maven Plugin Tools
>  Issue Type: Improvement
>  Components: maven-plugin-tools-annotations
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.5
>
>
> Currently MojoAnnotationsScanner always scans all dependencies in search for 
> Mojo's. However, most of the time there's no need to do so: the sources are 
> all the mojo's for the plugin.
> The simple solution would be to specify if the plugin should scan, and maybe 
> even which dependencies.
> A more elegant way would be to analyze the source-classes. If the Mojo's 
> extend known classes like AbstractMojo, there's no need to scan at all.
> ps. plugins which require dependencies-scanning are the maven-surefire-plugin 
> and maven-failsafe-plugin



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MPLUGIN-303) Plugin Plugin breaks when ASM6.0_ALPHA is configured as dependency

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384697#comment-15384697
 ] 

Paul Benedict commented on MPLUGIN-303:
---

The ASM used by the Plugin Plugin chokes on reading the new module-info.class 
file found in your project's ASM. The problem is the Plugin Plugin scans all 
dependencies of your project for other mojo annotations. MPLUGIN-304 should be 
the official solution. In the mean time, delete module-info.class out of your 
copy of ASM6.



> Plugin Plugin breaks when ASM6.0_ALPHA is configured as dependency
> --
>
> Key: MPLUGIN-303
> URL: https://issues.apache.org/jira/browse/MPLUGIN-303
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Andrew Dinn
>
> When the latest (3.0.7) Byteman project pom dependency on the ASM library is 
> upgraded from 5.0.3 to 6.0_ALPHA building  of  Byteman's maven rulechceck 
> plugin fails. If the version is reverted to 5.0.3 the plugin builds without 
> problem.
> Note that although this upgrade is needed in order to allow Byteman to 
> transform JDK9 class files no such files need to be present in the build for 
> the problme to manifest.  The failure occurs when building Byteman with JDK7, 
> JDK8 or JDK9. The ASM library and Byteman source do not use features beyond 
> JDK6. The Byteman build is configured with source and target level 1.6 The 
> ASM library has source and target 1.4.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5900) early interpolation: support ${this.*} as expression

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15224400#comment-15224400
 ] 

Paul Benedict commented on MNG-5900:


I'd like further background on the ticket's requirement: "So it is not possible 
that parent poms can lock values, ie avoid child poms override". Can you please 
give an example why something like this is necessary? Why is the child POM so 
problematic for your use case?

> early interpolation: support ${this.*} as expression
> 
>
> Key: MNG-5900
> URL: https://issues.apache.org/jira/browse/MNG-5900
> Project: Maven
>  Issue Type: New Feature
>  Components: Inheritance and Interpolation
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Right now we have $\{project.\*} which always interpolates values based on 
> the final project: "classical" interpolation is "late" interpolation. So it 
> is not possible that parent poms can lock values, ie avoid child poms 
> override. By adding $\{this} for "early" interpolation, it will be possible 
> to have intermediate interpolation.
> If a pomfile depends on a parent, that parent will first resolve all 
> $\{this.\*} values for itself. Once the fully inherited pom is there, all 
> $\{project.\*} will be resolved. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5885) Optimize execution when phases of same lifecycle are called

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130967#comment-15130967
 ] 

Paul Benedict commented on MNG-5885:


I tend to agree with you but for a different reason. First, "compile package" 
does not look like garbage; it looks like someone just explicitly listed out 
the phases they are most interested in. However, it's surprising this is not a 
runtime error, honestly. I don't believe optimizing is the right solution here 
but rejecting the syntax altogether. I don't believe we should allow more than 
one phase to be explicitly listed.

> Optimize execution when phases of same lifecycle are called
> ---
>
> Key: MNG-5885
> URL: https://issues.apache.org/jira/browse/MNG-5885
> Project: Maven
>  Issue Type: Sub-task
>  Components: Plugins and Lifecycle
>Affects Versions: 3.3.3
>Reporter: Robert Scholte
> Fix For: 3.x / Backlog
>
>
> In case someone calls {{compile package}} there's no need for the separate 
> {{compile}} call. Now the lifecycle is executed twice: once until {{compile}} 
> and once again until {{package}}.
> Note: {{package compile}} is weird due to its order, but should not be 
> optimized. {{compile resources:copy-resources package}} is a bit complicated. 
> Ideally this should call all phases up until {{compile}}, followed by 
> {{resources:copy-resources}}, followed by the {{process-classes}} to 
> {{package}} phases.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5904) Remove the whole Ant Build

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022898#comment-15022898
 ] 

Paul Benedict commented on MNG-5904:


With OpenJDK, they have a JDK-1 build policy. That is that JDK 9, for example, 
must be able to be compiled with JDK 8. If you plan on bootstrapping Maven with 
Maven, I think some sort of policy needs to be define. Perhaps it's based on 
minor version, for example: 3.4 requires that any 3.3.x Maven must be able to 
build it. WDYT?

> Remove the whole Ant Build
> --
>
> Key: MNG-5904
> URL: https://issues.apache.org/jira/browse/MNG-5904
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.4.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.4.0
>
>
> We should remove the whole Ant build cause we have a large number of Maven 
> versions which could be used to start building Maven itself.
> So i don't see any usefulness in it anymore.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNG-5904) Remove the whole Ant Build

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022898#comment-15022898
 ] 

Paul Benedict edited comment on MNG-5904 at 11/23/15 8:16 PM:
--

With OpenJDK, they have a JDK-1 build policy. That is JDK 9, for example, must 
be able to be compiled with JDK 8. If you plan on bootstrapping Maven with 
Maven, I think some sort of policy needs to be defined. Perhaps it's based on 
minor version, for example: 3.4 requires that any 3.3.x Maven must be able to 
build it. WDYT?


was (Author: paul4christ79):
With OpenJDK, they have a JDK-1 build policy. That is JDK 9, for example, must 
be able to be compiled with JDK 8. If you plan on bootstrapping Maven with 
Maven, I think some sort of policy needs to be define. Perhaps it's based on 
minor version, for example: 3.4 requires that any 3.3.x Maven must be able to 
build it. WDYT?

> Remove the whole Ant Build
> --
>
> Key: MNG-5904
> URL: https://issues.apache.org/jira/browse/MNG-5904
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.4.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.4.0
>
>
> We should remove the whole Ant build cause we have a large number of Maven 
> versions which could be used to start building Maven itself.
> So i don't see any usefulness in it anymore.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNG-5904) Remove the whole Ant Build

[Paul Benedict (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022898#comment-15022898
 ] 

Paul Benedict edited comment on MNG-5904 at 11/23/15 8:16 PM:
--

With OpenJDK, they have a JDK-1 build policy. That is JDK 9, for example, must 
be able to be compiled with JDK 8. If you plan on bootstrapping Maven with 
Maven, I think some sort of policy needs to be define. Perhaps it's based on 
minor version, for example: 3.4 requires that any 3.3.x Maven must be able to 
build it. WDYT?


was (Author: paul4christ79):
With OpenJDK, they have a JDK-1 build policy. That is that JDK 9, for example, 
must be able to be compiled with JDK 8. If you plan on bootstrapping Maven with 
Maven, I think some sort of policy needs to be define. Perhaps it's based on 
minor version, for example: 3.4 requires that any 3.3.x Maven must be able to 
build it. WDYT?

> Remove the whole Ant Build
> --
>
> Key: MNG-5904
> URL: https://issues.apache.org/jira/browse/MNG-5904
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.4.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.4.0
>
>
> We should remove the whole Ant build cause we have a large number of Maven 
> versions which could be used to start building Maven itself.
> So i don't see any usefulness in it anymore.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] (MNG-5743) Add support for splitted POMs

[Paul Benedict (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364699#comment-364699
 ] 

Paul Benedict commented on MNG-5743:


Maven uses XPP3 to consume XML. but I don't know if that can process XInclude 
directives. XInclude is the definitive way of breaking down a big file into 
little files. If you really want this feature, I'd say go down the direction of 
making sure such support exists in Maven's XML parser.

 Add support for splitted POMs
 -

 Key: MNG-5743
 URL: https://jira.codehaus.org/browse/MNG-5743
 Project: Maven
  Issue Type: Improvement
  Components: Design, Patterns  Best Practices
Affects Versions: Issues to be reviewed for 4.x
Reporter: Oliver B. Fischer

 Please add the possibility to split a POM into multiple files. A huge POM is 
 difficult to maintain and it is also difficult to navigate through a huge 
 POM. 
 So it would be nice to have the possibility to split a POM into multiple 
 files.
 This could be achived by adding an {{include}} directive or by supporting 
 configuration directory as suggested in [Optional support for splitting up 
 pom.xml in multiple files|http://docs.codehaus.org/x/BgSV].
 Adding this feature would be help to promoted Maven in new projects. 
 Futhermore it would be helpful for all maintaining large Maven based projects.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1991) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project

[Paul Benedict (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361824#comment-361824
 ] 

Paul Benedict commented on MNG-1991:


Yes, that's how I have seen it done. You add the war to get the artifact and 
the war's pom to get its dependencies.

 Can't get transitive dependencies from a war pom when this war is added as a 
 depdency of a project
 --

 Key: MNG-1991
 URL: https://jira.codehaus.org/browse/MNG-1991
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.2
Reporter: Emmanuel Venisse
 Attachments: war-deps.tar


 I have a project (continuum-core-it) that need to use all transitive 
 dependencies of a war (continuum-webapp). If i add the war as a dependency of 
 the project with packaging war, war dependencies aren't shown by project, 
 maven doesn't try to resolve them and doesn't add them in classpath.
 If if replace packaging from war to pom, all dependencies are resolved and 
 added to classpath.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5686) mvn cannot execute /usr/libexec/java_home/bin/java on OS X.

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-5686:
---

Fix Version/s: (was: 3.2.5)
   3.2.6

 mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
 ---

 Key: MNG-5686
 URL: https://jira.codehaus.org/browse/MNG-5686
 Project: Maven
  Issue Type: Bug
  Components: Command Line
Affects Versions: 3.2.3
 Environment: Mac OS X 10.9.4
Reporter: Takayoshi Fujiki
Assignee: Mirko Friedenhagen
 Fix For: 3.2.6

 Attachments: 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.patch, 
 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.v2.patch, 
 0002-MNG-5686-detect-JAVA_HOME-on-newer-OSX-again.patch, maven-bin-mvn.patch


 From 3.2.3, mvn cannot start and outputs the following error.
 {code}
 $ ./apache-maven-3.2.3/bin/mvn -version
 Error: JAVA_HOME is not defined correctly.
   We cannot execute /usr/libexec/java_home/bin/java
 {code}
 3.2.2 doesn't have this problem.
 {code}
 $ ./apache-maven-3.2.2/bin/mvn -version
 Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e; 
 2014-06-17T22:51:42+09:00)
 Maven home: /Users/xxx/tmp/apache-maven-3.2.2
 Java version: 1.8.0_11, vendor: Oracle Corporation
 Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: mac os x, version: 10.9.4, arch: x86_64, family: mac
 {code}
 When I modified {{bin/mvn}} like the following, this problem was gone.
 {code}
 --- bin/mvn.orig  2014-09-10 03:33:52.0 +0900
 +++ bin/mvn   2014-09-10 03:34:18.0 +0900
 @@ -83,7 +83,7 @@
   #
   # Apple JDKs
   #
 - export JAVA_HOME=/usr/libexec/java_home
 + export JAVA_HOME=`/usr/libexec/java_home`
 fi
 ;;
  esac
 {code}
 Maybe MNG-5658 is related to this problem. {{/usr/libexec/java_home}} is a 
 command([java_home(1)|https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man1/java_home.1.html]),
  and {{$(command)}} is a style of [Command 
 Substitution|http://www.tldp.org/LDP/abs/html/commandsub.html] (Another(old) 
 style is {{`command`}}).
 So removing $() breaks the JAVA_HOME detection on OS X.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1683) type zip for packaging ?

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict reassigned MNG-1683:
--

Assignee: Paul Benedict

 type zip for packaging ?
 

 Key: MNG-1683
 URL: https://jira.codehaus.org/browse/MNG-1683
 Project: Maven
  Issue Type: Improvement
 Environment: not significant
Reporter: Olivier Lamy
Assignee: Paul Benedict
 Fix For: Issues to be reviewed for 3.x

 Attachments: archive+file-plugins.tar.bz2, maven-war-plugin.tar.gz, 
 maven-zip-plugin.tar.gz, MNG-1683.tar.gz, patch1, temp-test_version.zip


 Hi,
 I don't know if the artifact type zip exists (I think not after few test).
 But I want to separate the html content and the webapp content (classes, 
 configuration files and so on).
 The use case is to separate this different works (html designer and java 
 developpement) and production installation (one is to an http server and the 
 other is on an app server) in two artifacts with separate versionning.
 But the packagingzip/packaging is not recognized.
 Then I would like to use it as an artifact with maven's features (snapshot, 
 pom, version, goals : install, deploy release and all others).
 Add it to the webapp dependencies (needed only for developpment or unit 
 tests).
 With this type of dependency the zip content could be unpacked to a directory 
 in the exploded webapp. (certainly need hack on the maven-war-plugin).
 I have certainly the workaround to declare this as jar and using the assembly 
 plugin to generate a zip. 
 But I can't use install release deploy or something else to manage the 
 generated zip which is not an artifact.
 Thanks for help or workaround.
 - Olivier 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1683) type zip for packaging ?

[Paul Benedict (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359770#comment-359770
 ] 

Paul Benedict edited comment on MNG-1683 at 12/27/14 1:45 PM:
--

Of course we still need it. This will reduce the boilerplate to produce the zip 
artifacts. I've been an active conversation about this on dev@:
http://mail-archives.apache.org/mod_mbox/maven-dev/201412.mbox/browser

My plan (as recommended by Stephen) is to make a new mojo inside of the 
assembly plugin. Let's keep this issue and link it to the MASSEMBLY issue when 
I get to it.


was (Author: paul4christ79):
Of course we still need it. This will reduce the boilerplate to produce the zip 
artifacts. I've been an active conversation about this on dev@:
http://mail-archives.apache.org/mod_mbox/maven-dev/201412.mbox/browser



 type zip for packaging ?
 

 Key: MNG-1683
 URL: https://jira.codehaus.org/browse/MNG-1683
 Project: Maven
  Issue Type: Improvement
 Environment: not significant
Reporter: Olivier Lamy
Assignee: Paul Benedict
 Fix For: Issues to be reviewed for 3.x

 Attachments: archive+file-plugins.tar.bz2, maven-war-plugin.tar.gz, 
 maven-zip-plugin.tar.gz, MNG-1683.tar.gz, patch1, temp-test_version.zip


 Hi,
 I don't know if the artifact type zip exists (I think not after few test).
 But I want to separate the html content and the webapp content (classes, 
 configuration files and so on).
 The use case is to separate this different works (html designer and java 
 developpement) and production installation (one is to an http server and the 
 other is on an app server) in two artifacts with separate versionning.
 But the packagingzip/packaging is not recognized.
 Then I would like to use it as an artifact with maven's features (snapshot, 
 pom, version, goals : install, deploy release and all others).
 Add it to the webapp dependencies (needed only for developpment or unit 
 tests).
 With this type of dependency the zip content could be unpacked to a directory 
 in the exploded webapp. (certainly need hack on the maven-war-plugin).
 I have certainly the workaround to declare this as jar and using the assembly 
 plugin to generate a zip. 
 But I can't use install release deploy or something else to manage the 
 generated zip which is not an artifact.
 Thanks for help or workaround.
 - Olivier 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1683) type zip for packaging ?

[Paul Benedict (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=359770#comment-359770
 ] 

Paul Benedict commented on MNG-1683:


Of course we still need it. This will reduce the boilerplate to produce the zip 
artifacts. I've been an active conversation about this on dev@:
http://mail-archives.apache.org/mod_mbox/maven-dev/201412.mbox/browser



 type zip for packaging ?
 

 Key: MNG-1683
 URL: https://jira.codehaus.org/browse/MNG-1683
 Project: Maven
  Issue Type: Improvement
 Environment: not significant
Reporter: Olivier Lamy
Assignee: Paul Benedict
 Fix For: Issues to be reviewed for 3.x

 Attachments: archive+file-plugins.tar.bz2, maven-war-plugin.tar.gz, 
 maven-zip-plugin.tar.gz, MNG-1683.tar.gz, patch1, temp-test_version.zip


 Hi,
 I don't know if the artifact type zip exists (I think not after few test).
 But I want to separate the html content and the webapp content (classes, 
 configuration files and so on).
 The use case is to separate this different works (html designer and java 
 developpement) and production installation (one is to an http server and the 
 other is on an app server) in two artifacts with separate versionning.
 But the packagingzip/packaging is not recognized.
 Then I would like to use it as an artifact with maven's features (snapshot, 
 pom, version, goals : install, deploy release and all others).
 Add it to the webapp dependencies (needed only for developpment or unit 
 tests).
 With this type of dependency the zip content could be unpacked to a directory 
 in the exploded webapp. (certainly need hack on the maven-war-plugin).
 I have certainly the workaround to declare this as jar and using the assembly 
 plugin to generate a zip. 
 But I can't use install release deploy or something else to manage the 
 generated zip which is not an artifact.
 Thanks for help or workaround.
 - Olivier 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1683) type zip for packaging ?

[Paul Benedict (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=358406#comment-358406
 ] 

Paul Benedict commented on MNG-1683:


Is adding a zip packaging really going to be part of 3.x? Or 4.0?

 type zip for packaging ?
 

 Key: MNG-1683
 URL: https://jira.codehaus.org/browse/MNG-1683
 Project: Maven
  Issue Type: Improvement
 Environment: not significant
Reporter: Olivier Lamy
 Fix For: Issues to be reviewed for 3.x

 Attachments: archive+file-plugins.tar.bz2, maven-war-plugin.tar.gz, 
 maven-zip-plugin.tar.gz, MNG-1683.tar.gz, patch1, temp-test_version.zip


 Hi,
 I don't know if the artifact type zip exists (I think not after few test).
 But I want to separate the html content and the webapp content (classes, 
 configuration files and so on).
 The use case is to separate this different works (html designer and java 
 developpement) and production installation (one is to an http server and the 
 other is on an app server) in two artifacts with separate versionning.
 But the packagingzip/packaging is not recognized.
 Then I would like to use it as an artifact with maven's features (snapshot, 
 pom, version, goals : install, deploy release and all others).
 Add it to the webapp dependencies (needed only for developpment or unit 
 tests).
 With this type of dependency the zip content could be unpacked to a directory 
 in the exploded webapp. (certainly need hack on the maven-war-plugin).
 I have certainly the workaround to declare this as jar and using the assembly 
 plugin to generate a zip. 
 But I can't use install release deploy or something else to manage the 
 generated zip which is not an artifact.
 Thanks for help or workaround.
 - Olivier 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCHANGES-150) [regression] Incorrect parsing of the author element

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MCHANGES-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict reopened MCHANGES-150:



Reopening since this is a confirmed bug.

 [regression] Incorrect parsing of the author element
 --

 Key: MCHANGES-150
 URL: https://jira.codehaus.org/browse/MCHANGES-150
 Project: Maven Changes Plugin
  Issue Type: Bug
  Components: changes.xml, modello
Affects Versions: 2.1
Reporter: Paul Benedict
 Attachments: changes.xml, MNG-4045-debug.txt, MNG-4045.zip


 I was locking down my Maven Changes Plugin version with the following config:
 {code}
 reporting
   plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-changes-plugin/artifactId
   version2.1/version
   reportSets
 reportSet
   reports
 reportchanges-report/report
   /reports
 /reportSet
   /reportSets
   /plugin
 /reporting
 {code}
 And then I created the site and noticed the report was empty. The report 
 markup was there, of course, but it generated like my changes.xml was blank. 
 I could run changes:changes-report just fine. However, when I then removed 
 the version tag and tried site:site again, the report output was present as 
 expected.
 Here's an interesting line from the debug output when version is specified:
 {quote}[DEBUG]  The following artifacts were filtered out for plugin: 
 org.apache.maven.plugins:maven-changes-plugin:2.1 because they're already in 
 the core of Maven:{quote}
 My theory is that because my plugin version has an exact match on the 
 version, my specified plugin configuration is tossed. That certainly seems 
 like a bug to me.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1204) don't show disabled repositories in artifact exceptions

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-1204:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 don't show disabled repositories in artifact exceptions
 ---

 Key: MNG-1204
 URL: https://jira.codehaus.org/browse/MNG-1204
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Reporter: Brett Porter
Assignee: Edwin Punzalan
Priority: Minor
 Attachments: MNG-1204-maven-artifact.patch






--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1958) we need a var that always points to the root directory in multi module builds

[Paul Benedict (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=350260#comment-350260
 ] 

Paul Benedict commented on MNG-1958:


I don't see this as a good idea. There is no guarantee the root project even 
exists in a sensible location -- it could exist solely in the local repository 
and resolved at build time. Surely, you wouldn't want to reference that 
location. I think you should keep your builds relative to ${basedir} for 
portability.

 we need a var that always points to the root directory in multi module builds
 -

 Key: MNG-1958
 URL: https://jira.codehaus.org/browse/MNG-1958
 Project: Maven
  Issue Type: Improvement
  Components: Reactor and workspace
Reporter: Mark Proctor
Assignee: Jason van Zyl
 Fix For: 3.2.3


 $\{basedir} always points to the local module. There are cases, when having a 
 local relative repository, when it would be usefull to have a var that always 
 pointed to the root project, $\{rootdir}.
 In such a case you may want to think of having the names $\{rootdir} 
 $\{moduledir}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1958) we need a var that always points to the root directory in multi module builds

[Paul Benedict (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=350260#comment-350260
 ] 

Paul Benedict edited comment on MNG-1958 at 7/23/14 1:53 PM:
-

I don't see this as a good idea. There is no guarantee the root project even 
exists in a sensible location -- it could exist solely in the local repository 
and resolved at build time. Surely, you wouldn't want to reference that 
location. I think you should keep your builds relative to basedir for 
portability.


was (Author: paul4christ79):
I don't see this as a good idea. There is no guarantee the root project even 
exists in a sensible location -- it could exist solely in the local repository 
and resolved at build time. Surely, you wouldn't want to reference that 
location. I think you should keep your builds relative to ${basedir} for 
portability.

 we need a var that always points to the root directory in multi module builds
 -

 Key: MNG-1958
 URL: https://jira.codehaus.org/browse/MNG-1958
 Project: Maven
  Issue Type: Improvement
  Components: Reactor and workspace
Reporter: Mark Proctor
Assignee: Jason van Zyl
 Fix For: 3.2.3


 $\{basedir} always points to the local module. There are cases, when having a 
 local relative repository, when it would be usefull to have a var that always 
 pointed to the root project, $\{rootdir}.
 In such a case you may want to think of having the names $\{rootdir} 
 $\{moduledir}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5660) prerequisites element in pom does not work on maven 3.2.2

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-5660:
---

Fix Version/s: (was: 3.2.x)

 prerequisites element in pom does not work on maven 3.2.2
 -

 Key: MNG-5660
 URL: https://jira.codehaus.org/browse/MNG-5660
 Project: Maven
  Issue Type: Bug
  Components: Command Line, Errors
Affects Versions: 3.2.2
 Environment: java 1.7
Reporter: Alan Mehio
Priority: Minor

 Failed to execute goal 
 com.google.appengine:appengine-maven-plugin:1.9.6:devserver (default-cli) on 
 project guestbook: The plugin com.google
 .appengine:appengine-maven-plugin:1.9.6 requires Maven version 3.1.0 -
 It should work on a min version of  3.1.0 and not exact same version as 
 explained in maven pom specification below:
 http://maven.apache.org/pom.html#Prerequisites
 The POM may have certain prerequisites in order to execute correctly. For 
 example, perhaps there was a fix in Maven 2.0.3 that you need in order to 
 deploy using sftp. Here is where you give the prerequisites to building. If 
 these are not met, Maven will fail the build before even starting. The only 
 element that exists as a prerequisite in POM 4.0 is the maven element, which 
 takes a minimum version number.
 look at the project   
 https://code.google.com/p/appengine-maven-plugin/
 and its usage  
 https://developers.google.com/appengine/docs/java/gettingstarted/ui_and_code
 and the command line which cause the issue
 mvn appengine:devserver
 error message :
  Failed to execute goal 
 com.google.appengine:appengine-maven-plugin:1.9.6:devserver (default-cli) on 
 project guestbook: The plugin com.google
 .appengine:appengine-maven-plugin:1.9.6 requires Maven version 3.1.0 - [Help 
 1]
 the pom file from the  google app engine maven plugin
 
 prerequisites
 maven3.1.0/maven
 /prerequisites
 .



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3695) Allow dependencies' scopes to be managed without explicit versions

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3695:
---

Fix Version/s: (was: Issues to be reviewed for 4.x)

 Allow dependencies' scopes to be managed without explicit versions
 --

 Key: MNG-3695
 URL: https://jira.codehaus.org/browse/MNG-3695
 Project: Maven
  Issue Type: New Feature
  Components: Dependencies
Affects Versions: 2.0.9
Reporter: Mark Hobson

 Currently, a dependency's version or a dependency's version and scope can be 
 managed in dependency management, but a dependency's scope alone cannot be 
 managed.  For example, we cannot express the following:
 {noformat}dependencies
   dependency
 groupIdjavax.mail/groupId
 artifactIdmail/artifactId
 scopeprovided/scope
   /dependency
 /dependencies{noformat}
 Of course it does work if we also specify a version, but there are times when 
 we want to merely control the scope and not change the resolved version.  
 When we try the above example we get:
 {noformat}[INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] An invalid artifact was detected.
 This artifact might be in your project's POM, or it might have been included 
 transitively during the resolution process.
  Here is the information we do have for this artifact:
 o GroupID: javax.mail
 o ArtifactID:  mail
 o Version:  MISSING 
 o Type:jar
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.artifact.InvalidArtifactRTException: For artifact 
 {javax.mail:mail:null:jar}: The version cannot be empty.
 at 
 org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147)
 at 
 org.apache.maven.artifact.DefaultArtifact.init(DefaultArtifact.java:122)
 at 
 org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:158)
 at 
 org.apache.maven.artifact.factory.DefaultArtifactFactory.createDependencyArtifact(DefaultArtifactFactory.java:58)
 at 
 org.apache.maven.project.DefaultMavenProjectBuilder.createManagedVersionMap(DefaultMavenProjectBuilder.java:452)
 at 
 org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:912)
 at 
 org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
 at 
 org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
 at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
 at 
 org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
 at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
 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:597)
 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){noformat}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-841) Support customization of default excludes

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-841:
--

Fix Version/s: (was: Issues to be reviewed for 4.x)

 Support customization of default excludes
 -

 Key: MNG-841
 URL: https://jira.codehaus.org/browse/MNG-841
 Project: Maven
  Issue Type: Improvement
  Components: POM
Affects Versions: 2.0-alpha-3
 Environment: WinXP SP2, Java 1.5, Maven 2.0-alpha-3
Reporter: John Fallows

 Our company uses a home-grown version control system that has it's own 
 per-directory admin subdirectory, similar in purpose to the administration 
 subdirectories used by other version control systems, eg. CVS, .svn, etc.
 These directories are excluded from processing by default in Maven2, and we 
 would like to add our custom admin subdirectory to the default exclusion list.
 Recommended solution from Maven Users Mailing List:
 Brett Porter wrote:
 # What you really need is to be able to configure it in a root POM shared by 
 all projects, I think.
 Hopefully, any such entry in pom.xml would not completely replace the default 
 excludes list, but merely entend the built-in definition.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-2557) Various enhancements to profiles

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2557:
---

Fix Version/s: (was: Issues to be reviewed for 4.x)

 Various enhancements to profiles
 

 Key: MNG-2557
 URL: https://jira.codehaus.org/browse/MNG-2557
 Project: Maven
  Issue Type: Improvement
  Components: Profiles
Affects Versions: 2.0.4
Reporter: Jimisola Laursen

 The current support for profiles is somewhat limited and this issue report 
 proposes some enhancements to profiles for ease and flexibility of use.
 Enhancement #1: Make it possible to have profiles that mutually exclude each 
 other. A profile should be able to exclude one or more other profiles.
 Example of usage: We have a couple of profiles for databas settings (MSSQL, 
 PostgreSQL and Derby). Only one of these profiles should be able to be active 
 at the same time. Today, we can't express this in the profiles section.
 Enhancement #2: Make it possible to deactivate profiles from the command line.
 Example of usage: User and/or project has a set of profiles that are activate 
 per default. The user wants to temporary disable on or more of these (by 
 temporary I mean for one execution).
 Possible syntax might be: mvn -PsomeProfile=inactive|false|no or perhaps a 
 separate command line switch.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1569) Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-1569:
---

Fix Version/s: (was: Issues to be reviewed for 4.x)

 Make build process info read-only to mojos, and provide mechanism for 
 explicit out-params for mojos to declare
 --

 Key: MNG-1569
 URL: https://jira.codehaus.org/browse/MNG-1569
 Project: Maven
  Issue Type: New Feature
  Components: Design, Patterns  Best Practices
Affects Versions: 2.0
Reporter: John Casey
Priority: Trivial

 We need to have the ability to look at a mojo descriptor and see how it will 
 change the build environment. This requires two things:
 1. Cut off the loophole allowing unauthorized mutation of build state by 
 making build state read-only to the mojo
 2. Provide an API/annotation-set to allow explicit export of values from a 
 mojo, where they will be incorporated into the build state.
 This should enable things like determining whether a mojo generates sources, 
 or collecting the source directories (even generated ones) by scanning the 
 plugins configured for the build.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-2719) Request for Summary element in POM

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2719:
---

Fix Version/s: (was: Issues to be reviewed for 4.x)

 Request for Summary element in POM
 --

 Key: MNG-2719
 URL: https://jira.codehaus.org/browse/MNG-2719
 Project: Maven
  Issue Type: New Feature
  Components: POM
Reporter: Ole Ersoy
Priority: Minor

 If a summary element were added it would make RPM
 Spec file generation more efficient, since spec files
 require both a description and a summary.
 A summary element can also be handy for 
 for other tools that want to generate reports
 giving a summary, as well as a longer description
 of the project.
 If this sounds reasonable I will update the XML Schema for maven with the 
 summary
 element and submit.
 Cheers,
 - Ole



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4622) Throw Validation Error if pom contains a dependency with two different versions.

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4622:
---

Fix Version/s: (was: Issues to be reviewed for 4.x)

 Throw Validation Error if pom contains a dependency with two different 
 versions.
 

 Key: MNG-4622
 URL: https://jira.codehaus.org/browse/MNG-4622
 Project: Maven
  Issue Type: Improvement
  Components: Inheritance and Interpolation
Reporter: Shane Isbell

 Throw a validation error if a pom contains the same dependency with two 
 different versions. 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-2598) profile element in POM should support overriding project.build.directory

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2598:
---

Fix Version/s: (was: Issues to be reviewed for 4.x)

 profile element in POM should support overriding project.build.directory
 

 Key: MNG-2598
 URL: https://jira.codehaus.org/browse/MNG-2598
 Project: Maven
  Issue Type: Improvement
  Components: Profiles
Affects Versions: 2.0.4
Reporter: Ian Springer

 I am trying to set up a 'dev' build profile that, when enabled, will cause my 
 j2ee artifacts to be built directly to exploded j2ee deployment dirs, instead 
 of target/classes/. The purpose is to make the everyday development process 
 more efficient by skipping a number of time-consuming intermediate mvn steps 
 (i.e. jarring artifacts, copying the jars to the local repo, then unjarring 
 the artifacts to their deploy locations).
 The intuitive way to achieve this is to override 'project.build.directory' 
 and/or 'project.build.outputDirectory' in a profile; e.g.:
 profile
 ...
  build
   
 outputDirectory${jboss.home}/server/default/deploy/my.ear/my-exploded-ejb.jar
  /build
 ...
 /profile
 Unfortunately, profiles currently do not allow one to override either 
 'project.build.directory' or 'project.build.outputDirectory'. Please change 
 Maven to allow profiles to override these props. Otherwise, I can't see any 
 other way to achieve what my team needs to do to have a practical build/dev 
 infrastructure.
 Thanks,
 Ian



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4004) Artifact not found when searching on multiple repositories

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4004:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Artifact not found when searching on multiple repositories
 --

 Key: MNG-4004
 URL: https://jira.codehaus.org/browse/MNG-4004
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.9
Reporter: ol
Priority: Critical

 We have a project P that depends on a dependency D1.
 This dependency D1 has a dependency on D2 with a version range. Let's say 
 [1.7,)
 In our company, we have 2 enterprise repositories :
 central : central repository that contains all dependencies that can be used 
 by our development teams.
 poc :  repository that contains dependencies which are being validated by our 
 experts.
 In the settings.xml, the central repository is defined before the poc 
 repository
 The D2 artifact is present in both repositories, but with different versions:
 - D2 version 1.2 is in our poc repository
 - D2 version 1.5, 1.7 and 1.8 are in our central repository
 When Maven tries to resolve dependencies, it tries to find the best version 
 of the D2 dependency.
 So it does the intersection of [1.2, 1.5, 1.7, 1.8] and [1.7,)
 The result is 1.8 (available in our central repository).
 The problem is that Maven does not find the version 1.8 of D2 because it only 
 searches for it in the poc repository.
 We don't know why, but we think that it's because the version 1.2 is in the 
 poc repository, so it also tries to find the version 1.8 in the poc 
 repository.
 We found 2 workarounds:
 - If we remove the version 1.2 from the poc repository, maven searches for 
 version 1.8 in the central repository (so it works fine).
 - If we add the version 1.8 to the poc repository, maven searches for version 
 1.8 in the poc repository (so it works fine).



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-977) remove need for plugin groups

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-977:
--

Fix Version/s: (was: Issues to be reviewed for 3.x)

 remove need for plugin groups
 -

 Key: MNG-977
 URL: https://jira.codehaus.org/browse/MNG-977
 Project: Maven
  Issue Type: Improvement
  Components: Plugins and Lifecycle
Reporter: Brett Porter

 we could store the avilable plugin groups at the root of the repository and 
 grab those instead



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4579) Maven Wagon SSH does not mask password

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4579:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Maven Wagon SSH does not mask password
 --

 Key: MNG-4579
 URL: https://jira.codehaus.org/browse/MNG-4579
 Project: Maven
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 2.2.1
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
 Java version: 1.6.0_17
 Java home: C:\program Files\Java\jdk1.6.0_17\jre
 Default locale: de_DE, platform encoding: Cp1252
 OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Heinrich Schuchardt
Priority: Minor

 I am using 
 mvn site:deploy
 with scp as protocol.
 When uploading mvn asks for the ssh password. The password is displayed 
 instead of being masked by .
 To reproduce the issue try the following:
 mvn wagon:upload-single -Dwagon.fromFile=c:\temp\test.mhtml 
 -Dwagon.url=scp:www.myserver.com/home/myuser/temp
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'wagon'.
 [INFO] 
 
 [INFO] Building Io
 [INFO]task-segment: [wagon:upload-single] (aggregator-style)
 [INFO] 
 
 [INFO] [wagon:upload-single {execution: default-cli}]
 Password for myu...@www.myserver.com: password



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3006) Maven does not always download artifacts from specified repos

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3006:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Maven does not always download artifacts from specified repos
 -

 Key: MNG-3006
 URL: https://jira.codehaus.org/browse/MNG-3006
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.6
 Environment: Windows XP SP2
Reporter: David Hoffer
 Attachments: settings.xml


 Performing maven2 builds does not always downloaded requested artifacts from 
 specified repos before complaining that the required artifact is not 
 available and giving up.  However if I delete my local repo then it always 
 works.
 Here is the failure log:
 [12:42:04]: Couldn't find a version in [1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 
 1.7, 1.8, 1.9, 1.10, 1.9-SNAPSHOT, 1.11-SNAPSHOT] to match range [1.11,)
 [12:42:04]: com.xrite.retail:retail-commons-classic:jar:null
 [12:42:04]:
 [12:42:04]: from the specified remote repositories:
 [12:42:04]: central (http://xrbuild3:8081/artifactory/repo),
 [12:42:04]: snapshots (http://xrbuild3:8082/artifactory/repo)
 An HTTP port monitor shows that maven refuses to contact the servers until I 
 delete my local repo.  Maven should always check the remote server before 
 giving up.
 I will attach my settings.xml.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4047) NPE in resolver if artifact defined with a version range

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4047:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 NPE in resolver if artifact defined with a version range
 

 Key: MNG-4047
 URL: https://jira.codehaus.org/browse/MNG-4047
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.9
 Environment: Mac OS X, Maven 2.0.9
Reporter: Alex Miller
 Attachments: out.txt


 I'm seeing the following NPE when calling the ArtifactResolver with an 
 Artifact defined by a VersionRange.  Here the version for this artifact is 
 defined as [1.0.0-SNAPSHOT,1.1.0-SNAPSHOT) and the 1.0.0-SNAPSHOT artifact 
 is in my local repository.  
 java.lang.NullPointerException: version was null for 
 org.terracotta:terracotta-test-api
 at 
 org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362)
 at 
 org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOf(DefaultRepositoryLayout.java:47)
 at 
 org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOf(DefaultArtifactRepository.java:110)
 at 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:125)
 at 
 org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74)
 at 
 org.terracotta.maven.plugins.tc.DsoArtifactResolverImpl.resolveArtifact(DsoArtifactResolverImpl.java:82)
 at 
 org.terracotta.maven.plugins.tc.ManifestMojo.generateRequiredBundles(ManifestMojo.java:336)
 at 
 org.terracotta.maven.plugins.tc.ManifestMojo.createManifest(ManifestMojo.java:272)
 at 
 org.terracotta.maven.plugins.tc.ManifestMojo.execute(ManifestMojo.java:205)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
 The tc-maven-plugin source can be perused here:
 http://svn.terracotta.org/svn/forge/projects/tc-maven-plugin/trunk



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4584) Setting scope of transitive dependency can break version resolution

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4584:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Setting scope of transitive dependency can break version resolution
 ---

 Key: MNG-4584
 URL: https://jira.codehaus.org/browse/MNG-4584
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.2.1
 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
 Java version: 1.5.0_19
 Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
 Default locale: en_US, platform encoding: UTF-8
 OS name: mac os x version: 10.4.11 arch: ppc Family: unix
Reporter: Craig S. Cottingham

 I have an artifact A which has a dependency with default scope on 
 javax.mail:mail:1.4.1.
 I have an artifact B which has a dependency with default scope on A, and a 
 dependency with runtime scope on log4j:log4j:1.2.15, which apparently has a 
 dependency on javax.mail:mail:1.4. The dependency on A is defined in the POM 
 before the dependency on log4j.
 When I run dependency:list or dependency:tree on B, I see that 
 javax.mail:mail:1.4 is selected.
 mvn -X compile on B shows (amidst all the other output):
 ...
 [DEBUG] javax.j2ee:j2ee:jar:1.3.1:compile (selected for compile)
 [DEBUG] javax.mail:mail:jar:1.4.1:compile (selected for compile)
 [DEBUG]   javax.activation:activation:jar:1.1:compile (selected for 
 compile)
 ...
 So far, so good.
 ...
 [DEBUG]   javax.mail:mail:jar:1.4:compile (removed - nearer 
 found: 1.4.1)
 ...
 As expected. This shows up several times in the output, for various 
 dependencies not mentioned above.
 ...
 [DEBUG]   javax.mail:mail:jar:1.4.1:provided
 ...
 This shows up several times as well.
 ...
 [DEBUG]   log4j:log4j:jar:1.2.15:runtime (selected for runtime)
 [DEBUG] javax.mail:mail:jar:1.4:runtime (setting scope to: compile)
 [DEBUG] javax.jms:jms:jar:1.1:runtime (selected for runtime)
 ...
 And here we hit the problem. It looks like the selected version for 
 javax.mail:mail is being changed to 1.4 when the scope on that runtime 
 dependency is changed to compile.
 The workaround for now is to add an explicit dependency on 
 javax.mail:mail:1.4.1 to B.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3762) Relocation not working for plugins

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3762:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Relocation not working for plugins
 --

 Key: MNG-3762
 URL: https://jira.codehaus.org/browse/MNG-3762
 Project: Maven
  Issue Type: Bug
Affects Versions: 2.0.9
 Environment: Maven version: 2.0.9
 Java version: 1.5.0_13
 OS name: mac os x version: 10.5.4 arch: i386 Family: unix
Reporter: Wendy Smoak

 As discussed on the user list, the relocation pom for the Jetty plugin does 
 not seem to work correctly.
 See:  http://www.nabble.com/Does-relocation-work-for-plugins--td19618624.html
 To reproduce, create a project from the webapp archetype, and introduce the 
 Jetty plugin:
 {noformat}
  build
...
plugins
  plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version7.0.0pre3/version
  /plugin
/plugins
 {noformat}
 Attempting to build the project results in an error:
 {noformat}
 $ mvn install
 [INFO] Scanning for projects...
 [INFO] 
 
 [INFO] Building mywebapp Maven Webapp
 [INFO]task-segment: [install]
 [INFO] 
 
 Downloading: 
 http://repo1.maven.org/maven2/org/mortbay/jetty/maven-jetty-plugin/7.0.0pre3/maven-jetty-plugin-7.0.0pre3.jar
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] A required plugin was not found: Plugin could not be found -
 check that the goal name is correct: Unable to download the artifact
 from any repository
 Try downloading the file manually from the project website.
 Then, install it using the command:
mvn install:install-file -DgroupId=org.mortbay.jetty
 -DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
 -Dpackaging=maven-plugin -Dfile=/path/to/file
 Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
 -DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url]
 -DrepositoryId=[id]
  org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
 from the specified remote repositories:
  central (http://repo1.maven.org/maven2)
  org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
 from the specified remote repositories:
  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: Mon Sep 22 19:02:01 MST 2008
 [INFO] Final Memory: 3M/7M
 [INFO] 
 
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4223) Resolve expressions in POM artifact coordinates

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4223:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Resolve expressions in POM artifact coordinates
 ---

 Key: MNG-4223
 URL: https://jira.codehaus.org/browse/MNG-4223
 Project: Maven
  Issue Type: Bug
  Components: POM
Affects Versions: 2.2.0
Reporter: John Casey

 See: 
 http://docs.codehaus.org/display/MAVEN/Artifact-Coordinate+Expression+Transformation
 See also: MNG-3057, MNG-4167
 We need to resolve artifact coordinates in the POM, including project 
 coordinate, dependencies, plugins, reports, etc. but NOT plugin configuration 
 sections. These coordinates need to be resolved prior to plugins like GPG 
 being executed, and prior to install/deploy steps, to ensure that signatures 
 and derivatives (shade plugin output, for instance), along with installed and 
 deployed copies, contain resolved values.
 We attempted this for version expressions in 2.1.0, but this had several 
 problems, including not being in place for plugin executions, and resolving 
 version expressions within plugin configurations. When we tried to remedy 
 this in 2.2.0, a bunch of more subtle issues sprang up, which are described 
 in the link at the top of this description. In short, we can't really solve 
 this adequately in 2.2.0 without performing major surgery, and even then I'm 
 not sure it'd work. We need to consider this as a design requirement for 
 Maven 3.x, where we can design it into the system instead of trying to 
 retrofit...



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3626) Improve pom to handle i18n fields

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3626:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Improve pom to handle i18n fields
 -

 Key: MNG-3626
 URL: https://jira.codehaus.org/browse/MNG-3626
 Project: Maven
  Issue Type: Improvement
  Components: POM
Reporter: Vincent Siveton

 Some fields like name or description could be internationalized. I see the 
 following:
 {noformat}
 project
 ...
   description xml:lang=enEnglish description./description
   description xml:lang=deDeutsch  description./description
   description xml:lang=frFrench description./description
 ...
 /project
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-2142) Forcing execution of the post-integration-test phase

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2142:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Forcing execution of the post-integration-test phase
 

 Key: MNG-2142
 URL: https://jira.codehaus.org/browse/MNG-2142
 Project: Maven
  Issue Type: Improvement
  Components: Integration Tests
Affects Versions: 2.0.3
Reporter: Vincent Massol

 The post-integration-test phase needs to always be called even in case of 
 tests failures in the integration-test phase. 
 For example when using Cargo the container may be left running if the 
 post-integration-test phase is not called...



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4136) Regression: Environment Variables With Parenthesis Can't Be Referenced in POM

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4136:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Regression: Environment Variables With Parenthesis Can't Be Referenced in POM
 -

 Key: MNG-4136
 URL: https://jira.codehaus.org/browse/MNG-4136
 Project: Maven
  Issue Type: Bug
Affects Versions: 2.1.0
 Environment: Windows XP Professional (64-bit)
Reporter: Joel Turkel
 Attachments: pom.xml


 It looks like Maven can longer use environment variables with parenthesis 
 e.g. ProgramFiles(x86). The attached pom.xml emits the following with Maven 
 2.1.0:
 ProgramFiles(x86) = ${env.ProgramFiles(x86)}
 With Maven 2.0.10 we correctly get the following:
 ProgramFiles(x86) = C:\Program Files (x86)
 This is a pain since ProgramFiles(x86) is standard environment variable on 
 64-bit Windows.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1991) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-1991:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Can't get transitive dependencies from a war pom when this war is added as a 
 depdency of a project
 --

 Key: MNG-1991
 URL: https://jira.codehaus.org/browse/MNG-1991
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.2
Reporter: Emmanuel Venisse

 I have a project (continuum-core-it) that need to use all transitive 
 dependencies of a war (continuum-webapp). If i add the war as a dependency of 
 the project with packaging war, war dependencies aren't shown by project, 
 maven doesn't try to resolve them and doesn't add them in classpath.
 If if replace packaging from war to pom, all dependencies are resolved and 
 added to classpath.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3290) add the ability to exclude dependencies from a plugin

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3290:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 add the ability to exclude dependencies from a plugin
 -

 Key: MNG-3290
 URL: https://jira.codehaus.org/browse/MNG-3290
 Project: Maven
  Issue Type: Improvement
  Components: Plugins and Lifecycle
Affects Versions: 2.0.7
Reporter: nicolas de loof
Priority: Minor

 As plugins declare theyre own dependencies, we sometime need to override the 
 plugin dependencies to use a != version of the supported tool.
 In some situations, due to groupId beeing relocated, this is not possible :
 example : the axistool mojo depends on org.apache.axis:axis:1.4. To generate 
 code for a previous version of axis, we cannot override this dependency as 
 older axis versions use groupId axis.
 same on the castor mojo : cannot use a newest org.codehaus.castor version as 
 the plugin depends on groupId castor.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4354) DefaultArtifactResolver has problems when used with multiple repos

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4354:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 DefaultArtifactResolver has problems when used with multiple repos
 --

 Key: MNG-4354
 URL: https://jira.codehaus.org/browse/MNG-4354
 Project: Maven
  Issue Type: Bug
  Components: Bootstrap  Build
Affects Versions: 2.2.1
 Environment: N/A
Reporter: Hasan Ceylan
Priority: Blocker
 Attachments: maven.patch


 DefaultArtifactResolver attaches the repositories to artifacts (AFAIK) to 
 optimize the repo look ups.
 Here I have a case
 1) An artifact dependens on org.eclipse.equniox:app:1.2.0
 2) org.eclipse.equinox:app depends on 
 org.eclipse.equinox:registry:[3.4.0,4.0.0)
 3) Both central repo and custom corporate repo has 
 org.eclipse.equinox:registry
 4) central repo has outdated versions
  3.2.1-R32x_v20060814
  3.3.0-v20070522
 5) DefaultArtifactResolver for optimization attaches central repo (last one 
 wins) 
 6) Central repo neither satisfies the version range nor - even if it did - 
 has the latest version
 7) dependency is not satisfied
 8) Build halts
 Attached patch is a dirty hack to disable signle repo downloand and checks 
 all the repositories.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4713) ${basedir} variable makes portable builds overly difficult

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4713:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 ${basedir} variable makes portable builds overly difficult
 --

 Key: MNG-4713
 URL: https://jira.codehaus.org/browse/MNG-4713
 Project: Maven
  Issue Type: Bug
  Components: Design, Patterns  Best Practices
Affects Versions: 2.2.1
Reporter: Gili

 Please reopen MNG-3198. I believe that Brett misunderstood what Jochen wrote. 
 There is no simple workaround with the current Maven implementation. Jochen 
 was saying that Maven should use unix-style slashes under Windows for the 
 sake of portability and let users convert to Windows-style slashes themselves 
 if they wish to use an external script.
 Simple use-case: try passing a $\{basedir\}-relative path into the 
 java.library.path property. It's impossible to do this portably under 
 Maven's existing implementation.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3603) Incomplete set of transitive dependencies resolved when transitive dependencies repository is not listed.

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3603:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Incomplete set of transitive dependencies resolved when transitive 
 dependencies repository is not listed.
 -

 Key: MNG-3603
 URL: https://jira.codehaus.org/browse/MNG-3603
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories, Dependencies
Affects Versions: 2.0.9
 Environment: windows vista jdk 1.5.0_11
Reporter: Micah Whitacre
 Attachments: maven_testcase.zip


 I have project D which is dependent on project C.  Project D lists the 
 repository that the latest snapshot or release project C resides in.  Project 
 C depends on project B which depends on project A.  Both projects B and A 
 reside in a different repository than Project C and D.  Project C properly 
 lists the repository A and B reside in.  All dependency scopes are compile so 
 therefore transitively project D has a compile time dependency on A.  The 
 issue arises in that when building project D with a clean local maven 
 repository project A is never resolved, no error is given but errors will 
 occur later when actually trying to run tests.
 I have attached a testcase of this situation with projects A,B,C,and D.  To 
 duplicate this issue:
 1. Unzip the attachment to a folder on your machine.
 2. At the root of that folder run mvn deploy.  This will deploy projects A 
 and B to fake-remote-repo2 and project C to fake-remote-repo1.  One note is 
 the URL of the repositories is windows based to this will need to be adjusted 
 in the POMs and in the projectD pom if you are *nix based.
 3. Clear your local maven repository.
 4. Navigate to the projectD folder and run mvn compile.
 After step 4 completes browse your local maven repo and you will notice that 
 project A is not present.  
 In the actual situation I'm encountering this it not only fails to resolve 
 dependencies but also parent poms.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-2973) Cannot specify a version range for build extensions

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2973:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Cannot specify a version range for build extensions
 ---

 Key: MNG-2973
 URL: https://jira.codehaus.org/browse/MNG-2973
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories, Plugins and Lifecycle
Affects Versions: 2.0.5
Reporter: Tim Meighen
 Attachments: pom.xml


 When specifying a version range in a build extension, I get the following:
 + Error stacktraces are turned on.
 Maven version: 2.0.6
 [DEBUG] Building Maven user-level plugin registry from: 
 '/Users/tmeighen/.m2/plugin-registry.xml'
 [DEBUG] Building Maven global-level plugin registry from: 
 '/Users/tmeighen/maven/conf/plugin-registry.xml'
 [INFO] Scanning for projects...
 [DEBUG] Initialising extension: junit:junit
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] An invalid artifact was detected.
 This artifact might be in your project's POM, or it might have been included 
 transitively during the resolution process. Here is the information we do 
 have for this artifact:
 o GroupID: junit
 o ArtifactID:  junit
 o Version:  MISSING 
 o Type:pom
 [INFO] 
 
 [DEBUG] Trace
 org.apache.maven.artifact.InvalidArtifactRTException: For artifact 
 {junit:junit:null:pom}: The version cannot be empty.
 at 
 org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147)
 at 
 org.apache.maven.artifact.DefaultArtifact.init(DefaultArtifact.java:122)
 at 
 org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:158)
 at 
 org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:117)
 at 
 org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:111)
 at 
 org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:40)
 at 
 org.apache.maven.artifact.factory.DefaultArtifactFactory.createProjectArtifact(DefaultArtifactFactory.java:95)
 at 
 org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:94)
 at 
 org.apache.maven.extension.DefaultExtensionManager.addExtension(DefaultExtensionManager.java:98)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions(DefaultLifecycleExecutor.java:158)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
 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)
 [INFO] 
 
 [INFO] Total time:  1 second
 [INFO] Finished at: Tue May 01 17:53:00 PDT 2007
 [INFO] Final Memory: 2M/1016M
 [INFO] 
 
 Note that this works with Maven 2.0.5.  Also the same version range works 
 with 2.0.6 when specified in the dependencies section (i.e. not a build 
 extension).



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-2889) Generic readModel method missing in embedder

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2889:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Generic readModel method missing in embedder
 

 Key: MNG-2889
 URL: https://jira.codehaus.org/browse/MNG-2889
 Project: Maven
  Issue Type: Improvement
  Components: Embedding
Affects Versions: 2.0.4
Reporter: Piotr Smolinski
Assignee: Jason van Zyl

 Currently there is only one method to read model in MavenEmbedder. It 
 supports only reading from file.
 There is need to provide readModel method using Reader as data source. I can 
 find related methods for writing.
 Please consider opening pom.xml from archive in eclipse. There is only input 
 stream to use.
 Thanks a lot,
 Piotr Smolinski



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4376) allow wildcards and versions in In/ExcludesArtifactFilter

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4376:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 allow wildcards and versions in In/ExcludesArtifactFilter
 -

 Key: MNG-4376
 URL: https://jira.codehaus.org/browse/MNG-4376
 Project: Maven
  Issue Type: Improvement
Reporter: Brett Porter





--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3561) Improved error message when maven 2.1 is run with jdk 14

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3561:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Improved error message when maven 2.1 is run with jdk 14
 

 Key: MNG-3561
 URL: https://jira.codehaus.org/browse/MNG-3561
 Project: Maven
  Issue Type: Improvement
Affects Versions: 3.0-alpha-1
 Environment: Maven 2.1-alpha-1-SNAPSHOT
Reporter: Paul Gier
Priority: Minor

 Currently if I try to run maven 2.1-alpha-1-SNAPSHOT with java 1.4 I get the 
 standard jvm errors about wrong class type.  It would be nice to have some 
 better error message saying that java 1.5 or higher is required.  This could 
 probably go into the startup script.
 Exception in thread main java.lang.UnsupportedClassVersionError: 
 org/codehaus/plexus/logging/AbstractLogEnabled (Unsupported major.minor 
 version 49.0)
 at java.lang.ClassLoader.defineClass0(Native Method)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
 at 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
 at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:187)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3457) Add Method to AbstractMojo for Obtaining Toolchain

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3457:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Add Method to AbstractMojo for Obtaining Toolchain 
 ---

 Key: MNG-3457
 URL: https://jira.codehaus.org/browse/MNG-3457
 Project: Maven
  Issue Type: Improvement
Affects Versions: 3.0-alpha-1
Reporter: Shane Isbell
Priority: Minor

 I would like to see a method, say: AbstractMojo.getToolchainFor(String 
 toolchainType). 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3132) New SNAPSHOT versions on (self managed) remote repository are downloaded but not used

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3132:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 New SNAPSHOT versions on (self managed) remote repository are downloaded but 
 not used
 -

 Key: MNG-3132
 URL: https://jira.codehaus.org/browse/MNG-3132
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.7
Reporter: Bryan Brouckaert
 Attachments: BugReport.zip


 I upload a new SNAPSHOT version to my self managed remote repository with the 
 deploy:deploy-file goal.  The next maven run will download the new file 
 into the local repository, but the old version will still be used.
 I included a test case (see attachment).
 First, specify your self managed remote repository in the pom.xml and 
 run.bat files.  Then execute the run.bat file, it should fail the second 
 time the test runs, but it doesn't because the old version is still used.
 I did not check the code, but I did check the local repository.  All files 
 seems to be normal (including 2 versions of the jar), except that the 
 SNAPSHOT version is still a copy of the first version while the meta files 
 contain information about the second version.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3089) DefaultArtifactCollector does not filter ResolutionListener events

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3089:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 DefaultArtifactCollector does not filter ResolutionListener events
 --

 Key: MNG-3089
 URL: https://jira.codehaus.org/browse/MNG-3089
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.7
Reporter: Mark Hobson
 Attachments: MNG-3089.patch


 The ArtifactFilter passed to the ArtifactCollector.collect methods is only 
 used to filter the ArtifactResolutionResult.artifacts and not the 
 ResolutionListener events.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3090) Nearest dependency, which is not included by a filter, wins, although a farthest dependency, which is included by the same filter, does not win.

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3090:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Nearest dependency, which is not included by a filter, wins, although a 
 farthest dependency, which is included by the same filter, does not win.
 

 Key: MNG-3090
 URL: https://jira.codehaus.org/browse/MNG-3090
 Project: Maven
  Issue Type: Improvement
  Components: Artifacts and Repositories
Affects Versions: 2.0.7
Reporter: Christian Schulte
Assignee: Jason van Zyl
 Attachments: maven-artifact-2.0.x.patch, MNG-3090.patch, 
 testcase.tar.bz2


 There seems to be a problem with transitive dependencies and the nearest wins 
 strategy. The nearest dependency wins, although a filter is in use which will 
 not include that dependency when there is the same dependency at a deeper 
 level, where it is included by the same filter. The nearest dependency gets 
 discarded (e.g. is missing on the compile classpath) although the farthest 
 dependency would have been included. Please see the comments in the attached 
 patch.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4431) Separate mirror settings for repositories vs. pluginRepositories

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4431:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Separate mirror settings for repositories vs. pluginRepositories
 

 Key: MNG-4431
 URL: https://jira.codehaus.org/browse/MNG-4431
 Project: Maven
  Issue Type: New Feature
  Components: Dependencies, Settings
Reporter: Paul Gier

 I want to have a way to track what artifacts are downloaded because of 
 project dependencies vs. what is downloaded because of plugins and their 
 dependencies.  One way to do this would be to have a separate mirror setting 
 for pluginRepositories.  That way all plugin dependencies would be downloaded 
 from one URL and project dependencies would be downloaded from a different 
 URL.
 The dependencies plugin is currently not sufficient to accomplish this 
 because the go-offline goal does not download all plugin dependencies 
 [MDEP-82|http://jira.codehaus.org/browse/MDEP-82].



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4556) Relocation can't be used on Root Pom.

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4556:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Relocation can't be used on Root Pom.
 -

 Key: MNG-4556
 URL: https://jira.codehaus.org/browse/MNG-4556
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.9
 Environment: Windows, Eclipse, Dos.
Reporter: Pierre Devreux
Priority: Minor

 We slit our project in several modules.
 All modules have a parent.
 In this parent, we define among other things, groupID, and we don't define 
 GroupID in module (they inherit of him).
 Now we wan't to relocate our groupID.
 But if we define relocation in parent, it is not taken into account in module.
 We have to define relocation in each module.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4132) import dependencies should honor nearest definition resolution

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4132:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 import dependencies should honor nearest definition resolution
 

 Key: MNG-4132
 URL: https://jira.codehaus.org/browse/MNG-4132
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.10, 2.1.0
Reporter: Mike Youngstrom
 Attachments: import.zip


 Maven defines a nearest definition approach to dependency resolution.  
 However, the newly introduced import dependencies don't.  They take a top 
 down first defined approach.
 For example:
 bom1:
  defines log4j:1.2.9
 bom2:
  defines log4j:1.2.12
 bom3
  imports bom1
 jar
  imports bom3
  imports bom2
 mvn dependency:tree in jar will resolve log4j:1.2.9 simply because it is 
 first in the dependencyManagement section of the jar.  I would expect it to 
 resolve log4j:1.2.12 since it is the nearest definition in this scenario.
 This is somewhat confusing because this example works differently:
 bom1
  defines log4j:1.2.9
 jar
  imports bom1
  defines log4j:1.2.12
 mvn dependency:tree in jar will resolve log4j:1.2.12.  In this case 
 nearest definition is honored.
 I've attached a test case illustrating the problem.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3582) Support 'parameter' mechanism for mojo aggregated objects

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3582:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Support 'parameter' mechanism for mojo aggregated objects
 -

 Key: MNG-3582
 URL: https://jira.codehaus.org/browse/MNG-3582
 Project: Maven
  Issue Type: Improvement
  Components: Plugins and Lifecycle
Affects Versions: 2.0.8
Reporter: Ittay Dror

 if class AMojo has a field AObject, then this field can have xdoclet tags to 
 define how to instantiate it (expression, default-value). however, inside the 
 object, we cannot use this mechanism. so if in AObject, I want a field whose 
 default value will be ${project.build.finalName}, i have to do get it 
 manually



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1945) project.getBuild().setSourceDirectory() should modify the compile source roots automatically

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-1945:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 project.getBuild().setSourceDirectory() should modify the compile source 
 roots automatically
 

 Key: MNG-1945
 URL: https://jira.codehaus.org/browse/MNG-1945
 Project: Maven
  Issue Type: Improvement
  Components: POM
Affects Versions: 2.0.1
Reporter: Vincent Massol
Assignee: Jason van Zyl

 Here's the code that I have in the clover plugin right now:
 private void redirectSourceDirectories()
 {
 String oldSourceDirectory = 
 this.project.getBuild().getSourceDirectory();
 this.project.getBuild().setSourceDirectory( 
 this.cloverOutputSourceDirectory );
 
 // Maven2 limitation: changing the source directory doesn't change 
 the compile source roots
 Iterator sourceRoots = 
 this.project.getCompileSourceRoots().iterator();
 for (int i = 0; sourceRoots.hasNext(); i++)
 {
 String sourceRoot = (String) 
 this.project.getCompileSourceRoots().get( i );
 if (sourceRoot.equals(oldSourceDirectory))
 {
 this.project.getCompileSourceRoots().remove( i );
 // Note: Ideally we should add the new compile source root at 
 the same place as the
 // one we're removing but there's no API for this...
 this.project.addCompileSourceRoot( 
 this.project.getBuild().getSourceDirectory() );
 }
 }
 }
 I believe this could be put in Maven core.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4487) POM allows duplicate plugin configuration

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4487:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 POM allows duplicate plugin configuration
 -

 Key: MNG-4487
 URL: https://jira.codehaus.org/browse/MNG-4487
 Project: Maven
  Issue Type: Improvement
Affects Versions: 2.0.9
Reporter: Ken Wong
Priority: Minor
 Attachments: MNG-4487.zip, pom.xml


 I have a project that uses FlexMOJO to compile the swc and then optimize and 
 create a swf. If you look at the following pom extract, you will see that I 
 defined the configuration for the same plugin twice (flexmojos-maven-plugin). 
 There was no error but having the duplicate definition caused maven to be 
 confused and the locale and namespace parameters ended up being 'lost'. If I 
 comment out the 2nd part, then it works. If having duplicate definition 
 confuses maven, it would be nice to have it throw an error when it sees 
 duplicate configuration for the same plugin, instead of yielding confusing 
 result.
 build
 plugins
 plugin
 groupIdorg.sonatype.flexmojos/groupId
 
 artifactIdflexmojos-maven-plugin/artifactId
 configuration
 compiledLocales
 localeen_US/locale
 localees_ES/locale
 localeja_JP/locale
 /compiledLocales
 resourceBundlePath
 namespaces
 namespace
 
 urihttp://www.stoneriver.com/2009/uicore/uri
 
 manifest${basedir}/src/manifest.xml/manifest
 /namespace
 /namespaces
 includeNamespaces
 
 namespacehttp://www.stoneriver.com/2009/uicore/namespace
 /includeNamespaces
 /configuration
 /plugin
  plugin
  groupIdorg.sonatype.flexmojos/groupId
  
 artifactIdflexmojos-maven-plugin/artifactId
  executions
  execution
  goals
  goaloptimize/goal
  /goals
  /execution
  /executions
  /plugin
  
 /plugins 
 /build



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4656) Declarative plugins similar to jsp tags or jsf composites

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4656:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Declarative plugins similar to jsp tags or jsf composites
 -

 Key: MNG-4656
 URL: https://jira.codehaus.org/browse/MNG-4656
 Project: Maven
  Issue Type: New Feature
  Components: Design, Patterns  Best Practices
Reporter: Mykola Golubyev

 By now there is only one option to create maven plugin. And this is by using 
 JVM based language.
 There are situations when all you need is just to combine some already 
 written plugins, pass to them some attributes and you can use this as a 
 plugin. But you can't. You need to copy and paste bunch of plugins. And move 
 some predefined configuration to pluginManagment.
 I suggest to add mechanic which is similar to JSP tags or JSF composites.
 Let's say
 pluginDefinition
groupIdmy.com/groupId
artifactIddeploy/artifactId
attribute name=path/
attribute name=list type=.../
body
   plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdexec-maven-plugin/artifactId
  executions
  execution
 ... ${path} ...
 ... ${list} ...
  /execution
  ...
  /executions
   /plugin
   plugin
...
   /plugin
/body
 /pluginDefinition
 and then in some other pom.xml
 plugin
groupIdmy.com/groupId
artifactIddeploy/artifactId
configuration
   pathtest.war/path
   list
   item1/item
   item2/item
   /list
/configuration
 /plugin
 or something like this.
 Thanks for the attention.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1609) Force update of files in the repo if checksum has been updated

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-1609:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Force update of files in the repo if checksum has been updated
 --

 Key: MNG-1609
 URL: https://jira.codehaus.org/browse/MNG-1609
 Project: Maven
  Issue Type: Improvement
  Components: Plugins and Lifecycle
Affects Versions: 2.0
Reporter: Jörg Schaible

 Maven should support an option -ccu, --check-checksum-update that looks in 
 the remote repositories for updated checksums and redownloads the 
 corresponding file (artifact, pom, ...). Especially pom updates are currently 
 really cumbersome, since every user has to clean them in his local repo.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-2040) [toolchain] Allow to specify javadoc url in pom.xml

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2040:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 [toolchain] Allow to specify javadoc url in pom.xml
 ---

 Key: MNG-2040
 URL: https://jira.codehaus.org/browse/MNG-2040
 Project: Maven
  Issue Type: New Feature
  Components: POM
Reporter: Eugene Kuleshov

 Allow to specify javadoc url in pom.xml. 
 It is even more critical for projects not managed by Maven, so they won't 
 package javadoc for repository deployment, but may choose to publish javadoc 
 on project web site.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-671) implement a license clickthrough

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-671:
--

Fix Version/s: (was: Issues to be reviewed for 3.x)

 implement a license clickthrough
 

 Key: MNG-671
 URL: https://jira.codehaus.org/browse/MNG-671
 Project: Maven
  Issue Type: New Feature
  Components: Dependencies
Reporter: Brett Porter
 Attachments: maven-artifact-manager-patch-2.txt, 
 maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, 
 maven-license-patches-3.zip, maven-settings-patch-2.txt, 
 maven-settings-patch.txt


 we need some basic license acceptance policy for downloadable artifacts. For 
 now, this can just be a Y/N that is saved forever.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3300) Nested compile source roots in effective POM cause bad Eclipse build path

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3300:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Nested compile source roots in effective POM cause bad Eclipse build path
 -

 Key: MNG-3300
 URL: https://jira.codehaus.org/browse/MNG-3300
 Project: Maven
  Issue Type: Bug
Affects Versions: 2.0.7
 Environment: Maven 2.0.7, JDK 1.5.0_12, WinXP
Reporter: Benjamin Bentmann
 Attachments: nested-source-roots.patch, nested-sources.zip


 Source generating plugins like for JavaCC or JFlex usually add their output 
 folder to the POM as a compile source root. If these source directories 
 happen to be nested, i.e. src/main/java and additional something like 
 src/main/java/org/apache, mvn eclipse:eclipse produces the following bad 
 .classpath contents with overlapping build paths:{code:xml}
 classpath
   classpathentry kind=src path=src/main/java/
   classpathentry kind=src path=src/main/java/org/apache/
   ...
 /classpath
 {code}
 While this issues relates to MECLIPSE-114, I really think my problem is 
 caused by Maven.
 Though the maven-eclipse-plugin causes the problem to manifest itself, it 
 might not be the proper place to solve it as it appears to be a more general 
 issue (i.e. the Maven Eclipse Integration might also be affected, though I 
 did not test this). Surely, each and every plugin developer could be told to 
 check for source directory nesting but I consider this an error-prone 
 approach. I would rather appreciate either that 
 MavenProject.addCompileSourceRoot() automatically ignores nested source 
 directories (if such a general change is acceptable) or that new methods in 
 MavenProject are introduced that allow for conditional addition of source 
 roots only if they do not nest with existing roots such that plugin 
 developers can easily fix the problem.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4366) profile activation based on presence of a dependency

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4366:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 profile activation based on presence of a dependency
 

 Key: MNG-4366
 URL: https://jira.codehaus.org/browse/MNG-4366
 Project: Maven
  Issue Type: Wish
  Components: Profiles
Reporter: jieryn

 It would be handy to have profile activation based on a dependency being 
 present. For example, I would like to be able to have a profile in my 
 corporate super-pom which gets activated when any of the projects at my 
 corporation (which use a parent of the super-pom) include log4j as a 
 dependency. The profile would automatically add a dependency on our custom 
 Log4j appenders.
 There are other uses as well, like  if log4j is detected to be in the 
 dependency list, then unpack a maven-remote-resources-plugin bundle with a 
 log4j.xml.vm which gets velocity-processed for a default corporate-wide 
 configuration. This would best be chained with negative-file exist profile 
 activation for an existing log4j.xml.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-2011) Add new integration-test scope for dependencies

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2011:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Add new integration-test scope for dependencies
 ---

 Key: MNG-2011
 URL: https://jira.codehaus.org/browse/MNG-2011
 Project: Maven
  Issue Type: Task
  Components: Integration Tests, Plugins and Lifecycle
Reporter: Vincent Massol

 This is required not to mix unit tests deps with it tests deps. See also 
 http://www.nabble.com/-PROPOSAL-Integration-testing-proposal-for-Maven-2.0.x-t980095.html



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3340) Allow profile activation based on availability of executable in PATH environment variable

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3340:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Allow profile activation based on availability of executable in PATH 
 environment variable
 -

 Key: MNG-3340
 URL: https://jira.codehaus.org/browse/MNG-3340
 Project: Maven
  Issue Type: New Feature
  Components: Profiles
Affects Versions: 2.0.8
Reporter: Erik Drolshammer

 17:29  Sherriff Anyone know how to activate a profile if a certain file is 
 in _path_? 
 17:29  Sherriff (i.e., not hardcode a specific path) 
 17:30  wsmoak where do you want to specify the path?  with a property?
 17:31  trygvis I just looked for that myself, but couldn't find any way
 17:31  Sherriff I don't want to specify a path. The file (a script) is 
 present in $PATH
 It would be really nice if it were possible to activate a profile if a given 
 file was found in PATH. 
 Typical use case: Only run a certain group of tests in a certain 
 script/application is available. 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4612) Password escaping doesn't work

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4612:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Password escaping doesn't work
 --

 Key: MNG-4612
 URL: https://jira.codehaus.org/browse/MNG-4612
 Project: Maven
  Issue Type: Bug
  Components: Settings
Affects Versions: 2.2.1, 3.0-alpha-7
Reporter: Benjamin Bentmann
Priority: Minor

 In MNG-4611 some user presented a *cleartext* password of the form
 {noformat}
 {DESede}y+qq...==
 {noformat}
 Given the presence of braces, this password needs to be escaped to be used as 
 a cleartext password. However, the escaping syntax documented in [Maven 
 Password 
 Encryption|http://maven.apache.org/guides/mini/guide-encryption.html#Tips] is 
 broken. Trying the documented way of putting in backslashes and embedding the 
 entire string again in braces like
 {noformat}
 {\{DESede\}y+qq...==}
 {noformat}
 yields
 {noformat}
 [WARNING] Not decrypting password for server 'maven-core-it' due to exception 
 in security handler.
 Cause: null
 [DEBUG] Full trace follows
 org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException:
 org.sonatype.plexus.components.cipher.PlexusCipherException:
 java.lang.ArrayIndexOutOfBoundsException
 at 
 org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher.decrypt(DefaultSecDispatcher.java:121)
 at 
 org.apache.maven.DefaultMaven.resolveParameters(DefaultMaven.java:738)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:250)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
 at 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
 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:592)
 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.sonatype.plexus.components.cipher.PlexusCipherException: 
 java.lang.ArrayIndexOutOfBoundsException
 at 
 org.sonatype.plexus.components.cipher.PBECipher.decrypt64(PBECipher.java:193)
 at 
 org.sonatype.plexus.components.cipher.DefaultPlexusCipher.decrypt(DefaultPlexusCipher.java:72)
 at 
 org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher.decrypt(DefaultSecDispatcher.java:96)
 ... 13 more
 Caused by: java.lang.ArrayIndexOutOfBoundsException
 at java.lang.System.arraycopy(Native Method)
 at 
 org.sonatype.plexus.components.cipher.PBECipher.decrypt64(PBECipher.java:175)
 ... 15 more
 {noformat}
 Trying without the surrounding braces as suggested by the source code
 {noformat}
 \{DESede\}y+qq...==
 {noformat}
 successfully prevents decryption, but the string isn't unescaped either, 
 making Maven use a wrong password.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-2412) global variable filtering of pom.xml for parent and sub module pom.xml files is not working when deploying to a repository.

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2412:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 global variable filtering of pom.xml for parent and sub module pom.xml files 
 is not working when deploying to a repository.
 ---

 Key: MNG-2412
 URL: https://jira.codehaus.org/browse/MNG-2412
 Project: Maven
  Issue Type: Bug
  Components: Deployment, Inheritance and Interpolation
Affects Versions: 2.0.4
 Environment: Windows XP., JDK 1.5
Reporter: Bill Brown

 Greetings:  
 I have a maven2 project with two sub modules.  I run into an issue when I 
 build and deploy a SNAPSHOT of this project and try to reference one of the 
 modules as a dependency when I build another project.  
 here is the project structure. 
 project
 module1
 pom.xml
 module2
 pom.xml
 pom.xml
 The parent pom declares a global property in the properties section:
 properties
 applicationVersion1.1.2-SNAPSHOT/applicationVersion
   /properties
 The parent pom declares the project version in the following way:
 version${applicationVersion}/version
 The module poms refrence the parent pom with the parent tags:
 parent
 groupIdcom.gocsc/groupId
 artifactIdsam/artifactId
 version${applicationVersion}/version
   /parent
 The module poms both declare the project version in the same way:
 version${applicationVersion}/version
 The project deploys the artifacts to the corporate repository without error 
 but the generated poms for each sub module and also the parent module do not 
 resolve the  ${applicationVersion} in all of the locations:  
 The parent pom project version remains the same in the deployed pom.
 version${applicationVersion}/version
 The parent tags in the sub module poms remain the same:
 parent
 groupIdcom.gocsc/groupId
 artifactIdsam/artifactId
 version${applicationVersion}/version
   /parent
 The only section that gets resolved / filtered is the project version tags of 
 the sub modules.
 version1.1.2-20060628.195852-10/version
 This seems to be what is causing the problem when I use one of the sub 
 modules as dependency in another project and try to build it.  Here is the 
 output: 
 *
 [INFO] snapshot com.gocsc:sam-common:1.1.2-SNAPSHOT: checking for updates 
 from com.gocsc
 Downloading: 
 file:///\\gatling\maven2\repository/com/gocsc/sam/${applicationVersion}/sam-${applicationVersion}.pom
 [WARNING] Unable to get resource from repository com.gocsc 
 (file:///\\gatling\maven2\repository)
 Downloading: 
 http://repo1.maven.org/maven2/com/gocsc/sam/${applicationVersion}/sam-${applicationVersion}.pom
 [WARNING] Unable to get resource from repository central 
 (http://repo1.maven.org/maven2)
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Failed to resolve artifact.
 GroupId: com.gocsc
 ArtifactId: sam
 Version: ${applicationVersion}
 Reason: Unable to download the artifact from any repository
   com.gocsc:sam:pom:${applicationVersion}
 from the specified remote repositories:
   central (http://repo1.maven.org/maven2),
   com.gocsc (file:///\\gatling\maven2\repository)
 ***
 Even if I manually modify the repository pom files to use the timstamp 
 version of: 
 version1.1.2-20060628.195852-10/version
 I still get the same error above.  
 Is this the expected behavior of the system?  Is this a bug? 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4161) possibility to omit version in dependency of same project (and fill in on install/deploy)

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4161:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 possibility to omit version in dependency of same project (and fill in on 
 install/deploy)
 -

 Key: MNG-4161
 URL: https://jira.codehaus.org/browse/MNG-4161
 Project: Maven
  Issue Type: New Feature
  Components: Dependencies, Deployment
Reporter: Jörg Hohwiller

 I want to suggest a feature discussed on dev-list:
 A dependency currently must have groupId, artifactId and version.
 If you have a complex multi-module project you typically have lots of project 
 internal dependencies.
 Typically these dependencies point to the same version that is currently 
 active (on disc/head).
 So for the main usecase you have the version of a module redundant (a lot!)
 causing lots of maintenance overhead, that might be covered by release-plugin
 but might be not (in my case and there are others as well).
 Following the principle Conventions over Configuration, a coming version of 
 maven should allow
 to omit the version of a dependency if a pom.xml is loaded for a build (NOT 
 from repository)
 AND the reactor contains a module that has the same groupId and artifactId. 
 In that
 case maven will behave as if the version was declared in the pom.xml with the 
 version-value of
 the module in the reactor. In any other case maven will fail.
 The feature can be combined with MNG-2576 so that it also makes sense if just 
 a single
 module or a sub-tree of the project is to be build.
 Additionally the ArtifactInstaller and ArtifactDeployer have to guarantee, 
 that when the pom.xml
 is installed or deployed, that the omitted version(s) are automatically 
 filled in.
 This feature will therefore be 100% compatible with older versions of maven 
 and will never
 be visible in the repository. If a pom is loaded from any repository 
 (including local repo)
 maven should NOT accept it in order to avoid accidental usage or even miss 
 usage of this feature.
 Besides it is just an option that would NOT hurt anybody not interested in 
 the feature.
 But for those that get crazy maintaining large projects and for some reason 
 do NOT follow
 the philosophy of release-plugin, this feature would bring final freedom!



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4699) Properties appending, changing, self-reference, scope and other

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4699:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Properties appending, changing, self-reference, scope and other
 ---

 Key: MNG-4699
 URL: https://jira.codehaus.org/browse/MNG-4699
 Project: Maven
  Issue Type: Improvement
Affects Versions: 2.2.1
 Environment: Any
Reporter: Ivan Bondarenko

 1. Currently property mechanism is not very strong in Maven. So I think 
 property management should be complemented with such things:
 1) overridden-by option - is a comma-separated list of values ('parent', 
 'children', 'profiles', 'env', 'cli', maybe some other) which specifies which 
 properties with the same name can override this one. For example value 
 env,cli,profiles means property can be overridden by environment variables, 
 command line params and by profiles.
 2) scope option (related to overridden-by) - scope of variable. Values at 
 least: 'local' (visible only in current context, e.g. not visible in profiles 
 if declared in project), 'global' (visible everywhere), some other scopes).
 3) read-only (true/false) - 'true' means that variable can be changed 
 somewhere, possibly !!!self-referenced!!!
 So pom will look like:
 properties
   property
 name_name_/name
 value_value_/value
 overridden-byenv,cli,profiles/overridden-by
 scopeglobal/scope!-- default--
 read-only/read-only!-- default--
   /property
 /properties
 2. Of course old style of properties can be left (left also), because 
 additional options are not extremely important in practice. But what is 
 really important here - is ability to append/self-reference properties.
 For example in our current project we have different feature sets, 
 unnecessary of which are excluded with the help of profiles, like this:
 project !-- simplified syntax --
   properties
 ex1/ex1
 ex2/ex2
 ...
 exN/exN
   properties
   profile id=p1
 properties
   ex1,path1/ex1
 properties
   /profile
   profile id=p2
 properties
   ex2,path2/ex2
 properties
   /profile
   ...
   build
 war-plugin
   packagingExcludes${ex1}${ex2}...${exN}/packagingExcludes
 /war-plugin
   /build
 /project
 It would be much better if only one property is necessary (ex), so in each 
 profile we can write ex${ex},pathI/ex, so war-plugin configuration will 
 not be aware of profiles count.
 If this problem can be solved in some other way (but without antrun-plugin), 
 I would be grateful if somebody tell me the solution.
 I apologize if this is duplication or can be solved in another way.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-2021) Allow properties to be dom objects

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2021:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Allow properties to be dom objects
 --

 Key: MNG-2021
 URL: https://jira.codehaus.org/browse/MNG-2021
 Project: Maven
  Issue Type: Improvement
  Components: POM
Affects Versions: 2.0, 2.0.1, 2.0.2
Reporter: Carlos Sanchez
Priority: Minor

 Allow properties like 
 property
   includes
 includewhatever1/*.java/include
 includewhatever2/*.java/include
   /include
 /property
 to avoid repeating stuff in the different plugins
 Not very important if we have a way to share mojo configuration



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3163) Profile activation based on hostname or IP

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3163:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Profile activation based on hostname or IP
 --

 Key: MNG-3163
 URL: https://jira.codehaus.org/browse/MNG-3163
 Project: Maven
  Issue Type: Improvement
  Components: Profiles
Reporter: David J. M. Karlsen
Priority: Minor
 Attachments: exampleproject.zip


 It would be very nice to be able to activate profiles based on hostname[s] or 
 IP-address[es].
 Yes, this could be exported from the system as a systemproperty quite easily 
 on *NIX with -Dhostname=`hostname` but is a little more tricky on other 
 platforms - so why not include it in maven itself?
 It would be even better if it can be expressed with regex'es or the likes.
 WDYT?



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3322) Skip phase

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3322:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Skip phase
 --

 Key: MNG-3322
 URL: https://jira.codehaus.org/browse/MNG-3322
 Project: Maven
  Issue Type: New Feature
  Components: Command Line
Affects Versions: 2.0.8
Reporter: Paul Gier

 It would be helpful to be able to skip certain phases of execution.  Similar 
 to the way that the tests can be skipped with maven.test.skip.
 I would like this to be generalized to skip any phase, so you could have 
 something like:
 mvn -Dskip.phase=test-compile,process-test-classes,test
 All plugins in each of the phases in the comma separated list would be 
 skipped during the build process.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-1505) Create an abstract source generation mojo

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-1505:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Create an abstract source generation mojo
 -

 Key: MNG-1505
 URL: https://jira.codehaus.org/browse/MNG-1505
 Project: Maven
  Issue Type: New Feature
  Components: Plugin API
Reporter: Jason van Zyl

 There are many source generation mojos and a common base can't hurt.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4076) Maven tries to download the correct artifact version, but from the false repository

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4076:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Maven tries to download the correct artifact version, but from the false 
 repository
 ---

 Key: MNG-4076
 URL: https://jira.codehaus.org/browse/MNG-4076
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.10
Reporter: Clovis Seragiotto

 My project depends on the artifact org.eclipse.core.runtime 3.4.0, which 
 depends on org.eclipse.osgi [3.2.0,4.0.0).  Our company's repository has both 
 org.eclipse.core.runtime 3.4.0 and org.eclipse.osgi.3.4.2, while the Maven 
 central repository has older versions of both artifacts. When compiling our 
 project, maven tries to download org.eclipse.osgi.3.4.2 from the central 
 repository but not from the company's repository:
 ...
 [INFO] Using default encoding to copy filtered resources.
 Downloading: 
 http://repo1.maven.org/maven2/org/eclipse/osgi/3.4.2/osgi-3.4.2.jar
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Failed to resolve artifact.
 Missing:
 --
 1) org.eclipse:osgi:jar:3.4.2
 ...
   Path to dependency:
 1) main:main:jar:0
 2) org.eclipse.core:runtime:jar:3.4.0
 3) org.eclipse:osgi:jar:3.4.2
 ...
 from the specified remote repositories:
   OurRepository (file:///O|/maven-repository)
   central (http://repo1.maven.org/maven2) 
 This is how the project's pom looks like:
 ?xml version=1.0 encoding=UTF-8?
 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
 groupIdmain/groupId
 artifactIdmain/artifactId
 version0/version
 dependencies
 dependency
 groupIdorg.eclipse.core/groupId
 artifactIdruntime/artifactId
 version3.4.0/version
 /dependency
 /dependencies
 
 repositories
  repository
   idOurRepository/id
   nameour repository/name
   urlfile:///O|/maven-repository/url
   releases
 enabledtrue/enabled
 updatePolicydaily/updatePolicy
 checksumPolicyfail/checksumPolicy
   /releases
   snapshots
 enabledfalse/enabled
   /snapshots
/repository
 /repositories
 /project
 If I add the central repository to the pom BEFORE our repository, then 
 org.eclipse.osgi is found in our repository. If, however, I add the central 
 repository to the pom AFTER our repository, org.eclipse.osgi is again not 
 found.
 Simplified version for the poms of org.eclipse.* (so that one can deploy fake 
 versions of org.eclipse.osgi and org.eclipse.core.runtime):
 ?xml version=1.0 encoding=UTF-8?
 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
 groupIdorg.eclipse/groupId
 artifactIdosgi/artifactId
 version3.4.2/version
 
 distributionManagement
 repository
 idOurRepository/id
 nameour repository/name
 urlfile:///O|/maven-repository/url
 /repository
 /distributionManagement
 /project
 ?xml version=1.0 encoding=UTF-8?
 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
 groupIdorg.eclipse.core/groupId
 artifactIdruntime/artifactId
 version3.4.0/version
 
 dependencies
 dependency
 groupIdorg.eclipse/groupId
 artifactIdosgi/artifactId
 version[3.2.0,4.0.0)/version
 /dependency
 /dependencies
 
 distributionManagement
 repository
 idOurRepository/id
 nameour repository/name
 urlfile:///O:|/maven-repository/url
 /repository
 /distributionManagement
 /project



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4374) Clarify value of basedir property for ArtifactRepository

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4374:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Clarify value of basedir property for ArtifactRepository
 

 Key: MNG-4374
 URL: https://jira.codehaus.org/browse/MNG-4374
 Project: Maven
  Issue Type: Task
Reporter: Benjamin Bentmann

 There seems to be some confusion what exactly the return value from 
 {{ArtifactRepository.getBasedir()}} delivers:
 # always some part of a URL (i.e. a string that is subject to URL-encoding) or
 # something depending on the URL protocol (e.g. a normal file system path in 
 case of {{file://}})
 The javadoc should be be extended to clearly express what contents callers of 
 the method have to expect such that they can handle it properly.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-462) if a proxy is not reachable, don't use it instead of failing

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-462:
--

Fix Version/s: (was: Issues to be reviewed for 3.x)

 if a proxy is not reachable, don't use it instead of failing
 

 Key: MNG-462
 URL: https://jira.codehaus.org/browse/MNG-462
 Project: Maven
  Issue Type: Improvement
  Components: Artifacts and Repositories
Reporter: Brett Porter
Priority: Minor

 while profiles are available for working in different environments, this 
 would be convenient to allow multiple proxies to be configured, and search 
 for one that is needed in the current environment for people on the road a 
 lot.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4712) Access final artifact properties such as uniqueVersion within Maven

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4712:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Access final artifact properties such as uniqueVersion within Maven
 ---

 Key: MNG-4712
 URL: https://jira.codehaus.org/browse/MNG-4712
 Project: Maven
  Issue Type: Improvement
  Components: Artifacts and Repositories
Affects Versions: 2.2.1
 Environment: 64-bit Linux 2.6.18-128 (x86_64)
Reporter: thinkpipes

 Access to properties about the final artifact, such as the final, constructed 
 uniqueVersion, filename, would be extremely useful.
 During deployment, I store a build's info in a local MySQL db that includes 
 the URL where the artifact is deployed (to Nexus). However, I can't reliably 
 do this when uniqueVersion=true.
 With the assembly plugin, I can construct a file name myself (and store in 
 the db with the sql-maven-plugin), however this requires the developer to 
 adhere to my final name format. Plus, with multi-module projects, I'd have to 
 define a different assembly plugin for each module.
 I want to be able to save the final constructed artifact name (with the 
 uniqueVersion already defined) in a user-definable property, like so:
deployableArtifactFinalNamethis.jar.final/deployableArtifactFinalName
(call the XML tag whatever fits best)
 This would be perfect for multi-module projects, as I would be able to save 
 and reference each modules' final constructed artifact name in a property I 
 define, if I so choose (e.g. ${this.jar.final} using the example above).
 I looked through the code, and unless I'm reading it incorrectly, referencing 
 /[Apache-SVN]/maven/maven-2/branches/maven-2.2.x/maven-artifact-manager/src/main/java/org/apache/maven/artifact/transform/SnapshotTransformation.java,
  I'm basically suggesting having an easy way to expose the members in the 
 Snapshot object, as used in the transformForDeployment and constructVersion 
 methods.
 It would be great if this could then be extended to things like file size and 
 extension, however for now, just getting the uniqueVersion would be terrific.
 Thanks.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-532) Allow Mojos to be private

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-532:
--

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Allow Mojos to be private
 -

 Key: MNG-532
 URL: https://jira.codehaus.org/browse/MNG-532
 Project: Maven
  Issue Type: New Feature
  Components: Plugins and Lifecycle
Affects Versions: 2.0-alpha-3
Reporter: Vincent Massol

 Some Mojos are called by other mojos (by using a custom lifecycle for 
 example). It might happen that these called mojos should not be called by the 
 end user. It would be nice to prevent them from being called. For example by 
 using a javadoc tag.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-2903) Snapshots are being packaged with datestamps in their filename instead of SNAPSHOT,

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2903:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Snapshots are being packaged with datestamps in their filename instead of 
 SNAPSHOT, 
 --

 Key: MNG-2903
 URL: https://jira.codehaus.org/browse/MNG-2903
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.5
Reporter: Tim Cederman
Priority: Critical

 When I run mvn package on a project, it collects all the correct and most 
 recent
 jar files for me in the lib directory, however in the zip file instead
 of naming them project-3.0-SNAPSHOT.jar (for example) it will name
 them project-20070318.080720-37.jar.  
 Meanwhile in the project's own jar file, the manifest will point to
 ./lib/project-3.0-SNAPSHOT.jar.  This means the packaged project does
 not run.
 It doesn't do this for every single dependency snapshot, and I can't
 seem to work out a pattern as to which get named correctly and which
 don't.
 I have two repositories in my pom file:
 repositories
   repository
   idcommon-repository/id
   name Common Repository/name
   urlhttp://repository/common-repository/url
   /repository
   repository
   idsnapshot-repository/id
   nameTrovix Snapshot Repository/name
   urlhttp://repository/snapshots/url
   snapshots
   enabledtrue/enabled
   updatePolicyalways/updatePolicy
   /snapshots
   /repository
 /repositories
 If I try to disable them manually (and use only the local repository),
 the problem persists.  However, this is where it gets weird.  If I
 unplug my network cable - my package file is created perfectly!
 However - if I unplug my network cable with the snapshot repository
 removed, it creates the package incorrectly once again!
 This seems to be the key part of what is making it work (blacklisting
 the snapshot-repository):
 [INFO]task-segment: [package]
 [INFO]
 -
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] snapshot com:com.benchmark:3.0-SNAPSHOT: checking for updates
 from snapshot-repository
 [WARNING] repository metadata for: 'snapshot
 com:com.benchmark:3.0-SNAPSHOT' could not be retrieved from repository:
  snapshot-repository due to an error: Error transferring file
 [INFO] Repository 'snapshot-repository' will be blacklisted
 [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] No sources to compile
 [INFO] [surefire:test]
 [INFO] No tests to run.
 [INFO] [jar:jar]
 I have also run mvn -X package, and the debug log shows that it thinks
 it is collecting all the correct SNAPSHOT named jars, even though it
 then stores the date-stamped ones.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-3038) Transitive DepMan not working (per MNG-1577) [use case attached]

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3038:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Transitive DepMan not working (per MNG-1577) [use case attached]
 

 Key: MNG-3038
 URL: https://jira.codehaus.org/browse/MNG-3038
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.5, 2.0.6
Reporter: Joakim Erdfelt
Assignee: Patrick Schneider
 Attachments: carlos_transitive_version.tar.gz


 When working with the example use case described by Carlos on the MNG-1577 
 thread.
 http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html
 {noformat}
 What about this use case for transitive dependencyManagement? has been tested?
 A - B - C - D
 C depends on D 1.0
 B has D 2.0 in dependencyManagement, no D in dependencies
 A should get D 2.0 
 {noformat}
 It was discovered that this does not work.
 Sample Project / Use Case is attached. (655 bytes)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-4141) Properties are not propagated reccusivly in the dependency tree

[Paul Benedict (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4141:
---

Fix Version/s: (was: Issues to be reviewed for 3.x)

 Properties are not propagated reccusivly in the dependency tree
 ---

 Key: MNG-4141
 URL: https://jira.codehaus.org/browse/MNG-4141
 Project: Maven
  Issue Type: Bug
Affects Versions: 2.0.9
 Environment: Linux and windows
Reporter: fabrice

 Hi
 I am use to use Maven profile for building my projects. For each profile I 
 declare a specific classifier properties that will be used by Maven to embed 
 dependencies that match the profile use to build my main project.
 It works well with type that embed librairies like EAR, WAR.
 I can compile my WAR with a specific profil, this war embed JAR that match 
 the profil
 In the same way my EAR embed the WAR.
 Example :
 --- the WAR that call 
 a specific JAR, it is based on classifier mecanism  
 
   modelVersion4.0.0/modelVersion
   groupIdcom.toto/groupId
   artifactIdmyWAR/artifactId
   packagingwar/packaging
   nameebeesign-server/name
   version1.0.9.0.0/version
   profiles
   profile
   idenv-dev/id
   activation
   activeByDefaulttrue/activeByDefault
   /activation
   properties
   profile.namedev/profile.name
   profile.classifier/
   /properties
   /profile
   profile
   idenv-preprod/id
   properties
   profile.namepreprod/profile.name
   
 profile.classifier${profile.name}/profile.classifier
   /properties
   /profile
   /profiles
   
   build
   filters
   
 filtersrc/main/filters/${profile.name}.properties/filter
   /filters
   /build
 dependency
   groupIdcom.company/groupId
   artifactIdfoo-core/artifactId
   version1.0.9.0.0/version
   classifier${profile.classifier}/classifier
 /dependency
 /project
 -
 the JAR itself need a specific jar that match the profil
 -
   modelVersion4.0.0/modelVersion
   groupIdcom.toto/groupId
   artifactIdmyJAR/artifactId
   packagingjar/packaging
   version1.2/version
   profiles
   profile
   idenv-dev/id
   activation
   activeByDefaulttrue/activeByDefault
   /activation
   properties
   profile.namedev/profile.name
   profile.classifier/
   /properties
   /profile
   profile
   idenv-preprod/id
   properties
   profile.namepreprod/profile.name
   
 profile.classifier${profile.name}/profile.classifier
   /properties
   /profile
   
   /profiles
   
   build
   filters
   
 filtersrc/main/filters/${profile.name}.properties/filter
   /filters
   /build
 dependency
   groupIdcom.company/groupId
   artifactIdmyJAR2/artifactId
   version1.0.9.3/version
   classifier${profile.classifier}/classifier
 /dependency
 /project
 
 finally my WAR does not contains JAR2 with the good profile
 When I want a WAR with demo profile I have myJAR with demo profile embeded 
 but myJAR2 with dev profile embeded
 I believed that properties was propagated but in fact not !!!



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)