[jira] [Created] (MJAVADOC-439) Spelling of additionalDependencies is wrong on the page for java doc plugin
Moiz Randhikpurwala created MJAVADOC-439: Summary: Spelling of additionalDependencies is wrong on the page for java doc plugin Key: MJAVADOC-439 URL: https://issues.apache.org/jira/browse/MJAVADOC-439 Project: Maven Javadoc Plugin Issue Type: Documentation Reporter: Moiz Randhikpurwala Priority: Minor The spelling of the tags mentioned on the page are wrong, I realized when I copy pasted the tags and my build failed. https://maven.apache.org/plugins/maven-javadoc-plugin/examples/additionnal-dependencies.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARCHETYPE-494) Provide a way to change the generated project after archetype:generate execution
[ https://issues.apache.org/jira/browse/ARCHETYPE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated ARCHETYPE-494: Summary: Provide a way to change the generated project after archetype:generate execution (was: Provide a way to change the generated project after archetype execution) > Provide a way to change the generated project after archetype:generate > 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] [Updated] (ARCHETYPE-494) Provide a way to change the generated project after archetype:generate execution
[
https://issues.apache.org/jira/browse/ARCHETYPE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated ARCHETYPE-494:
Description: It would be a nice enhancement to be able to modify the
created project after {{{archetype:generate}}} 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. (was: 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.)
> Provide a way to change the generated project after archetype:generate
> 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:generate}}} 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] [Updated] (ARCHETYPE-494) Provide a way to change the generated project after archetype:generate execution
[
https://issues.apache.org/jira/browse/ARCHETYPE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated ARCHETYPE-494:
Description: It would be a nice enhancement to be able to modify the
created project after archetype:generate 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. (was: It would be a nice enhancement to be able
to modify the created project after {{{archetype:generate}}} 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.)
> Provide a way to change the generated project after archetype:generate
> 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:generate 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
[
https://issues.apache.org/jira/browse/MNG-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063888#comment-15063888
]
Erlend Birkedal commented on MNG-5837:
--
After upgrading to Maven 3.3.3 and still finding this broken on Solaris (and
this ticket unresolved as well), I gave up and just replaced {{#\!/bin/sh}}
with {{#\!/bin/bash/}} in {{bin/mvn}}...
> 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] (MRELEASE-909) Add workItem/task support for scm deliver
[ https://issues.apache.org/jira/browse/MRELEASE-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063889#comment-15063889 ] Hervé Boutemy commented on MRELEASE-909: yes, seems you missed version 2.5.3 on 2015-10-14 there were some discussion about it on maven-dev ml: http://mail-archives.apache.org/mod_mbox/maven-dev/201510.mbox/%3CCALhtWkcx%2BP6diR3U7L8NBy1A65BGh%3DSe6yu8V8DKHo34S8pSKQ%40mail.gmail.com%3E followed by explanations on the revert http://mail-archives.apache.org/mod_mbox/maven-dev/201510.mbox/%3CCALhtWkf19xMTA1ae551TW9Hr-uQ4T0Cq85ymUsMeqJ6H%3DtHrVg%40mail.gmail.com%3E > 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] [Updated] (ARCHETYPE-494) Provide a way to change the generated project after archetype:generate execution
[
https://issues.apache.org/jira/browse/ARCHETYPE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated ARCHETYPE-494:
Description:
It would be a nice enhancement to be able to modify the created project after
{{archetype:generate}} 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.
was:It would be a nice enhancement to be able to modify the created project
after archetype:generate 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.
> Provide a way to change the generated project after archetype:generate
> 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:generate}} 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] [Comment Edited] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064015#comment-15064015
]
Jason Mihalick edited comment on MNG-5868 at 12/18/15 2:42 PM:
---
[~schulte77], so was there any change made? It looks like commit
020e35816f184c10c3f87f103336fed4516f7af6 made a change, then that change was
backed out by 5f048234ff44dbf70fcad9f17834c64866f452e1? We are unable to deploy
artifacts to our nexus repository via the Maven release plugin without the
workarounds discussed in MNG-5939.
was (Author: jrmihalick):
So was there any change made? It looks like commit
020e35816f184c10c3f87f103336fed4516f7af6 made a change, then that change was
backed out by 5f048234ff44dbf70fcad9f17834c64866f452e1? We are unable to deploy
artifacts to our nexus repository via the Maven release plugin without the
workarounds discussed in MNG-5939.
> 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.
> *
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063981#comment-15063981
]
Jason Mihalick commented on MNG-5868:
-
As I mentioned on MNG-5939, I confirmed that the problem does not occur on
Maven 3.2.1 (I didn't have access to 3.2.2). It definitely occurs on 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] [Commented] (MNG-5852) "mvn" script invokes /bin/sh but requires /bin/bash functions
[ https://issues.apache.org/jira/browse/MNG-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064120#comment-15064120 ] Jeffrey Alexander commented on MNG-5852: Thank you, that does work as expected! > "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-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064015#comment-15064015
]
Jason Mihalick commented on MNG-5868:
-
So was there any change made? It looks like commit
020e35816f184c10c3f87f103336fed4516f7af6 made a change, then that change was
backed out by 5f048234ff44dbf70fcad9f17834c64866f452e1? We are unable to deploy
artifacts to our nexus repository via the Maven release plugin without the
workarounds discussed in MNG-5939.
> 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
[jira] [Updated] (MCLEAN-54) Support moving instead of deleting directories
[ https://issues.apache.org/jira/browse/MCLEAN-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MCLEAN-54: Issue Type: New Feature (was: Bug) > Support moving instead of deleting directories > -- > > Key: MCLEAN-54 > URL: https://issues.apache.org/jira/browse/MCLEAN-54 > Project: Maven Clean Plugin > Issue Type: New Feature >Affects Versions: 2.5 >Reporter: Leandro de Oliveira > Fix For: more-investigation > > Attachments: MCLEAN-54.patch > > > It'd be helpful if the plugin moved target directories to java.io.tmpdir > instead of delete them because directory deletion on Windows takes a lot of > time if there are many small files to delete. A less than ideal workaround is > described here: > http://bosy.dailydev.org/2009/02/speed-up-your-maven-build-four-times.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MJAVADOC-440) -sourcepath config option does not work with explicit jar file
Anton Atanassov created MJAVADOC-440: Summary: -sourcepath config option does not work with explicit jar file Key: MJAVADOC-440 URL: https://issues.apache.org/jira/browse/MJAVADOC-440 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10.3, 2.10.1 Environment: Linux 2.6.32-358.23.2.el6.x86_64 x86_64 using maven 3.3.3 Reporter: Anton Atanassov I have this config of my javadoc plugin goal in a pom: jar "absolute path to jar" when I execute: mvn clean install -X The resulting options file for the javadoc generation does not mention at all the jar file in the sourcepath option. And obviously the sources in the jar are not included in the generated html documentation. Javadoc tool supports passing jar files with sources into the sourcepath option but it seems that the maven javadoc plugin has a limitation. If I extract the jar and use the folder in the source path all is well. Also it would be nice if I can append to the default source path rather than replace it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSITE-751) Site generation fails with source directory not found on multimodule project
[
https://issues.apache.org/jira/browse/MSITE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064162#comment-15064162
]
Hervé Boutemy commented on MSITE-751:
-
I cannot reproduce the issue: can you provide sample project and instructions
to reproduce it?
and eventually mvn -X result, to have the complete stacktrace on error
> Site generation fails with source directory not found on multimodule project
> -
>
> Key: MSITE-751
> URL: https://issues.apache.org/jira/browse/MSITE-751
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: Maven 3, multi module
>Affects Versions: 3.4
> Environment: Windows 10, JDK8, Maven 3.3.3
>Reporter: Pedro Vieira Silva
>Priority: Blocker
> Fix For: 3.5
>
>
> When building site for a multimodule project maven site:site fails with the
> following error:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-cli) on project
> eclipse: Execution default-cli of goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site failed: Source directory
> 'D:\test-project\target\classes' not exists -> [Help 1]
> {noformat}
> The parent project has packaging pom so it hasn't any target/classes
> directory inside it ...But test-project has several subprojects inside it
> that in turn have packaging type set to jar.
> My maven configuration is as follows:
> {code:xml}
> [...]
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.4
>
>
> org.apache.maven.doxia
> doxia-module-markdown
> 1.6
>
>
>
> UTF-8
> UTF-8
>
>
> [...]
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> false
>
>
>
> aggregate
>
> aggregate
>
> site
>
>
>
> [..]
>
>
> test-project-site
> My Site
> file:///var/www/html/test-project
>
>
> [...]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MJAR-177) Empty string should be treated as default classifier
[
https://issues.apache.org/jira/browse/MJAR-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MJAR-177.
Resolution: Fixed
Assignee: Karl Heinz Marbaise
Fixed in [r1720830|http://svn.apache.org/r1720830]
> Empty string should be treated as default classifier
>
>
> Key: MJAR-177
> URL: https://issues.apache.org/jira/browse/MJAR-177
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: $ mvn -version
> Apache Maven 3.0.4
> Maven home: /usr/share/maven
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.11.0-14-generic", arch: "amd64", family: "unix"
>Reporter: Stefan Fussenegger
>Assignee: Karl Heinz Marbaise
> Fix For: 3.0.0
>
>
> I'm not an expert for Maven internals, but there seem to be subtle
> differences regarding empty properties. Sometimes they are set to null and
> sometimes they remain an empty string (""). The later causes an error when
> used as classifier
> This seems to be the problematic code from AbstratJarMojo.java:
> {code:java}
> String classifier = getClassifier();
> if ( classifier != null ) // ERROR check for empty string
> {
> projectHelper.attachArtifact( getProject(), getType(), classifier,
> jarFile );
> }
> else
> {
> getProject().getArtifact().setFile( jarFile );
> }
> {code}
> The resulting error is
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:2.4:jar (default-jar) on project
> sample-project: Execution default-jar of goal
> org.apache.maven.plugins:maven-jar-plugin:2.4:jar failed: For artifact
> {org.example:sample-project:1.0.0-SNAPSHOT:jar}: An attached artifact must
> have a different ID than its corresponding main artifact. -> [Help 1]
> {code}
> It's not easy to set a property to "" though as properties from XML will
> typically resolve to null but some plugins do. For example, it's possible to
> use gmaven-plugin to achieve this:
> {code:xml}
>
> org.codehaus.gmaven
> gmaven-plugin
>
>
> artifact-classifier
> initialize
>
> execute
>
>
>
> project.properties['artifact.classifier'] = "";
>
>
>
>
>
>
> maven-jar-plugin
> ${maven-jar-plugin.version}
> true
>
> ${artifact.classifier}
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MJAR-177) Empty string should be treated as default classifier
[
https://issues.apache.org/jira/browse/MJAR-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MJAR-177:
-
Fix Version/s: 3.0.0
> Empty string should be treated as default classifier
>
>
> Key: MJAR-177
> URL: https://issues.apache.org/jira/browse/MJAR-177
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: $ mvn -version
> Apache Maven 3.0.4
> Maven home: /usr/share/maven
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.11.0-14-generic", arch: "amd64", family: "unix"
>Reporter: Stefan Fussenegger
> Fix For: 3.0.0
>
>
> I'm not an expert for Maven internals, but there seem to be subtle
> differences regarding empty properties. Sometimes they are set to null and
> sometimes they remain an empty string (""). The later causes an error when
> used as classifier
> This seems to be the problematic code from AbstratJarMojo.java:
> {code:java}
> String classifier = getClassifier();
> if ( classifier != null ) // ERROR check for empty string
> {
> projectHelper.attachArtifact( getProject(), getType(), classifier,
> jarFile );
> }
> else
> {
> getProject().getArtifact().setFile( jarFile );
> }
> {code}
> The resulting error is
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:2.4:jar (default-jar) on project
> sample-project: Execution default-jar of goal
> org.apache.maven.plugins:maven-jar-plugin:2.4:jar failed: For artifact
> {org.example:sample-project:1.0.0-SNAPSHOT:jar}: An attached artifact must
> have a different ID than its corresponding main artifact. -> [Help 1]
> {code}
> It's not easy to set a property to "" though as properties from XML will
> typically resolve to null but some plugins do. For example, it's possible to
> use gmaven-plugin to achieve this:
> {code:xml}
>
> org.codehaus.gmaven
> gmaven-plugin
>
>
> artifact-classifier
> initialize
>
> execute
>
>
>
> project.properties['artifact.classifier'] = "";
>
>
>
>
>
>
> maven-jar-plugin
> ${maven-jar-plugin.version}
> true
>
> ${artifact.classifier}
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MJAR-198) jar:jar without classifier replaces default jar
[
https://issues.apache.org/jira/browse/MJAR-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064380#comment-15064380
]
Karl Heinz Marbaise commented on MJAR-198:
--
So after diving into the attached example i'm completely puzzled, cause the
attached example uses {{finalName}} which will change only the name for
{{target}} folder and not the filename which is used during the install/deploy
part. If you really need to have different jars you need to use a classifier
something [like
this|http://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html]:
{code:xml}
...
...
org.apache.maven.plugins
maven-jar-plugin
2.6
package
jar
client
**/service/*
...
...
{code}
So the question is: What should happen if there is no classifier given and the
plugin will be executed a second time? From my point of view it should fail the
build in such cases...
> jar:jar without classifier replaces default jar
> ---
>
> Key: MJAR-198
> URL: https://issues.apache.org/jira/browse/MJAR-198
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1, 2.3.2, 2.4, 2.5, 2.6
> Environment: Windows 8.1 Pro
> JDK 1.8 45
> Maven 3.2.5
>Reporter: Elias Elmqvist Wulcan
>Priority: Minor
> Labels: newbie
> Attachments: 0.tar, mvn.install.debug.txt
>
>
> If I add an execution of jar:jar in a project of packaging jar and do not
> configure a classifier for the additional jar, the additional jar will be
> installed instead of the default jar.
> Omitting a classifier in the configuration for the goal jar:jar is documented
> to have the effect that the jar will not be attached and this is the behavior
> that I want. Instead, the jar is attached and replaces the default jar.
> AbstractJarMojo.java:254 checks nullness of classifier to decide whether to
> attach or not. JarMojo.java:51 declares a default value the empty string for
> classifier. Maybe the combination of these lines cause the bug.
> http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java?revision=1664111=markup
> http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/JarMojo.java?revision=1664111=markup
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MJAR-177) Empty string should be treated as default classifier
[
https://issues.apache.org/jira/browse/MJAR-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064384#comment-15064384
]
Hudson commented on MJAR-177:
-
SUCCESS: Integrated in maven-plugins #4893 (See
[https://builds.apache.org/job/maven-plugins/4893/])
[MJAR-177] Empty string should be treated as default classifier
- The classifier will now correctly being checked against null
and to contain more than white spaces. The default value for
the classifier empty string has been removed. (khmarbaise:
[http://svn.apache.org/viewvc/?view=rev=1720830])
*
maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java
* maven-jar-plugin/src/main/java/org/apache/maven/plugins/jar/JarMojo.java
* maven-jar-plugin/src/test/java/org/apache/maven/plugins/jar/JarMojoTest.java
> Empty string should be treated as default classifier
>
>
> Key: MJAR-177
> URL: https://issues.apache.org/jira/browse/MJAR-177
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: $ mvn -version
> Apache Maven 3.0.4
> Maven home: /usr/share/maven
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.11.0-14-generic", arch: "amd64", family: "unix"
>Reporter: Stefan Fussenegger
>Assignee: Karl Heinz Marbaise
> Fix For: 3.0.0
>
>
> I'm not an expert for Maven internals, but there seem to be subtle
> differences regarding empty properties. Sometimes they are set to null and
> sometimes they remain an empty string (""). The later causes an error when
> used as classifier
> This seems to be the problematic code from AbstratJarMojo.java:
> {code:java}
> String classifier = getClassifier();
> if ( classifier != null ) // ERROR check for empty string
> {
> projectHelper.attachArtifact( getProject(), getType(), classifier,
> jarFile );
> }
> else
> {
> getProject().getArtifact().setFile( jarFile );
> }
> {code}
> The resulting error is
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:2.4:jar (default-jar) on project
> sample-project: Execution default-jar of goal
> org.apache.maven.plugins:maven-jar-plugin:2.4:jar failed: For artifact
> {org.example:sample-project:1.0.0-SNAPSHOT:jar}: An attached artifact must
> have a different ID than its corresponding main artifact. -> [Help 1]
> {code}
> It's not easy to set a property to "" though as properties from XML will
> typically resolve to null but some plugins do. For example, it's possible to
> use gmaven-plugin to achieve this:
> {code:xml}
>
> org.codehaus.gmaven
> gmaven-plugin
>
>
> artifact-classifier
> initialize
>
> execute
>
>
>
> project.properties['artifact.classifier'] = "";
>
>
>
>
>
>
> maven-jar-plugin
> ${maven-jar-plugin.version}
> true
>
> ${artifact.classifier}
>
>
> {code}
--
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
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064172#comment-15064172
]
Christian Schulte commented on MNG-5868:
Pre 3.2.3 behaviour got restored in commit
[5f048234ff44dbf70fcad9f17834c64866f452e1|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=5f048234ff44dbf70fcad9f17834c64866f452e1]
> 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] [Resolved] (MNG-5852) "mvn" script invokes /bin/sh but requires /bin/bash functions
[ https://issues.apache.org/jira/browse/MNG-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte resolved MNG-5852. Resolution: Fixed Fix Version/s: 3.4.0 > "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 > Fix For: 3.4.0 > > > 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-5837) Syntax error in bin/mvn on Solaris SPARC
[
https://issues.apache.org/jira/browse/MNG-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064645#comment-15064645
]
ASF GitHub Bot commented on MNG-5837:
-
Github user asfgit closed the pull request at:
https://github.com/apache/maven/pull/50
> 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] [Resolved] (MNG-5837) Syntax error in bin/mvn on Solaris SPARC
[
https://issues.apache.org/jira/browse/MNG-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte resolved MNG-5837.
Resolution: Fixed
Fix Version/s: 3.4.0
> 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
> Fix For: 3.4.0
>
>
> 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] (MJAVADOC-439) Spelling of additionalDependencies is wrong on the page for java doc plugin
[ https://issues.apache.org/jira/browse/MJAVADOC-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MJAVADOC-439: --- Assignee: Michael Osipov > Spelling of additionalDependencies is wrong on the page for java doc plugin > --- > > Key: MJAVADOC-439 > URL: https://issues.apache.org/jira/browse/MJAVADOC-439 > Project: Maven Javadoc Plugin > Issue Type: Documentation >Reporter: Moiz Randhikpurwala >Assignee: Michael Osipov >Priority: Minor > > The spelling of the tags mentioned on the page are wrong, I realized when I > copy pasted the tags and my build failed. > https://maven.apache.org/plugins/maven-javadoc-plugin/examples/additionnal-dependencies.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5832) Cannot override systemPath with dependencyManagement
[
https://issues.apache.org/jira/browse/MNG-5832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064689#comment-15064689
]
Christian Schulte commented on MNG-5832:
Can you please provide a small test project demonstrating the issue.
> Cannot override systemPath with dependencyManagement
>
>
> Key: MNG-5832
> URL: https://issues.apache.org/jira/browse/MNG-5832
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.5
>Reporter: Marcin Wisnicki
>Assignee: Christian Schulte
>
> CRaSH has [invalid path|https://jira.exoplatform.org/browse/CRASH-225] to
> tools.jar in systemPath which causes errors during generation of maven site.
> I though I should be able to override it with dependencyManagement like so
> {code}
>
> com.sun
> tools
> 1.7
> system
> ${java.home}/../lib/tools.jar
>
> {code}
> but it seems to be ignored.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MJAVADOC-439) Spelling of additionalDependencies is wrong
[ https://issues.apache.org/jira/browse/MJAVADOC-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MJAVADOC-439. --- Resolution: Duplicate > Spelling of additionalDependencies is wrong > --- > > Key: MJAVADOC-439 > URL: https://issues.apache.org/jira/browse/MJAVADOC-439 > Project: Maven Javadoc Plugin > Issue Type: Documentation >Reporter: Moiz Randhikpurwala >Priority: Minor > > The spelling of the tags mentioned on the page are wrong, I realized when I > copy pasted the tags and my build failed. > https://maven.apache.org/plugins/maven-javadoc-plugin/examples/additionnal-dependencies.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-439) Spelling of additionalDependencies is wrong
[ https://issues.apache.org/jira/browse/MJAVADOC-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MJAVADOC-439: Assignee: (was: Michael Osipov) > Spelling of additionalDependencies is wrong > --- > > Key: MJAVADOC-439 > URL: https://issues.apache.org/jira/browse/MJAVADOC-439 > Project: Maven Javadoc Plugin > Issue Type: Documentation >Reporter: Moiz Randhikpurwala >Priority: Minor > > The spelling of the tags mentioned on the page are wrong, I realized when I > copy pasted the tags and my build failed. > https://maven.apache.org/plugins/maven-javadoc-plugin/examples/additionnal-dependencies.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MNG-5832) Cannot override systemPath with dependencyManagement
[
https://issues.apache.org/jira/browse/MNG-5832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5832:
--
Assignee: Christian Schulte
> Cannot override systemPath with dependencyManagement
>
>
> Key: MNG-5832
> URL: https://issues.apache.org/jira/browse/MNG-5832
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.5
>Reporter: Marcin Wisnicki
>Assignee: Christian Schulte
>
> CRaSH has [invalid path|https://jira.exoplatform.org/browse/CRASH-225] to
> tools.jar in systemPath which causes errors during generation of maven site.
> I though I should be able to override it with dependencyManagement like so
> {code}
>
> com.sun
> tools
> 1.7
> system
> ${java.home}/../lib/tools.jar
>
> {code}
> but it seems to be ignored.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5837) Syntax error in bin/mvn on Solaris SPARC
[
https://issues.apache.org/jira/browse/MNG-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064674#comment-15064674
]
Hudson commented on MNG-5837:
-
SUCCESS: Integrated in maven-3.x #1175 (See
[https://builds.apache.org/job/maven-3.x/1175/])
[MNG-5837] "mvn" script invokes /bin/sh but requires /bin/bash functions
(schulte: rev d980040ffd4e4ad9343171140270c1725c19a6fe)
* apache-maven/src/bin/mvnyjp
* apache-maven/src/bin/mvn
* apache-maven/src/bin/mvnDebug
> 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
> Fix For: 3.4.0
>
>
> 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] [Updated] (MJAVADOC-385) Fix documentation of feature
[
https://issues.apache.org/jira/browse/MJAVADOC-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-385:
Issue Type: Documentation (was: Bug)
> Fix documentation of feature
> -
>
> Key: MJAVADOC-385
> URL: https://issues.apache.org/jira/browse/MJAVADOC-385
> Project: Maven Javadoc Plugin
> Issue Type: Documentation
>Affects Versions: 2.9.1
>Reporter: Stephan Schroevers
>
> The feature introduced with MJAVADOC-322 had a typo. Code-wise, this was
> fixed in MJAVADOC-334. However, the documentation on the website still has
> the typo. So when I copy-pasted it, it didn't work...
> Anyway, the documentation can be fixed as follows:
> {noformat}
> $ find . -type f -print0 | xargs -0 sed -i 's,additionnal,additional,g'
> $ mv ./src/site/apt/examples/additionnal-dependencies.apt.vm
> ./src/site/apt/examples/additional-dependencies.apt.vm
> $ mv ./src/it/additionnal-dependencies-non-aggregate
> ./src/it/additional-dependencies-non-aggregate
> $ mv ./src/it/additionnal-dependencies ./src/it/additional-dependencies
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MJAVADOC-439) Spelling of additionalDependencies is wrong on the page for java doc plugin
[ https://issues.apache.org/jira/browse/MJAVADOC-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064654#comment-15064654 ] Michael Osipov commented on MJAVADOC-439: - Everything seems to be wrong on this page. > Spelling of additionalDependencies is wrong on the page for java doc plugin > --- > > Key: MJAVADOC-439 > URL: https://issues.apache.org/jira/browse/MJAVADOC-439 > Project: Maven Javadoc Plugin > Issue Type: Documentation >Reporter: Moiz Randhikpurwala >Assignee: Michael Osipov >Priority: Minor > > The spelling of the tags mentioned on the page are wrong, I realized when I > copy pasted the tags and my build failed. > https://maven.apache.org/plugins/maven-javadoc-plugin/examples/additionnal-dependencies.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAVADOC-439) Spelling of additionalDependencies is wrong
[ https://issues.apache.org/jira/browse/MJAVADOC-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MJAVADOC-439: Summary: Spelling of additionalDependencies is wrong (was: Spelling of additionalDependencies is wrong on the page for java doc plugin) > Spelling of additionalDependencies is wrong > --- > > Key: MJAVADOC-439 > URL: https://issues.apache.org/jira/browse/MJAVADOC-439 > Project: Maven Javadoc Plugin > Issue Type: Documentation >Reporter: Moiz Randhikpurwala >Assignee: Michael Osipov >Priority: Minor > > The spelling of the tags mentioned on the page are wrong, I realized when I > copy pasted the tags and my build failed. > https://maven.apache.org/plugins/maven-javadoc-plugin/examples/additionnal-dependencies.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MNG-5832) Cannot override systemPath with dependencyManagement
[
https://issues.apache.org/jira/browse/MNG-5832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte resolved MNG-5832.
Resolution: Not A Problem
I am closing this. You can change that system path by moving a corresponding
dependency nearer to where it is used so that the 'nearest winst' strategy will
use that instead of something else. See method
[manageArtifact|http://maven.apache.org/ref/3.3.9/apidocs/src-html/org/apache/maven/repository/legacy/resolver/DefaultLegacyArtifactCollector.html#line.602].
> Cannot override systemPath with dependencyManagement
>
>
> Key: MNG-5832
> URL: https://issues.apache.org/jira/browse/MNG-5832
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.5
>Reporter: Marcin Wisnicki
>Assignee: Christian Schulte
>
> CRaSH has [invalid path|https://jira.exoplatform.org/browse/CRASH-225] to
> tools.jar in systemPath which causes errors during generation of maven site.
> I though I should be able to override it with dependencyManagement like so
> {code}
>
> com.sun
> tools
> 1.7
> system
> ${java.home}/../lib/tools.jar
>
> {code}
> but it seems to be ignored.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-126) don't copy resources when rendering documents but copy all resources in 1 call
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064967#comment-15064967 ] Hudson commented on DOXIASITETOOLS-126: --- FAILURE: Integrated in doxia-all #193 (See [https://builds.apache.org/job/doxia-all/193/]) [DOXIASITETOOLS-126] don't copy resources when rendering documents (hboutemy: [http://svn.apache.org/viewvc/?view=rev=1720856]) * ./doxia-sitetools/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java * ./doxia-sitetools/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/Renderer.java * ./doxia-sitetools/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/RenderingContext.java > don't copy resources when rendering documents but copy all resources in 1 call > -- > > Key: DOXIASITETOOLS-126 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-126 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 1.6 >Reporter: Hervé Boutemy > Fix For: 1.7 > > > found while working on MSITE-744: copying resources during document rendering > has bad side effects: > - multiple executions of resources copy, since rendering is done 3 times > (Doxia docs, reports and generated Doxia docs) > - when there is no generated Doxia docs to render, resources are not copied > (= MSITE-744) > in addition, calling copyResources for each resource directory copies skin > resources for each resource directory: instead of having a > siteResourcesDirectory argument, the method should iterate directly on site > rendering context -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5538) mvn start script causes cygwin warning
[
https://issues.apache.org/jira/browse/MNG-5538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064980#comment-15064980
]
ASF GitHub Bot commented on MNG-5538:
-
Github user asfgit closed the pull request at:
https://github.com/apache/maven/pull/27
> mvn start script causes cygwin warning
> --
>
> Key: MNG-5538
> URL: https://issues.apache.org/jira/browse/MNG-5538
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.1.1
> Environment: windows 7 64bit, cygwin 1.7.25, mvn 3.1.1
>Reporter: Martin Vavra
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: mvn.diff, mvn.fixed, mvn.orig
>
>
> The shell script mvn in the bin directory of maven does various tricks with
> the variable M2_HOME but before the last line (the JAVACMD) is executed, the
> value of M2_HOME contains the Windows-style path to maven.
> One of the arguments to java.exe is:
> {noformat}-classpath "${M2_HOME}"/boot/plexus-classworlds-*.jar{noformat}
> The resolving of the asterisk is still done by the cygwin bash,
> and since M2_HOME is windows-style at that time,
> cygwin generates the following warning:
> {noformat}
> cygwin warning:
> MS-DOS style path detected: D:\apps\apache-maven-3.1.1/boot/
> Preferred POSIX equivalent is: /cygdrive/d/apps/apache-maven-3.1.1/boot/
> CYGWIN environment variable option "nodosfilewarning" turns off this
> warning.
> Consult the user's guide for more details about POSIX paths:
> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> {noformat}
> This can be fixed quite easily - attached please find my proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MNG-5538) mvn start script causes cygwin warning
[
https://issues.apache.org/jira/browse/MNG-5538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte resolved MNG-5538.
Resolution: Fixed
Fix Version/s: 3.4.0
> mvn start script causes cygwin warning
> --
>
> Key: MNG-5538
> URL: https://issues.apache.org/jira/browse/MNG-5538
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.1.1
> Environment: windows 7 64bit, cygwin 1.7.25, mvn 3.1.1
>Reporter: Martin Vavra
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: mvn.diff, mvn.fixed, mvn.orig
>
>
> The shell script mvn in the bin directory of maven does various tricks with
> the variable M2_HOME but before the last line (the JAVACMD) is executed, the
> value of M2_HOME contains the Windows-style path to maven.
> One of the arguments to java.exe is:
> {noformat}-classpath "${M2_HOME}"/boot/plexus-classworlds-*.jar{noformat}
> The resolving of the asterisk is still done by the cygwin bash,
> and since M2_HOME is windows-style at that time,
> cygwin generates the following warning:
> {noformat}
> cygwin warning:
> MS-DOS style path detected: D:\apps\apache-maven-3.1.1/boot/
> Preferred POSIX equivalent is: /cygdrive/d/apps/apache-maven-3.1.1/boot/
> CYGWIN environment variable option "nodosfilewarning" turns off this
> warning.
> Consult the user's guide for more details about POSIX paths:
> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> {noformat}
> This can be fixed quite easily - attached please find my proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MNG-5538) mvn start script causes cygwin warning
[
https://issues.apache.org/jira/browse/MNG-5538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5538:
--
Assignee: Christian Schulte
> mvn start script causes cygwin warning
> --
>
> Key: MNG-5538
> URL: https://issues.apache.org/jira/browse/MNG-5538
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.1.1
> Environment: windows 7 64bit, cygwin 1.7.25, mvn 3.1.1
>Reporter: Martin Vavra
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: mvn.diff, mvn.fixed, mvn.orig
>
>
> The shell script mvn in the bin directory of maven does various tricks with
> the variable M2_HOME but before the last line (the JAVACMD) is executed, the
> value of M2_HOME contains the Windows-style path to maven.
> One of the arguments to java.exe is:
> {noformat}-classpath "${M2_HOME}"/boot/plexus-classworlds-*.jar{noformat}
> The resolving of the asterisk is still done by the cygwin bash,
> and since M2_HOME is windows-style at that time,
> cygwin generates the following warning:
> {noformat}
> cygwin warning:
> MS-DOS style path detected: D:\apps\apache-maven-3.1.1/boot/
> Preferred POSIX equivalent is: /cygdrive/d/apps/apache-maven-3.1.1/boot/
> CYGWIN environment variable option "nodosfilewarning" turns off this
> warning.
> Consult the user's guide for more details about POSIX paths:
> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> {noformat}
> This can be fixed quite easily - attached please find my proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DOXIASITETOOLS-126) don't copy resources when rendering documents but copy all resources in 1 call
Hervé Boutemy created DOXIASITETOOLS-126: Summary: don't copy resources when rendering documents but copy all resources in 1 call Key: DOXIASITETOOLS-126 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-126 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Site renderer Affects Versions: 1.6 Reporter: Hervé Boutemy Fix For: 1.7 found while working on MSITE-744: copying resources during document rendering has bad side effects: - multiple executions of resources copy, since rendering is done 3 times (Doxia docs, reports and generated Doxia docs) - when there is no generated Doxia docs to render, resources are not copied (= MSITE-744) in addition, calling copyResources for each resource directory copies skin resources for each resource directory: instead of having a siteResourcesDirectory argument, the method should iterate directly on site rendering context -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DOXIASITETOOLS-129) remove (Site)Renderer.renderDocument() method
Hervé Boutemy created DOXIASITETOOLS-129: Summary: remove (Site)Renderer.renderDocument() method Key: DOXIASITETOOLS-129 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-129 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Site renderer Affects Versions: 1.6 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: 1.7 this method should not exist in (Site)Renderer and be called from DoxiaDocumentRenderer.renderDocument(), which cause confusion ((Site)Renderer is here supposed to render a Doxia document: it was supposed to work on site) instead, it should be implemented directly in DoxiaDocumentRenderer.renderDocument() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSITE-744) Regression in 3.4: File in `generated-site/resources/` ignored unless there is a file in `generated-site/markdown/` too
[ https://issues.apache.org/jira/browse/MSITE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064968#comment-15064968 ] Hudson commented on MSITE-744: -- FAILURE: Integrated in maven-plugins #4894 (See [https://builds.apache.org/job/maven-plugins/4894/]) [MSITE-744] copy generated resources even if there is no generated Doxia document (hboutemy: [http://svn.apache.org/viewvc/?view=rev=1720857]) * maven-site-plugin/src/it/resources * maven-site-plugin/src/it/resources/invoker.properties * maven-site-plugin/src/it/resources/pom.xml * maven-site-plugin/src/it/resources/src * maven-site-plugin/src/it/resources/src/site * maven-site-plugin/src/it/resources/src/site/resources * maven-site-plugin/src/it/resources/src/site/resources/src-site-resources.txt * maven-site-plugin/src/it/resources/verify.groovy * maven-site-plugin/src/main/java/org/apache/maven/plugins/site/render/AbstractSiteRenderingMojo.java * maven-site-plugin/src/main/java/org/apache/maven/plugins/site/render/ReportDocumentRenderer.java * maven-site-plugin/src/main/java/org/apache/maven/plugins/site/render/SiteMojo.java * maven-site-plugin/src/main/java/org/apache/maven/plugins/site/run/SiteRunMojo.java > Regression in 3.4: File in `generated-site/resources/` ignored unless there > is a file in `generated-site/markdown/` too > --- > > Key: MSITE-744 > URL: https://issues.apache.org/jira/browse/MSITE-744 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.4 >Reporter: Christian Schlichtherle > Fix For: 3.5 > > Attachments: maven-site-test.zip > > > The attached test project copies a file into `generated-site/resources/` and > calls the maven-site-plugin to render the site. The site will not contain the > resource file however, unless another file is copied into > `generated-site/markdown/`, too. You need to edit the pom.xml to uncomment > the instruction for this. > If you change the version of the maven-site-plugin from 3.4 to 3.3, then it > works like expected, with or without the additional file in > `generated-site/markdown/`. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5538) mvn start script causes cygwin warning
[
https://issues.apache.org/jira/browse/MNG-5538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064997#comment-15064997
]
Hudson commented on MNG-5538:
-
SUCCESS: Integrated in maven-3.x #1177 (See
[https://builds.apache.org/job/maven-3.x/1177/])
[MNG-5538] mvn start script causes cygwin warning (schulte: rev
5ca3ca55086d125366b58a3d58c1df77604dedbf)
* apache-maven/src/bin/mvn
> mvn start script causes cygwin warning
> --
>
> Key: MNG-5538
> URL: https://issues.apache.org/jira/browse/MNG-5538
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.1.1
> Environment: windows 7 64bit, cygwin 1.7.25, mvn 3.1.1
>Reporter: Martin Vavra
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: mvn.diff, mvn.fixed, mvn.orig
>
>
> The shell script mvn in the bin directory of maven does various tricks with
> the variable M2_HOME but before the last line (the JAVACMD) is executed, the
> value of M2_HOME contains the Windows-style path to maven.
> One of the arguments to java.exe is:
> {noformat}-classpath "${M2_HOME}"/boot/plexus-classworlds-*.jar{noformat}
> The resolving of the asterisk is still done by the cygwin bash,
> and since M2_HOME is windows-style at that time,
> cygwin generates the following warning:
> {noformat}
> cygwin warning:
> MS-DOS style path detected: D:\apps\apache-maven-3.1.1/boot/
> Preferred POSIX equivalent is: /cygdrive/d/apps/apache-maven-3.1.1/boot/
> CYGWIN environment variable option "nodosfilewarning" turns off this
> warning.
> Consult the user's guide for more details about POSIX paths:
> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> {noformat}
> This can be fixed quite easily - attached please find my proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5538) mvn start script causes cygwin warning
[
https://issues.apache.org/jira/browse/MNG-5538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065104#comment-15065104
]
Hudson commented on MNG-5538:
-
SUCCESS: Integrated in maven-3.x #1178 (See
[https://builds.apache.org/job/maven-3.x/1178/])
[MNG-5538] mvn start script causes cygwin warning (schulte: rev
6aa015d116fc6d98329c5ee020073d11cf3cb8d4)
* apache-maven/src/bin/mvn
> mvn start script causes cygwin warning
> --
>
> Key: MNG-5538
> URL: https://issues.apache.org/jira/browse/MNG-5538
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.1.1
> Environment: windows 7 64bit, cygwin 1.7.25, mvn 3.1.1
>Reporter: Martin Vavra
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: mvn.diff, mvn.fixed, mvn.orig
>
>
> The shell script mvn in the bin directory of maven does various tricks with
> the variable M2_HOME but before the last line (the JAVACMD) is executed, the
> value of M2_HOME contains the Windows-style path to maven.
> One of the arguments to java.exe is:
> {noformat}-classpath "${M2_HOME}"/boot/plexus-classworlds-*.jar{noformat}
> The resolving of the asterisk is still done by the cygwin bash,
> and since M2_HOME is windows-style at that time,
> cygwin generates the following warning:
> {noformat}
> cygwin warning:
> MS-DOS style path detected: D:\apps\apache-maven-3.1.1/boot/
> Preferred POSIX equivalent is: /cygdrive/d/apps/apache-maven-3.1.1/boot/
> CYGWIN environment variable option "nodosfilewarning" turns off this
> warning.
> Consult the user's guide for more details about POSIX paths:
> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> {noformat}
> This can be fixed quite easily - attached please find my proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DOXIASITETOOLS-128) rename RenderingContext to DocumentRenderingContext
Hervé Boutemy created DOXIASITETOOLS-128: Summary: rename RenderingContext to DocumentRenderingContext Key: DOXIASITETOOLS-128 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-128 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Site renderer Affects Versions: 1.6 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: 1.7 currently, we have RenderingContext and SiteRenderingContext renaming RenderingContext to DocumentRenderingContext will ease understanding -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DOXIASITETOOLS-127) rename Renderer interface to SiteRenderer (with RendererException
Hervé Boutemy created DOXIASITETOOLS-127: Summary: rename Renderer interface to SiteRenderer (with RendererException Key: DOXIASITETOOLS-127 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-127 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Site renderer Affects Versions: 1.6 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: 1.7 Renderer is implemented by DefaultSiteRenderer would make it more clear if was renamed to SiteRenderer (to better differentiate renderers related to documents from renderers related to site) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-126) don't copy resources when rendering documents but copy all resources in 1 call
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065004#comment-15065004 ] Hudson commented on DOXIASITETOOLS-126: --- SUCCESS: Integrated in doxia-all #194 (See [https://builds.apache.org/job/doxia-all/194/]) [DOXIASITETOOLS-126] fixed error reported by Checkstyle (hboutemy: [http://svn.apache.org/viewvc/?view=rev=1720861]) * ./doxia-sitetools/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java > don't copy resources when rendering documents but copy all resources in 1 call > -- > > Key: DOXIASITETOOLS-126 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-126 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 1.6 >Reporter: Hervé Boutemy > Fix For: 1.7 > > > found while working on MSITE-744: copying resources during document rendering > has bad side effects: > - multiple executions of resources copy, since rendering is done 3 times > (Doxia docs, reports and generated Doxia docs) > - when there is no generated Doxia docs to render, resources are not copied > (= MSITE-744) > in addition, calling copyResources for each resource directory copies skin > resources for each resource directory: instead of having a > siteResourcesDirectory argument, the method should iterate directly on site > rendering context -- 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
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064807#comment-15064807
]
Jason Mihalick commented on MNG-5868:
-
Ok, thank you. I built maven from the latest 3.4.0-SNAPSHOT and I can confirm
that the problem I was having when deploying artifacts to Nexus using the
release plugin did not occur when building my project using maven
3.4.0-SNAPSHOT. Nice job.
> 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] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064901#comment-15064901
]
Hudson commented on MNG-5868:
-
SUCCESS: Integrated in maven-3.x #1176 (See
[https://builds.apache.org/job/maven-3.x/1176/])
[MNG-5868] Adding serval times the same artifact via MavenProjectHelper
(schulte: rev dc7b41455499e7f6b58fbbd05472142f052c)
*
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.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
[jira] [Closed] (MNG-5830) maven.multiModuleProjectDirectory system propery is not set
[
https://issues.apache.org/jira/browse/MNG-5830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-5830.
--
Resolution: Cannot Reproduce
Assignee: Christian Schulte
I just downloaded Maven 3.3.1 and 3.3.3 from
[here|http://archive.apache.org/dist/maven/maven-3/].
{code}
$ env M2_HOME=/tmp/apache-maven-3.3.1 /tmp/apache-maven-3.3.1/bin/mvn -v
Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c;
2015-03-13T21:10:27+01:00)
Maven home: /tmp/apache-maven-3.3.1
Java version: 1.8.0_45, vendor: Oracle Corporation
Java home: /usr/local/jdk-1.8.0/jre
Default locale: en_DE, platform encoding: UTF-8
{code}
{code}
$ env M2_HOME=/tmp/apache-maven-3.3.3 /tmp/apache-maven-3.3.3/bin/mvn -v
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
2015-04-22T13:57:37+02:00)
Maven home: /tmp/apache-maven-3.3.3
Java version: 1.8.0_45, vendor: Oracle Corporation
Java home: /usr/local/jdk-1.8.0/jre
Default locale: en_DE, platform encoding: UTF-8
{code}
Not reproducible.
> maven.multiModuleProjectDirectory system propery is not set
> ---
>
> Key: MNG-5830
> URL: https://issues.apache.org/jira/browse/MNG-5830
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build, Command Line
>Affects Versions: 3.3.1, 3.3.3
>Reporter: Krzysztof Sobkowiak
>Assignee: Christian Schulte
> Labels: Linux
>
> I have downloaded the newest Maven 3.3.3 and point the M2_HOME to the
> directory with unpacked Maven. {{mvn -v}} produces following error (whereas
> the versions prior to 3.1.1 worked correctly)
> {code}
> kso@lenovo:/tmp$ export
> M2_HOME=/home/kso/work/pde/dev/maven/apache-maven-3.3.3/
> kso@lenovo:/tmp$ mvn -v
> -Dmaven.multiModuleProjectDirectory system propery is not set. Check $M2_HOME
> environment variable and mvn script match.kso@lenovo:/tmp$
> {code}
> The same problem when I want to build any maven project.
> Below the same output with Maven 3.2.5 to give you informations about my
> environment
> {code}
> kso@lenovo:/tmp$ export
> M2_HOME=/home/kso/work/pde/dev/maven/apache-maven-3.2.5/
> kso@lenovo:/tmp$ mvn -v
> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
> 2014-12-14T18:29:23+01:00)
> Maven home: /home/kso/work/pde/dev/maven/apache-maven-3.2.5
> Java version: 1.7.0_71, vendor: Oracle Corporation
> Java home: /home/kso/work/pde/run/jvm/jdk1.7.0_71/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-38-generic", arch: "amd64", family: "unix"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEPLOY-177) Maven release:perform hangs when downloading maven-metadata.xml
[
https://issues.apache.org/jira/browse/MDEPLOY-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065264#comment-15065264
]
Wolfgang Fahl commented on MDEPLOY-177:
---
In the following environment:
mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /opt/local/share/java/maven3
Java version: 1.8.0_65, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "10.9.5", arch: "x86_64", family: "mac"
The issue got worse again. mvn hangs on running scp but this time there is no
message at all. The famous (x/x-1) message is not shown any more. wagon-ssh
2.10 is configured.
> Maven release:perform hangs when downloading maven-metadata.xml
> ---
>
> Key: MDEPLOY-177
> URL: https://issues.apache.org/jira/browse/MDEPLOY-177
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.1
> Environment: $ mvn -v
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T11:37:52-06:00)
> Maven home: /usr/local/Cellar/maven/3.2.1/libexec
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.2", arch: "x86_64", family: "mac"
>Reporter: Michael Heuer
>Priority: Critical
> Fix For: waiting-for-feedback
>
> Attachments: deploy-debug.txt, release-perform-3.0.5.txt,
> release-perform-debug.txt
>
>
> When attempting to mvn release:perform
> {code:none}
> $ mvn release:perform
> ...
> [INFO] [INFO]
>
> [INFO] [INFO] Building biojava-legacy 1.8.5
> [INFO] [INFO]
>
> [INFO] [INFO]
> [INFO] [INFO] >>> maven-source-plugin:2.2.1:jar (attach-sources) @
> biojava-legacy >>>
> [INFO] [INFO]
> [INFO] [INFO] <<< maven-source-plugin:2.2.1:jar (attach-sources) @
> biojava-legacy <<<
> [INFO] [INFO]
> [INFO] [INFO] --- maven-source-plugin:2.2.1:jar (attach-sources) @
> biojava-legacy ---
> [INFO] [INFO]
> [INFO] [INFO] --- maven-javadoc-plugin:2.9.1:jar (attach-javadocs) @
> biojava-legacy ---
> [INFO] [INFO] Not executing Javadoc as the project is not a Java
> classpath-capable package
> [INFO] [INFO]
> [INFO] [INFO] --- maven-install-plugin:2.4:install (default-install) @
> biojava-legacy ---
> [INFO] [INFO] Installing
> /Users/xxx/working/biojava-legacy/target/checkout/pom.xml to
> /Users/xxx/.m2/repository/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
> [INFO] [INFO]
> [INFO] [INFO] --- maven-deploy-plugin:2.8.1:deploy (default-deploy) @
> biojava-legacy ---
> [INFO] Uploading:
> scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
> [INFO] 4/9 KB
> [INFO] 8/9 KB
> [INFO] 9/9 KB
> [INFO]
> [INFO] Uploaded:
> scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
> (9 KB at 3.0 KB/sec)
> [INFO] Downloading:
> scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/maven-metadata.xml
> [INFO] 750/750 B
> [INFO] 751/750 B
> {code}
> the build hangs at this point. It appears there might be a difference
> between the expected file size and the downloaded file size, but no
> warning/error messages appear, the build just hangs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MDEPLOY-177) Maven release:perform hangs when downloading maven-metadata.xml
[
https://issues.apache.org/jira/browse/MDEPLOY-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065264#comment-15065264
]
Wolfgang Fahl edited comment on MDEPLOY-177 at 12/19/15 6:08 AM:
-
In the following environment:
mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /opt/local/share/java/maven3
Java version: 1.8.0_65, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "10.9.5", arch: "x86_64", family: "mac"
The issue got worse again. mvn hangs on running scp but this time there is no
message at all. The famous (x/x-1) message is not shown any more. wagon-ssh
2.10 is configured.
Downgrading to mvn 3.0.5 (sigh ...) fixes the issue
was (Author: wolfgangfahl):
In the following environment:
mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /opt/local/share/java/maven3
Java version: 1.8.0_65, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "10.9.5", arch: "x86_64", family: "mac"
The issue got worse again. mvn hangs on running scp but this time there is no
message at all. The famous (x/x-1) message is not shown any more. wagon-ssh
2.10 is configured.
> Maven release:perform hangs when downloading maven-metadata.xml
> ---
>
> Key: MDEPLOY-177
> URL: https://issues.apache.org/jira/browse/MDEPLOY-177
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.1
> Environment: $ mvn -v
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T11:37:52-06:00)
> Maven home: /usr/local/Cellar/maven/3.2.1/libexec
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.2", arch: "x86_64", family: "mac"
>Reporter: Michael Heuer
>Priority: Critical
> Fix For: waiting-for-feedback
>
> Attachments: deploy-debug.txt, release-perform-3.0.5.txt,
> release-perform-debug.txt
>
>
> When attempting to mvn release:perform
> {code:none}
> $ mvn release:perform
> ...
> [INFO] [INFO]
>
> [INFO] [INFO] Building biojava-legacy 1.8.5
> [INFO] [INFO]
>
> [INFO] [INFO]
> [INFO] [INFO] >>> maven-source-plugin:2.2.1:jar (attach-sources) @
> biojava-legacy >>>
> [INFO] [INFO]
> [INFO] [INFO] <<< maven-source-plugin:2.2.1:jar (attach-sources) @
> biojava-legacy <<<
> [INFO] [INFO]
> [INFO] [INFO] --- maven-source-plugin:2.2.1:jar (attach-sources) @
> biojava-legacy ---
> [INFO] [INFO]
> [INFO] [INFO] --- maven-javadoc-plugin:2.9.1:jar (attach-javadocs) @
> biojava-legacy ---
> [INFO] [INFO] Not executing Javadoc as the project is not a Java
> classpath-capable package
> [INFO] [INFO]
> [INFO] [INFO] --- maven-install-plugin:2.4:install (default-install) @
> biojava-legacy ---
> [INFO] [INFO] Installing
> /Users/xxx/working/biojava-legacy/target/checkout/pom.xml to
> /Users/xxx/.m2/repository/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
> [INFO] [INFO]
> [INFO] [INFO] --- maven-deploy-plugin:2.8.1:deploy (default-deploy) @
> biojava-legacy ---
> [INFO] Uploading:
> scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
> [INFO] 4/9 KB
> [INFO] 8/9 KB
> [INFO] 9/9 KB
> [INFO]
> [INFO] Uploaded:
> scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
> (9 KB at 3.0 KB/sec)
> [INFO] Downloading:
> scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/maven-metadata.xml
> [INFO] 750/750 B
> [INFO] 751/750 B
> {code}
> the build hangs at this point. It appears there might be a difference
> between the expected file size and the downloaded file size, but no
> warning/error messages appear, the build just hangs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
