date:20151217

[jira] [Commented] (MJARSIGNER-17) The plugin should pass proxy information to the jarsigner command.

2015-12-17 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/MJARSIGNER-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062266#comment-15062266
 ] 

Hudson commented on MJARSIGNER-17:
--

SUCCESS: Integrated in maven-plugins #4889 (See 
[https://builds.apache.org/job/maven-plugins/4889/])
[MJARSIGNER-17] The plugin should pass proxy information to the jarsigner 
command.

o Updated to pass the active proxy from the Maven settings to 'jarsigner'.
o Updated to pass the 'file.encoding' the plugin is executed with to 
'jarsigner'. (schulte: [http://svn.apache.org/viewvc/?view=rev=1720607])
* maven-jarsigner-plugin/pom.xml
* 
maven-jarsigner-plugin/src/main/java/org/apache/maven/plugins/jarsigner/AbstractJarsignerMojo.java


> The plugin should pass proxy information to the jarsigner command.
> --
>
> Key: MJARSIGNER-17
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-17
> Project: Maven Jar Signer Plugin
>  Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Attachments: MJARSIGNER-17.patch
>
>
> Since 'jarsigner' may need to access network resources, the plugin should 
> pass proxy information to the command.



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

[jira] [Resolved] (MJARSIGNER-17) The plugin should pass proxy information to the jarsigner command.

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte resolved MJARSIGNER-17.
-
Resolution: Fixed

> The plugin should pass proxy information to the jarsigner command.
> --
>
> Key: MJARSIGNER-17
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-17
> Project: Maven Jar Signer Plugin
>  Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Attachments: MJARSIGNER-17.patch
>
>
> Since 'jarsigner' may need to access network resources, the plugin should 
> pass proxy information to the command.



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

[jira] [Assigned] (MJARSIGNER-17) The plugin should pass proxy information to the jarsigner command.

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte reassigned MJARSIGNER-17:
---

Assignee: Christian Schulte

> The plugin should pass proxy information to the jarsigner command.
> --
>
> Key: MJARSIGNER-17
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-17
> Project: Maven Jar Signer Plugin
>  Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Attachments: MJARSIGNER-17.patch
>
>
> Since 'jarsigner' may need to access network resources, the plugin should 
> pass proxy information to the command.



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

[jira] [Commented] (MJAVADOC-431) allow javadoc jar to contain Maven descriptor

2015-12-17 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MJAVADOC-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062488#comment-15062488
 ] 

ASF GitHub Bot commented on MJAVADOC-431:
-

Github user peterlynch closed the pull request at:

https://github.com/apache/maven-plugins/pull/70


> allow javadoc jar to contain Maven descriptor
> -
>
> Key: MJAVADOC-431
> URL: https://issues.apache.org/jira/browse/MJAVADOC-431
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.10.3
>Reporter: Peter lynch
>Assignee: Michael Osipov
> Fix For: 2.10.4
>
>
> The javadoc:jar mojo explicitly prevents the Maven descriptor from being 
> added to the produced javadoc.jar file.
> https://github.com/apache/maven-plugins/blob/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/JavadocJar.java#L299-299
> I could not find an explanation or technical reason why this is done.
> Adding the maven descriptor to the javadoc jar can help expose valuable 
> information about the build that produced it and should be at the discretion 
> of the build process.
> Expected:
> - allow the archiver used to create the javadoc jar to respect the plexus 
> archiver configuration if it is configured to include the Maven descriptor.
> - preserve the default behaviour of not including the Maven descriptor, for 
> (unknown) backwards compatibility reasons only



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

[jira] [Commented] (MJAVADOC-431) allow javadoc jar to contain Maven descriptor

2015-12-17 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MJAVADOC-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062483#comment-15062483
 ] 

ASF GitHub Bot commented on MJAVADOC-431:
-

GitHub user peterlynch opened a pull request:

https://github.com/apache/maven-plugins/pull/73

MJAVADOC-431 allow maven descriptor to javadoc jar

replaces #70 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sonatype/maven-plugins 
MJAVADOC-431-maven-descriptor-3

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/73.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #73


commit fe06afdbb22172e3129e0e7f9e21935100943b50
Author: Peter Lynch 
Date:   2015-12-17T18:07:13Z

MJAVADOC-431 allow maven descriptor to javadoc jar




> allow javadoc jar to contain Maven descriptor
> -
>
> Key: MJAVADOC-431
> URL: https://issues.apache.org/jira/browse/MJAVADOC-431
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.10.3
>Reporter: Peter lynch
>Assignee: Michael Osipov
> Fix For: 2.10.4
>
>
> The javadoc:jar mojo explicitly prevents the Maven descriptor from being 
> added to the produced javadoc.jar file.
> https://github.com/apache/maven-plugins/blob/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/JavadocJar.java#L299-299
> I could not find an explanation or technical reason why this is done.
> Adding the maven descriptor to the javadoc jar can help expose valuable 
> information about the build that produced it and should be at the discretion 
> of the build process.
> Expected:
> - allow the archiver used to create the javadoc jar to respect the plexus 
> archiver configuration if it is configured to include the Maven descriptor.
> - preserve the default behaviour of not including the Maven descriptor, for 
> (unknown) backwards compatibility reasons only



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

[jira] [Commented] (MSOURCES-81) allow sources jar to contain Maven descriptor

2015-12-17 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MSOURCES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062491#comment-15062491
 ] 

ASF GitHub Bot commented on MSOURCES-81:


Github user peterlynch closed the pull request at:

https://github.com/apache/maven-plugins/pull/58


> allow sources jar to contain Maven descriptor
> -
>
> Key: MSOURCES-81
> URL: https://issues.apache.org/jira/browse/MSOURCES-81
> Project: Maven Source Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Peter lynch
>Assignee: Karl Heinz Marbaise
> Fix For: 3.0.0
>
>
> The source:jar mojo explicitly prevents the Maven descriptor from being added 
> to the produced -sources.jar file.
> https://github.com/apache/maven-plugins/blob/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractSourceJarMojo.java#L292-292
> I could not find an explanation or technical reason why this is done.
> Adding the maven descriptor to the source jar can help expose valuable 
> information about the build that produced it.
> Expected:
> - allow the archiver used to create the source jar to respect the plexus 
> archiver configuration if it is configured to include the Maven descriptor.
> - preserve the default behaviour of not including the Maven descriptor, for 
> (unknown) backwards compatibility reasons only



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

