[jira] (MNG-5580) mvn 3.x - unable to resolve snapshot artifact via ArtifactResolver using override local repository
[ https://jira.codehaus.org/browse/MNG-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated MNG-5580: -- Description: I can use ArtifactResolver to download a given snapshot maven coordinate. This works with private local repository ( ie I dont want to use the default one) using mvn2 but fails with mvn3.x This type of invocation also under maven-dependency-plugin Similar invocation using technique at https://github.com/ljnelson/maven-artifacts/blob/master/src/main/java/com/edugility/maven/Artifacts.java also see the same result The main motivation is for my plugin to download a huge artifact using a given artifact under 'target' directory using maven 2/3.x without using aether a demo is also at https://svn.codehaus.org/mojo/trunk/sandbox/download-maven-plugin was: I can use ArtifactResolver to download a given snapshot maven coordinate. This works with private local repository ( ie I dont want to use the default one) using mvn2 but fails with mvn3.x This type of invocation also under maven-dependency-plugin Similar invocation using technique at https://github.com/ljnelson/maven-artifacts/blob/master/src/main/java/com/edugility/maven/Artifacts.java also see the same result The main motivation is for my plugin to download a huge artifact using a given artifact under 'target' directory using maven 2/3.x without using aether > mvn 3.x - unable to resolve snapshot artifact via ArtifactResolver using > override local repository > -- > > Key: MNG-5580 > URL: https://jira.codehaus.org/browse/MNG-5580 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.5, 3.1.0, 3.1.1 >Reporter: Dan Tran > > I can use ArtifactResolver to download a given snapshot maven coordinate. > This works with private local repository ( ie I dont want to use the default > one) using mvn2 but fails with mvn3.x > This type of invocation also under maven-dependency-plugin > Similar invocation using technique at > https://github.com/ljnelson/maven-artifacts/blob/master/src/main/java/com/edugility/maven/Artifacts.java > also see the same result > The main motivation is for my plugin to download a huge artifact using a > given artifact under 'target' directory using maven 2/3.x without using aether > a demo is also at > https://svn.codehaus.org/mojo/trunk/sandbox/download-maven-plugin -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5580) mvn 3.x - unable to resolve snapshot artifact via ArtifactResolver using override local repository
Dan Tran created MNG-5580: - Summary: mvn 3.x - unable to resolve snapshot artifact via ArtifactResolver using override local repository Key: MNG-5580 URL: https://jira.codehaus.org/browse/MNG-5580 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.1.1, 3.1.0, 3.0.5 Reporter: Dan Tran I can use ArtifactResolver to download a given snapshot maven coordinate. This works with private local repository ( ie I dont want to use the default one) using mvn2 but fails with mvn3.x This type of invocation also under maven-dependency-plugin Similar invocation using technique at https://github.com/ljnelson/maven-artifacts/blob/master/src/main/java/com/edugility/maven/Artifacts.java also see the same result The main motivation is for my plugin to download a huge artifact using a given artifact under 'target' directory using maven 2/3.x without using aether -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://jira.codehaus.org/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340851#comment-340851
]
Robert Scholte commented on MJAVADOC-387:
-
Confirmed, MSITE-701 exposed these issues.
> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://jira.codehaus.org/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Reporter: Stephen Colebourne
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default
> settings, it rejects many HTML elements that are perfectly acceptable to
> browsers, and all invalid Javadoc references (@links). This is likely to
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can
> control the doclint tool (currently this requires using additionalparam
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
> not opt-out (ie. fix Oracle's messed up default). This will also make it much
> easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5574) Write error/warning messages from mvn shell and batch scripts to stderr
[
https://jira.codehaus.org/browse/MNG-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340850#comment-340850
]
Robert Scholte commented on MNG-5574:
-
right. AFAIK for Windows JAVA_HOME is required, there's no discovery of the
java executable, so Maven will exit with an error.
IIRC the shell script has a way to discover the java executable. Maven will
run, so it should just be a warning.
> Write error/warning messages from mvn shell and batch scripts to stderr
> ---
>
> Key: MNG-5574
> URL: https://jira.codehaus.org/browse/MNG-5574
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.1.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2
>
>
> If I disable stdout on {{mvn}} and {{JAVA_HOME}} is not set in cron env, I'll
> never see the error message.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5579) Unify error output/check logic from shell and batch scripts
[
https://jira.codehaus.org/browse/MNG-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5579:
Description:
Currently,
both output two different messages.
Shell:
{quote}
Error: JAVA_HOME is not defined correctly.
We cannot execute $JAVACMD
{quote}
while batch says:
{quote}
Error: JAVA_HOME not found in your environment.
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
{quote}
Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
handled different in both scripts. The batch script relies on JAVA_HOME while
the shell script can ignore it. Both should require {{JAVA_HOME}} or warn about
and use {{which java}}, respectively {{java}} in {{PATH}} ({{for %%X in
(java.exe) do (set JAVACMD=%%~$PATH:X)}}) on Windows. After that should proceed
to checking {{M2_HOME}}.
Any thoughts?
was:
Currently,
both output two different messages.
Shell:
{quote}
Error: JAVA_HOME is not defined correctly.
We cannot execute $JAVACMD
{quote}
while batch says:
{quote}
Error: JAVA_HOME not found in your environment.
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
{quote}
Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
handled different in both scripts. The batch script relies on JAVA_HOME while
the shell script can ignore it. Both should require {{JAVA_HOME}} or warn about
and use {{which java}}, respectively {{java}} in {{PATH}} on Windows. After
that should proceed to checking {{M2_HOME}}.
Any thoughts?
> Unify error output/check logic from shell and batch scripts
> ---
>
> Key: MNG-5579
> URL: https://jira.codehaus.org/browse/MNG-5579
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.1.1
>Reporter: Michael Osipov
>Priority: Minor
>
> Currently,
> both output two different messages.
> Shell:
> {quote}
> Error: JAVA_HOME is not defined correctly.
>We cannot execute $JAVACMD
> {quote}
> while batch says:
> {quote}
> Error: JAVA_HOME not found in your environment.
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation.
> {quote}
> Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
> handled different in both scripts. The batch script relies on JAVA_HOME while
> the shell script can ignore it. Both should require {{JAVA_HOME}} or warn
> about and use {{which java}}, respectively {{java}} in {{PATH}} ({{for %%X
> in (java.exe) do (set JAVACMD=%%~$PATH:X)}}) on Windows. After that should
> proceed to checking {{M2_HOME}}.
> Any thoughts?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5579) Unify error output/check logic from shell and batch scripts
[
https://jira.codehaus.org/browse/MNG-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5579:
Description:
Currently,
both output two different messages.
Shell:
{quote}
Error: JAVA_HOME is not defined correctly.
We cannot execute $JAVACMD
{quote}
while batch says:
{quote}
Error: JAVA_HOME not found in your environment.
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
{quote}
Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
handled different in both scripts. The batch script relies on JAVA_HOME while
the shell script can ignore it. Both should require {{JAVA_HOME}} or warn about
and use {{which java}}, respectively {{java}} in {{PATH}} on Windows. After
that should proceed to checking {{M2_HOME}}.
Any thoughts?
was:
Currently,
both output two different messages.
Shell:
{quote}
Error: JAVA_HOME is not defined correctly.
We cannot execute $JAVACMD
{quote}
while batch says:
{quote}
Error: JAVA_HOME not found in your environment.
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
{quote}
Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
handled different in both scripts. The batch script relies on JAVA_HOME while
the shell script can ignore it. Both should require {{JAVA_HOME}} or warn about
and use {{which java}}, respectively {{java}} in {{PATH}} on Windows. After
that should proceed to checking {{M2_HOME}}.
> Unify error output/check logic from shell and batch scripts
> ---
>
> Key: MNG-5579
> URL: https://jira.codehaus.org/browse/MNG-5579
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.1.1
>Reporter: Michael Osipov
>Priority: Minor
>
> Currently,
> both output two different messages.
> Shell:
> {quote}
> Error: JAVA_HOME is not defined correctly.
>We cannot execute $JAVACMD
> {quote}
> while batch says:
> {quote}
> Error: JAVA_HOME not found in your environment.
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation.
> {quote}
> Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
> handled different in both scripts. The batch script relies on JAVA_HOME while
> the shell script can ignore it. Both should require {{JAVA_HOME}} or warn
> about and use {{which java}}, respectively {{java}} in {{PATH}} on Windows.
> After that should proceed to checking {{M2_HOME}}.
> Any thoughts?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5579) Unify error output/check logic from shell and batch scripts
[
https://jira.codehaus.org/browse/MNG-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5579:
Description:
Currently,
both output two different messages.
Shell:
{quote}
Error: JAVA_HOME is not defined correctly.
We cannot execute $JAVACMD
{quote}
while batch says:
{quote}
Error: JAVA_HOME not found in your environment.
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
{quote}
Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
handled different in both scripts. The batch script relies on JAVA_HOME while
the shell script can ignore it. Both should require {{JAVA_HOME}} or warn about
and use {{which java}}, respectively {{java}} in {{PATH}} on Windows. After
that should proceed to checking {{M2_HOME}}.
was:
Currently,
both output two different messages.
Shell:
{quote}
Error: JAVA_HOME is not defined correctly.
We cannot execute $JAVACMD
{quote}
while batch says:
{quote}
Error: JAVA_HOME not found in your environment.
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
{quote}
Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
handled different in both scripts. That should be unified in one go.
> Unify error output/check logic from shell and batch scripts
> ---
>
> Key: MNG-5579
> URL: https://jira.codehaus.org/browse/MNG-5579
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.1.1
>Reporter: Michael Osipov
>Priority: Minor
>
> Currently,
> both output two different messages.
> Shell:
> {quote}
> Error: JAVA_HOME is not defined correctly.
>We cannot execute $JAVACMD
> {quote}
> while batch says:
> {quote}
> Error: JAVA_HOME not found in your environment.
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation.
> {quote}
> Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
> handled different in both scripts. The batch script relies on JAVA_HOME while
> the shell script can ignore it. Both should require {{JAVA_HOME}} or warn
> about and use {{which java}}, respectively {{java}} in {{PATH}} on Windows.
> After that should proceed to checking {{M2_HOME}}.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5484) Changing the Maven distribution name breaks ITs
[
https://jira.codehaus.org/browse/MNG-5484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5484.
---
Resolution: Fixed
Assignee: Igor Fedorenko
Fixed in http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/980481c6
> Changing the Maven distribution name breaks ITs
> ---
>
> Key: MNG-5484
> URL: https://jira.codehaus.org/browse/MNG-5484
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Integration Tests
>Affects Versions: 3.1.0-alpha-1
> Environment: 3.1-SNAPSHOT but probably existing for a long time
>Reporter: Arnaud Heritier
>Assignee: Igor Fedorenko
>
> We have a feature branch like slf4j-log4j2 where we temporarily changed the
> distribution name :
> {code}
> arnaud@mbp-arnaud:~/Code/Maven/maven-integration-testing (git:master)$ mvn
> --version
> Apache Maven (Log4J2) 3.1-SNAPSHOT (e8de237706061aff5e6924f0d553ae23d7321f16;
> 2013-06-11 23:02:46+0200)
> Maven home: /Users/arnaud/Applications/apache-maven-3.1-SNAPSHOT-log4j2
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
> {code}
> All ITs are skipped with :
> {code}
> Running integration tests for Maven 4J2)
> using Maven executable:
> /Users/arnaud/Applications/apache-maven-3.1-SNAPSHOT-log4j2/bin/mvn
> Bootstrap(Bootstrap)SKIPPED - Maven
> version 4J2) not in range [2.0,)
> mng5482AetherNotFound(PluginDependency).SKIPPED - Maven
> version 4J2) not in range [3.1-A,)
> mng5482AetherNotFound(PluginSite)...SKIPPED - Maven
> version 4J2) not in range [3.1-A,)
> mng5445LegacyStringSearchModelInterpolator(it)..SKIPPED - Maven
> version 4J2) not in range [3.1,)
> mng5387ArtifactReplacementPlugin(ArtifactReplacementExecution)SKIPPED - Maven
> version 4J2) not in range [3.1,)
> mng5382Jsr330Plugin(Jsr330PluginExecution)..SKIPPED - Maven
> version 4J2) not in range [3.1-alpha,)
> mng5338FileOptionToDirectory(FileOptionToADirectory)SKIPPED - Maven
> version 4J2) not in range [3.1-A,)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5579) Unify error output/check logic from shell and batch scripts
[
https://jira.codehaus.org/browse/MNG-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5579:
Description:
Currently,
both output two different messages.
Shell:
{quote}
Error: JAVA_HOME is not defined correctly.
We cannot execute $JAVACMD
{quote}
while batch says:
{quote}
Error: JAVA_HOME not found in your environment.
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
{quote}
Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
handled different in both scripts. That should be unified in one go.
was:
Currently,
both output two different messages.
Shell:
{quote}
Error: JAVA_HOME is not defined correctly.
We cannot execute $JAVACMD
{quote}
while batch says:
{quote}
Error: JAVA_HOME not found in your environment.
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
{quote}
Same applies for {{M2_HOME}. Additionally, testing for the Java command is
handled different in both scripts. That should be unified in one go.
> Unify error output/check logic from shell and batch scripts
> ---
>
> Key: MNG-5579
> URL: https://jira.codehaus.org/browse/MNG-5579
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.1.1
>Reporter: Michael Osipov
>Priority: Minor
>
> Currently,
> both output two different messages.
> Shell:
> {quote}
> Error: JAVA_HOME is not defined correctly.
>We cannot execute $JAVACMD
> {quote}
> while batch says:
> {quote}
> Error: JAVA_HOME not found in your environment.
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation.
> {quote}
> Same applies for {{M2_HOME}}. Additionally, testing for the Java command is
> handled different in both scripts. That should be unified in one go.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-387) Handle JDK8 -Xdoclint
Stephen Colebourne created MJAVADOC-387:
---
Summary: Handle JDK8 -Xdoclint
Key: MJAVADOC-387
URL: https://jira.codehaus.org/browse/MJAVADOC-387
Project: Maven Javadoc Plugin
Issue Type: Improvement
Reporter: Stephen Colebourne
The Oracle team have added the doclint tool to JDK 8. The tool validates
Javadoc as part of a standard Javadoc run. Unfortunately, with the default
settings, it rejects many HTML elements that are perfectly acceptable to
browsers, and all invalid Javadoc references (@links). This is likely to prove
very unpopular with developers.
Action needed:
1) Provide a maven-javadoc-plugin configuration item and property that can
control the doclint tool (currently this requires using additionalparam AFAICT).
2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
not opt-out (ie. fix Oracle's messed up default). This will also make it much
easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5574) Write error/warning messages from mvn shell and batch scripts to stderr
[
https://jira.codehaus.org/browse/MNG-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340848#comment-340848
]
Michael Osipov commented on MNG-5574:
-
You mean in a sense that maven can still work as expected and stdout can be
turned off?
> Write error/warning messages from mvn shell and batch scripts to stderr
> ---
>
> Key: MNG-5574
> URL: https://jira.codehaus.org/browse/MNG-5574
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.1.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2
>
>
> If I disable stdout on {{mvn}} and {{JAVA_HOME}} is not set in cron env, I'll
> never see the error message.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5572) Warn for building plugins with extensions in a reactor
[
https://jira.codehaus.org/browse/MNG-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5572.
---
Resolution: Fixed
Fix Version/s: 3.2
Assignee: Robert Scholte
Fixed in http://git-wip-us.apache.org/repos/asf/maven/commit/f6bb98f5 and
http://git-wip-us.apache.org/repos/asf/maven-integration-testing/commit/b5f7a802
(IT)
> Warn for building plugins with extensions in a reactor
> --
>
> Key: MNG-5572
> URL: https://jira.codehaus.org/browse/MNG-5572
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle, Reactor and workspace
>Affects Versions: 3.0, 3.1.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.2
>
>
> MNG-1911 Has been closed as {{won't fix}}. However, if the project was build
> with {{mvn install}} you can still get it from the local repository, which is
> probably an unexpected and unwanted situation.
> It would be better if Maven warns for these constructions within a reactor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340845#comment-340845 ] Jörg Schaible commented on MNG-5207: q. Is it expected to build correctly? For sure. If you had run the prepare step as explained above in the first comment. Or, didn't you simply use the attached integration test? > [Regression] Maven 3 fails to calculate proper build order with dependencies > with classifiers > - > > Key: MNG-5207 > URL: https://jira.codehaus.org/browse/MNG-5207 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0.3 >Reporter: Jörg Schaible >Assignee: Jason van Zyl >Priority: Critical > Fix For: Issues to be reviewed for 4.x > > Attachments: mng5207-it.tgz, MNG-5207.tgz > > > Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in > proper order, if a transitive dependency (that is part of the reactor build) > is overruled in the dependencyManagement section with the current SNAPSHOT > version. Build order is perfectly calculated with Maven 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5207: --- Fix Version/s: (was: 3.2) Issues to be reviewed for 4.x > [Regression] Maven 3 fails to calculate proper build order with dependencies > with classifiers > - > > Key: MNG-5207 > URL: https://jira.codehaus.org/browse/MNG-5207 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0.3 >Reporter: Jörg Schaible >Assignee: Jason van Zyl >Priority: Critical > Fix For: Issues to be reviewed for 4.x > > Attachments: mng5207-it.tgz, MNG-5207.tgz > > > Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in > proper order, if a transitive dependency (that is part of the reactor build) > is overruled in the dependencyManagement section with the current SNAPSHOT > version. Build order is perfectly calculated with Maven 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340844#comment-340844 ] Jason van Zyl commented on MNG-5207: The right build order is calculated in 2.2.1 but the sample project still doesn't build. Is it expected to build correctly? > [Regression] Maven 3 fails to calculate proper build order with dependencies > with classifiers > - > > Key: MNG-5207 > URL: https://jira.codehaus.org/browse/MNG-5207 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0.3 >Reporter: Jörg Schaible >Assignee: Jason van Zyl >Priority: Critical > Fix For: 3.2 > > Attachments: mng5207-it.tgz, MNG-5207.tgz > > > Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in > proper order, if a transitive dependency (that is part of the reactor build) > is overruled in the dependencyManagement section with the current SNAPSHOT > version. Build order is perfectly calculated with Maven 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5574) Write error/warning messages from mvn shell and batch scripts to stderr
[
https://jira.codehaus.org/browse/MNG-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340841#comment-340841
]
Robert Scholte commented on MNG-5574:
-
IMHO warnings should not be written to std.err
> Write error/warning messages from mvn shell and batch scripts to stderr
> ---
>
> Key: MNG-5574
> URL: https://jira.codehaus.org/browse/MNG-5574
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.1.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2
>
>
> If I disable stdout on {{mvn}} and {{JAVA_HOME}} is not set in cron env, I'll
> never see the error message.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5579) Unify error output/check logic from shell and batch scripts
Michael Osipov created MNG-5579:
---
Summary: Unify error output/check logic from shell and batch
scripts
Key: MNG-5579
URL: https://jira.codehaus.org/browse/MNG-5579
Project: Maven 2 & 3
Issue Type: Improvement
Components: Command Line
Affects Versions: 3.1.1
Reporter: Michael Osipov
Priority: Minor
Currently,
both output two different messages.
Shell:
{quote}
Error: JAVA_HOME is not defined correctly.
We cannot execute $JAVACMD
{quote}
while batch says:
{quote}
Error: JAVA_HOME not found in your environment.
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
{quote}
Same applies for {{M2_HOME}. Additionally, testing for the Java command is
handled different in both scripts. That should be unified in one go.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5574) Write error/warning messages from mvn shell and batch scripts to stderr
[
https://jira.codehaus.org/browse/MNG-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5574.
---
Resolution: Fixed
Fixed with
[088193ca4cc1a7a1e4838c424a0f2120300479fa|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=088193ca4cc1a7a1e4838c424a0f2120300479fa]
> Write error/warning messages from mvn shell and batch scripts to stderr
> ---
>
> Key: MNG-5574
> URL: https://jira.codehaus.org/browse/MNG-5574
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.1.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2
>
>
> If I disable stdout on {{mvn}} and {{JAVA_HOME}} is not set in cron env, I'll
> never see the error message.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5476) [REGRESSION] @required parameter not being enforced for arrays
[
https://jira.codehaus.org/browse/MNG-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-5476:
---
Affects Version/s: (was: 3.2)
> [REGRESSION] @required parameter not being enforced for arrays
> --
>
> Key: MNG-5476
> URL: https://jira.codehaus.org/browse/MNG-5476
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, 3.1.0, 3.1.1
>Reporter: Chris Graham
>
> For a plugin that has the following parameters defined:
> {code}
> /**
> * The message flows to be added to the bar file.
> * @parameter expression="${msgFlows}"
> * @required
> */
> private String[] msgFlows;
> /**
> * The message sets to be added to the bar file.
> * @parameter expression="${msgSets}"
> * @required
> */
> private String[] msgSets;
> {code}
> and a pom config snippet of (note missing the msgSets):
> {code:xml}
>
>
>
>
>
> {code}
> maven 2.x (2.09 and 2.2.1) will correctly fail with the following error:
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] One or more required plugin parameters are invalid/missing for
> 'message-broker:package-bar-file'
> [0] Inside the definition for plugin 'maven-message-broker-plugin' specify
> the following:
>
> ...
> VALUE
>
> OR
> on the command line, specify: '-DmsgSets=VALUE'
> {code}
> However, maven 3.x (3.0-beta-1 through to 3.0.5) do NOT enforce this.
> I would expect the build to be failed in the same manner as 2.x.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5522) properties project.parent.xxx not supported under Linux
[
https://jira.codehaus.org/browse/MNG-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel updated MNG-5522:
---
Attachment: maven-MNG-5522.zip
You are right, sorry.
I've provide minimal project to show problem.
The idea recursively define rootProject.path to do not redefine it manually in
dozens of submodules. That property then used to run checkstyle plugin
automatically on each.
Attached project consist of two modules only. And works just fine on windows
platform (mvn clean install) on version:
{noformat}
D:\imus\temp\maven-MNG-5522\submodule>mvn -version
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17
19:22:22+0400)
Maven home: D:\imus\bin\build\apache-maven-3.1.1\bin\..
Java version: 1.7.0_21, vendor: Oracle Corporation
Java home: d:\imus\bin\jdk\jre
Default locale: en_US, platform encoding: Cp1251
OS name: "windows server 2008 r2", version: "6.1", arch: "amd64", family:
"windows"
{noformat}
but fails on my linux machine when I run _mvn clean install_ in submodule with:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.10:check (checkstyle) on
project test-proj-submodule: Failed during checkstyle execution: Unable to find
configuration file at location
${project.parent.rootProject.path}/../checkstyle.xml: Could not find resource
'${project.parent.rootProject.path}/../checkstyle.xml'. -> [Help 1]
{noformat}
Version of maven:
{noformat}
$ mvn -version
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
-Dsun.java2d.pmoffscreen=false -XX:+UseCompressedOops
Apache Maven 3.1.1 (NON-CANONICAL_2013-11-08_14-32_mockbuild; 2013-11-08
18:32:41+0400)
Maven home: /usr/share/maven
Java version: 1.7.0_45, vendor: Oracle Corporation
Java home: /usr/java/jdk1.7.0_45/jre
Default locale: ru_RU, platform encoding: UTF-8
OS name: "linux", version: "3.12.9-301.fc20.x86_64", arch: "amd64", family:
"unix"
{noformat}
> properties project.parent.xxx not supported under Linux
> ---
>
> Key: MNG-5522
> URL: https://jira.codehaus.org/browse/MNG-5522
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Bootstrap & Build, POM
>Affects Versions: 3.0.5
> Environment: Few Linuxes tested, work under Windows
>Reporter: Pavel
> Attachments: maven-MNG-5522.zip
>
>
> Initially it was there:
> https://jira.codehaus.org/browse/MRM-1772#comment-333654 . But It is maven
> problem itself.
> It is reproducible on two our Linux machines (Fedora and Gentoo), so it may
> be Linux relative. On all our colleagues on windows it does not reproduced.
> Some details.
> Parent pom among others have:
> {code}
> 1.5.300-SNAPSHOT
> imus
> ...
>
> 2.5.6
> 3.2.2.RELEASE
> 2.1.1
> 1.7.0
> windows-1251
> none
> 1.7
> 1.7
> ${basedir}
> QWERTY
>
> {code}
> First child module:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.1
>
>
> validate
>
> run
>
>
>
>
> [project.parent.rootProjectPath]:
> ${project.parent.rootProjectPath}
>
> [project.parent.getRootProjectPath()]:
> ${project.parent.getRootProjectPath()}
>
> [project.parent.rootProjectPath1]:
> ${project.parent.rootProjectPath1}
>
> [project.parent.spring3.version]:
> ${project.parent.spring3.version}
>
> [project.parent.properties.spring3.version]:
> ${project.parent.properties.spring3.version}
>
> [project.parent.properties.rootProjectPath]:
> ${project.parent.properties.rootProjectPath}
>
> [project.parent.properties.rootProjectPath1]:
> ${project.parent.properties.rootProjectPath1}
>
> [project.parent.name]: ${project.parent.name}
>
> [project.parent.
[jira] (MNG-5574) Write error/warning messages from mvn shell and batch scripts to stderr
[
https://jira.codehaus.org/browse/MNG-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5574:
Summary: Write error/warning messages from mvn shell and batch scripts to
stderr (was: Write error messages from mvn shell and batch scripts to stderr)
> Write error/warning messages from mvn shell and batch scripts to stderr
> ---
>
> Key: MNG-5574
> URL: https://jira.codehaus.org/browse/MNG-5574
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.1.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2
>
>
> If I disable stdout on {{mvn}} and {{JAVA_HOME}} is not set in cron env, I'll
> never see the error message.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5476) [REGRESSION] @required parameter not being enforced for arrays
[
https://jira.codehaus.org/browse/MNG-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-5476:
-
Affects Version/s: 3.2
3.1.0
3.1.1
> [REGRESSION] @required parameter not being enforced for arrays
> --
>
> Key: MNG-5476
> URL: https://jira.codehaus.org/browse/MNG-5476
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, 3.1.0, 3.1.1, 3.2
>Reporter: Chris Graham
>
> For a plugin that has the following parameters defined:
> {code}
> /**
> * The message flows to be added to the bar file.
> * @parameter expression="${msgFlows}"
> * @required
> */
> private String[] msgFlows;
> /**
> * The message sets to be added to the bar file.
> * @parameter expression="${msgSets}"
> * @required
> */
> private String[] msgSets;
> {code}
> and a pom config snippet of (note missing the msgSets):
> {code:xml}
>
>
>
>
>
> {code}
> maven 2.x (2.09 and 2.2.1) will correctly fail with the following error:
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] One or more required plugin parameters are invalid/missing for
> 'message-broker:package-bar-file'
> [0] Inside the definition for plugin 'maven-message-broker-plugin' specify
> the following:
>
> ...
> VALUE
>
> OR
> on the command line, specify: '-DmsgSets=VALUE'
> {code}
> However, maven 3.x (3.0-beta-1 through to 3.0.5) do NOT enforce this.
> I would expect the build to be failed in the same manner as 2.x.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5576) Allow continuous delivery friendly versions
[
https://jira.codehaus.org/browse/MNG-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-5576:
---
Description:
Currently warnings will be emitted when there are expressions in versions, a
few exceptions should be deemed valid to make continuous delivery easier. The
use case is to allow easy versioning of an entire multi-module build that can
take a version from an external source like SCM. These are the types of
exceptions that will be allowed:
1.0.0.$\{changelist}
1.0.0.$\{revision}
1.0.0.$\{sha1}
When a whole build is versioned like this we can avoid churning the POMs in the
SCM which makes it a lot easier to see the actual changes in the project. Not a
complete solution for continuous delivery but is a step in the right direction
and doesn't interfere with currently behavior as it is currently allowed, just
warned against.
was:
Currently warnings will be emitted when there are expressions in versions, a
few exceptions should be deemed valid to make continuous delivery easier. The
use case is to allow easy versioning of an entire multi-module build that can
take a version from an external source like SCM. These are the types of
exceptions that will be allowed:
1.0.0.${changelist}
1.0.0.${revision}
1.0.0.${sha1}
When a whole build is versioned like this we can avoid churning the POMs in the
SCM which makes it a lot easier to see the actual changes in the project. Not a
complete solution for continuous delivery but is a step in the right direction
and doesn't interfere with currently behavior as it is currently allowed, just
warned against.
> Allow continuous delivery friendly versions
> ---
>
> Key: MNG-5576
> URL: https://jira.codehaus.org/browse/MNG-5576
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.1.1
>Reporter: Jason van Zyl
> Fix For: 3.2
>
>
> Currently warnings will be emitted when there are expressions in versions, a
> few exceptions should be deemed valid to make continuous delivery easier. The
> use case is to allow easy versioning of an entire multi-module build that can
> take a version from an external source like SCM. These are the types of
> exceptions that will be allowed:
> 1.0.0.$\{changelist}
> 1.0.0.$\{revision}
> 1.0.0.$\{sha1}
> When a whole build is versioned like this we can avoid churning the POMs in
> the SCM which makes it a lot easier to see the actual changes in the project.
> Not a complete solution for continuous delivery but is a step in the right
> direction and doesn't interfere with currently behavior as it is currently
> allowed, just warned against.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3514) MPIR ignores reports set declared in child modules
[ https://jira.codehaus.org/browse/MNG-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-3514: --- Component/s: Inheritance and Interpolation > MPIR ignores reports set declared in child modules > -- > > Key: MNG-3514 > URL: https://jira.codehaus.org/browse/MNG-3514 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation >Reporter: Michael Osipov > Fix For: Issues to be reviewed for 3.x > > > I have declared my parent POM to produce selective reports only, see > [here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4/pom.xml#L114]. > Then I reclared the child modules to produces less reports but they still > produce the same reports as the parent pom. See > [here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4/fckeditor-java/pom.xml#L127] > and > [there|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4/fckeditor-java-demo/pom.xml#L105]. > this is a bug to me, breaking inheritance override. > You may [checkout|http://svn.fckeditor.net/FCKeditor.Java/branches/2.4/] my > project and try yourself. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-108) Assembly Plugin Implicitly Excludes Empty Directory
[ https://jira.codehaus.org/browse/MASSEMBLY-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MASSEMBLY-108. - Resolution: Cannot Reproduce Can't be reproduced for release 2.4. > Assembly Plugin Implicitly Excludes Empty Directory > --- > > Key: MASSEMBLY-108 > URL: https://jira.codehaus.org/browse/MASSEMBLY-108 > Project: Maven Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Sharmarke Aden > > It seems that the inclusion of an empty directory isn't currently possible > with the assembly plugin. This is a problem because I would like to have an > empty "logs" directory included with my zip file assembly. It would be nice > if the assembly plugin gave you the option to add empty directories to an > assembly. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-108) Assembly Plugin Implicitly Excludes Empty Directory
[ https://jira.codehaus.org/browse/MASSEMBLY-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340717#comment-340717 ] Karl Heinz Marbaise edited comment on MASSEMBLY-108 at 2/8/14 5:00 AM: --- I have checked the issue and couldn't reproduce the issue. Therefore I have created a sample project https://github.com/khmarbaise/massembly/tree/master/massembly-108 which can be used to discuss the problem. This example uses maven-assembly-plugin 2.4 and it proves that empty folders are handled correct by maven-assembly-plugin. May be i misunderstand a thing here in the discussion or a wish you have, but if you see it different please use the example project to reproduce the issue and send pull request (or patches) to the given project so we get nail down the problem. Update: I will close the issue. If you have wishes/problems i have oversight or didn't understand don't hesitate to reopen the issue. was (Author: khmarbaise): I have checked the issue and couldn't reproduce the issue. Therefor I have created a sample project https://github.com/khmarbaise/massembly/tree/master/massembly-108 which can be used to discuss the problem. This example uses maven-assembly-plugin 2.4 and it proves that empty folders are handled correct by maven-assembly-plugin. May be i misunderstand a thing here in the discussion or a wish you have, but if you see it different please use the example project to reproduce the issue and send pull request (or patches) to the given project so we get nail down the problem. > Assembly Plugin Implicitly Excludes Empty Directory > --- > > Key: MASSEMBLY-108 > URL: https://jira.codehaus.org/browse/MASSEMBLY-108 > Project: Maven Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Sharmarke Aden > > It seems that the inclusion of an empty directory isn't currently possible > with the assembly plugin. This is a problem because I would like to have an > empty "logs" directory included with my zip file assembly. It would be nice > if the assembly plugin gave you the option to add empty directories to an > assembly. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-681) plugin ignores empty finalName and uses default value
[
https://jira.codehaus.org/browse/MASSEMBLY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340829#comment-340829
]
Karl Heinz Marbaise commented on MASSEMBLY-681:
---
Sorry but my explanation wasn't accurate. The XML parser of Maven handles
everything well. The point is the injection mechanism in Maven says if the
value is not been set the default value will be injected. As a result of that
during the execution of a plugin it's usually not to distinguish if the values
hasn't been set at all or if the tags has been given empty.
> plugin ignores empty finalName and uses default value
> -
>
> Key: MASSEMBLY-681
> URL: https://jira.codehaus.org/browse/MASSEMBLY-681
> Project: Maven Assembly Plugin
> Issue Type: Wish
>Affects Versions: 2.4
>Reporter: Paul Millar
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 2.5
>
>
> When used in the 'dir' format, I would argue that an empty finalName is
> reasonable.
> For example, I would expect the following configuration, with the 'dir'
> format, to output the assembled files in ${foo.baseDirectory}
>
>
> src/main/assembly/foo.xml
>
> ${foo.baseDirectory}
>
>
> The actual behaviour is to silently ignore the configured empty finalName and
> use the default finalName value, which is append this to the outputDirectory.
> Arguably there are two bugs here:
> finalName is silently ignored (if this is invalid, it should report an
> error)
> the empty finalName is not honoured.
> Specify '.' as the finalName (.) seems to work as a
> work-around, at least for unix-like systems.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
