[jira] [Updated] (MNG-5756) Java home output in mvn -v is misleading

2015-10-07 Thread Jarkko Rantavuori (JIRA)

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

Jarkko Rantavuori updated MNG-5756:
---
Description: 
For example on my windows box, mvn -v prints the following:

{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}

But my JAVA_HOME is actually

{code}
> echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}

In the source code, the line comes from:

https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
{code}
version.append( "Java home: " ).append( System.getProperty( "java.home", 
"" ) ).append( ls );
{code}

which is using property "java.home" to fetch java home. However, "java.home" 
property is not JAVA_HOME! This is explained in detail in here: 
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html

To quote:

{quote}
What's the difference between JAVA_HOME and java.home?

JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set 
as an environment variable and referenced in Windows batch files or Unix 
scripts. I always have it in my Windows Control Panel and .tcsh files,along 
with other common environment variables. Some Java applications use the name 
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has 
been used since the beginning and is now a convention.

java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program 
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an 
environment variable. java.home is a build-in Java system property, whose value 
is the JRE install directory. Since all Java system properties are also exposed 
as Ant build properties, you can also use ${java.home} in build files.

Would jre.home be a better name? Maybe, but I don't think Sun will change 
it.
{quote}

This is a source of constant confusion. Some stackoverflow threads to 
illustrate:

http://stackoverflow.com/questions/15279586/java-home-in-maven
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk

The correct way to print JAVA_HOME would be to use System.getenv("JAVA_HOME"). 
Either that should be used or current output should be changed so it wouldn't 
be so misleading.

  was:
For example on my windows box, mvn -v prints the following:

{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}

But my JAVA_HOME is actually

{code}
> echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}

In the source code, the line comes from:

https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
{code}
version.append( "Java home: " ).append( System.getProperty( "java.home", 
"" ) ).append( ls );
{code}

which is using property "java.home" to fetch java home. However, "java.home" 
property is not JAVA_HOME! This is explained in detail in here: 
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html

To quote:

{quote}
What's the difference between JAVA_HOME and java.home?

JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set 
as an environment variable and referenced in Windows batch files or Unix 
scripts. I always have it in my Windows Control Panel and .tcsh files,along 
with other common environment variables. Some Java applications use the name 
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has 
been used since the beginning and is now a convention.

java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program 
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an 
environment variable. java.home is a build-in Java system property, whose value 
is the JRE install directory. Since all Java system properties are also exposed 
as Ant build properties, you can also use ${java.home} in build files.

Would jre.home be a better name? Maybe, but I don't think Sun will change 
it.
{quote}

This is a source of constant confusion. Some stackoverflow threads to 
illustrate:

http://stackoverflow.com/questions/15279586/java-home-in-maven
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk

The correct way to print JAVA_HOME would be to use System.getenv("JAVA_HOME"). 
Either that should be used or current output should be changed so it wouldn't 
be so misleading.


> Java home output in mvn -v is misleading
> 
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> J

[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading

2015-10-07 Thread Jarkko Rantavuori (JIRA)

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

Jarkko Rantavuori commented on MNG-5756:


Agreed. But it is Maven talking about "Java home", and it is maven doing
{noformat}System.getProperty( "java.home", "" ) {noformat}
instead of
{noformat}System.getenv("JAVA_HOME"){noformat}
when describing it.

Your suggestion sounds good to me. There might be some confusion if some user 
thinks "JRE home" is something one should set in the environment, like 
JAVA_HOME, so personally I would maybe say something like
{noformat}
Java home: .../java8
JRE used: .../java8/jre
{noformat}

> Java home output in mvn -v is misleading
> 
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home", 
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home" 
> property is not JAVA_HOME! This is explained in detail in here: 
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be 
> set as an environment variable and referenced in Windows batch files or Unix 
> scripts. I always have it in my Windows Control Panel and .tcsh files,along 
> with other common environment variables. Some Java applications use the name 
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has 
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program 
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an 
> environment variable. java.home is a build-in Java system property, whose 
> value is the JRE install directory. Since all Java system properties are also 
> exposed as Ant build properties, you can also use ${java.home} in build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change 
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to 
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use 
> System.getenv("JAVA_HOME"). Either that should be used or current output 
> should be changed so it wouldn't be so misleading.



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


[jira] [Closed] (MNG-5727) unexpected InvalidArtifactRTException from ProjectBuilder#build

2015-10-07 Thread Igor Fedorenko (JIRA)

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

Igor Fedorenko closed MNG-5727.
---
   Resolution: Fixed
Fix Version/s: 3.2.5

I am not sure what attached project you refer to. The test project I committed 
as part of [1] includes  entry without  element. 
The test project is expected to fail with ProjectBuildingException, which is 
ensured by the regression test introduced as part of the commit. 

This issue was specifically about InvalidArtifactRTException, which is fixed 
now, so I am closing this issue as such.

[1] 
https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=ce6f0bfdb527e20c3afbd76b9c742e07b13d25b2

> unexpected InvalidArtifactRTException from ProjectBuilder#build
> ---
>
> Key: MNG-5727
> URL: https://issues.apache.org/jira/browse/MNG-5727
> Project: Maven
>  Issue Type: Bug
>Reporter: Igor Fedorenko
> Fix For: 3.2.5
>
>
> Calling into ProjectBuilder#build(File, ProjectBuildingRequest) results in 
> InvalidArtifactRTException below if project pom.xml has managed dependency 
> without . Although the pom is invalid, I expected to get 
> ProjectBuildingException that includes location of problematic dependency, 
> similar to what I get during command line build.
> {code}
> org.apache.maven.artifact.InvalidArtifactRTException: For artifact 
> {org.apache.maven.its:a:null:jar}: The version cannot be empty.
>   at 
> org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:148)
>   at 
> org.apache.maven.artifact.DefaultArtifact.(DefaultArtifact.java:123)
>   at 
> org.apache.maven.bridge.MavenRepositorySystem.XcreateArtifact(MavenRepositorySystem.java:695)
>   at 
> org.apache.maven.bridge.MavenRepositorySystem.XcreateDependencyArtifact(MavenRepositorySystem.java:613)
>   at 
> org.apache.maven.bridge.MavenRepositorySystem.createDependencyArtifact(MavenRepositorySystem.java:121)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:808)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> ...
> {code}



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


[jira] [Updated] (MNG-5907) org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails starting at midnight

2015-10-07 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise updated MNG-5907:
-
Description: 
Currently this test fails (it seemed to be the reason having started the build 
at midnight CET):

Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< 
FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest
gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest)
  Time elapsed: 0.011 sec  <<< FAILURE!
java.lang.AssertionError: Expected 20151007 to be in [20151008]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79)

Running org.apache.maven.repository.internal.RepositorySystemTest
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec - in 
org.apache.maven.repository.internal.RepositorySystemTest

I have run maven build several times over the day and had no problems..I have 
to take a deeper look into this...

  was:
Currently this test fails (it seemed to be the reason having started the build 
at midnight CET):

Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< 
FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest
gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest)
  Time elapsed: 0.011 sec  <<< FAILURE!
java.lang.AssertionError: Expected 20151007 to be in [20151008]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79)

Running org.apache.maven.repository.internal.RepositorySystemTest
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec - in 
org.apache.maven.repository.internal.RepositorySystemTest


> org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails 
> starting at midnight
> --
>
> Key: MNG-5907
> URL: https://issues.apache.org/jira/browse/MNG-5907
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.3.7
>Reporter: Karl Heinz Marbaise
>
> Currently this test fails (it seemed to be the reason having started the 
> build at midnight CET):
> Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< 
> FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest
> gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest)
>   Time elapsed: 0.011 sec  <<< FAILURE!
> java.lang.AssertionError: Expected 20151007 to be in [20151008]
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at 
> org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79)
> Running org.apache.maven.repository.internal.RepositorySystemTest
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec - 
> in org.apache.maven.repository.internal.RepositorySystemTest
> I have run maven build several times over the day and had no problems..I have 
> to take a deeper look into this...



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


[jira] [Created] (MNG-5907) org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails starting at midnight

2015-10-07 Thread Karl Heinz Marbaise (JIRA)
Karl Heinz Marbaise created MNG-5907:


 Summary: 
org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails starting 
at midnight
 Key: MNG-5907
 URL: https://issues.apache.org/jira/browse/MNG-5907
 Project: Maven
  Issue Type: Bug
  Components: core
Affects Versions: 3.3.7
Reporter: Karl Heinz Marbaise


Currently this test fails (it seemed to be the reason having started the build 
at midnight CET):

Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< 
FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest
gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest)
  Time elapsed: 0.011 sec  <<< FAILURE!
java.lang.AssertionError: Expected 20151007 to be in [20151008]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79)

Running org.apache.maven.repository.internal.RepositorySystemTest
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec - in 
org.apache.maven.repository.internal.RepositorySystemTest



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


[jira] [Commented] (MNG-5727) unexpected InvalidArtifactRTException from ProjectBuilder#build

2015-10-07 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MNG-5727:
-

Igor, you made the commit but did not close the issue. Why?
Anyway, I ran the test project you attached and it fails. Though it does not 
mention {{dependencyManagement}} but {{dependencies}} only. Is that what you 
intended? I have raised a question to his on the dev mailing list.

> unexpected InvalidArtifactRTException from ProjectBuilder#build
> ---
>
> Key: MNG-5727
> URL: https://issues.apache.org/jira/browse/MNG-5727
> Project: Maven
>  Issue Type: Bug
>Reporter: Igor Fedorenko
>
> Calling into ProjectBuilder#build(File, ProjectBuildingRequest) results in 
> InvalidArtifactRTException below if project pom.xml has managed dependency 
> without . Although the pom is invalid, I expected to get 
> ProjectBuildingException that includes location of problematic dependency, 
> similar to what I get during command line build.
> {code}
> org.apache.maven.artifact.InvalidArtifactRTException: For artifact 
> {org.apache.maven.its:a:null:jar}: The version cannot be empty.
>   at 
> org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:148)
>   at 
> org.apache.maven.artifact.DefaultArtifact.(DefaultArtifact.java:123)
>   at 
> org.apache.maven.bridge.MavenRepositorySystem.XcreateArtifact(MavenRepositorySystem.java:695)
>   at 
> org.apache.maven.bridge.MavenRepositorySystem.XcreateDependencyArtifact(MavenRepositorySystem.java:613)
>   at 
> org.apache.maven.bridge.MavenRepositorySystem.createDependencyArtifact(MavenRepositorySystem.java:121)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:808)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> ...
> {code}



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