[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte commented on MNG-5868:


Can someone explain what is the correct behaviour here? The Javadoc comment for 
'MavenProject.addAttachedArtifact' and 'MavenProjectHelper.attachArtifact()' is 
not consistent to what the code does. For example:

MavenProject.addAttachedArtifact:

{code}
/**
 * Add or replace an artifact. This method is now deprecated. Use the 
@{MavenProjectHelper} to attach artifacts to a
 * project. In spite of the 'throws' declaration on this API, this method 
has never thrown an exception since Maven
 * 3.0.x. Historically, it logged and ignored a second addition of the same 
g/a/v/c/t. Now it replaces the file for
 * the artifact, so that plugins (e.g. shade) can change the pathname of 
the file for a particular set of
 * coordinates.
 *
 * @param artifact the artifact to add or replace.
 * @throws DuplicateArtifactAttachmentException
 */
{code}

DefaultMavenProjectHelper.attachArtifact(MavenProject,Artifact):

{code}
/**
 * Add an attached artifact or replace the file for an existing artifact.
 *
 * @see MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
 * @param project project reference.
 * @param artifact artifact to add or replace.
 */
{code}

The code does not replace anything. It just adds the artifact to the list. How 
to solve this issue? Should the methods be updated to match the documentation, 
or is the documentation wrong?


> Adding serval times the same artifact via MavenProjectHelper (attachArtifact) 
> does not produce a failure 
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.3
>Reporter: Karl Heinz Marbaise
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at: 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> MSHADE-195-example ---
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] 
> {noformat}
> Install plugin tries to install two identical artifacts which will work for 
> maven-install-plugin but would fail a deploy to repository manager (for 
> releases) etc.
> So after diving into the problem i found the following code in maven-core 
> (MavenProject.java):
> {code:java}
> /**
>  * Add or replace an artifact. This method is now deprecated. Use the 
> @{MavenProjectHelper} to attach artifacts to a
>  * project. In spite of the 'throws' declaration on this API, this method 
> has never thrown an exception since Maven
>  * 3.0.x. Historically, it logged and ignored a second addition of the 
> same g/a/v/c/t. Now it replaces the file for
>  * the artifact, so that plugins (e.g. shade) can change the pathname of 
> the file for a particular set of
>  * coordinates.
>  *
>  * @param artifact the artifact to add or replace.
>  * @throws

[jira] [Assigned] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte reassigned MNG-5868:
--

Assignee: Christian Schulte

> Adding serval times the same artifact via MavenProjectHelper (attachArtifact) 
> does not produce a failure 
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at: 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> MSHADE-195-example ---
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] 
> {noformat}
> Install plugin tries to install two identical artifacts which will work for 
> maven-install-plugin but would fail a deploy to repository manager (for 
> releases) etc.
> So after diving into the problem i found the following code in maven-core 
> (MavenProject.java):
> {code:java}
> /**
>  * Add or replace an artifact. This method is now deprecated. Use the 
> @{MavenProjectHelper} to attach artifacts to a
>  * project. In spite of the 'throws' declaration on this API, this method 
> has never thrown an exception since Maven
>  * 3.0.x. Historically, it logged and ignored a second addition of the 
> same g/a/v/c/t. Now it replaces the file for
>  * the artifact, so that plugins (e.g. shade) can change the pathname of 
> the file for a particular set of
>  * coordinates.
>  *
>  * @param artifact the artifact to add or replace.
>  * @throws DuplicateArtifactAttachmentException
>  */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation 
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
>  * Add an attached artifact or replace the file for an existing artifact.
>  *
>  * @see 
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
>  * @param project project reference.
>  * @param artifact artifact to add or replace.
>  */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.



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

[jira] [Commented] (MCHECKSTYLE-314) checkstyle:check should invoke the execution of this plugin's goal "checkstyle" prior to executing itself

2015-12-17 Thread Michael Osipov (JIRA)


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

Michael Osipov commented on MCHECKSTYLE-314:


A week has passed, I will go ahead and apply the change.

> checkstyle:check should invoke the execution of this plugin's goal 
> "checkstyle" prior to executing itself
> -
>
> Key: MCHECKSTYLE-314
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-314
> Project: Maven Checkstyle Plugin
>  Issue Type: Improvement
>Affects Versions: 2.17
>Reporter: Roman Ivanov
>Assignee: Michael Osipov
>
> I run into problem with using checkstyles goal "checkstyle:check" in 
> sevntu.checkstyle project 
> (https://github.com/sevntu-checkstyle/sevntu.checkstyle/blob/master/sevntu-checks/pom.xml#L75)
>  as it always use default Sun config when I run "checkstyle:check", It took 
> me a while to figure out why that does not work.
> I had a habit and convenience to run in such a ways pmd and findbug, just 
> "mvn pmd:check", "mvn findbug:check" it is human friendly.
> PMD and Findbugs plugins already do this:
> http://gleclaire.github.io/findbugs-maven-plugin/check-mojo.html
> https://maven.apache.org/plugins/maven-pmd-plugin/check-mojo.html
> search for "Invokes the execution of this plugin's goal"
> vs
> http://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html
> Problem was also raised at : 
> http://stackoverflow.com/questions/11106767/maven-checkstylecheck-not-working
> Please add support of this, most users are not professionals in Maven. I use 
> Maven for many years and it took me too much time to find a reason why it 
> does not work.



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

[jira] [Updated] (MJAVADOC-431) Allow Javadoc Jar to contain Maven descriptor

2015-12-17 Thread Michael Osipov (JIRA)


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

Michael Osipov updated MJAVADOC-431:

Summary: Allow Javadoc Jar to contain Maven descriptor  (was: allow javadoc 
jar to contain Maven descriptor)

> Allow Javadoc Jar to contain Maven descriptor
> -
>
> Key: MJAVADOC-431
> URL: https://issues.apache.org/jira/browse/MJAVADOC-431
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.10.3
>Reporter: Peter lynch
>Assignee: Michael Osipov
> Fix For: 2.10.4
>
>
> The javadoc:jar mojo explicitly prevents the Maven descriptor from being 
> added to the produced javadoc.jar file.
> https://github.com/apache/maven-plugins/blob/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/JavadocJar.java#L299-299
> I could not find an explanation or technical reason why this is done.
> Adding the maven descriptor to the javadoc jar can help expose valuable 
> information about the build that produced it and should be at the discretion 
> of the build process.
> Expected:
> - allow the archiver used to create the javadoc jar to respect the plexus 
> archiver configuration if it is configured to include the Maven descriptor.
> - preserve the default behaviour of not including the Maven descriptor, for 
> (unknown) backwards compatibility reasons only



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

[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte commented on MNG-5868:


@Karl Heinz Marbaise: Are you sure the list of affected versions is corrent? I 
think the issue got introduced by [this 
commit|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=6cf9320942c34bc68205425ab696b1712ace9ba4].
 So only Maven > 3.2.2 should be affected.
 

> Adding serval times the same artifact via MavenProjectHelper (attachArtifact) 
> does not produce a failure 
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at: 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> MSHADE-195-example ---
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] 
> {noformat}
> Install plugin tries to install two identical artifacts which will work for 
> maven-install-plugin but would fail a deploy to repository manager (for 
> releases) etc.
> So after diving into the problem i found the following code in maven-core 
> (MavenProject.java):
> {code:java}
> /**
>  * Add or replace an artifact. This method is now deprecated. Use the 
> @{MavenProjectHelper} to attach artifacts to a
>  * project. In spite of the 'throws' declaration on this API, this method 
> has never thrown an exception since Maven
>  * 3.0.x. Historically, it logged and ignored a second addition of the 
> same g/a/v/c/t. Now it replaces the file for
>  * the artifact, so that plugins (e.g. shade) can change the pathname of 
> the file for a particular set of
>  * coordinates.
>  *
>  * @param artifact the artifact to add or replace.
>  * @throws DuplicateArtifactAttachmentException
>  */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation 
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
>  * Add an attached artifact or replace the file for an existing artifact.
>  *
>  * @see 
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
>  * @param project project reference.
>  * @param artifact artifact to add or replace.
>  */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.



--
This message was sent by Atlassian

[jira] [Closed] (MJAVADOC-431) Allow Javadoc Jar to contain Maven descriptor

2015-12-17 Thread Michael Osipov (JIRA)


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

Michael Osipov closed MJAVADOC-431.
---
Resolution: Fixed

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

> Allow Javadoc Jar to contain Maven descriptor
> -
>
> Key: MJAVADOC-431
> URL: https://issues.apache.org/jira/browse/MJAVADOC-431
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.10.3
>Reporter: Peter lynch
>Assignee: Michael Osipov
> Fix For: 2.10.4
>
>
> The javadoc:jar mojo explicitly prevents the Maven descriptor from being 
> added to the produced javadoc.jar file.
> https://github.com/apache/maven-plugins/blob/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/JavadocJar.java#L299-299
> I could not find an explanation or technical reason why this is done.
> Adding the maven descriptor to the javadoc jar can help expose valuable 
> information about the build that produced it and should be at the discretion 
> of the build process.
> Expected:
> - allow the archiver used to create the javadoc jar to respect the plexus 
> archiver configuration if it is configured to include the Maven descriptor.
> - preserve the default behaviour of not including the Maven descriptor, for 
> (unknown) backwards compatibility reasons only



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

[jira] [Commented] (MNG-4777) Match property for profile activation against a regex

2015-12-17 Thread Ville (JIRA)


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

Ville commented on MNG-4777:


I have a patch I would like to submit for this issue (see attached). 
Unfortunately, I am unable to re-open this issue; [~jvanzyl] please let me know 
if you would prefer that I file a new issue. 

Our use case is to activate a profile when the project version is (or is not) a 
SNAPSHOT version. In order to do this, we create a project property for the 
version, then a inactive-by-default profile with a property activation rule. 
The property value of the rule may be set to either: "~.*-SNAPSHOT" (is a 
SNAPSHOT version) or "!~.*-SNAPSHOT" (is not a SNAPSHOT version).

The patch includes the following changes:

 - Fetching the property value from project properties if it is not found in 
either user properties or system properties.
 - Supporting a prefix character "~" for a regular expression comparison (as 
suggested by [~ja...@planet57.com] above).

Negation is extended to regular expressions if "!" is specified before "~". The 
patch includes unit tests and the integration tests pass with "mvn -Prun-its 
install" from the root of the project tree. I would be happy to submit a 
documentation patch as well; however, I have been unable to locate the 
documentation source to modify around profile activation using properties. The 
closest I have come is the Maven Book on Sonatype here:

https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html

> Match property for profile activation against a regex
> -
>
> Key: MNG-4777
> URL: https://issues.apache.org/jira/browse/MNG-4777
> Project: Maven
>  Issue Type: Improvement
>  Components: Profiles
>Affects Versions: 2.0.11
>Reporter: Andreas Ebbert-Karroum
>
> For activating a profile it would be nice, in addition or as a seperate 
> feature to MNG-3328, to match a property not against a specific value but 
> against a regex. In our case, we need to set some properties for some hudson 
> builds. Not only is that setup fragile against job name changes, but also 
> doesn't scale for multiple jobs. IMHO adding a regex matcher would be a nice 
> feature for multiple purposes.
> Old:
> {code:xml}
> 
>   
> env.JOB_NAME
> 
> xyz-abc-foo/label=robotframework,maven.browser-profile=firefox,maven.env-profile=dev
>   
> 
> {code}
> New:
> {code:xml}
> 
>   
> env.JOB_NAME
> xyz-abc-foo/.*
>   
> 
> {code}



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

[jira] [Updated] (MNG-4777) Match property for profile activation against a regex

2015-12-17 Thread Ville (JIRA)


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

Ville updated MNG-4777:
---
Attachment: regex-project-property-profile-activator.patch

Patch to https://git-wip-us.apache.org/repos/asf/maven.git (master).

> Match property for profile activation against a regex
> -
>
> Key: MNG-4777
> URL: https://issues.apache.org/jira/browse/MNG-4777
> Project: Maven
>  Issue Type: Improvement
>  Components: Profiles
>Affects Versions: 2.0.11
>Reporter: Andreas Ebbert-Karroum
> Attachments: regex-project-property-profile-activator.patch
>
>
> For activating a profile it would be nice, in addition or as a seperate 
> feature to MNG-3328, to match a property not against a specific value but 
> against a regex. In our case, we need to set some properties for some hudson 
> builds. Not only is that setup fragile against job name changes, but also 
> doesn't scale for multiple jobs. IMHO adding a regex matcher would be a nice 
> feature for multiple purposes.
> Old:
> {code:xml}
> 
>   
> env.JOB_NAME
> 
> xyz-abc-foo/label=robotframework,maven.browser-profile=firefox,maven.env-profile=dev
>   
> 
> {code}
> New:
> {code:xml}
> 
>   
> env.JOB_NAME
> xyz-abc-foo/.*
>   
> 
> {code}



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

[jira] [Commented] (MJAVADOC-431) Allow Javadoc Jar to contain Maven descriptor

2015-12-17 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/MJAVADOC-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062999#comment-15062999
 ] 

Hudson commented on MJAVADOC-431:
-

SUCCESS: Integrated in maven-plugins #4890 (See 
[https://builds.apache.org/job/maven-plugins/4890/])
[MJAVADOC-431] Allow Javadoc Jar to contain Maven descriptor

Contributed by: Peter Lynch 

This closes #73 (michaelo: [http://svn.apache.org/viewvc/?view=rev=1720689])
* 
maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/JavadocArchiveConfiguration.java
* 
maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/JavadocJar.java
* 
maven-javadoc-plugin/src/test/java/org/apache/maven/plugin/javadoc/JavadocJarTest.java
* 
maven-javadoc-plugin/src/test/java/org/apache/maven/plugin/javadoc/stubs/JavadocJarArchiveConfigProjectStub.java
* maven-javadoc-plugin/src/test/resources/unit/javadocjar-archive-config
* 
maven-javadoc-plugin/src/test/resources/unit/javadocjar-archive-config/javadocjar
* 
maven-javadoc-plugin/src/test/resources/unit/javadocjar-archive-config/javadocjar-archive-config.xml
* 
maven-javadoc-plugin/src/test/resources/unit/javadocjar-archive-config/javadocjar/def
* 
maven-javadoc-plugin/src/test/resources/unit/javadocjar-archive-config/javadocjar/def/App.java


> Allow Javadoc Jar to contain Maven descriptor
> -
>
> Key: MJAVADOC-431
> URL: https://issues.apache.org/jira/browse/MJAVADOC-431
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.10.3
>Reporter: Peter lynch
>Assignee: Michael Osipov
> Fix For: 2.10.4
>
>
> The javadoc:jar mojo explicitly prevents the Maven descriptor from being 
> added to the produced javadoc.jar file.
> https://github.com/apache/maven-plugins/blob/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/JavadocJar.java#L299-299
> I could not find an explanation or technical reason why this is done.
> Adding the maven descriptor to the javadoc jar can help expose valuable 
> information about the build that produced it and should be at the discretion 
> of the build process.
> Expected:
> - allow the archiver used to create the javadoc jar to respect the plexus 
> archiver configuration if it is configured to include the Maven descriptor.
> - preserve the default behaviour of not including the Maven descriptor, for 
> (unknown) backwards compatibility reasons only



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

[jira] [Commented] (MJAVADOC-431) Allow Javadoc Jar to contain Maven descriptor

2015-12-17 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MJAVADOC-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063011#comment-15063011
 ] 

ASF GitHub Bot commented on MJAVADOC-431:
-

Github user asfgit closed the pull request at:

https://github.com/apache/maven-plugins/pull/73


> Allow Javadoc Jar to contain Maven descriptor
> -
>
> Key: MJAVADOC-431
> URL: https://issues.apache.org/jira/browse/MJAVADOC-431
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.10.3
>Reporter: Peter lynch
>Assignee: Michael Osipov
> Fix For: 2.10.4
>
>
> The javadoc:jar mojo explicitly prevents the Maven descriptor from being 
> added to the produced javadoc.jar file.
> https://github.com/apache/maven-plugins/blob/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/JavadocJar.java#L299-299
> I could not find an explanation or technical reason why this is done.
> Adding the maven descriptor to the javadoc jar can help expose valuable 
> information about the build that produced it and should be at the discretion 
> of the build process.
> Expected:
> - allow the archiver used to create the javadoc jar to respect the plexus 
> archiver configuration if it is configured to include the Maven descriptor.
> - preserve the default behaviour of not including the Maven descriptor, for 
> (unknown) backwards compatibility reasons only



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