[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading

2015-10-07 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MNG-5756:
-

I do understand your point but Maven isn't showing you the JRE home but the VM 
does. It is a mere property.

What one could do in 3.4 is to show:
{noformat}
Java home: .../java8 JRE home: .../java8/jre
{noformat}

> Java home output in mvn -v is misleading
> 
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home", 
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home" 
> property is not JAVA_HOME! This is explained in detail in here: 
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be 
> set as an environment variable and referenced in Windows batch files or Unix 
> scripts. I always have it in my Windows Control Panel and .tcsh files,along 
> with other common environment variables. Some Java applications use the name 
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has 
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program 
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an 
> environment variable. java.home is a build-in Java system property, whose 
> value is the JRE install directory. Since all Java system properties are also 
> exposed as Ant build properties, you can also use ${java.home} in build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change 
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to 
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use 
> System.getenv("JAVA_HOME"). Either that should be used or current output 
> should be changed so it wouldn't be so misleading.



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


[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading

2015-10-07 Thread Jarkko Rantavuori (JIRA)

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

Jarkko Rantavuori commented on MNG-5756:


It does matter, when users constantly confuse it with JAVA_HOME (like I pointed 
out in stackoverflow threads. there are others as well). JAVA_HOME is the thing 
everybody knows and can set directly, so when Maven output is talking about 
"Java home", it is understandable that users get confused. In common language, 
JAVA_HOME is indeed the thing everybody in java world means when talking about 
java home. Furthermore, Maven startup scripts use JAVA_HOME to look up which 
java they use for running Maven, so it is actually the relevant piece of 
information when configuring Maven. I can't imagine a reason why mvn -v output 
would show jre used for running.

> Java home output in mvn -v is misleading
> 
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home", 
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home" 
> property is not JAVA_HOME! This is explained in detail in here: 
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be 
> set as an environment variable and referenced in Windows batch files or Unix 
> scripts. I always have it in my Windows Control Panel and .tcsh files,along 
> with other common environment variables. Some Java applications use the name 
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has 
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program 
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an 
> environment variable. java.home is a build-in Java system property, whose 
> value is the JRE install directory. Since all Java system properties are also 
> exposed as Ant build properties, you can also use ${java.home} in build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change 
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to 
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use 
> System.getenv("JAVA_HOME"). Either that should be used or current output 
> should be changed so it wouldn't be so misleading.



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


[jira] [Updated] (MCHANGELOG-141) Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 version of Maven SCM

2015-10-07 Thread James MacNider (JIRA)

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

James MacNider updated MCHANGELOG-141:
--
Description: 
I've found that the maven-changelog-plugin will fail to generate a tag-based 
changelog.xml file when the SCM is mercurial.  This is actually a bug in the 
1.8 version of the maven-scm-plugin.  

My testing with a custom (built by me) version of maven-changelog-plugin that 
depends on version 1.9.4 of maven-scm-plugin worked fine.


  was:
I've found that the maven-changelog-plugin will fail to generate a tag-based 
changelog.xml file when the SCM is mercurial.  This is actually a bug in the 
1.8 version of the maven-scm-plugin.  

My testing with a custom version of maven-changelog-plugin that depends on 
version 1.9.4 of maven-scm-plugin worked fine.



> Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 
> version of Maven SCM
> 
>
> Key: MCHANGELOG-141
> URL: https://issues.apache.org/jira/browse/MCHANGELOG-141
> Project: Maven Changelog Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: RHEL 6.5, mercurial
>Reporter: James MacNider
> Fix For: 2.4
>
>
> I've found that the maven-changelog-plugin will fail to generate a tag-based 
> changelog.xml file when the SCM is mercurial.  This is actually a bug in the 
> 1.8 version of the maven-scm-plugin.  
> My testing with a custom (built by me) version of maven-changelog-plugin that 
> depends on version 1.9.4 of maven-scm-plugin worked fine.



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


[jira] [Commented] (MCHANGELOG-141) Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 version of Maven SCM

2015-10-07 Thread James MacNider (JIRA)

[ 
https://issues.apache.org/jira/browse/MCHANGELOG-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947496#comment-14947496
 ] 

James MacNider commented on MCHANGELOG-141:
---

This is how I have maven-changelog-plugin configured:

{code:xml}

   org.apache.maven.plugins
   maven-changelog-plugin
   2.3
   
  EEE MMM dd hh:mm:ss  Z
  tag
  
 tip
 1.3.0
 1.2.0
 1.1.0
 1.0.0
  
   
   
  changelog
  dev-activity
  file-activity
   

{code>

> Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 
> version of Maven SCM
> 
>
> Key: MCHANGELOG-141
> URL: https://issues.apache.org/jira/browse/MCHANGELOG-141
> Project: Maven Changelog Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: RHEL 6.5, mercurial
>Reporter: James MacNider
> Fix For: 2.4
>
>
> I've found that the maven-changelog-plugin will fail to generate a tag-based 
> changelog.xml file when the SCM is mercurial.  This is actually a bug in the 
> 1.8 version of the maven-scm-plugin.  
> My testing with a custom version of maven-changelog-plugin that depends on 
> version 1.9.4 of maven-scm-plugin worked fine.



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


[jira] [Comment Edited] (MCHANGELOG-141) Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 version of Maven SCM

2015-10-07 Thread James MacNider (JIRA)

[ 
https://issues.apache.org/jira/browse/MCHANGELOG-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947496#comment-14947496
 ] 

James MacNider edited comment on MCHANGELOG-141 at 10/7/15 8:13 PM:


This is how I have maven-changelog-plugin configured:

{code:xml}

   org.apache.maven.plugins
   maven-changelog-plugin
   2.3
   
  EEE MMM dd hh:mm:ss  Z
  tag
  
 tip
 1.3.0
 1.2.0
 1.1.0
 1.0.0
  
   
   
  changelog
  dev-activity
  file-activity
   

{code}


was (Author: jphorx):
This is how I have maven-changelog-plugin configured:

{code:xml}

   org.apache.maven.plugins
   maven-changelog-plugin
   2.3
   
  EEE MMM dd hh:mm:ss  Z
  tag
  
 tip
 1.3.0
 1.2.0
 1.1.0
 1.0.0
  
   
   
  changelog
  dev-activity
  file-activity
   

{code>

> Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 
> version of Maven SCM
> 
>
> Key: MCHANGELOG-141
> URL: https://issues.apache.org/jira/browse/MCHANGELOG-141
> Project: Maven Changelog Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: RHEL 6.5, mercurial
>Reporter: James MacNider
> Fix For: 2.4
>
>
> I've found that the maven-changelog-plugin will fail to generate a tag-based 
> changelog.xml file when the SCM is mercurial.  This is actually a bug in the 
> 1.8 version of the maven-scm-plugin.  
> My testing with a custom version of maven-changelog-plugin that depends on 
> version 1.9.4 of maven-scm-plugin worked fine.



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


[jira] [Commented] (MCHANGELOG-141) Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 version of Maven SCM

2015-10-07 Thread James MacNider (JIRA)

[ 
https://issues.apache.org/jira/browse/MCHANGELOG-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947492#comment-14947492
 ] 

James MacNider commented on MCHANGELOG-141:
---

These are the failure logs I see with current 2.3 version of 
maven-changelog-plugin:

{noformat}

[DEBUG] Generating /home/bob/components/mycomponent/target/site/changelog.html
[INFO] Generating "Change Log" report   --- 
maven-changelog-plugin:2.3:changelog
[INFO] Generating changed sets xml to: 
/home/bob/components/mycomponent/target/changelog.xml
[INFO] EXECUTING: /bin/sh -c cd /home/bob/components/mycomponent && hg log 
'--template "changeset:   {rev}:{node|short}
branch:  {branch}
user:{author}
date:{date|isodatesec}
tag: {tags}
files:   {files}
description:
{desc}

"' --no-merges -r tip:1.3.0
[WARNING] Could not figure out: hg log: option --template "changeset:   
{rev}:{node|short}
[WARNING] Could not figure out: branch:  {branch}
[WARNING] skip ParseException: Unparseable date: "{date|isodatesec}" during 
parsing date {date|isodatesec} with pattern -MM-dd HH:mm:ss Z with Locale en
java.text.ParseException: Unparseable date: "{date|isodatesec}"
at java.text.DateFormat.parse(DateFormat.java:357)
at 
org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:112)
at 
org.apache.maven.scm.provider.hg.command.changelog.HgChangeLogConsumer.doConsume(HgChangeLogConsumer.java:161)
at 
org.apache.maven.scm.provider.hg.command.changelog.HgChangeLogConsumer.consumeLine(HgChangeLogConsumer.java:92)
at 
org.codehaus.plexus.util.cli.StreamPumper.consumeLine(StreamPumper.java:190)
at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:135)
[ERROR] 
EXECUTION FAILED
  Execution of cmd : log failed with exit code: 255.
  Working directory was: 
/home/bob/components/mycomponent
  Your Hg installation seems to be valid and complete.
Hg version: 2.9 (OK)


[ERROR] Provider message:
[ERROR] 
EXECUTION FAILED
  Execution of cmd : log failed with exit code: 255.
  Working directory was: 
/home/bob/components/mycomponent
  Your Hg installation seems to be valid and complete.
Hg version: 2.9 (OK)


[ERROR] Command output:
[ERROR] 
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 14.444s
[INFO] Finished at: Wed Oct 07 19:44:48 GMT 2015
[INFO] Final Memory: 28M/225M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project 
mycomponent: Error generating maven-changelog-plugin:2.3:changelog: An error 
has occurred during changelog command : Command failed. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project 
mycomponent: Error generating maven-changelog-plugin:2.3:changelog: An error 
has occurred during changelog command : 
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
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:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launc

[jira] [Created] (MCHANGELOG-141) Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 version of Maven SCM

2015-10-07 Thread James MacNider (JIRA)
James MacNider created MCHANGELOG-141:
-

 Summary: Failure to generate changelog.xml with mercurial - need 
to upgrade to 1.9.4 version of Maven SCM
 Key: MCHANGELOG-141
 URL: https://issues.apache.org/jira/browse/MCHANGELOG-141
 Project: Maven Changelog Plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: RHEL 6.5, mercurial
Reporter: James MacNider
 Fix For: 2.4


I've found that the maven-changelog-plugin will fail to generate a tag-based 
changelog.xml file when the SCM is mercurial.  This is actually a bug in the 
1.8 version of the maven-scm-plugin.  

My testing with a custom version of maven-changelog-plugin that depends on 
version 1.9.4 of maven-scm-plugin worked fine.




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


[jira] [Resolved] (MDEP-509) dependency:tree should reveal 'optional'

2015-10-07 Thread Benson Margulies (JIRA)

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

Benson Margulies resolved MDEP-509.
---
   Resolution: Fixed
Fix Version/s: 3.0


r1707376 | bimargulies | 2015-10-07 15:58:29 -0400 (Wed, 07 Oct 2015) | 2 lines

MDEP-509: add optional to the display of the tree when available.

The change is in maven-dependency-tree.


> dependency:tree should reveal 'optional'
> 
>
> Key: MDEP-509
> URL: https://issues.apache.org/jira/browse/MDEP-509
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>Reporter: Benson Margulies
>Assignee: Benson Margulies
> Fix For: 3.0
>
>
> It would be helpful if dependency:tree would reveal the 'optional' status.



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


[jira] [Created] (MNG-5906) Use canonical name for UTC timezone

2015-10-07 Thread Michael Osipov (JIRA)
Michael Osipov created MNG-5906:
---

 Summary: Use canonical name for UTC timezone
 Key: MNG-5906
 URL: https://issues.apache.org/jira/browse/MNG-5906
 Project: Maven
  Issue Type: Improvement
Affects Versions: 3.3.3
Reporter: Michael Osipov
Assignee: Michael Osipov
Priority: Trivial
 Fix For: 3.3.7


Throughout {{UTC}} is used. We shall use the canonical name {{Etc/UTC}}.



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


[jira] [Assigned] (MDEP-509) dependency:tree should reveal 'optional'

2015-10-07 Thread Benson Margulies (JIRA)

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

Benson Margulies reassigned MDEP-509:
-

Assignee: Benson Margulies

> dependency:tree should reveal 'optional'
> 
>
> Key: MDEP-509
> URL: https://issues.apache.org/jira/browse/MDEP-509
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>Reporter: Benson Margulies
>Assignee: Benson Margulies
>
> It would be helpful if dependency:tree would reveal the 'optional' status.



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


[jira] [Created] (MDEP-509) dependency:tree should reveal 'optional'

2015-10-07 Thread Benson Margulies (JIRA)
Benson Margulies created MDEP-509:
-

 Summary: dependency:tree should reveal 'optional'
 Key: MDEP-509
 URL: https://issues.apache.org/jira/browse/MDEP-509
 Project: Maven Dependency Plugin
  Issue Type: New Feature
Reporter: Benson Margulies


It would be helpful if dependency:tree would reveal the 'optional' status.



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


[jira] [Assigned] (MECLIPSE-763) Retire this plugin

2015-10-07 Thread Robert Scholte (JIRA)

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

Robert Scholte reassigned MECLIPSE-763:
---

Assignee: Robert Scholte

> Retire this plugin
> --
>
> Key: MECLIPSE-763
> URL: https://issues.apache.org/jira/browse/MECLIPSE-763
> Project: Maven Eclipse Plugin (RETIRED)
>  Issue Type: Task
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>
> This is the final version of this plugin. It has been retired.
> The maven-eclipse-plugin will be donated to http://www.mojohaus.org



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


[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading

2015-10-07 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MNG-5756:
-

See this reference, a Java app runs always on top of a JRE: 
https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html

I might be confusing but the output is correct. Does it matter for you to the 
the environment variable {{JAVA_HOME}} instead of {{java.home}}?

> Java home output in mvn -v is misleading
> 
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home", 
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home" 
> property is not JAVA_HOME! This is explained in detail in here: 
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be 
> set as an environment variable and referenced in Windows batch files or Unix 
> scripts. I always have it in my Windows Control Panel and .tcsh files,along 
> with other common environment variables. Some Java applications use the name 
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has 
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program 
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an 
> environment variable. java.home is a build-in Java system property, whose 
> value is the JRE install directory. Since all Java system properties are also 
> exposed as Ant build properties, you can also use ${java.home} in build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change 
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to 
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use 
> System.getenv("JAVA_HOME"). Either that should be used or current output 
> should be changed so it wouldn't be so misleading.



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


[jira] [Created] (MECLIPSE-763) Retire this plugin

2015-10-07 Thread Robert Scholte (JIRA)
Robert Scholte created MECLIPSE-763:
---

 Summary: Retire this plugin
 Key: MECLIPSE-763
 URL: https://issues.apache.org/jira/browse/MECLIPSE-763
 Project: Maven Eclipse Plugin
  Issue Type: Task
Reporter: Robert Scholte


This is the final version of this plugin. It has been retired.
The maven-eclipse-plugin will be donated to http://www.mojohaus.org



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


[jira] [Commented] (MSITE-747) Failure during site generation

2015-10-07 Thread Michael Osipov (JIRA)

[ 
https://issues.apache.org/jira/browse/MSITE-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947319#comment-14947319
 ] 

Michael Osipov commented on MSITE-747:
--

What does {{dependency:analyze}} say?

> Failure during site generation
> --
>
> Key: MSITE-747
> URL: https://issues.apache.org/jira/browse/MSITE-747
> Project: Maven Site Plugin
>  Issue Type: Bug
>Affects Versions: 3.4
> Environment: Maven 3.0.5
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
>
> Running with Maven 3.0.5:
> {code}
> maven-ejb-plugin/target/checkout$ mvn -Preporting site:stage
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building Apache Maven EJB Plugin 2.5.1
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-site-plugin:3.4:stage (default-cli) @ maven-ejb-plugin ---
> [INFO] Using this base directory for staging: 
> /Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/
>  - Session: Opened
> [INFO] Pushing 
> /Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/site
> [INFO]>>> to 
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/../../../components/plugins-archives/maven-ejb-plugin-LATEST
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/
>  - Session: Disconnecting
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/
>  - Session: Disconnected
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 1.777s
> [INFO] Finished at: Tue Jun 16 21:54:09 CEST 2015
> [INFO] Final Memory: 13M/214M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.4:stage (default-cli) on project 
> maven-ejb-plugin: Execution default-cli of goal 
> org.apache.maven.plugins:maven-site-plugin:3.4:stage failed: A required class 
> was missing while executing 
> org.apache.maven.plugins:maven-site-plugin:3.4:stage: 
> org/apache/commons/lang/StringUtils
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-site-plugin:3.4
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = 
> file:/Users/kama/.m2/repository/org/apache/maven/plugins/maven-site-plugin/3.4/maven-site-plugin-3.4.jar
> [ERROR] urls[1] = 
> file:/Users/kama/.m2/repository/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.jar
> [ERROR] urls[2] = 
> file:/Users/kama/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.15/plexus-interpolation-1.15.jar
> [ERROR] urls[3] = 
> file:/Users/kama/.m2/repository/org/codehaus/plexus/plexus-archiver/2.4.4/plexus-archiver-2.4.4.jar
> [ERROR] urls[4] = 
> file:/Users/kama/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> [ERROR] urls[5] = 
> file:/Users/kama/.m2/repository/org/codehaus/plexus/plexus-io/2.0.10/plexus-io-2.0.10.jar
> [ERROR] urls[6] = 
> file:/Users/kama/.m2/repository/org/apache/commons/commons-compress/1.5/commons-compress-1.5.jar
> [ERROR] urls[7] = 
> file:/Users/kama/.m2/repository/org/tukaani/xz/1.2/xz-1.2.jar
> [ERROR] urls[8] = 
> file:/Users/kama/.m2/repository/org/apache/maven/reporting/maven-reporting-exec/1.2/maven-reporting-exec-1.2.jar
> [ERROR] urls[9] = 
> file:/Users/kama/.m2/repository/org/apache/maven/reporting/maven-reporting-api/3.0/maven-reporting-api-3.0.jar
> [ERROR] urls[10] = 
> file:/Users/kama/.m2/repository/org/apache/maven/shared/maven-shared-utils/0.3/maven-shared-utils-0.3.jar
> [ERROR] urls[11] = 
> file:/Users/kama/.m2/repository/com/google/code/findbugs/jsr305/2.0.1/jsr305-2.0.1.jar
> [ERROR] urls[12] = 
> file:/Users/kama/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> [ERROR] urls[13] = 
> file:/Users/kama/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
> [ERROR] urls[14] = 
> file:/Users/kama/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> [ERROR] urls[15] = 
> file:/Users/kama/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> [ERROR] urls[16] = 
> file:/Users/kama/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[17] = 
> file:/Users/kama/.m2/repository/org/sonatype/plexu

[jira] [Commented] (MCHECKSTYLE-309) Upgrade SLF4J dependency version

2015-10-07 Thread Michael Osipov (JIRA)

[ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947317#comment-14947317
 ] 

Michael Osipov commented on MCHECKSTYLE-309:


Still waiting for a reply. Try trunk please.

> Upgrade SLF4J dependency version
> 
>
> Key: MCHECKSTYLE-309
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-309
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>Reporter: Konstantin Pokrovsky
>Priority: Minor
>  Labels: close-pending
>
> Checkstyle has dependencies on old SLF4J versions: slf4j-jdk14-1.5.6 and 
> jcl-over-slf4j-1.5.6. Maven 3.3.3 provide SLF4J 1.7.5 in its libs. By default 
> maven use simple provider for slf4j and it is backward compatible to API 
> 1.5.6. But when I change the provier to logback API compatibility breaks:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-checkstyle-plugin:2.16:check (default) on 
> project rt: Execution default of goal 
> org.apache.maven.plugins:maven-checkstyle-plugin:2.16:check failed: An API 
> incompatibility was encountered while executing 
> org.apache.maven.plugins:maven-checkstyle-plugin:2.16:check: 
> java.lang.NoSuchMethodError: 
> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
> [ERROR] -
> [ERROR] realm =
> plugin>org.apache.maven.plugins:maven-checkstyle-plugin:2.16
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = 
> file:/C:/Users/kpokrovsky/.m2/repository/org/apache/maven/plugins/maven-checkstyle-plugin/2.16/maven-checkstyle-plugin-2.16.jar
> [ERROR] urls[1] = 
> file:/C:/Users/kpokrovsky/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
> [ERROR] urls[2] = 
> file:/C:/Users/kpokrovsky/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
> [ERROR] urls[3] = 
> file:/C:/Users/kpokrovsky/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> {noformat}
> Please refer to http://www.slf4j.org/faq.html#compatibility - while API is 
> backward compatible, bindings are not. So checkstyle has to keep its SLF4J 
> versions in sync with maven's SLF4J providers.
> For now problem can be fixed by overriding plugin's dependencies:
> {noformat}
> 
>   org.apache.maven.plugins
>   maven-checkstyle-plugin
>   2.16
>   
> 
>   org.slf4j
>   slf4j-jdk14
>   1.7.5
> 
> 
>   org.slf4j
>   jcl-over-slf4j
>   1.7.5
> 
>   
> 
> {noformat}
> BTW, for some reason the issue does not appear on maven 3.2.3.



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


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

2015-10-07 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MNG-5904:
-

It's about time. We should have done this a long time ago. Let's eat our own 
dog food. If someone says, I need Ant to build Maven then he has a problem. 
Then he would need Ant to build Ant...?!

> 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] [Updated] (MNG-5904) Remove the whole Ant Build

2015-10-07 Thread Michael Osipov (JIRA)

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

Michael Osipov updated MNG-5904:

Environment: (was: 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.)

> 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
>
>




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


[jira] [Assigned] (MRELEASE-549) Pin svn:externals when tagging

2015-10-07 Thread Michael Osipov (JIRA)

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

Michael Osipov reassigned MRELEASE-549:
---

Assignee: Michael Osipov

> Pin svn:externals when tagging
> --
>
> Key: MRELEASE-549
> URL: https://issues.apache.org/jira/browse/MRELEASE-549
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0
>Reporter: Stephen Connolly
>Assignee: Michael Osipov
>
> svn:externals is a property set on directories in a subversion repository.
> there are two classes of svn:externals, ones which specify a revision and 
> ones which do not.
> when creating a tag, the tag should only contain svn:externals which have 
> been pinned to specific revisions, otherwise the tag is not a tag, i.e. it is 
> subject to change.
> A generic solution (i.e. not SVN specific) would be to add preTagGoals and 
> postTagGoals so that a custom goal could be invoked around creating the tag.



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


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

2015-10-07 Thread Michael Osipov (JIRA)

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

Michael Osipov updated MNG-5904:

Description: 
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.

> 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] [Commented] (MRELEASE-549) Pin svn:externals when tagging

2015-10-07 Thread Michael Osipov (JIRA)

[ 
https://issues.apache.org/jira/browse/MRELEASE-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947186#comment-14947186
 ] 

Michael Osipov commented on MRELEASE-549:
-

It shouldn't be to hard to implement. I am overloaded currently and won't get 
to it before next week.

> Pin svn:externals when tagging
> --
>
> Key: MRELEASE-549
> URL: https://issues.apache.org/jira/browse/MRELEASE-549
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0
>Reporter: Stephen Connolly
>
> svn:externals is a property set on directories in a subversion repository.
> there are two classes of svn:externals, ones which specify a revision and 
> ones which do not.
> when creating a tag, the tag should only contain svn:externals which have 
> been pinned to specific revisions, otherwise the tag is not a tag, i.e. it is 
> subject to change.
> A generic solution (i.e. not SVN specific) would be to add preTagGoals and 
> postTagGoals so that a custom goal could be invoked around creating the tag.



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


[jira] [Assigned] (MDEP-506) NPE in AnalyzeDepMgt.getMismatch

2015-10-07 Thread Michael Osipov (JIRA)

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

Michael Osipov reassigned MDEP-506:
---

Assignee: Michael Osipov

> NPE in AnalyzeDepMgt.getMismatch
> 
>
> Key: MDEP-506
> URL: https://issues.apache.org/jira/browse/MDEP-506
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 2.10
> Environment: Apache Maven 3.3.3 
> (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00)
> Java version: 1.8.0_40, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: olivier o
>Assignee: Michael Osipov
>
> The goal analyze-dep-mgt generates an NPE.  Please check the github link 
> below to repoduce this issue: 
> https://github.com/Orange-OpenSource/mdep-506-analyse-dep-mgt
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.getMismatch(AnalyzeDepMgt.java:272)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.checkDependencyManagement(AnalyzeDepMgt.java:175)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.execute(AnalyzeDepMgt.java:102)



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


[jira] [Reopened] (MDEP-508) URL contains illegal character ("[") for google guava artifact from central repo (goal: dependency:go-offline)

2015-10-07 Thread Mark Leone (JIRA)

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

Mark Leone reopened MDEP-508:
-

The warning about a misconfigured plugin appears to have been transient.  The 
failure occurs now when the plugin is present, with no warning about it being 
misconfigured.

> URL contains illegal character ("[") for google guava artifact from central 
> repo (goal: dependency:go-offline)
> --
>
> Key: MDEP-508
> URL: https://issues.apache.org/jira/browse/MDEP-508
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: go-offline, resolve-plugins
>Affects Versions: 2.8
> Environment: CentOS 6.7; Tycho 0.23.0
>Reporter: Mark Leone
> Attachments: sample-build.zip
>
>
> While running the Maven goal dependency:go-offline, the build fails while 
> trying to download google guava artifacts from the central repository. The 
> error message indicates an illegal character in the URL, specifically a "[" 
> character, which comes from the version specifier.
> First I run
> {noformat}mvn -Dmaven.repo.local=/some/path/ -DgeneratePom=true clean 
> install{noformat}
> to create the artifacts, and that build succeeds. Then when I run
> {noformat}mvn -Dmaven.repo.local=/some/path/ -o clean install{noformat}
> it fails because it's running in offline mode and there is no local cache 
> available for http://download.eclipse.org/tools/cdt/releases/8.6
> So then I run
> {noformat}mvn -Dmaven.repo.local=/some/path/ dependency:go-offline{noformat}
> to make it download all the artifacts it needs for the build, but it fails 
> with this message:
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.8:resolve-plugins 
> (resolve-plugins) on project : Nested: Could not transfer artifact 
> com.google.guava:guava:jar:[10.0.1,14.0.1] from/to central 
> (https://repo.maven.apache.org/maven2): Illegal character in path at index 
> 60: 
> https://repo.maven.apache.org/maven2/com/google/guava/guava/[10.0.1,14.0.1]/guava-[10.0.1,14.0.1].jar{noformat}
> The product being built is an Eclipse RCP product, using the 
> org.eclipse.tycho:target-platform-configuration plug-in to load the 
> dependencies from an RCP target file.



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


[jira] [Updated] (MDEP-508) URL contains illegal character ("[") for google guava artifact from central repo (goal: dependency:go-offline)

2015-10-07 Thread Mark Leone (JIRA)

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

Mark Leone updated MDEP-508:

Attachment: sample-build.zip

Here's a sample build to demonstrate the "invalid URL character" error.

Steps to reproduce
1. cd mvn-demo-parent/releng
2. mvn clean install #succeeds
3. mvn clean dependency:go-offline
4. Build fails
5. vim mvn-demo-parent/releng/pom.xml
6. Comment out  element xtend-mvn-plugin beginning at line 94
7. mvn clean dependency:go-offline
8. Build succeeds

Previously I saw an error on the console about this plug-in being misconfigured 
(a property missing, I don't recall which). This is not happening anymore for 
some reason. Also in my actual project, the problem only occurs if I add the 
 element in the pom file for one of the eclipse plug-ins. In this 
sample project, the problem occurs when the  element is placed in the 
parent pom file.

> URL contains illegal character ("[") for google guava artifact from central 
> repo (goal: dependency:go-offline)
> --
>
> Key: MDEP-508
> URL: https://issues.apache.org/jira/browse/MDEP-508
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: go-offline, resolve-plugins
>Affects Versions: 2.8
> Environment: CentOS 6.7; Tycho 0.23.0
>Reporter: Mark Leone
> Attachments: sample-build.zip
>
>
> While running the Maven goal dependency:go-offline, the build fails while 
> trying to download google guava artifacts from the central repository. The 
> error message indicates an illegal character in the URL, specifically a "[" 
> character, which comes from the version specifier.
> First I run
> {noformat}mvn -Dmaven.repo.local=/some/path/ -DgeneratePom=true clean 
> install{noformat}
> to create the artifacts, and that build succeeds. Then when I run
> {noformat}mvn -Dmaven.repo.local=/some/path/ -o clean install{noformat}
> it fails because it's running in offline mode and there is no local cache 
> available for http://download.eclipse.org/tools/cdt/releases/8.6
> So then I run
> {noformat}mvn -Dmaven.repo.local=/some/path/ dependency:go-offline{noformat}
> to make it download all the artifacts it needs for the build, but it fails 
> with this message:
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.8:resolve-plugins 
> (resolve-plugins) on project : Nested: Could not transfer artifact 
> com.google.guava:guava:jar:[10.0.1,14.0.1] from/to central 
> (https://repo.maven.apache.org/maven2): Illegal character in path at index 
> 60: 
> https://repo.maven.apache.org/maven2/com/google/guava/guava/[10.0.1,14.0.1]/guava-[10.0.1,14.0.1].jar{noformat}
> The product being built is an Eclipse RCP product, using the 
> org.eclipse.tycho:target-platform-configuration plug-in to load the 
> dependencies from an RCP target file.



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


[jira] [Updated] (MNG-5756) Java home output in mvn -v is misleading

2015-10-07 Thread Jarkko Rantavuori (JIRA)

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

Jarkko Rantavuori updated MNG-5756:
---
Affects Version/s: 3.3.3

> Java home output in mvn -v is misleading
> 
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home", 
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home" 
> property is not JAVA_HOME! This is explained in detail in here: 
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be 
> set as an environment variable and referenced in Windows batch files or Unix 
> scripts. I always have it in my Windows Control Panel and .tcsh files,along 
> with other common environment variables. Some Java applications use the name 
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has 
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program 
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an 
> environment variable. java.home is a build-in Java system property, whose 
> value is the JRE install directory. Since all Java system properties are also 
> exposed as Ant build properties, you can also use ${java.home} in build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change 
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to 
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use 
> System.getenv("JAVA_HOME"). Either that should be used or current output 
> should be changed so it wouldn't be so misleading.



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


[jira] [Commented] (MRELEASE-549) Pin svn:externals when tagging

2015-10-07 Thread JIRA

[ 
https://issues.apache.org/jira/browse/MRELEASE-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947094#comment-14947094
 ] 

Eduardo Hernández Guerra commented on MRELEASE-549:
---

It was rather a request, but maybe I can look a little bit into it, it should 
not a difficult change.

> Pin svn:externals when tagging
> --
>
> Key: MRELEASE-549
> URL: https://issues.apache.org/jira/browse/MRELEASE-549
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0
>Reporter: Stephen Connolly
>
> svn:externals is a property set on directories in a subversion repository.
> there are two classes of svn:externals, ones which specify a revision and 
> ones which do not.
> when creating a tag, the tag should only contain svn:externals which have 
> been pinned to specific revisions, otherwise the tag is not a tag, i.e. it is 
> subject to change.
> A generic solution (i.e. not SVN specific) would be to add preTagGoals and 
> postTagGoals so that a custom goal could be invoked around creating the tag.



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


[jira] [Commented] (MNG-5905) Maven build does not work with Maven 2.2.1

2015-10-07 Thread Hudson (JIRA)

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

Hudson commented on MNG-5905:
-

SUCCESS: Integrated in maven-3.x #1129 (See 
[https://builds.apache.org/job/maven-3.x/1129/])
[MNG-5905] Maven build does not work with Maven 2.2.1 Added (khmarbaise: rev 
bcacea2cfb9702658914a40a95251f2d8335b3f5)
* pom.xml


> Maven build does not work with Maven 2.2.1
> --
>
> Key: MNG-5905
> URL: https://issues.apache.org/jira/browse/MNG-5905
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.3.7
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.3.7
>
>
> The maven core can not be built with Maven 2.2.1 as the prerequisites stated. 
> We have plugins in the maven-core-build which need Maven 3.0.4 at minimum. 
> This should be forced by using Maven Enforcer Rule.



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


[jira] [Updated] (MNG-5905) Maven build does not work with Maven 2.2.1

2015-10-07 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise updated MNG-5905:
-
Description: The maven core can not be built with Maven 2.2.1 as the 
prerequisites stated. We have plugins in the maven-core-build which need Maven 
3.0.4 at minimum. This should be forced by using Maven Enforcer Ruel  (was: The 
maven core can not be built with Maven 2.2.1 as the prerequisites stated. We 
have plugins in the maven-core-build which need Maven 3.0.4 at minimum. This 
should be forced by using Maven Enforcer.)

> Maven build does not work with Maven 2.2.1
> --
>
> Key: MNG-5905
> URL: https://issues.apache.org/jira/browse/MNG-5905
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.3.7
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.3.7
>
>
> The maven core can not be built with Maven 2.2.1 as the prerequisites stated. 
> We have plugins in the maven-core-build which need Maven 3.0.4 at minimum. 
> This should be forced by using Maven Enforcer Ruel



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


[jira] [Updated] (MNG-5905) Maven build does not work with Maven 2.2.1

2015-10-07 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise updated MNG-5905:
-
Description: The maven core can not be built with Maven 2.2.1 as the 
prerequisites stated. We have plugins in the maven-core-build which need Maven 
3.0.4 at minimum. This should be forced by using Maven Enforcer Rule.  (was: 
The maven core can not be built with Maven 2.2.1 as the prerequisites stated. 
We have plugins in the maven-core-build which need Maven 3.0.4 at minimum. This 
should be forced by using Maven Enforcer Ruel)

> Maven build does not work with Maven 2.2.1
> --
>
> Key: MNG-5905
> URL: https://issues.apache.org/jira/browse/MNG-5905
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.3.7
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.3.7
>
>
> The maven core can not be built with Maven 2.2.1 as the prerequisites stated. 
> We have plugins in the maven-core-build which need Maven 3.0.4 at minimum. 
> This should be forced by using Maven Enforcer Rule.



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


[jira] [Closed] (MNG-5905) Maven build does not work with Maven 2.2.1

2015-10-07 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise closed MNG-5905.

Resolution: Fixed
  Assignee: Karl Heinz Marbaise

Fixed in 
[bcacea2cfb9702658914a40a95251f2d8335b3f5|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=bcacea2cfb9702658914a40a95251f2d8335b3f5]

> Maven build does not work with Maven 2.2.1
> --
>
> Key: MNG-5905
> URL: https://issues.apache.org/jira/browse/MNG-5905
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.3.7
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.3.7
>
>
> The maven core can not be built with Maven 2.2.1 as the prerequisites stated. 
> We have plugins in the maven-core-build which need Maven 3.0.4 at minimum. 
> This should be forced by using Maven Enforcer.



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


[jira] [Updated] (MNG-5905) Maven build does not work with Maven 2.2.1

2015-10-07 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise updated MNG-5905:
-
Description: The maven core can not be built with Maven 2.2.1 as the 
prerequisites stated. We have plugins in the maven-core-build which need Maven 
3.0.4 at minimum. This should be forced by using Maven Enforcer.  (was: The 
maven core can not be built with Maven 2.2.1 as the prerequisites stated. We 
have plugins in the maven-core-build which needed Maven 3.0.4 at minimum. This 
should be forced by using Maven Enforcer.)

> Maven build does not work with Maven 2.2.1
> --
>
> Key: MNG-5905
> URL: https://issues.apache.org/jira/browse/MNG-5905
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.3.7
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.3.7
>
>
> The maven core can not be built with Maven 2.2.1 as the prerequisites stated. 
> We have plugins in the maven-core-build which need Maven 3.0.4 at minimum. 
> This should be forced by using Maven Enforcer.



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


[jira] [Created] (MNG-5905) Maven build does not work with Maven 2.2.1

2015-10-07 Thread Karl Heinz Marbaise (JIRA)
Karl Heinz Marbaise created MNG-5905:


 Summary: Maven build does not work with Maven 2.2.1
 Key: MNG-5905
 URL: https://issues.apache.org/jira/browse/MNG-5905
 Project: Maven
  Issue Type: Improvement
  Components: core
Affects Versions: 3.3.7
Reporter: Karl Heinz Marbaise
Priority: Blocker
 Fix For: 3.3.7


The maven core can not be built with Maven 2.2.1 as the prerequisites stated. 
We have plugins in the maven-core-build which needed Maven 3.0.4 at minimum. 
This should be forced by using Maven Enforcer.



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


[jira] [Comment Edited] (MDEP-506) NPE in AnalyzeDepMgt.getMismatch

2015-10-07 Thread Michael Osipov (JIRA)

[ 
https://issues.apache.org/jira/browse/MDEP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947009#comment-14947009
 ] 

Michael Osipov edited comment on MDEP-506 at 10/7/15 3:21 PM:
--

Great, I will preare a patch and will let you know. After your test, I'll 
commit it.


was (Author: michael-o):
Great, I will preare a patch and will let you know. After you test, I'll commit 
it.

> NPE in AnalyzeDepMgt.getMismatch
> 
>
> Key: MDEP-506
> URL: https://issues.apache.org/jira/browse/MDEP-506
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 2.10
> Environment: Apache Maven 3.3.3 
> (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00)
> Java version: 1.8.0_40, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: olivier o
>
> The goal analyze-dep-mgt generates an NPE.  Please check the github link 
> below to repoduce this issue: 
> https://github.com/Orange-OpenSource/mdep-506-analyse-dep-mgt
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.getMismatch(AnalyzeDepMgt.java:272)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.checkDependencyManagement(AnalyzeDepMgt.java:175)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.execute(AnalyzeDepMgt.java:102)



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


[jira] [Commented] (MDEP-506) NPE in AnalyzeDepMgt.getMismatch

2015-10-07 Thread Michael Osipov (JIRA)

[ 
https://issues.apache.org/jira/browse/MDEP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947009#comment-14947009
 ] 

Michael Osipov commented on MDEP-506:
-

Great, I will preare a patch and will let you know. After you test, I'll commit 
it.

> NPE in AnalyzeDepMgt.getMismatch
> 
>
> Key: MDEP-506
> URL: https://issues.apache.org/jira/browse/MDEP-506
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 2.10
> Environment: Apache Maven 3.3.3 
> (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00)
> Java version: 1.8.0_40, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: olivier o
>
> The goal analyze-dep-mgt generates an NPE.  Please check the github link 
> below to repoduce this issue: 
> https://github.com/Orange-OpenSource/mdep-506-analyse-dep-mgt
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.getMismatch(AnalyzeDepMgt.java:272)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.checkDependencyManagement(AnalyzeDepMgt.java:175)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.execute(AnalyzeDepMgt.java:102)



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


[jira] [Commented] (MNG-5681) Properties on command line with leading or trailing quotes are stripped

2015-10-07 Thread Hudson (JIRA)

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

Hudson commented on MNG-5681:
-

SUCCESS: Integrated in maven-3.x #1128 (See 
[https://builds.apache.org/job/maven-3.x/1128/])
[MNG-5681] Properties on command line with leading or trailing quotes 
(khmarbaise: rev 8a51f9e5121a4cff75fbc7ddaf0b7eea9c9d4e10)
* maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
* 
maven-embedder/src/test/java/org/apache/maven/cli/CLIManagerDocumentationTest.java
* maven-embedder/src/test/java/org/apache/maven/cli/CLIManagerTest.java
* maven-embedder/src/main/java/org/apache/maven/cli/CleanArgument.java
* pom.xml
* maven-embedder/src/test/java/org/apache/maven/cli/CleanArgumentTest.java


> Properties on command line with leading or trailing quotes are stripped
> ---
>
> Key: MNG-5681
> URL: https://issues.apache.org/jira/browse/MNG-5681
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.0.5, 3.1.1, 3.2.1, 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.3.7
>
>
> The current problem is a command line like this:
> {code}
> mvn -Dtest=\"anton\" clean package
> {code}
> The trailing backslash with the quote is stripped away. This is not the 
> problem of Maven itself. This is a known bug (and fixed) in 
> [commons-cli|https://issues.apache.org/jira/browse/CLI-185].
> This should be postponed until commons-cli 1.3 will be released.



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


[jira] [Closed] (MNG-5681) Properties on command line with leading or trailing quotes are stripped

2015-10-07 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise closed MNG-5681.

Resolution: Fixed
  Assignee: Karl Heinz Marbaise

Fixed in 
[8a51f9e5121a4cff75fbc7ddaf0b7eea9c9d4e10|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=8a51f9e5121a4cff75fbc7ddaf0b7eea9c9d4e10]

> Properties on command line with leading or trailing quotes are stripped
> ---
>
> Key: MNG-5681
> URL: https://issues.apache.org/jira/browse/MNG-5681
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.0.5, 3.1.1, 3.2.1, 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.3.7
>
>
> The current problem is a command line like this:
> {code}
> mvn -Dtest=\"anton\" clean package
> {code}
> The trailing backslash with the quote is stripped away. This is not the 
> problem of Maven itself. This is a known bug (and fixed) in 
> [commons-cli|https://issues.apache.org/jira/browse/CLI-185].
> This should be postponed until commons-cli 1.3 will be released.



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


[jira] [Updated] (MNG-5681) Properties on command line with leading or trailing quotes are stripped

2015-10-07 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise updated MNG-5681:
-
Fix Version/s: 3.3.7

> Properties on command line with leading or trailing quotes are stripped
> ---
>
> Key: MNG-5681
> URL: https://issues.apache.org/jira/browse/MNG-5681
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.0.5, 3.1.1, 3.2.1, 3.2.3
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.3.7
>
>
> The current problem is a command line like this:
> {code}
> mvn -Dtest=\"anton\" clean package
> {code}
> The trailing backslash with the quote is stripped away. This is not the 
> problem of Maven itself. This is a known bug (and fixed) in 
> [commons-cli|https://issues.apache.org/jira/browse/CLI-185].
> This should be postponed until commons-cli 1.3 will be released.



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


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

2015-10-07 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise commented on MNG-5904:
--

I see two options to support this scenario. Either we create the functionality 
via Maven (plugins?) itself (I'm thinking about maven-assembly-plugin) or just 
create a simple script which handles this.

> 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
> Environment: 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.
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.4.0
>
>




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


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

2015-10-07 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise updated MNG-5904:
-
Environment: 
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.

  was:
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 useful in it anymore.


> 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
> Environment: 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.
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.4.0
>
>




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


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

2015-10-07 Thread Arnaud HERITIER (JIRA)

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

Arnaud HERITIER commented on MNG-5904:
--

The advantage of the ant build was to define a system property {{M2_HOME}} 
(existing path or not) and then ant took care to bootstrap maven and install 
the distribution into {{M2_HOME}}. 
With another shell using this maven deployed in {{M2_HOME}} I was able to test 
it on various projects without having to manually extract and potentially move 
the archive produce by {{mvn package}}

> 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
> Environment: 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 useful in it anymore.
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.4.0
>
>




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


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

2015-10-07 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise commented on MNG-5904:
--

What about {{mvn clean package}} or {{mvn clean deploy}} ? I never used Ant to 
build Maven...

> 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
> Environment: 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 useful in it anymore.
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.4.0
>
>




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


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

2015-10-07 Thread Arnaud HERITIER (JIRA)

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

Arnaud HERITIER commented on MNG-5904:
--

Not sure  Myself I'm using it to build and deploy in one step a new maven 
core distro locally. Maybe there is another way to build/install/test dev 
versions of maven core ?
(At the end, based on my limited/inexistent contributions, I won't veto this if 
you judge it useful but verify if others dev aren't using it)

> 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
> Environment: 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 useful in it anymore.
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.4.0
>
>




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


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

2015-10-07 Thread Karl Heinz Marbaise (JIRA)

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

Karl Heinz Marbaise updated MNG-5904:
-
Fix Version/s: 3.4.0

> 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
> Environment: 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 useful in it anymore.
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.4.0
>
>




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


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

2015-10-07 Thread Karl Heinz Marbaise (JIRA)
Karl Heinz Marbaise created MNG-5904:


 Summary: 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
 Environment: 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 useful in it anymore.
Reporter: Karl Heinz Marbaise
Priority: Minor






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


[jira] [Commented] (MDEP-506) NPE in AnalyzeDepMgt.getMismatch

2015-10-07 Thread olivier o (JIRA)

[ 
https://issues.apache.org/jira/browse/MDEP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946854#comment-14946854
 ] 

olivier o commented on MDEP-506:


That's fine, deal :-)

> NPE in AnalyzeDepMgt.getMismatch
> 
>
> Key: MDEP-506
> URL: https://issues.apache.org/jira/browse/MDEP-506
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 2.10
> Environment: Apache Maven 3.3.3 
> (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00)
> Java version: 1.8.0_40, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: olivier o
>
> The goal analyze-dep-mgt generates an NPE.  Please check the github link 
> below to repoduce this issue: 
> https://github.com/Orange-OpenSource/mdep-506-analyse-dep-mgt
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.getMismatch(AnalyzeDepMgt.java:272)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.checkDependencyManagement(AnalyzeDepMgt.java:175)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.execute(AnalyzeDepMgt.java:102)



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


[jira] [Commented] (MSITE-747) Failure during site generation

2015-10-07 Thread HT (JIRA)

[ 
https://issues.apache.org/jira/browse/MSITE-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946723#comment-14946723
 ] 

HT commented on MSITE-747:
--

I had this problem and it was solved by following:
http://wiki.apache.org/commons/VfsProblems

Which says:
{noformat}
Some Maven goals like site:stage fail under Ubuntu 14.04 with
A required class was missing while executing
org.apache.maven.plugins:maven-site-plugin:3.4:stage: 
org/apache/commons/lang/StringUtils 
This happens if you use the Ubuntu Maven package which misses the commons-lang 
dependency. You can either unpack a stand-alone Maven archive or use the 
following commands:

cd /usr/share/maven/lib
sudo ln -s ../../java/commons-lang.jar .
{noformat}



> Failure during site generation
> --
>
> Key: MSITE-747
> URL: https://issues.apache.org/jira/browse/MSITE-747
> Project: Maven Site Plugin
>  Issue Type: Bug
>Affects Versions: 3.4
> Environment: Maven 3.0.5
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
>
> Running with Maven 3.0.5:
> {code}
> maven-ejb-plugin/target/checkout$ mvn -Preporting site:stage
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building Apache Maven EJB Plugin 2.5.1
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-site-plugin:3.4:stage (default-cli) @ maven-ejb-plugin ---
> [INFO] Using this base directory for staging: 
> /Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/
>  - Session: Opened
> [INFO] Pushing 
> /Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/site
> [INFO]>>> to 
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/../../../components/plugins-archives/maven-ejb-plugin-LATEST
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/
>  - Session: Disconnecting
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/
>  - Session: Disconnected
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 1.777s
> [INFO] Finished at: Tue Jun 16 21:54:09 CEST 2015
> [INFO] Final Memory: 13M/214M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.4:stage (default-cli) on project 
> maven-ejb-plugin: Execution default-cli of goal 
> org.apache.maven.plugins:maven-site-plugin:3.4:stage failed: A required class 
> was missing while executing 
> org.apache.maven.plugins:maven-site-plugin:3.4:stage: 
> org/apache/commons/lang/StringUtils
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-site-plugin:3.4
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = 
> file:/Users/kama/.m2/repository/org/apache/maven/plugins/maven-site-plugin/3.4/maven-site-plugin-3.4.jar
> [ERROR] urls[1] = 
> file:/Users/kama/.m2/repository/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.jar
> [ERROR] urls[2] = 
> file:/Users/kama/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.15/plexus-interpolation-1.15.jar
> [ERROR] urls[3] = 
> file:/Users/kama/.m2/repository/org/codehaus/plexus/plexus-archiver/2.4.4/plexus-archiver-2.4.4.jar
> [ERROR] urls[4] = 
> file:/Users/kama/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> [ERROR] urls[5] = 
> file:/Users/kama/.m2/repository/org/codehaus/plexus/plexus-io/2.0.10/plexus-io-2.0.10.jar
> [ERROR] urls[6] = 
> file:/Users/kama/.m2/repository/org/apache/commons/commons-compress/1.5/commons-compress-1.5.jar
> [ERROR] urls[7] = 
> file:/Users/kama/.m2/repository/org/tukaani/xz/1.2/xz-1.2.jar
> [ERROR] urls[8] = 
> file:/Users/kama/.m2/repository/org/apache/maven/reporting/maven-reporting-exec/1.2/maven-reporting-exec-1.2.jar
> [ERROR] urls[9] = 
> file:/Users/kama/.m2/repository/org/apache/maven/reporting/maven-reporting-api/3.0/maven-reporting-api-3.0.jar
> [ERROR] urls[10] = 
> file:/Users/kama/.m2/repository/org/apache/maven/shared/maven-shared-utils/0.3/maven-shared-utils-0.3.jar
> [ERROR] urls[11] = 
> file:/Users/kama/.m2/repository/com/google/code/findbugs/jsr305/2.0.1/jsr305-2.0.1.jar
> [ERROR] urls[12] = 
> file:/Users/kama/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> [ERROR] urls[13] = 
> file:/Users/kama/.m2/repository/org/eclipse

[jira] [Comment Edited] (MSITE-747) Failure during site generation

2015-10-07 Thread HT (JIRA)

[ 
https://issues.apache.org/jira/browse/MSITE-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946723#comment-14946723
 ] 

HT edited comment on MSITE-747 at 10/7/15 11:45 AM:


I had this problem and it was solved by following:
http://wiki.apache.org/commons/VfsProblems

Which says:
{noformat}
Some Maven goals like site:stage fail under Ubuntu 14.04 with
A required class was missing while executing
org.apache.maven.plugins:maven-site-plugin:3.4:stage: 
org/apache/commons/lang/StringUtils 
This happens if you use the Ubuntu Maven package which misses the commons-lang 
dependency. 
You can either unpack a stand-alone Maven archive or use the following commands:

cd /usr/share/maven/lib
sudo ln -s ../../java/commons-lang.jar .
{noformat}




was (Author: henriktellander):
I had this problem and it was solved by following:
http://wiki.apache.org/commons/VfsProblems

Which says:
{noformat}
Some Maven goals like site:stage fail under Ubuntu 14.04 with
A required class was missing while executing
org.apache.maven.plugins:maven-site-plugin:3.4:stage: 
org/apache/commons/lang/StringUtils 
This happens if you use the Ubuntu Maven package which misses the commons-lang 
dependency. You can either unpack a stand-alone Maven archive or use the 
following commands:

cd /usr/share/maven/lib
sudo ln -s ../../java/commons-lang.jar .
{noformat}



> Failure during site generation
> --
>
> Key: MSITE-747
> URL: https://issues.apache.org/jira/browse/MSITE-747
> Project: Maven Site Plugin
>  Issue Type: Bug
>Affects Versions: 3.4
> Environment: Maven 3.0.5
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
>
> Running with Maven 3.0.5:
> {code}
> maven-ejb-plugin/target/checkout$ mvn -Preporting site:stage
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building Apache Maven EJB Plugin 2.5.1
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-site-plugin:3.4:stage (default-cli) @ maven-ejb-plugin ---
> [INFO] Using this base directory for staging: 
> /Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/
>  - Session: Opened
> [INFO] Pushing 
> /Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/site
> [INFO]>>> to 
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/../../../components/plugins-archives/maven-ejb-plugin-LATEST
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/
>  - Session: Disconnecting
> file:///Users/kama/apache-maven/maven-plugins/maven-ejb-plugin/target/checkout/target/staging/
>  - Session: Disconnected
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 1.777s
> [INFO] Finished at: Tue Jun 16 21:54:09 CEST 2015
> [INFO] Final Memory: 13M/214M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.4:stage (default-cli) on project 
> maven-ejb-plugin: Execution default-cli of goal 
> org.apache.maven.plugins:maven-site-plugin:3.4:stage failed: A required class 
> was missing while executing 
> org.apache.maven.plugins:maven-site-plugin:3.4:stage: 
> org/apache/commons/lang/StringUtils
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-site-plugin:3.4
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = 
> file:/Users/kama/.m2/repository/org/apache/maven/plugins/maven-site-plugin/3.4/maven-site-plugin-3.4.jar
> [ERROR] urls[1] = 
> file:/Users/kama/.m2/repository/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.jar
> [ERROR] urls[2] = 
> file:/Users/kama/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.15/plexus-interpolation-1.15.jar
> [ERROR] urls[3] = 
> file:/Users/kama/.m2/repository/org/codehaus/plexus/plexus-archiver/2.4.4/plexus-archiver-2.4.4.jar
> [ERROR] urls[4] = 
> file:/Users/kama/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> [ERROR] urls[5] = 
> file:/Users/kama/.m2/repository/org/codehaus/plexus/plexus-io/2.0.10/plexus-io-2.0.10.jar
> [ERROR] urls[6] = 
> file:/Users/kama/.m2/repository/org/apache/commons/commons-compress/1.5/commons-compress-1.5.jar
> [ERROR] urls[7] = 
> file:/Users/kama/.m2/repository/org/tukaani/xz/1.2/xz-1.2.jar
> [ERROR] urls[8] = 
> f

[jira] [Comment Edited] (MDEP-506) NPE in AnalyzeDepMgt.getMismatch

2015-10-07 Thread Michael Osipov (JIRA)

[ 
https://issues.apache.org/jira/browse/MDEP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946644#comment-14946644
 ] 

Michael Osipov edited comment on MDEP-506 at 10/7/15 10:34 AM:
---

The problem here is simple: missing version. {{dependencyConvergence}} won't 
help because it resolves the tree first. You need a static analysis on the dep 
mngt section. That requires a custom rule. Should be doable.

I fully agree that a NPE is not helpful and requires some context. If we take a 
look at the description of this goal, we can do better:

bq. analyzes your projects dependencies and lists mismatches between resolved 
dependencies and those listed in your dependencyManagement section.

In this case, your dep from depmngt has no version and the resolved one has a 
version, of course. This is a misatch and should be logged.

What do you think?


was (Author: michael-o):
The problem here is simple. Missing version. {{dependencyConvergence}} won't 
help because it resolves the tree first. You need a static analysis on the dep 
mngt section. That requires a custom rule. Should be doable.

I fully agree that an NPE is not helpful and requires some context. If we take 
a look at the description of this goal, we can do better:

bq. analyzes your projects dependencies and lists mismatches between resolved 
dependencies and those listed in your dependencyManagement section.

In this case, your dep from depmngt has no version and the resolved one has a 
version, of course. This is a misatch and should be logged.

What do you think?

> NPE in AnalyzeDepMgt.getMismatch
> 
>
> Key: MDEP-506
> URL: https://issues.apache.org/jira/browse/MDEP-506
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 2.10
> Environment: Apache Maven 3.3.3 
> (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00)
> Java version: 1.8.0_40, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: olivier o
>
> The goal analyze-dep-mgt generates an NPE.  Please check the github link 
> below to repoduce this issue: 
> https://github.com/Orange-OpenSource/mdep-506-analyse-dep-mgt
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.getMismatch(AnalyzeDepMgt.java:272)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.checkDependencyManagement(AnalyzeDepMgt.java:175)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.execute(AnalyzeDepMgt.java:102)



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


[jira] [Commented] (MDEP-506) NPE in AnalyzeDepMgt.getMismatch

2015-10-07 Thread Michael Osipov (JIRA)

[ 
https://issues.apache.org/jira/browse/MDEP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946644#comment-14946644
 ] 

Michael Osipov commented on MDEP-506:
-

The problem here is simple. Missing version. {{dependencyConvergence}} won't 
help because it resolves the tree first. You need a static analysis on the dep 
mngt section. That requires a custom rule. Should be doable.

I fully agree that an NPE is not helpful and requires some context. If we take 
a look at the description of this goal, we can do better:

bq. analyzes your projects dependencies and lists mismatches between resolved 
dependencies and those listed in your dependencyManagement section.

In this case, your dep from depmngt has no version and the resolved one has a 
version, of course. This is a misatch and should be logged.

What do you think?

> NPE in AnalyzeDepMgt.getMismatch
> 
>
> Key: MDEP-506
> URL: https://issues.apache.org/jira/browse/MDEP-506
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 2.10
> Environment: Apache Maven 3.3.3 
> (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00)
> Java version: 1.8.0_40, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: olivier o
>
> The goal analyze-dep-mgt generates an NPE.  Please check the github link 
> below to repoduce this issue: 
> https://github.com/Orange-OpenSource/mdep-506-analyse-dep-mgt
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.getMismatch(AnalyzeDepMgt.java:272)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.checkDependencyManagement(AnalyzeDepMgt.java:175)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.execute(AnalyzeDepMgt.java:102)



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


[jira] [Commented] (MRELEASE-549) Pin svn:externals when tagging

2015-10-07 Thread Michael Osipov (JIRA)

[ 
https://issues.apache.org/jira/browse/MRELEASE-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946633#comment-14946633
 ] 

Michael Osipov commented on MRELEASE-549:
-

That's exactly what I had in mind. Are you able to provide a patch for that?

> Pin svn:externals when tagging
> --
>
> Key: MRELEASE-549
> URL: https://issues.apache.org/jira/browse/MRELEASE-549
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0
>Reporter: Stephen Connolly
>
> svn:externals is a property set on directories in a subversion repository.
> there are two classes of svn:externals, ones which specify a revision and 
> ones which do not.
> when creating a tag, the tag should only contain svn:externals which have 
> been pinned to specific revisions, otherwise the tag is not a tag, i.e. it is 
> subject to change.
> A generic solution (i.e. not SVN specific) would be to add preTagGoals and 
> postTagGoals so that a custom goal could be invoked around creating the tag.



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


[jira] [Comment Edited] (MSITE-750) site plugin 3.4 doesn't override correctly parent distributionManagement site url with another one defined in child project

2015-10-07 Thread Marat Saitov (JIRA)

[ 
https://issues.apache.org/jira/browse/MSITE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945030#comment-14945030
 ] 

Marat Saitov edited comment on MSITE-750 at 10/7/15 10:20 AM:
--

Example attached.

1) mysite-parent
mvn clean install site-deploy

2) mysite-child
mvn clean install site-deploy

{code}
[INFO] --- maven-site-plugin:3.4:deploy (default-deploy) @ mysite-child ---
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Opened  
[INFO] Pushing Q:\devs\mysite-child\target\site
[INFO]>>> to 
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/../../../../../../../nexus2.mysite.net:123/nexus/content/sites/site/mysite-child/2.0.0
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Disconnecting  
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Disconnected
{code}

Look and click to the relative path calculation
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/../../../../../../../nexus2.mysite.net:123/nexus/content/sites/site/mysite-child/2.0.0

It results into the 
https://nexus1.mysite.net:123/nexus2.mysite.net:123/nexus/content/sites/site/mysite-child/2.0.0


was (Author: mtsv):
Example attached.

1) mysite-parent
mvn clean install site-deploy

2) mysite-child
mvn clean install site-deploy

{code}
[INFO] --- maven-site-plugin:3.4:deploy (default-deploy) @ mysite-child ---
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Opened  
[INFO] Pushing Q:\devs\mysite-child\target\site
[INFO]>>> to 
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/../../../../../../../nexus2.mysite.net:123/nexus/content/sites/site/mysite-child/2.0.0
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Disconnecting  
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Disconnected
{code}

Look at relative path calculation
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/../../../../../../../nexus2.mysite.net:123/nexus/content/sites/site/mysite-child/2.0.0


> site plugin 3.4 doesn't override correctly parent distributionManagement site 
> url with another one defined in child project
> ---
>
> Key: MSITE-750
> URL: https://issues.apache.org/jira/browse/MSITE-750
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Affects Versions: 3.4
> Environment: maven 3.2.1, 3.2.3, 3.3.3, windows 7 professional
>Reporter: Marat Saitov
> Attachments: maven-site-plugin-example.zip
>
>
> site plugin 3.4 doesn't override correctly parent distributionManagement site 
> url (absolute url) with different absolute url defined in child project.
> parent project
> {code:xml}
>   com.mysite
>   mysite-parent
>   1.0.0
>   pom
>   
>   
> mysite-nexus1-repositories
>   
> dav:https://nexus1.mysite.net:123/nexus/content/sites/site/${project.artifactId}/${project.version}/
>   
>   
>   
>   ${siteDistribution.nexusId}
>   ${siteDistribution.nexusUrl}
>   
>   
> {code}
> child project
> {code:xml}
>   
>   com.mysite
>   mysite-parent
>   1.0.0
>   
>   mysite-child
>   2.0.0
>   content-package
>   
>   
> mysite-nexus2-repositories
>   
> dav:https://nexus2.mysite.net:123/nexus/content/sites/site/${project.artifactId}/${project.version}/
>   
>   
>   
>   ${siteDistribution.nexusId2}
>   ${siteDistribution.nexusUrl2}
>   
>   
> {code}
> The error is that in case if we defined another absolute path in the 
> "distributionManagement.site.url" with different domain in the CHILD project 
> the maven site plugin tries to generate a relative path to the url defined in 
> the "distributionManagement.site.url" in the PARENTproject.
> But I expected that the absolute url defined in the  
> "distributionManagement.site.url" in the CHILD project just will be used by 
> maven-site-plugin without transformation like this
> {code}
> [INFO] --- maven-site-plugin:3.4:deploy (default-deploy) @ mysite-child ---
> https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
> Session: Opened  
> [INFO] Pushing C:\devs\mysite-child\target\site
> [INFO]>>> to 
> https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/../../../../../../../nexus2.mysite.net:123/nexus/content/sites/sit

[jira] [Commented] (MSITE-750) site plugin 3.4 doesn't override correctly parent distributionManagement site url with another one defined in child project

2015-10-07 Thread Marat Saitov (JIRA)

[ 
https://issues.apache.org/jira/browse/MSITE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946632#comment-14946632
 ] 

Marat Saitov commented on MSITE-750:


ok, thanks.

> site plugin 3.4 doesn't override correctly parent distributionManagement site 
> url with another one defined in child project
> ---
>
> Key: MSITE-750
> URL: https://issues.apache.org/jira/browse/MSITE-750
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Affects Versions: 3.4
> Environment: maven 3.2.1, 3.2.3, 3.3.3, windows 7 professional
>Reporter: Marat Saitov
> Attachments: maven-site-plugin-example.zip
>
>
> site plugin 3.4 doesn't override correctly parent distributionManagement site 
> url (absolute url) with different absolute url defined in child project.
> parent project
> {code:xml}
>   com.mysite
>   mysite-parent
>   1.0.0
>   pom
>   
>   
> mysite-nexus1-repositories
>   
> dav:https://nexus1.mysite.net:123/nexus/content/sites/site/${project.artifactId}/${project.version}/
>   
>   
>   
>   ${siteDistribution.nexusId}
>   ${siteDistribution.nexusUrl}
>   
>   
> {code}
> child project
> {code:xml}
>   
>   com.mysite
>   mysite-parent
>   1.0.0
>   
>   mysite-child
>   2.0.0
>   content-package
>   
>   
> mysite-nexus2-repositories
>   
> dav:https://nexus2.mysite.net:123/nexus/content/sites/site/${project.artifactId}/${project.version}/
>   
>   
>   
>   ${siteDistribution.nexusId2}
>   ${siteDistribution.nexusUrl2}
>   
>   
> {code}
> The error is that in case if we defined another absolute path in the 
> "distributionManagement.site.url" with different domain in the CHILD project 
> the maven site plugin tries to generate a relative path to the url defined in 
> the "distributionManagement.site.url" in the PARENTproject.
> But I expected that the absolute url defined in the  
> "distributionManagement.site.url" in the CHILD project just will be used by 
> maven-site-plugin without transformation like this
> {code}
> [INFO] --- maven-site-plugin:3.4:deploy (default-deploy) @ mysite-child ---
> https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
> Session: Opened  
> [INFO] Pushing C:\devs\mysite-child\target\site
> [INFO]>>> to 
> https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/../../../../../../../nexus2.mysite.net:123/nexus/content/sites/site/mysite-child/2.0.0
> {code}



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


[jira] [Comment Edited] (MSITE-750) site plugin 3.4 doesn't override correctly parent distributionManagement site url with another one defined in child project

2015-10-07 Thread Marat Saitov (JIRA)

[ 
https://issues.apache.org/jira/browse/MSITE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945030#comment-14945030
 ] 

Marat Saitov edited comment on MSITE-750 at 10/7/15 10:18 AM:
--

Example attached.

1) mysite-parent
mvn clean install site-deploy

2) mysite-child
mvn clean install site-deploy

{code}
[INFO] --- maven-site-plugin:3.4:deploy (default-deploy) @ mysite-child ---
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Opened  
[INFO] Pushing Q:\devs\mysite-child\target\site
[INFO]>>> to 
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/../../../../../../../nexus2.mysite.net:123/nexus/content/sites/site/mysite-child/2.0.0
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Disconnecting  
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Disconnected
{code}

Look at relative path calculation
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/../../../../../../../nexus2.mysite.net:123/nexus/content/sites/site/mysite-child/2.0.0



was (Author: mtsv):
Example attached.

1) mysite-parent
mvn clean install site-deploy

2) mysite-child
mvn clean install site-deploy

{code}
[INFO] --- maven-site-plugin:3.4:deploy (default-deploy) @ mysite-child ---
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Opened  
[INFO] Pushing 
Q:\gp\aems2\platform\stage2-parent\mysite-parent\mysite-child\target\site
[INFO]>>> to 
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/../../../../../../../nexus2.mysite.net:123/nexus/content/sites/site/mysite-child/2.0.0
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Disconnecting  
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
Session: Disconnected
{code}

Look at relative path calculation
https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/../../../../../../../nexus2.mysite.net:123/nexus/content/sites/site/mysite-child/2.0.0


> site plugin 3.4 doesn't override correctly parent distributionManagement site 
> url with another one defined in child project
> ---
>
> Key: MSITE-750
> URL: https://issues.apache.org/jira/browse/MSITE-750
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Affects Versions: 3.4
> Environment: maven 3.2.1, 3.2.3, 3.3.3, windows 7 professional
>Reporter: Marat Saitov
> Attachments: maven-site-plugin-example.zip
>
>
> site plugin 3.4 doesn't override correctly parent distributionManagement site 
> url (absolute url) with different absolute url defined in child project.
> parent project
> {code:xml}
>   com.mysite
>   mysite-parent
>   1.0.0
>   pom
>   
>   
> mysite-nexus1-repositories
>   
> dav:https://nexus1.mysite.net:123/nexus/content/sites/site/${project.artifactId}/${project.version}/
>   
>   
>   
>   ${siteDistribution.nexusId}
>   ${siteDistribution.nexusUrl}
>   
>   
> {code}
> child project
> {code:xml}
>   
>   com.mysite
>   mysite-parent
>   1.0.0
>   
>   mysite-child
>   2.0.0
>   content-package
>   
>   
> mysite-nexus2-repositories
>   
> dav:https://nexus2.mysite.net:123/nexus/content/sites/site/${project.artifactId}/${project.version}/
>   
>   
>   
>   ${siteDistribution.nexusId2}
>   ${siteDistribution.nexusUrl2}
>   
>   
> {code}
> The error is that in case if we defined another absolute path in the 
> "distributionManagement.site.url" with different domain in the CHILD project 
> the maven site plugin tries to generate a relative path to the url defined in 
> the "distributionManagement.site.url" in the PARENTproject.
> But I expected that the absolute url defined in the  
> "distributionManagement.site.url" in the CHILD project just will be used by 
> maven-site-plugin without transformation like this
> {code}
> [INFO] --- maven-site-plugin:3.4:deploy (default-deploy) @ mysite-child ---
> https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/ - 
> Session: Opened  
> [INFO] Pushing C:\devs\mysite-child\target\site
> [INFO]>>> to 
> https://nexus1.mysite.net:123/nexus/content/sites/site/mysite-parent/1.0.0/../../../../../../../nexus2.mysite.net:123/nexus/content/sites/site/mysite-child/2.0.0
> {code}



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

[jira] [Resolved] (MCHECKSTYLE-311) "mvn clean site -Preporting" fails with Could not find resource 'config/maven_checks.xml'

2015-10-07 Thread Michael Osipov (JIRA)

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

Michael Osipov resolved MCHECKSTYLE-311.

Resolution: Fixed

Fixed with [r1707214|http://svn.apache.org/r1707214].

> "mvn clean site -Preporting" fails with Could not find resource 
> 'config/maven_checks.xml'
> -
>
> Key: MCHECKSTYLE-311
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-311
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>Affects Versions: 2.16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 2.17
>
>
> Here is the output:
> {noformat}
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 06:20 min
> [INFO] Finished at: 2015-09-30T22:20:30+02:00
> [INFO] Final Memory: 47M/159M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project 
> maven-checkstyle-plugin: Error generating 
> maven-checkstyle-plugin:2.17-SNAPSHOT:checkstyle: Failed during checkstyle 
> execution: Unable to find configuration file at location: 
> config/maven_checks.xml: Could not find resource 'config/maven_checks.xml'. 
> -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> {noformat}
> The reason is that {{maven_checks.xml}} has been moved to [Maven Shared 
> Resources|https://maven.apache.org/shared/maven-shared-resources/] but this 
> plugin has not been changed.



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


[jira] [Commented] (MRELEASE-549) Pin svn:externals when tagging

2015-10-07 Thread JIRA

[ 
https://issues.apache.org/jira/browse/MRELEASE-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946584#comment-14946584
 ] 

Eduardo Hernández Guerra commented on MRELEASE-549:
---

Well I can confirm that using SVN client 1.9.2 and SVN server 1.8.5, the new 
"--pin-externals" parameter to "svn copy" works correctly using the command 
line. It pegs the revision of all the externals the revision at the time of the 
tagging.

I think that a "pinExternals" boolean parameter for release:prepare (that would 
only work if SVN version > 1.9) would be great to integrate this in Maven.

> Pin svn:externals when tagging
> --
>
> Key: MRELEASE-549
> URL: https://issues.apache.org/jira/browse/MRELEASE-549
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.0
>Reporter: Stephen Connolly
>
> svn:externals is a property set on directories in a subversion repository.
> there are two classes of svn:externals, ones which specify a revision and 
> ones which do not.
> when creating a tag, the tag should only contain svn:externals which have 
> been pinned to specific revisions, otherwise the tag is not a tag, i.e. it is 
> subject to change.
> A generic solution (i.e. not SVN specific) would be to add preTagGoals and 
> postTagGoals so that a custom goal could be invoked around creating the tag.



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


[jira] [Commented] (MDEP-506) NPE in AnalyzeDepMgt.getMismatch

2015-10-07 Thread olivier o (JIRA)

[ 
https://issues.apache.org/jira/browse/MDEP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946574#comment-14946574
 ] 

olivier o commented on MDEP-506:


As the API is not clear, I agree to don't fix the symptom. But I think it's not 
that easy to identify the cause with a complex pom. Enforcer plugin is an 
option, but you have know the issue before being able to write a custom rule. 
Enabling Enforcer with dependencyConvergence check runs fine. Anyway  failling 
with a NPE without context is not very helpful. I would expect this goal to 
fail with a descriptive error message. What do you think about improving the 
error message ?

> NPE in AnalyzeDepMgt.getMismatch
> 
>
> Key: MDEP-506
> URL: https://issues.apache.org/jira/browse/MDEP-506
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 2.10
> Environment: Apache Maven 3.3.3 
> (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00)
> Java version: 1.8.0_40, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: olivier o
>
> The goal analyze-dep-mgt generates an NPE.  Please check the github link 
> below to repoduce this issue: 
> https://github.com/Orange-OpenSource/mdep-506-analyse-dep-mgt
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.getMismatch(AnalyzeDepMgt.java:272)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.checkDependencyManagement(AnalyzeDepMgt.java:175)
>   at 
> org.apache.maven.plugin.dependency.analyze.AnalyzeDepMgt.execute(AnalyzeDepMgt.java:102)



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


[jira] [Resolved] (MCHECKSTYLE-313) Upgrade to Checkstyle 6.11.2

2015-10-07 Thread Michael Osipov (JIRA)

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

Michael Osipov resolved MCHECKSTYLE-313.

Resolution: Fixed

Fixed with [r1707208|http://svn.apache.org/r1707208].

> Upgrade to Checkstyle 6.11.2
> 
>
> Key: MCHECKSTYLE-313
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-313
> Project: Maven Checkstyle Plugin
>  Issue Type: Task
>Affects Versions: 2.17
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 2.17
>
>
> [New 
> version|https://github.com/checkstyle/checkstyle/issues?q=milestone%3A6.11.2] 
> is out. Let's upgrade.



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


[jira] [Created] (MCHECKSTYLE-313) Upgrade to Checkstyle 6.11.2

2015-10-07 Thread Michael Osipov (JIRA)
Michael Osipov created MCHECKSTYLE-313:
--

 Summary: Upgrade to Checkstyle 6.11.2
 Key: MCHECKSTYLE-313
 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-313
 Project: Maven Checkstyle Plugin
  Issue Type: Task
Affects Versions: 2.17
Reporter: Michael Osipov
Assignee: Michael Osipov
Priority: Minor
 Fix For: 2.17


[New 
version|https://github.com/checkstyle/checkstyle/issues?q=milestone%3A6.11.2] 
is out. Let's upgrade.



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


[jira] [Commented] (MNG-5903) Option in profiles to exclude modules from reactor

2015-10-07 Thread Michael Osipov (JIRA)

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

Michael Osipov commented on MNG-5903:
-

This would be clearly a breaking change because too many tools read out the 
{{}} element. I make this the other way around. I have enabled the 
module explicitly.

> Option in profiles to exclude modules from reactor
> --
>
> Key: MNG-5903
> URL: https://issues.apache.org/jira/browse/MNG-5903
> Project: Maven
>  Issue Type: New Feature
>Reporter: Arend v. Reinersdorff
>
> Sometimes it is useful to exclude modules from a reactor build.
> One reason for this can be: Don't generate Javadoc for a testing module.
> Since Maven 3.2.1 it is possible to exclude modules with command line 
> options, eg. mvn -pl !integration-tests
> See MNG-5230 "Command line option to exclude modules from reactor". In this 
> ticket enabling module exclusion for profiles was discussed, but apparently 
> not implemented.
> I'm currently using the -pl command line option on our build server to 
> exclude two projects of a multi module build from Javadoc generation. But I 
> would much prefer to keep this logic in the pom.xml. Something like this:
> 
> javadoc
> 
> !integration-tests
> 
> 



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


[jira] [Comment Edited] (MRELEASE-782) Properties defined in a child pom hide all the properties defined in the parent pom while performing release:prepare

2015-10-07 Thread Patric Schenke (JIRA)

[ 
https://issues.apache.org/jira/browse/MRELEASE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14907729#comment-14907729
 ] 

Patric Schenke edited comment on MRELEASE-782 at 10/7/15 7:07 AM:
--

I have ran into this issue and did some pinpointing. Please update the 
coordinates:

Component: update-versions
Affected Version: 2.2.2

Version 2.2.1 is not affected by this problem, so my guess is that the fix for 
MRELEASE-412 caused this. However, since the connection to a plugin-section 
being present has been made, it could also have been MRELEASE-467.

Edit (07/Oct/15): Further investigation showed that the issue starts appearing 
in "update-versions" from 2.2.1, but in "prepare" already since 2.0-beta-8. I 
could not test earlier versions since I am on a git repository.


was (Author: booiiing):
I have ran into this issue and did some pinpointing. Please update the 
coordinates:

Component: update-versions
Affected Version: 2.2.2

Version 2.2.1 is not affected by this problem, so my guess is that the fix for 
MRELEASE-412 caused this. However, since the connection to a plugin-section 
being present has been made, it could also have been MRELEASE-467.

> Properties defined in a child pom hide all the properties defined in the 
> parent pom while performing release:prepare
> 
>
> Key: MRELEASE-782
> URL: https://issues.apache.org/jira/browse/MRELEASE-782
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.3.2
> Environment: Any
>Reporter: Marius Dumitru Florea
>
> Suppose you have this two poms:
> {code:title=Parent POM}
> ...
> 
>   1.6
> 
> ...
> {code}
> {code:title=Child POM}
> ...
> 
> ...
> 
>   ...
>   
> 
>   ...
>   ${my.version}
> 
>   
> 
> ...
> {code}
> Running release:prepare on this works just fine. Now, if we add a 
> {{properties}} section with any property to the child pom we get:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on 
> project XYZ: The version could not be updated: ${my.version} -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare 
> (default-cli) on project XYZ: The version could not be updated: ${my.version}
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
>   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:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>   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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoFailureException: The version could 
> not be updated: ${commons.version}
>   at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:299)
>   at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   ... 19 more
> Caused by: org.apache.maven.shared