[jira] [Commented] (SCM-714) mvn release:prepare fails if the command line is too long on windows

2015-12-17 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063051#comment-15063051
 ] 

ASF GitHub Bot commented on SCM-714:


GitHub user McLuck reopened a pull request:

https://github.com/apache/maven-scm/pull/41

SCM-714 fix git commit when command line got too long

SCM-714 replace commit command individual files (ex: "pom.xml") to commit 
command using a pattern (ex: "*pom.xml").

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/McLuck/maven-scm master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-scm/pull/41.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #41


commit e802ae20979ca6bc7870d484b03dadbfc421e45d
Author: Lucas Israel 
Date:   2015-12-17T22:59:03Z

SCM-714 fix for Windows platform when command line got too long for adding 
files. This commit changed the git command add. Replacing from a list of type 
file to a list of file patterns.




> mvn release:prepare fails if the command line is too long on windows
> 
>
> Key: SCM-714
> URL: https://issues.apache.org/jira/browse/SCM-714
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-git
>Affects Versions: 1.8.1
>Reporter: Felix Simmendinger
>Assignee: Robert Scholte
>Priority: Blocker
>
> The issue from SCM-697 does not solve the issue as the gitprovider is not 
> using the add command but the checkin command during a release.



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

[jira] [Resolved] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte resolved MNG-5868.

   Resolution: Fixed
Fix Version/s: 3.4.0

> Adding serval times the same artifact via MavenProjectHelper (attachArtifact) 
> does not produce a failure 
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at: 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> MSHADE-195-example ---
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] 
> {noformat}
> Install plugin tries to install two identical artifacts which will work for 
> maven-install-plugin but would fail a deploy to repository manager (for 
> releases) etc.
> So after diving into the problem i found the following code in maven-core 
> (MavenProject.java):
> {code:java}
> /**
>  * Add or replace an artifact. This method is now deprecated. Use the 
> @{MavenProjectHelper} to attach artifacts to a
>  * project. In spite of the 'throws' declaration on this API, this method 
> has never thrown an exception since Maven
>  * 3.0.x. Historically, it logged and ignored a second addition of the 
> same g/a/v/c/t. Now it replaces the file for
>  * the artifact, so that plugins (e.g. shade) can change the pathname of 
> the file for a particular set of
>  * coordinates.
>  *
>  * @param artifact the artifact to add or replace.
>  * @throws DuplicateArtifactAttachmentException
>  */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation 
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
>  * Add an attached artifact or replace the file for an existing artifact.
>  *
>  * @see 
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
>  * @param project project reference.
>  * @param artifact artifact to add or replace.
>  */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.



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

[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure

2015-12-17 Thread Hudson (JIRA)


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

Hudson commented on MNG-5868:
-

SUCCESS: Integrated in maven-3.x #1174 (See 
[https://builds.apache.org/job/maven-3.x/1174/])
Revert "[MNG-5868] Adding serval times the same artifact via (schulte: rev 
536350f5c5960e6c639305acde79e3fc81a91dd4)
* maven-core/src/main/java/org/apache/maven/project/MavenProjectHelper.java
* maven-core/src/main/java/org/apache/maven/project/MavenProject.java
* 
maven-core/src/main/java/org/apache/maven/project/DefaultMavenProjectHelper.java
[MNG-5868] Adding serval times the same artifact via MavenProjectHelper 
(schulte: rev 5f048234ff44dbf70fcad9f17834c64866f452e1)
* maven-core/src/main/java/org/apache/maven/project/MavenProject.java
* 
maven-core/src/main/java/org/apache/maven/project/DefaultMavenProjectHelper.java


> Adding serval times the same artifact via MavenProjectHelper (attachArtifact) 
> does not produce a failure 
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at: 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> MSHADE-195-example ---
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] 
> {noformat}
> Install plugin tries to install two identical artifacts which will work for 
> maven-install-plugin but would fail a deploy to repository manager (for 
> releases) etc.
> So after diving into the problem i found the following code in maven-core 
> (MavenProject.java):
> {code:java}
> /**
>  * Add or replace an artifact. This method is now deprecated. Use the 
> @{MavenProjectHelper} to attach artifacts to a
>  * project. In spite of the 'throws' declaration on this API, this method 
> has never thrown an exception since Maven
>  * 3.0.x. Historically, it logged and ignored a second addition of the 
> same g/a/v/c/t. Now it replaces the file for
>  * the artifact, so that plugins (e.g. shade) can change the pathname of 
> the file for a particular set of
>  * coordinates.
>  *
>  * @param artifact the artifact to add or replace.
>  * @throws DuplicateArtifactAttachmentException
>  */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation 
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
>  * Add an attached artifact or replace the file for an existing artifact.
>  *
>

[jira] [Updated] (MNG-5939) Problem doing release when sources are generate as well

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte updated MNG-5939:
---
Affects Version/s: (was: 3.3.9)
   (was: 3.3.3)
   3.2.3

> Problem doing release when sources are generate as well
> ---
>
> Key: MNG-5939
> URL: https://issues.apache.org/jira/browse/MNG-5939
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.2.3
> Environment: Ubuntu 12.04.5 LTS
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 
> 2014-02-14T18:37:52+01:00)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T17:41:47+01:00)
> Java version: 1.7.0_76, vendor: Oracle Corporation
>Reporter: chibbe
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
> Attachments: 
> 0001-MNG-5939-Addresses-duplicate-attached-artifact-probl.patch, foo.bar.zip
>
>
> If I specified that sources should be generated with jar-no-fork goal 
> https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html .
> When doing a release with maven-release-plugin it will build the source again 
> when useReleaseProfile is true (use the release profile that adds sources and 
> javadocs to the released artifact 
> http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile).
> The outcome is that it will run with both jar and jar-no-fork and generate 
> and deploy 2 -sources.jar artifacts, with same version. That makes the 
> release build fails.
>  
> The same behavior could be reproduced when running both jar and jar-no-fork 
> goal between maven 3.2.1. and maven 3.3.9.
> 
> Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip
> With maven 3.3.9 it uploads it 2 times :
> Uploaded: 
> http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar
>  (722 B at 15.3 KB/sec)
> Uploading: 
> http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar
> 722/722 B



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

[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure

2015-12-17 Thread Hudson (JIRA)


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

Hudson commented on MNG-5868:
-

SUCCESS: Integrated in maven-3.x #1172 (See 
[https://builds.apache.org/job/maven-3.x/1172/])
[MNG-5868] Adding serval times the same artifact via MavenProjectHelper 
(schulte: rev 020e35816f184c10c3f87f103336fed4516f7af6)
* 
maven-core/src/main/java/org/apache/maven/project/DefaultMavenProjectHelper.java
* maven-core/src/main/java/org/apache/maven/project/MavenProject.java
* maven-core/src/main/java/org/apache/maven/project/MavenProjectHelper.java


> Adding serval times the same artifact via MavenProjectHelper (attachArtifact) 
> does not produce a failure 
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at: 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> MSHADE-195-example ---
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] 
> {noformat}
> Install plugin tries to install two identical artifacts which will work for 
> maven-install-plugin but would fail a deploy to repository manager (for 
> releases) etc.
> So after diving into the problem i found the following code in maven-core 
> (MavenProject.java):
> {code:java}
> /**
>  * Add or replace an artifact. This method is now deprecated. Use the 
> @{MavenProjectHelper} to attach artifacts to a
>  * project. In spite of the 'throws' declaration on this API, this method 
> has never thrown an exception since Maven
>  * 3.0.x. Historically, it logged and ignored a second addition of the 
> same g/a/v/c/t. Now it replaces the file for
>  * the artifact, so that plugins (e.g. shade) can change the pathname of 
> the file for a particular set of
>  * coordinates.
>  *
>  * @param artifact the artifact to add or replace.
>  * @throws DuplicateArtifactAttachmentException
>  */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation 
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
>  * Add an attached artifact or replace the file for an existing artifact.
>  *
>  * @see 
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
>  * @param project project reference.
>  * @param artifact artifact to add or replace.
>  */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
>

[jira] [Resolved] (MSHADE-195) createSourcesJar with source:jar-no-fork causes sources.jar to be deployed twice, causing the build to fail

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte resolved MSHADE-195.
--
   Resolution: Won't Fix
 Assignee: Christian Schulte
Fix Version/s: (was: 2.4.3)
   (was: waiting-for-feedback)

Seems to be related to MNG-5868.

> createSourcesJar with source:jar-no-fork causes sources.jar to be deployed 
> twice, causing the build to fail
> ---
>
> Key: MSHADE-195
> URL: https://issues.apache.org/jira/browse/MSHADE-195
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.3, 2.4
>Reporter: Esko Luontola
>Assignee: Christian Schulte
> Attachments: MSHADE-195-example.zip
>
>
> The workaround described in https://issues.apache.org/jira/browse/MSHADE-120 
> (i.e. running maven-source-plugin's jar-no-fork goal before shading) causes 
> the problem that Maven will install and deploy the same sources.jar file 
> twice:
> {noformat}
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> pricing-client ---
> [INFO] Installing xxx/pricing-client/target/pricing-client-0-SNAPSHOT.jar to 
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.jar
> [INFO] Installing xxx/pricing-client/target/dependency-reduced-pom.xml to 
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.pom
> [INFO] Installing 
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to 
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> [INFO] Installing 
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to 
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> {noformat}
> With maven-install-plugin this doesn't matter that much, but with 
> maven-deploy-plugin it *fails the build*, because it tries to upload the 
> sources.jar twice to the Maven repository and _Nexus doesn't allow that_:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on 
> project project: Failed to deploy artifacts: Could not transfer artifact 
> xxx.availability:availability-client:jar:sources:1.0.24 from/to xxx-releases 
> (http://xxx/nexus/content/repositories/releases): Failed to transfer file: 
> http://xxx/nexus/content/repositories/releases//availability/availability-client/1.0.24/availability-client-1.0.24-sources.jar.
>  Return code is: 400, ReasonPhrase: Bad Request.
> {noformat}
> I'm suspecting this to be something like the maven-source-plugin and 
> maven-shade-plugin both attaching the same sources.jar to the build, when 
> only one of them should do it. This problem only happens with the sources jar 
> and not the main artifact, so a trick similar to replacing the main artifact 
> is needed also for the sources jar.
> h4. Workaround
> Configure maven-source-plugin with {{false}}. Then the shade 
> plugin will find the sources and include them in the shaded sources jar, but 
> the sources jar won't be attached to the build twice.



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

[jira] [Closed] (MSHADE-195) createSourcesJar with source:jar-no-fork causes sources.jar to be deployed twice, causing the build to fail

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte closed MSHADE-195.


> createSourcesJar with source:jar-no-fork causes sources.jar to be deployed 
> twice, causing the build to fail
> ---
>
> Key: MSHADE-195
> URL: https://issues.apache.org/jira/browse/MSHADE-195
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.3, 2.4
>Reporter: Esko Luontola
>Assignee: Christian Schulte
> Attachments: MSHADE-195-example.zip
>
>
> The workaround described in https://issues.apache.org/jira/browse/MSHADE-120 
> (i.e. running maven-source-plugin's jar-no-fork goal before shading) causes 
> the problem that Maven will install and deploy the same sources.jar file 
> twice:
> {noformat}
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> pricing-client ---
> [INFO] Installing xxx/pricing-client/target/pricing-client-0-SNAPSHOT.jar to 
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.jar
> [INFO] Installing xxx/pricing-client/target/dependency-reduced-pom.xml to 
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.pom
> [INFO] Installing 
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to 
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> [INFO] Installing 
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to 
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> {noformat}
> With maven-install-plugin this doesn't matter that much, but with 
> maven-deploy-plugin it *fails the build*, because it tries to upload the 
> sources.jar twice to the Maven repository and _Nexus doesn't allow that_:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on 
> project project: Failed to deploy artifacts: Could not transfer artifact 
> xxx.availability:availability-client:jar:sources:1.0.24 from/to xxx-releases 
> (http://xxx/nexus/content/repositories/releases): Failed to transfer file: 
> http://xxx/nexus/content/repositories/releases//availability/availability-client/1.0.24/availability-client-1.0.24-sources.jar.
>  Return code is: 400, ReasonPhrase: Bad Request.
> {noformat}
> I'm suspecting this to be something like the maven-source-plugin and 
> maven-shade-plugin both attaching the same sources.jar to the build, when 
> only one of them should do it. This problem only happens with the sources jar 
> and not the main artifact, so a trick similar to replacing the main artifact 
> is needed also for the sources jar.
> h4. Workaround
> Configure maven-source-plugin with {{false}}. Then the shade 
> plugin will find the sources and include them in the shaded sources jar, but 
> the sources jar won't be attached to the build twice.



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

[jira] [Closed] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte closed MNG-5868.
--

> Adding serval times the same artifact via MavenProjectHelper (attachArtifact) 
> does not produce a failure 
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at: 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> MSHADE-195-example ---
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] 
> {noformat}
> Install plugin tries to install two identical artifacts which will work for 
> maven-install-plugin but would fail a deploy to repository manager (for 
> releases) etc.
> So after diving into the problem i found the following code in maven-core 
> (MavenProject.java):
> {code:java}
> /**
>  * Add or replace an artifact. This method is now deprecated. Use the 
> @{MavenProjectHelper} to attach artifacts to a
>  * project. In spite of the 'throws' declaration on this API, this method 
> has never thrown an exception since Maven
>  * 3.0.x. Historically, it logged and ignored a second addition of the 
> same g/a/v/c/t. Now it replaces the file for
>  * the artifact, so that plugins (e.g. shade) can change the pathname of 
> the file for a particular set of
>  * coordinates.
>  *
>  * @param artifact the artifact to add or replace.
>  * @throws DuplicateArtifactAttachmentException
>  */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation 
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
>  * Add an attached artifact or replace the file for an existing artifact.
>  *
>  * @see 
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
>  * @param project project reference.
>  * @param artifact artifact to add or replace.
>  */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.



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

[jira] [Closed] (MNG-5939) Problem doing release when sources are generate as well

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte closed MNG-5939.
--

> Problem doing release when sources are generate as well
> ---
>
> Key: MNG-5939
> URL: https://issues.apache.org/jira/browse/MNG-5939
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.3.3, 3.3.9
> Environment: Ubuntu 12.04.5 LTS
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 
> 2014-02-14T18:37:52+01:00)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T17:41:47+01:00)
> Java version: 1.7.0_76, vendor: Oracle Corporation
>Reporter: chibbe
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
> Attachments: 
> 0001-MNG-5939-Addresses-duplicate-attached-artifact-probl.patch, foo.bar.zip
>
>
> If I specified that sources should be generated with jar-no-fork goal 
> https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html .
> When doing a release with maven-release-plugin it will build the source again 
> when useReleaseProfile is true (use the release profile that adds sources and 
> javadocs to the released artifact 
> http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile).
> The outcome is that it will run with both jar and jar-no-fork and generate 
> and deploy 2 -sources.jar artifacts, with same version. That makes the 
> release build fails.
>  
> The same behavior could be reproduced when running both jar and jar-no-fork 
> goal between maven 3.2.1. and maven 3.3.9.
> 
> Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip
> With maven 3.3.9 it uploads it 2 times :
> Uploaded: 
> http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar
>  (722 B at 15.3 KB/sec)
> Uploading: 
> http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar
> 722/722 B



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

[jira] [Updated] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte updated MNG-5868:
---
Affects Version/s: (was: 3.0.5)

> Adding serval times the same artifact via MavenProjectHelper (attachArtifact) 
> does not produce a failure 
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at: 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> MSHADE-195-example ---
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] 
> {noformat}
> Install plugin tries to install two identical artifacts which will work for 
> maven-install-plugin but would fail a deploy to repository manager (for 
> releases) etc.
> So after diving into the problem i found the following code in maven-core 
> (MavenProject.java):
> {code:java}
> /**
>  * Add or replace an artifact. This method is now deprecated. Use the 
> @{MavenProjectHelper} to attach artifacts to a
>  * project. In spite of the 'throws' declaration on this API, this method 
> has never thrown an exception since Maven
>  * 3.0.x. Historically, it logged and ignored a second addition of the 
> same g/a/v/c/t. Now it replaces the file for
>  * the artifact, so that plugins (e.g. shade) can change the pathname of 
> the file for a particular set of
>  * coordinates.
>  *
>  * @param artifact the artifact to add or replace.
>  * @throws DuplicateArtifactAttachmentException
>  */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation 
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
>  * Add an attached artifact or replace the file for an existing artifact.
>  *
>  * @see 
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
>  * @param project project reference.
>  * @param artifact artifact to add or replace.
>  */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.



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

[jira] [Updated] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte updated MNG-5868:
---
Affects Version/s: (was: 3.3.3)
   (was: 3.2.5)
   (was: 3.1.1)
   3.2.3

> Adding serval times the same artifact via MavenProjectHelper (attachArtifact) 
> does not produce a failure 
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  with 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at: 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> MSHADE-195-example ---
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing 
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
>  to 
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] 
> {noformat}
> Install plugin tries to install two identical artifacts which will work for 
> maven-install-plugin but would fail a deploy to repository manager (for 
> releases) etc.
> So after diving into the problem i found the following code in maven-core 
> (MavenProject.java):
> {code:java}
> /**
>  * Add or replace an artifact. This method is now deprecated. Use the 
> @{MavenProjectHelper} to attach artifacts to a
>  * project. In spite of the 'throws' declaration on this API, this method 
> has never thrown an exception since Maven
>  * 3.0.x. Historically, it logged and ignored a second addition of the 
> same g/a/v/c/t. Now it replaces the file for
>  * the artifact, so that plugins (e.g. shade) can change the pathname of 
> the file for a particular set of
>  * coordinates.
>  *
>  * @param artifact the artifact to add or replace.
>  * @throws DuplicateArtifactAttachmentException
>  */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation 
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
>  * Add an attached artifact or replace the file for an existing artifact.
>  *
>  * @see 
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
>  * @param project project reference.
>  * @param artifact artifact to add or replace.
>  */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.



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

[jira] [Updated] (MNG-5387) Add ability to replace an artifact in mid-build

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte updated MNG-5387:
---
Fix Version/s: 3.4.0

> Add ability to replace an artifact in mid-build
> ---
>
> Key: MNG-5387
> URL: https://issues.apache.org/jira/browse/MNG-5387
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.1.0-alpha-1, 3.2.3
>Reporter: Benson Margulies
>Assignee: Benson Margulies
> Fix For: 3.1.0-alpha-1, 3.4.0
>
>
> To clean up how the shade plugin works, we need an API to allow it to say, 
> 'please replace the jar file that the jar plugin has given you with this 
> other one here.' 
> It turns out we already more or less have this method, due to a collection of 
> historical conflict.
> At some point in time, http://jira.codehaus.org/browse/MNG-3119 called for 
> Maven to reject more than one call to attach the same artifact to the build. 
> However, this proved an unacceptable incompatibility at the time. Instead, 
> under http://jira.codehaus.org/browse/MNG-4013, Maven was changed to log but 
> otherwise ignore all calls to 'addArtifact' on MavenProject after the first 
> for a G/A/V/C/T coordinate. 
> This decision to take 'first wins' instead of 'last wins' doesn't help much 
> of anyone. It prevents something like shade from intentionally displacing an 
> earlier execution's results, and while it doesn't produce backtraces, ever, 
> it can still be entirely confusing.
> Under this JIRA, I'm switching to 'last one wins'. This could still be 
> confusing, and someone might argue that there should be some way to 
> distinguish casual and incorrect user config that results in two plugins 
> trying to deliver the same thing from something intentional. On the other 
> hand, if two plugins are configured to attach the same G/A/V/C, having the 
> last one win makes more sense, and has the effect of enabling the desired 
> behavior in shade.



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

[jira] [Commented] (SCM-714) mvn release:prepare fails if the command line is too long on windows

2015-12-17 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063048#comment-15063048
 ] 

ASF GitHub Bot commented on SCM-714:


Github user McLuck closed the pull request at:

https://github.com/apache/maven-scm/pull/41


> mvn release:prepare fails if the command line is too long on windows
> 
>
> Key: SCM-714
> URL: https://issues.apache.org/jira/browse/SCM-714
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-git
>Affects Versions: 1.8.1
>Reporter: Felix Simmendinger
>Assignee: Robert Scholte
>Priority: Blocker
>
> The issue from SCM-697 does not solve the issue as the gitprovider is not 
> using the add command but the checkin command during a release.



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

[jira] [Commented] (SCM-714) mvn release:prepare fails if the command line is too long on windows

2015-12-17 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063046#comment-15063046
 ] 

ASF GitHub Bot commented on SCM-714:


GitHub user McLuck opened a pull request:

https://github.com/apache/maven-scm/pull/41

SCM-714 fix git commit when command line got too long

SCM-714 replace commit command individual files (ex: "pom.xml") to commit 
command using a pattern (ex: "*pom.xml").

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/McLuck/maven-scm master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-scm/pull/41.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #41






> mvn release:prepare fails if the command line is too long on windows
> 
>
> Key: SCM-714
> URL: https://issues.apache.org/jira/browse/SCM-714
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-git
>Affects Versions: 1.8.1
>Reporter: Felix Simmendinger
>Assignee: Robert Scholte
>Priority: Blocker
>
> The issue from SCM-697 does not solve the issue as the gitprovider is not 
> using the add command but the checkin command during a release.



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

[jira] [Resolved] (MNG-5939) Problem doing release when sources are generate as well

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte resolved MNG-5939.

   Resolution: Fixed
 Assignee: Christian Schulte
Fix Version/s: 3.4.0

Seems to be a duplicate of MNG-5868.


> Problem doing release when sources are generate as well
> ---
>
> Key: MNG-5939
> URL: https://issues.apache.org/jira/browse/MNG-5939
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.3.3, 3.3.9
> Environment: Ubuntu 12.04.5 LTS
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 
> 2014-02-14T18:37:52+01:00)
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T17:41:47+01:00)
> Java version: 1.7.0_76, vendor: Oracle Corporation
>Reporter: chibbe
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
> Attachments: 
> 0001-MNG-5939-Addresses-duplicate-attached-artifact-probl.patch, foo.bar.zip
>
>
> If I specified that sources should be generated with jar-no-fork goal 
> https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html .
> When doing a release with maven-release-plugin it will build the source again 
> when useReleaseProfile is true (use the release profile that adds sources and 
> javadocs to the released artifact 
> http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile).
> The outcome is that it will run with both jar and jar-no-fork and generate 
> and deploy 2 -sources.jar artifacts, with same version. That makes the 
> release build fails.
>  
> The same behavior could be reproduced when running both jar and jar-no-fork 
> goal between maven 3.2.1. and maven 3.3.9.
> 
> Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip
> With maven 3.3.9 it uploads it 2 times :
> Uploaded: 
> http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar
>  (722 B at 15.3 KB/sec)
> Uploading: 
> http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar
> 722/722 B



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

[jira] [Updated] (MNG-5387) Add ability to replace an artifact in mid-build

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte updated MNG-5387:
---
Affects Version/s: 3.2.3

> Add ability to replace an artifact in mid-build
> ---
>
> Key: MNG-5387
> URL: https://issues.apache.org/jira/browse/MNG-5387
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.1.0-alpha-1, 3.2.3
>Reporter: Benson Margulies
>Assignee: Benson Margulies
> Fix For: 3.1.0-alpha-1
>
>
> To clean up how the shade plugin works, we need an API to allow it to say, 
> 'please replace the jar file that the jar plugin has given you with this 
> other one here.' 
> It turns out we already more or less have this method, due to a collection of 
> historical conflict.
> At some point in time, http://jira.codehaus.org/browse/MNG-3119 called for 
> Maven to reject more than one call to attach the same artifact to the build. 
> However, this proved an unacceptable incompatibility at the time. Instead, 
> under http://jira.codehaus.org/browse/MNG-4013, Maven was changed to log but 
> otherwise ignore all calls to 'addArtifact' on MavenProject after the first 
> for a G/A/V/C/T coordinate. 
> This decision to take 'first wins' instead of 'last wins' doesn't help much 
> of anyone. It prevents something like shade from intentionally displacing an 
> earlier execution's results, and while it doesn't produce backtraces, ever, 
> it can still be entirely confusing.
> Under this JIRA, I'm switching to 'last one wins'. This could still be 
> confusing, and someone might argue that there should be some way to 
> distinguish casual and incorrect user config that results in two plugins 
> trying to deliver the same thing from something intentional. On the other 
> hand, if two plugins are configured to attach the same G/A/V/C, having the 
> last one win makes more sense, and has the effect of enabling the desired 
> behavior in shade.



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

[jira] [Created] (MNGSITE-270) Upgrade Building Maven Guide related to Removed ANT build support

2015-12-17 Thread Karl Heinz Marbaise (JIRA)

Karl Heinz Marbaise created MNGSITE-270:
---

 Summary: Upgrade Building Maven Guide related to Removed ANT build 
support
 Key: MNGSITE-270
 URL: https://issues.apache.org/jira/browse/MNGSITE-270
 Project: Maven Project Web Site
  Issue Type: Improvement
Reporter: Karl Heinz Marbaise
Priority: Minor


The building maven guide should be updated to represent the upgrades which have 
been made in 3.4.0...
http://maven.apache.org/guides/development/guide-building-maven.html



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

[jira] [Created] (MNGSITE-267) Update plugin versions etc.on Using Extensions site.

2015-12-17 Thread Karl Heinz Marbaise (JIRA)

Karl Heinz Marbaise created MNGSITE-267:
---

 Summary: Update plugin versions etc.on Using Extensions site.
 Key: MNGSITE-267
 URL: https://issues.apache.org/jira/browse/MNGSITE-267
 Project: Maven Project Web Site
  Issue Type: Improvement
Reporter: Karl Heinz Marbaise
Priority: Minor


Update the used plugin versions etc. on the {{Using Extensions}} site.
http://maven.apache.org/guides/mini/guide-using-extensions.html





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

[jira] [Created] (MNGSITE-269) Update documentation about Maven bash completion guide

2015-12-17 Thread Karl Heinz Marbaise (JIRA)

Karl Heinz Marbaise created MNGSITE-269:
---

 Summary: Update documentation about Maven bash completion guide
 Key: MNGSITE-269
 URL: https://issues.apache.org/jira/browse/MNGSITE-269
 Project: Maven Project Web Site
  Issue Type: Improvement
Reporter: Karl Heinz Marbaise
Priority: Minor


The [Bash M2 
Completion|http://maven.apache.org/guides/mini/guide-bash-m2-completion.html] 
guide should be updated.

See also: https://github.com/juven/maven-bash-completion



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

[jira] [Commented] (MCOMPILER-234) Resulting jar contains javac.sh and JavacCompiler arguments file

2015-12-17 Thread JIRA


[ 
https://issues.apache.org/jira/browse/MCOMPILER-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15061877#comment-15061877
 ] 

Hervé Boutemy commented on MCOMPILER-234:
-

can you provide a sample project to reproduce, please? I can't reproduce it 
currently

> Resulting jar contains javac.sh and JavacCompiler arguments file 
> -
>
> Key: MCOMPILER-234
> URL: https://issues.apache.org/jira/browse/MCOMPILER-234
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.1
> Environment: Java8, Amazon EC2 (m2.micro), Ubuntu LTS 14.04, -X flag
>Reporter: Mark Zalavari
>
> After every build I have a 'javac.sh' and an 
> 'org.codehaus.plexus.compiler.javac.JavacCompiler875746317233791135arguments' 
> file in the target/classes directory, and in the resulting jar as well.
> It might be related to Java8, and the -X flag.
> Without the -X flag, everything is okay.
> (both the source and the target level are 1.6)



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

[jira] [Created] (MNGSITE-266) Building for different Environments Documentation needs to be updated.

2015-12-17 Thread Karl Heinz Marbaise (JIRA)

Karl Heinz Marbaise created MNGSITE-266:
---

 Summary: Building for different Environments Documentation needs 
to be updated.
 Key: MNGSITE-266
 URL: https://issues.apache.org/jira/browse/MNGSITE-266
 Project: Maven Project Web Site
  Issue Type: Bug
Reporter: Karl Heinz Marbaise


The [documentation to build for different 
environments|http://maven.apache.org/guides/mini/guide-building-for-different-environments.html]
 should be changed and updated.



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

[jira] [Assigned] (MNGSITE-266) Building for different Environments Documentation needs to be updated.

2015-12-17 Thread Karl Heinz Marbaise (JIRA)


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

Karl Heinz Marbaise reassigned MNGSITE-266:
---

Assignee: Karl Heinz Marbaise

> Building for different Environments Documentation needs to be updated.
> --
>
> Key: MNGSITE-266
> URL: https://issues.apache.org/jira/browse/MNGSITE-266
> Project: Maven Project Web Site
>  Issue Type: Bug
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>
> The [documentation to build for different 
> environments|http://maven.apache.org/guides/mini/guide-building-for-different-environments.html]
>  should be changed and updated.



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

[jira] [Created] (MNGSITE-268) Update the page Building JDK14 on 15

2015-12-17 Thread Karl Heinz Marbaise (JIRA)

Karl Heinz Marbaise created MNGSITE-268:
---

 Summary: Update the page Building JDK14 on 15
 Key: MNGSITE-268
 URL: https://issues.apache.org/jira/browse/MNGSITE-268
 Project: Maven Project Web Site
  Issue Type: Improvement
Reporter: Karl Heinz Marbaise
Priority: Minor


The following page should upgraded and revised.
http://maven.apache.org/guides/mini/guide-building-jdk14-on-jdk15.html



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

[jira] [Created] (ARCHETYPE-494) Provide a way to change the generated project after archetype execution

2015-12-17 Thread Petar Tahchiev (JIRA)

Petar Tahchiev created ARCHETYPE-494:


 Summary: Provide a way to change the generated project after 
archetype execution
 Key: ARCHETYPE-494
 URL: https://issues.apache.org/jira/browse/ARCHETYPE-494
 Project: Maven Archetype
  Issue Type: New Feature
Affects Versions: 2.4
Reporter: Petar Tahchiev
Assignee: Petar Tahchiev


It would be a nice enhancement to be able to modify the created project after 
archetype execution (create/update/delete files, update dependencies in 
pom.xml, etc). The way I see it this can be achieved by providing a special 
script that will be executed every time a project is generated from the 
archetype.



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

[jira] [Commented] (MNG-5837) Syntax error in bin/mvn on Solaris SPARC

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte commented on MNG-5837:


Do you have a final patch available working on Solaris?


> Syntax error in bin/mvn on Solaris SPARC
> 
>
> Key: MNG-5837
> URL: https://issues.apache.org/jira/browse/MNG-5837
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.3.1
> Environment: Solaris 10
>Reporter: Erlend Birkedal
>Assignee: Christian Schulte
>
> When running {{mvn}} on Solaris 10 we get the following error:
> {code:none}/opt/apache-maven-3.3.1/bin/mvn: syntax error at line 200: `(' 
> unexpected{code}
> Looks like similas issues as in MNG-5658



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

[jira] [Commented] (MNG-5837) Syntax error in bin/mvn on Solaris SPARC

2015-12-17 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on MNG-5837:
-

Github user ChristianSchulte commented on the pull request:

https://github.com/apache/maven/pull/50#issuecomment-165627334
  
Can you please 'rebase' the commit onto 'origin/master' so that I can merge 
it without conflicts?


> Syntax error in bin/mvn on Solaris SPARC
> 
>
> Key: MNG-5837
> URL: https://issues.apache.org/jira/browse/MNG-5837
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.3.1
> Environment: Solaris 10
>Reporter: Erlend Birkedal
>Assignee: Christian Schulte
>
> When running {{mvn}} on Solaris 10 we get the following error:
> {code:none}/opt/apache-maven-3.3.1/bin/mvn: syntax error at line 200: `(' 
> unexpected{code}
> Looks like similas issues as in MNG-5658



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

[jira] [Assigned] (MNG-5852) "mvn" script invokes /bin/sh but requires /bin/bash functions

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte reassigned MNG-5852:
--

Assignee: Christian Schulte

> "mvn" script invokes /bin/sh but requires /bin/bash functions
> -
>
> Key: MNG-5852
> URL: https://issues.apache.org/jira/browse/MNG-5852
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.3.3
> Environment: Solaris 11
>Reporter: Jeffrey Alexander
>Assignee: Christian Schulte
>
> The bin/mvn script uses the "local" command which is a shell builtin of bash 
> and similar shells, but is not required for POSIX-compliance in sh.  When I 
> attempt to run mvn on my Solaris system, I see the following output:
> $ ./mvn
> ./mvn[200]: local: not found [No such file or directory]
> ./mvn[201]: local: not found [No such file or directory]
> ...
> Lines 200 and 201 invoke "local" to make local variables to the function.  
> According to "man bash", this is a shell builtin.  However, bin/mvn is 
> invoked as:
> #!/bin/sh
> On most flavors of linux, this resolves to bash or dash which probably runs 
> in a restricted environment after checking to see that its $0 is sh. But on 
> Solaris's /bin/sh is actually ksh93 for backwards compatibility.
> Since "local" is not part of a POSIX-compliant /bin/sh, depending on it in a 
> script that is invoked with /bin/sh is a bug.



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

[jira] [Commented] (MNG-5852) "mvn" script invokes /bin/sh but requires /bin/bash functions

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte commented on MNG-5852:


I am running 'OpenBSD 5.8'. '/bin/sh' also is 'ksh' and works flawlessly. Can 
you please confirm the following changes to 'apache-maven/src/bin/mvn' solve 
your issue?

{code}
@@ -197,8 +197,6 @@ fi
 # traverses directory structure from process work directory to filesystem root
 # first directory with .mvn subdirectory is considered project base directory
 find_maven_basedir() {
-  local basedir
-  local wdir
   basedir="$(pwd)"
   wdir="$(pwd)"
   while [ "$wdir" != '/' ] ; do
{code}



> "mvn" script invokes /bin/sh but requires /bin/bash functions
> -
>
> Key: MNG-5852
> URL: https://issues.apache.org/jira/browse/MNG-5852
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.3.3
> Environment: Solaris 11
>Reporter: Jeffrey Alexander
>Assignee: Christian Schulte
>
> The bin/mvn script uses the "local" command which is a shell builtin of bash 
> and similar shells, but is not required for POSIX-compliance in sh.  When I 
> attempt to run mvn on my Solaris system, I see the following output:
> $ ./mvn
> ./mvn[200]: local: not found [No such file or directory]
> ./mvn[201]: local: not found [No such file or directory]
> ...
> Lines 200 and 201 invoke "local" to make local variables to the function.  
> According to "man bash", this is a shell builtin.  However, bin/mvn is 
> invoked as:
> #!/bin/sh
> On most flavors of linux, this resolves to bash or dash which probably runs 
> in a restricted environment after checking to see that its $0 is sh. But on 
> Solaris's /bin/sh is actually ksh93 for backwards compatibility.
> Since "local" is not part of a POSIX-compliant /bin/sh, depending on it in a 
> script that is invoked with /bin/sh is a bug.



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

[jira] [Assigned] (MNG-5837) Syntax error in bin/mvn on Solaris SPARC

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte reassigned MNG-5837:
--

Assignee: Christian Schulte

> Syntax error in bin/mvn on Solaris SPARC
> 
>
> Key: MNG-5837
> URL: https://issues.apache.org/jira/browse/MNG-5837
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.3.1
> Environment: Solaris 10
>Reporter: Erlend Birkedal
>Assignee: Christian Schulte
>
> When running {{mvn}} on Solaris 10 we get the following error:
> {code:none}/opt/apache-maven-3.3.1/bin/mvn: syntax error at line 200: `(' 
> unexpected{code}
> Looks like similas issues as in MNG-5658



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

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

2015-12-17 Thread Christian Schulte (JIRA)


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

Christian Schulte commented on MNG-5885:


If someone tells Maven to execute 'compile package', it should do just that. 
Garbage in -> garbage out, IMHO.


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



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

[jira] [Commented] (MRELEASE-909) Add workItem/task support for scm deliver

2015-12-17 Thread Chris Graham (JIRA)


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

Chris Graham commented on MRELEASE-909:
---

Um, why? Was there a release of the release plugin that I missed?
Yes, the SCM code will need to be released first, but then, there has always 
been a dependency on SCM by the release plugin.

> Add workItem/task support for scm deliver
> -
>
> Key: MRELEASE-909
> URL: https://issues.apache.org/jira/browse/MRELEASE-909
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: prepare
>Affects Versions: 2.5.2
>Reporter: Chris Graham
>Assignee: Chris Graham
>  Labels: patch
> Attachments: Release-SCM-775.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Some SCMs (Jazz(RTC)/TFS/ClearCase etc) can support a mode where a workItem 
> or Task is required to be associated with changesets for a delivery operation 
> to work.
> The SCM-775 has the necessary work to support this feature (with the Jazz 
> provider as a starting point). This issue is the complimentary issue; the 
> changes in the release plugin needed to support calling the scm apis with 
> workItem support.



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

[jira] [Created] (MNG-5950) only first active proxy considered

2015-12-17 Thread Jiahongchao (JIRA)

Jiahongchao created MNG-5950:


 Summary: only first active proxy considered
 Key: MNG-5950
 URL: https://issues.apache.org/jira/browse/MNG-5950
 Project: Maven
  Issue Type: Bug
  Components: core
Affects Versions: 3.0.5
 Environment: windows 7 ,jdk 1.8
Reporter: Jiahongchao


only http proxy or https proxy can be used at the same time,however,only one 
proxy should be used for both http and https



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

48 matches

Mail list logo