[jira] [Commented] (MINSTALL-156) generatePom=false not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761659#comment-16761659
]
Robert Lieske commented on MINSTALL-156:
I uploaded a sample project to:
https://github.com/robert9876/test1.git
> generatePom=false not working with 3.0.0-M1
> ---
>
> Key: MINSTALL-156
> URL: https://issues.apache.org/jira/browse/MINSTALL-156
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Robert Lieske
>Priority: Major
>
> Steps to reproduce:
> {{mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT}}
>
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:2.5.2:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO]
>
> {quote}
>
> changing the version of the maven-install-plugin in pom.xml to
> {{}}
> {{ maven-install-plugin}}
> {{ 3.0.0-M1}}
> {{ }}
>
> the same call to
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO] Installing
> C:\Users\xxx\AppData\Local\Temp\test1-1.0-SNAPSHOT7157743325898943802.pom to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
> [INFO]
>
> {quote}
>
> Which also installs a POM - which is not what we want!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6500) Dependency resolution broken with Java 11
[ https://issues.apache.org/jira/browse/MNG-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761648#comment-16761648 ] Jörg Hohwiller commented on MNG-6500: - [~khmarbaise] I feel ashamed as I made you do my own homework. Thank you so much for figuring out what I missed. Indeed kind of odd that hibernate-validator seems to depend on JavaFX. Seems I have to look for an alternative implementation such as apache validation. > Dependency resolution broken with Java 11 > - > > Key: MNG-6500 > URL: https://issues.apache.org/jira/browse/MNG-6500 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.4 > Environment: Java 11 >Reporter: Jörg Hohwiller >Assignee: Karl Heinz Marbaise >Priority: Major > > I am facing an issue that some transitive dependencies are missing on maven > dependency resolution. This reproducible works fine with older Java (java8) > and always fails with java 11. > The code that fails can be found in this feature branch: > [https://github.com/hohwille/devon4j/tree/feature-16-java-11-build] > A detailed description of the issue can be found here: > [https://github.com/devonfw/devon4j/issues/16] > It would be awesome if someone could have a look and make maven work smooth > with Java 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MANTRUN-216) CLONE - Use of AntRun during clean phase fails multiproject with intermodule dependencies
[ https://issues.apache.org/jira/browse/MANTRUN-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark updated MANTRUN-216: - Description: Attaching the antrun plugin to the clean phase causes it to interfere with local dependency resolution for sibling projects. An example is attached to MANTRUN-78 . The project consists of project 'test' with modules 'test-a' and test-b'. 'test-a' depends on 'test-b'. If you run "mvn clean" on the root POM, the clean succeeds. If you run "mvn clean -Pbuild-failure" it fails. was: Attaching the antrun plugin to the clean phase causes it to interfere with local dependency resolution for sibling projects. An example is attached. The project consists of project 'test' with modules 'test-a' and test-b'. 'test-a' depends on 'test-b'. If you run "mvn clean" on the root POM, the clean succeeds. If you run "mvn clean -Pbuild-failure" it fails. > CLONE - Use of AntRun during clean phase fails multiproject with intermodule > dependencies > - > > Key: MANTRUN-216 > URL: https://issues.apache.org/jira/browse/MANTRUN-216 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.8 > Environment: Maven version: 3.6.0 > Java version: 11.0.2-open > OS name: ubuntu 18 x86-64 >Reporter: Mark >Priority: Major > > Attaching the antrun plugin to the clean phase causes it to interfere with > local dependency resolution for sibling projects. > An example is attached to MANTRUN-78 . > The project consists of project 'test' with modules 'test-a' and test-b'. > 'test-a' depends on 'test-b'. > If you run "mvn clean" on the root POM, the clean succeeds. > If you run "mvn clean -Pbuild-failure" it fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MSHARED-800) remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761741#comment-16761741
]
Michael Osipov edited comment on MSHARED-800 at 2/6/19 1:37 PM:
I order isn't stable because, as far as I know, it backed by a hash. It should
be at most a linked hash map or a lnked tree set. At least something stable.
Let's have another ticket for that.
was (Author: michael-o):
I order isn't stable because, as far as I know, it backed by a hash. It should
be at most a linked hash map or a lnked tree set. At least something stable.
> remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MSHARED-800) Remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-800:
---
Summary: Remove Maven version from pom.properties (was: remove Maven
version from pom.properties)
> Remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-800) Remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761751#comment-16761751
]
Michael Osipov commented on MSHARED-800:
{code:java}
package java.util.jar;
import java.io.FilterInputStream;
import java.io.DataOutputStream;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.IOException;
import java.util.Map;
import java.util.HashMap;
import java.util.Iterator;
/**
* The Manifest class is used to maintain Manifest entry names and their
* associated Attributes. There are main Manifest Attributes as well as
* per-entry Attributes. For information on the Manifest format, please
* see the
*
* Manifest format specification.
*
* @author David Connelly
* @see Attributes
* @since 1.2
*/
public class Manifest implements Cloneable {
// manifest main attributes
private Attributes attr = new Attributes();
// manifest entries
private Map entries = new HashMap<>();
{code}
> Remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6500) Dependency resolution broken with Java 11
[ https://issues.apache.org/jira/browse/MNG-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761668#comment-16761668 ] Karl Heinz Marbaise commented on MNG-6500: -- [~hohwille] I think you need to use a more recent version cause they have changed that dependency into provided already > Dependency resolution broken with Java 11 > - > > Key: MNG-6500 > URL: https://issues.apache.org/jira/browse/MNG-6500 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.4 > Environment: Java 11 >Reporter: Jörg Hohwiller >Assignee: Karl Heinz Marbaise >Priority: Major > > I am facing an issue that some transitive dependencies are missing on maven > dependency resolution. This reproducible works fine with older Java (java8) > and always fails with java 11. > The code that fails can be found in this feature branch: > [https://github.com/hohwille/devon4j/tree/feature-16-java-11-build] > A detailed description of the issue can be found here: > [https://github.com/devonfw/devon4j/issues/16] > It would be awesome if someone could have a look and make maven work smooth > with Java 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MANTRUN-78) Use of AntRun during clean phase fails multiproject with intermodule dependencies
[ https://issues.apache.org/jira/browse/MANTRUN-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761718#comment-16761718 ] Mark commented on MANTRUN-78: - Issue still exists with maven 3.6.0 and antrun plugin 1.8 in pre-clean phase. > Use of AntRun during clean phase fails multiproject with intermodule > dependencies > - > > Key: MANTRUN-78 > URL: https://issues.apache.org/jira/browse/MANTRUN-78 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.1, 1.2 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_12 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Brian Jackson >Priority: Major > Attachments: test.zip > > > Attaching the antrun plugin to the clean phase causes it to interfere with > local dependency resolution for sibling projects. > An example is attached. > The project consists of project 'test' with modules 'test-a' and test-b'. > 'test-a' depends on 'test-b'. > If you run "mvn clean" on the root POM, the clean succeeds. > If you run "mvn clean -Pbuild-failure" it fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MANTRUN-216) CLONE - Use of AntRun during clean phase fails multiproject with intermodule dependencies
Mark created MANTRUN-216: Summary: CLONE - Use of AntRun during clean phase fails multiproject with intermodule dependencies Key: MANTRUN-216 URL: https://issues.apache.org/jira/browse/MANTRUN-216 Project: Maven Antrun Plugin Issue Type: Bug Affects Versions: 1.1, 1.2 Environment: Maven version: 2.0.8 Java version: 1.5.0_12 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" Reporter: Mark Attaching the antrun plugin to the clean phase causes it to interfere with local dependency resolution for sibling projects. An example is attached. The project consists of project 'test' with modules 'test-a' and test-b'. 'test-a' depends on 'test-b'. If you run "mvn clean" on the root POM, the clean succeeds. If you run "mvn clean -Pbuild-failure" it fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MSHARED-800) Remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761741#comment-16761741
]
Michael Osipov edited comment on MSHARED-800 at 2/6/19 1:54 PM:
The order isn't stable because, as far as I know, it backed by a hash. It
should be at most a linked hash map or a lnked tree set. At least something
stable. Let's have another ticket for that.
{code:java}
package java.util.jar;
import java.io.FilterInputStream;
import java.io.DataOutputStream;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.IOException;
import java.util.Map;
import java.util.HashMap;
import java.util.Iterator;
/**
* The Manifest class is used to maintain Manifest entry names and their
* associated Attributes. There are main Manifest Attributes as well as
* per-entry Attributes. For information on the Manifest format, please
* see the
*
* Manifest format specification.
*
* @author David Connelly
* @see Attributes
* @since 1.2
*/
public class Manifest implements Cloneable {
// manifest main attributes
private Attributes attr = new Attributes();
// manifest entries
private Map entries = new HashMap<>();
{code}
was (Author: michael-o):
The order isn't stable because, as far as I know, it backed by a hash. It
should be at most a linked hash map or a lnked tree set. At least something
stable. Let's have another ticket for that.
> Remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MSHARED-800) Remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-800:
---
Comment: was deleted
(was: {code:java}
package java.util.jar;
import java.io.FilterInputStream;
import java.io.DataOutputStream;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.IOException;
import java.util.Map;
import java.util.HashMap;
import java.util.Iterator;
/**
* The Manifest class is used to maintain Manifest entry names and their
* associated Attributes. There are main Manifest Attributes as well as
* per-entry Attributes. For information on the Manifest format, please
* see the
*
* Manifest format specification.
*
* @author David Connelly
* @see Attributes
* @since 1.2
*/
public class Manifest implements Cloneable {
// manifest main attributes
private Attributes attr = new Attributes();
// manifest entries
private Map entries = new HashMap<>();
{code})
> Remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-800) Remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761844#comment-16761844
]
Hervé Boutemy commented on MSHARED-800:
---
I was not talking about {{MANIFEST.MF}} but {{pom.properties}}
> Remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-156) generatePom=false not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761665#comment-16761665
]
Karl Heinz Marbaise commented on MINSTALL-156:
--
I have taken a short look into the pom file. So now the real question is: Why
do you have configured maven-install-plugin and maven-deploy-plugin? The
destination repository where all artifacts will be deployed to is defined by
{{distributionManagement}} which is not defined here so you have to.
Furthermore is the question why you have configured maven-assembly-plugin but
configured {{false}} please explain what your use case is?
So in the end you can simply define a {{distributionManagement}} in your pom
file and remove {{false}} from the maven-assembly-plugin
everything will be installed/deployed via {{mvn clean deploy}} or {{mvn clean
install}} ?
I have made PR to your repository take a deep look into the result... cause it
sounds like you have a misunderstanding of how Maven works
> generatePom=false not working with 3.0.0-M1
> ---
>
> Key: MINSTALL-156
> URL: https://issues.apache.org/jira/browse/MINSTALL-156
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Robert Lieske
>Priority: Major
>
> Steps to reproduce:
> {{mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT}}
>
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:2.5.2:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO]
>
> {quote}
>
> changing the version of the maven-install-plugin in pom.xml to
> {{}}
> {{ maven-install-plugin}}
> {{ 3.0.0-M1}}
> {{ }}
>
> the same call to
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO] Installing
> C:\Users\xxx\AppData\Local\Temp\test1-1.0-SNAPSHOT7157743325898943802.pom to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
> [INFO]
>
> {quote}
>
> Which also installs a POM - which is not what we want!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DOXIA-575) Add support for (X)HTML5
[ https://issues.apache.org/jira/browse/DOXIA-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761664#comment-16761664 ] Graham Leggett commented on DOXIA-575: -- Checking in to see if there is any chance of an update? XHTML5 was supported so that we could handle the documentation we need for the Redwax Project at https://redwax.eu, and we're really stuck. It would be good to have confirmation that the approach is sound. > Add support for (X)HTML5 > > > Key: DOXIA-575 > URL: https://issues.apache.org/jira/browse/DOXIA-575 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Affects Versions: 1.8 >Reporter: Graham Leggett >Priority: Major > Attachments: DOXIA-575.patch > > > Doxia currently generates XHTML v1.1, and does not support any of the new > HTML5 tags. > Update Doxia to support HTML5.2 as per https://www.w3.org/TR/html52/. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MANTRUN-216) CLONE - Use of AntRun during clean phase fails multiproject with intermodule dependencies
[ https://issues.apache.org/jira/browse/MANTRUN-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark updated MANTRUN-216: - Description: Can't re-open the original issue. The blocking issue MNG-3283 is said to be fixed. Does the antrun plugin have the nesseray update for the upstream fix to work? Attaching the antrun plugin to the clean phase causes it to interfere with local dependency resolution for sibling projects. An example is attached to MANTRUN-78 . The project consists of project 'test' with modules 'test-a' and test-b'. 'test-a' depends on 'test-b'. If you run "mvn clean" on the root POM, the clean succeeds. If you run "mvn clean -Pbuild-failure" it fails. was: Can't re-open the original issue. The blocking issue is said to be fixed. Attaching the antrun plugin to the clean phase causes it to interfere with local dependency resolution for sibling projects. An example is attached to MANTRUN-78 . The project consists of project 'test' with modules 'test-a' and test-b'. 'test-a' depends on 'test-b'. If you run "mvn clean" on the root POM, the clean succeeds. If you run "mvn clean -Pbuild-failure" it fails. > CLONE - Use of AntRun during clean phase fails multiproject with intermodule > dependencies > - > > Key: MANTRUN-216 > URL: https://issues.apache.org/jira/browse/MANTRUN-216 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.8 > Environment: Maven version: 3.6.0 > Java version: 11.0.2-open > OS name: ubuntu 18 x86-64 >Reporter: Mark >Priority: Major > > Can't re-open the original issue. The blocking issue MNG-3283 is said to be > fixed. Does the antrun plugin have the nesseray update for the upstream fix > to work? > Attaching the antrun plugin to the clean phase causes it to interfere with > local dependency resolution for sibling projects. > An example is attached to MANTRUN-78 . > The project consists of project 'test' with modules 'test-a' and test-b'. > 'test-a' depends on 'test-b'. > If you run "mvn clean" on the root POM, the clean succeeds. > If you run "mvn clean -Pbuild-failure" it fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MANTRUN-216) CLONE - Use of AntRun during clean phase fails multiproject with intermodule dependencies
[ https://issues.apache.org/jira/browse/MANTRUN-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark updated MANTRUN-216: - Description: Can't re-open the original issue. The blocking issue is said to be fixed. Attaching the antrun plugin to the clean phase causes it to interfere with local dependency resolution for sibling projects. An example is attached to MANTRUN-78 . The project consists of project 'test' with modules 'test-a' and test-b'. 'test-a' depends on 'test-b'. If you run "mvn clean" on the root POM, the clean succeeds. If you run "mvn clean -Pbuild-failure" it fails. was: Can't re-open the original issue. Attaching the antrun plugin to the clean phase causes it to interfere with local dependency resolution for sibling projects. An example is attached to MANTRUN-78 . The project consists of project 'test' with modules 'test-a' and test-b'. 'test-a' depends on 'test-b'. If you run "mvn clean" on the root POM, the clean succeeds. If you run "mvn clean -Pbuild-failure" it fails. > CLONE - Use of AntRun during clean phase fails multiproject with intermodule > dependencies > - > > Key: MANTRUN-216 > URL: https://issues.apache.org/jira/browse/MANTRUN-216 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.8 > Environment: Maven version: 3.6.0 > Java version: 11.0.2-open > OS name: ubuntu 18 x86-64 >Reporter: Mark >Priority: Major > > Can't re-open the original issue. The blocking issue is said to be fixed. > Attaching the antrun plugin to the clean phase causes it to interfere with > local dependency resolution for sibling projects. > An example is attached to MANTRUN-78 . > The project consists of project 'test' with modules 'test-a' and test-b'. > 'test-a' depends on 'test-b'. > If you run "mvn clean" on the root POM, the clean succeeds. > If you run "mvn clean -Pbuild-failure" it fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MANTRUN-216) CLONE - Use of AntRun during clean phase fails multiproject with intermodule dependencies
[ https://issues.apache.org/jira/browse/MANTRUN-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark updated MANTRUN-216: - Description: Can't re-open the original issue. Attaching the antrun plugin to the clean phase causes it to interfere with local dependency resolution for sibling projects. An example is attached to MANTRUN-78 . The project consists of project 'test' with modules 'test-a' and test-b'. 'test-a' depends on 'test-b'. If you run "mvn clean" on the root POM, the clean succeeds. If you run "mvn clean -Pbuild-failure" it fails. was: Attaching the antrun plugin to the clean phase causes it to interfere with local dependency resolution for sibling projects. An example is attached to MANTRUN-78 . The project consists of project 'test' with modules 'test-a' and test-b'. 'test-a' depends on 'test-b'. If you run "mvn clean" on the root POM, the clean succeeds. If you run "mvn clean -Pbuild-failure" it fails. > CLONE - Use of AntRun during clean phase fails multiproject with intermodule > dependencies > - > > Key: MANTRUN-216 > URL: https://issues.apache.org/jira/browse/MANTRUN-216 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.8 > Environment: Maven version: 3.6.0 > Java version: 11.0.2-open > OS name: ubuntu 18 x86-64 >Reporter: Mark >Priority: Major > > Can't re-open the original issue. > Attaching the antrun plugin to the clean phase causes it to interfere with > local dependency resolution for sibling projects. > An example is attached to MANTRUN-78 . > The project consists of project 'test' with modules 'test-a' and test-b'. > 'test-a' depends on 'test-b'. > If you run "mvn clean" on the root POM, the clean succeeds. > If you run "mvn clean -Pbuild-failure" it fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] michael-o commented on issue #88: SCM-917 add untag for svn
michael-o commented on issue #88: SCM-917 add untag for svn URL: https://github.com/apache/maven-scm/pull/88#issuecomment-461019069 I will have a look at it Sunday on the train. Please ping me. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MSHARED-800) remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761741#comment-16761741
]
Michael Osipov commented on MSHARED-800:
I order isn't stable because, as far as I know, it backed by a hash. It should
be at most a linked hash map or a lnked tree set. At least something stable.
> remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (MANTRUN-78) Use of AntRun during clean phase fails multiproject with intermodule dependencies
[ https://issues.apache.org/jira/browse/MANTRUN-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MANTRUN-78: --- Reopening per request. > Use of AntRun during clean phase fails multiproject with intermodule > dependencies > - > > Key: MANTRUN-78 > URL: https://issues.apache.org/jira/browse/MANTRUN-78 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.1, 1.2 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_12 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Brian Jackson >Priority: Major > Attachments: test.zip > > > Attaching the antrun plugin to the clean phase causes it to interfere with > local dependency resolution for sibling projects. > An example is attached. > The project consists of project 'test' with modules 'test-a' and test-b'. > 'test-a' depends on 'test-b'. > If you run "mvn clean" on the root POM, the clean succeeds. > If you run "mvn clean -Pbuild-failure" it fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-800) remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761705#comment-16761705
]
Hervé Boutemy commented on MSHARED-800:
---
yes, I'm trying to reproduce every release on which I vote and track precisely
every little detail, with precise JIRA issue: it's good to know you've got the
same idea :)
yes, we can leave the value as simple as {{# Created by Apache Maven}}, that
will be sufficient
one question I had while looking at code: should we explicitely sort entries
also? I did not get any issue, but I fear the current order is not really kept
by design but by chance only...
> remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MANTRUN-216) CLONE - Use of AntRun during clean phase fails multiproject with intermodule dependencies
[ https://issues.apache.org/jira/browse/MANTRUN-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark updated MANTRUN-216: - Affects Version/s: (was: 1.2) (was: 1.1) 1.8 > CLONE - Use of AntRun during clean phase fails multiproject with intermodule > dependencies > - > > Key: MANTRUN-216 > URL: https://issues.apache.org/jira/browse/MANTRUN-216 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.8 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_12 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Mark >Priority: Major > > Attaching the antrun plugin to the clean phase causes it to interfere with > local dependency resolution for sibling projects. > An example is attached. > The project consists of project 'test' with modules 'test-a' and test-b'. > 'test-a' depends on 'test-b'. > If you run "mvn clean" on the root POM, the clean succeeds. > If you run "mvn clean -Pbuild-failure" it fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MANTRUN-216) CLONE - Use of AntRun during clean phase fails multiproject with intermodule dependencies
[ https://issues.apache.org/jira/browse/MANTRUN-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark updated MANTRUN-216: - Environment: Maven version: 3.6.0 Java version: 11.0.2-open OS name: ubuntu 18 x86-64 was: Maven version: 2.0.8 Java version: 1.5.0_12 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" > CLONE - Use of AntRun during clean phase fails multiproject with intermodule > dependencies > - > > Key: MANTRUN-216 > URL: https://issues.apache.org/jira/browse/MANTRUN-216 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.8 > Environment: Maven version: 3.6.0 > Java version: 11.0.2-open > OS name: ubuntu 18 x86-64 >Reporter: Mark >Priority: Major > > Attaching the antrun plugin to the clean phase causes it to interfere with > local dependency resolution for sibling projects. > An example is attached. > The project consists of project 'test' with modules 'test-a' and test-b'. > 'test-a' depends on 'test-b'. > If you run "mvn clean" on the root POM, the clean succeeds. > If you run "mvn clean -Pbuild-failure" it fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] cquoss commented on issue #88: SCM-917 add untag for svn
cquoss commented on issue #88: SCM-917 add untag for svn URL: https://github.com/apache/maven-scm/pull/88#issuecomment-461020972 OK. Will ping you sunday morning. Hopefully not forgetting it myself. I am good at at that ;-) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Assigned] (MSHARED-800) Remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSHARED-800:
--
Assignee: Michael Osipov
> Remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MSHARED-800) Remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761741#comment-16761741
]
Michael Osipov edited comment on MSHARED-800 at 2/6/19 1:47 PM:
The order isn't stable because, as far as I know, it backed by a hash. It
should be at most a linked hash map or a lnked tree set. At least something
stable. Let's have another ticket for that.
was (Author: michael-o):
I order isn't stable because, as far as I know, it backed by a hash. It should
be at most a linked hash map or a lnked tree set. At least something stable.
Let's have another ticket for that.
> Remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-800) Remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762059#comment-16762059
]
Michael Osipov commented on MSHARED-800:
[~hboutemy], branch created. Have a look, but I think that even this line is
just waste. Consider that someone provided a custom manifest file. We'd still
would write the comment.
> Remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-798) Add defaultEntries option
[
https://issues.apache.org/jira/browse/MSHARED-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762084#comment-16762084
]
Hudson commented on MSHARED-798:
Build succeeded in Jenkins: Maven TLP » maven-archiver » MSHARED-798 #2
See
https://builds.apache.org/job/maven-box/job/maven-archiver/job/MSHARED-798/2/
> Add defaultEntries option
> -
>
> Key: MSHARED-798
> URL: https://issues.apache.org/jira/browse/MSHARED-798
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Based on MSHARED-362 one should have the option to disable default
> (reproducible) manifest entries explicitly: {{Created-By}},
> {{Build-Jdk-Spec}} with the option {{addDefaultEntries: true}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-362) Support removing default manifest entries with Maven Archiver
[ https://issues.apache.org/jira/browse/MSHARED-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762068#comment-16762068 ] Michael Osipov commented on MSHARED-362: [~richardneish], please have a look at MSHARED-800 too. > Support removing default manifest entries with Maven Archiver > - > > Key: MSHARED-362 > URL: https://issues.apache.org/jira/browse/MSHARED-362 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-archiver >Affects Versions: maven-archiver-2.4.2, maven-archiver-2.5 >Reporter: Richard Neish >Assignee: Michael Osipov >Priority: Minor > Fix For: maven-archiver-3.4.0 > > Attachments: MSHARED-362-01.patch > > > As described in the StackOverflow question at > http://stackoverflow.com/q/25098307/274350 maven-archiver should allow the > user to remove the default manifest entries, such as "Built-By:" > Currently it is possible to set an empty value for these default entries, but > not to remove them from the manifest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6586) Allow proxy activation based on profile
[
https://issues.apache.org/jira/browse/MNG-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6586:
Fix Version/s: (was: 3.6.x-candidate)
> Allow proxy activation based on profile
> ---
>
> Key: MNG-6586
> URL: https://issues.apache.org/jira/browse/MNG-6586
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.6.0
>Reporter: Alon Bar-Lev
>Assignee: Michael Osipov
>Priority: Major
>
> Hello,
> In setting reference[1] it is written:
> """
> |{{proxies/[proxy|https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#class_proxy]*}}|{{List}}|*(Many)*
> Configuration for different proxy profiles. Multiple proxy profiles might
> come in handy for anyone working from a notebook or other mobile platform, to
> enable easy switching of entire proxy configurations by simply specifying the
> profile id, again either from the command line or from the defaults section
> below.|
> """
> So it should be possible to enable/disable proxy based on a profile. However,
> there is no instructions of how to do that.
> Adding ${property} automatically disables the entry, even if
> property is set to true, I verify this using help:effective-settings. I could
> not find any property that can make any difference.
> I see many people have tried and failed, and based on the above documentation
> it seems like either missing documentation or an actual bug.
> Please allow that, as multiple setting.xml are not supported and
> enable/disable proxy is required for a single CI settings.xml.
> Thanks!
>
> [1] https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#settings
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6586) Allow proxy activation based on profile
[
https://issues.apache.org/jira/browse/MNG-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6586:
Component/s: Documentation: General
> Allow proxy activation based on profile
> ---
>
> Key: MNG-6586
> URL: https://issues.apache.org/jira/browse/MNG-6586
> Project: Maven
> Issue Type: Bug
> Components: Documentation: General, Settings
>Affects Versions: 3.6.0
>Reporter: Alon Bar-Lev
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.1
>
>
> Hello,
> In setting reference[1] it is written:
> """
> |{{proxies/[proxy|https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#class_proxy]*}}|{{List}}|*(Many)*
> Configuration for different proxy profiles. Multiple proxy profiles might
> come in handy for anyone working from a notebook or other mobile platform, to
> enable easy switching of entire proxy configurations by simply specifying the
> profile id, again either from the command line or from the defaults section
> below.|
> """
> So it should be possible to enable/disable proxy based on a profile. However,
> there is no instructions of how to do that.
> Adding ${property} automatically disables the entry, even if
> property is set to true, I verify this using help:effective-settings. I could
> not find any property that can make any difference.
> I see many people have tried and failed, and based on the above documentation
> it seems like either missing documentation or an actual bug.
> Please allow that, as multiple setting.xml are not supported and
> enable/disable proxy is required for a single CI settings.xml.
> Thanks!
>
> [1] https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#settings
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-800) Remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762061#comment-16762061
]
Michael Osipov commented on MSHARED-800:
As for the sort, we could leverage this:
[https://stackoverflow.com/a/25059741/696632] while groupId, artifactId and
version come always as first element.
> Remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MNG-6586) Allow proxy activation based on profile
[
https://issues.apache.org/jira/browse/MNG-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6586:
---
Assignee: Michael Osipov
> Allow proxy activation based on profile
> ---
>
> Key: MNG-6586
> URL: https://issues.apache.org/jira/browse/MNG-6586
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.6.0
>Reporter: Alon Bar-Lev
>Assignee: Michael Osipov
>Priority: Major
>
> Hello,
> In setting reference[1] it is written:
> """
> |{{proxies/[proxy|https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#class_proxy]*}}|{{List}}|*(Many)*
> Configuration for different proxy profiles. Multiple proxy profiles might
> come in handy for anyone working from a notebook or other mobile platform, to
> enable easy switching of entire proxy configurations by simply specifying the
> profile id, again either from the command line or from the defaults section
> below.|
> """
> So it should be possible to enable/disable proxy based on a profile. However,
> there is no instructions of how to do that.
> Adding ${property} automatically disables the entry, even if
> property is set to true, I verify this using help:effective-settings. I could
> not find any property that can make any difference.
> I see many people have tried and failed, and based on the above documentation
> it seems like either missing documentation or an actual bug.
> Please allow that, as multiple setting.xml are not supported and
> enable/disable proxy is required for a single CI settings.xml.
> Thanks!
>
> [1] https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#settings
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6586) Allow proxy activation based on profile
[
https://issues.apache.org/jira/browse/MNG-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762182#comment-16762182
]
Michael Osipov commented on MNG-6586:
-
As far as I can see profiles cannot contain proxy config. I will change this
piece of documentation.
> Allow proxy activation based on profile
> ---
>
> Key: MNG-6586
> URL: https://issues.apache.org/jira/browse/MNG-6586
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.6.0
>Reporter: Alon Bar-Lev
>Priority: Major
>
> Hello,
> In setting reference[1] it is written:
> """
> |{{proxies/[proxy|https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#class_proxy]*}}|{{List}}|*(Many)*
> Configuration for different proxy profiles. Multiple proxy profiles might
> come in handy for anyone working from a notebook or other mobile platform, to
> enable easy switching of entire proxy configurations by simply specifying the
> profile id, again either from the command line or from the defaults section
> below.|
> """
> So it should be possible to enable/disable proxy based on a profile. However,
> there is no instructions of how to do that.
> Adding ${property} automatically disables the entry, even if
> property is set to true, I verify this using help:effective-settings. I could
> not find any property that can make any difference.
> I see many people have tried and failed, and based on the above documentation
> it seems like either missing documentation or an actual bug.
> Please allow that, as multiple setting.xml are not supported and
> enable/disable proxy is required for a single CI settings.xml.
> Thanks!
>
> [1] https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#settings
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6586) Allow proxy activation based on profile
[
https://issues.apache.org/jira/browse/MNG-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6586:
Fix Version/s: 3.6.1
> Allow proxy activation based on profile
> ---
>
> Key: MNG-6586
> URL: https://issues.apache.org/jira/browse/MNG-6586
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.6.0
>Reporter: Alon Bar-Lev
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.1
>
>
> Hello,
> In setting reference[1] it is written:
> """
> |{{proxies/[proxy|https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#class_proxy]*}}|{{List}}|*(Many)*
> Configuration for different proxy profiles. Multiple proxy profiles might
> come in handy for anyone working from a notebook or other mobile platform, to
> enable easy switching of entire proxy configurations by simply specifying the
> profile id, again either from the command line or from the defaults section
> below.|
> """
> So it should be possible to enable/disable proxy based on a profile. However,
> there is no instructions of how to do that.
> Adding ${property} automatically disables the entry, even if
> property is set to true, I verify this using help:effective-settings. I could
> not find any property that can make any difference.
> I see many people have tried and failed, and based on the above documentation
> it seems like either missing documentation or an actual bug.
> Please allow that, as multiple setting.xml are not supported and
> enable/disable proxy is required for a single CI settings.xml.
> Thanks!
>
> [1] https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#settings
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6586) Allow proxy activation based on profile
[
https://issues.apache.org/jira/browse/MNG-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6586:
Fix Version/s: 3.6.x-candidate
> Allow proxy activation based on profile
> ---
>
> Key: MNG-6586
> URL: https://issues.apache.org/jira/browse/MNG-6586
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.6.0
>Reporter: Alon Bar-Lev
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.x-candidate
>
>
> Hello,
> In setting reference[1] it is written:
> """
> |{{proxies/[proxy|https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#class_proxy]*}}|{{List}}|*(Many)*
> Configuration for different proxy profiles. Multiple proxy profiles might
> come in handy for anyone working from a notebook or other mobile platform, to
> enable easy switching of entire proxy configurations by simply specifying the
> profile id, again either from the command line or from the defaults section
> below.|
> """
> So it should be possible to enable/disable proxy based on a profile. However,
> there is no instructions of how to do that.
> Adding ${property} automatically disables the entry, even if
> property is set to true, I verify this using help:effective-settings. I could
> not find any property that can make any difference.
> I see many people have tried and failed, and based on the above documentation
> it seems like either missing documentation or an actual bug.
> Please allow that, as multiple setting.xml are not supported and
> enable/disable proxy is required for a single CI settings.xml.
> Thanks!
>
> [1] https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#settings
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6586) Allow proxy activation based on profile
[
https://issues.apache.org/jira/browse/MNG-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762188#comment-16762188
]
Alon Bar-Lev commented on MNG-6586:
---
This is not the answer I hoped to receive... :(
The expected configuration based on the text would be:
{code:java}
id1
${proxy.active}
enable-proxy
true
{code}
Should I open a new bug?
> Allow proxy activation based on profile
> ---
>
> Key: MNG-6586
> URL: https://issues.apache.org/jira/browse/MNG-6586
> Project: Maven
> Issue Type: Bug
> Components: Documentation: General, Settings
>Affects Versions: 3.6.0
>Reporter: Alon Bar-Lev
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.1
>
>
> Hello,
> In setting reference[1] it is written:
> """
> |{{proxies/[proxy|https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#class_proxy]*}}|{{List}}|*(Many)*
> Configuration for different proxy profiles. Multiple proxy profiles might
> come in handy for anyone working from a notebook or other mobile platform, to
> enable easy switching of entire proxy configurations by simply specifying the
> profile id, again either from the command line or from the defaults section
> below.|
> """
> So it should be possible to enable/disable proxy based on a profile. However,
> there is no instructions of how to do that.
> Adding ${property} automatically disables the entry, even if
> property is set to true, I verify this using help:effective-settings. I could
> not find any property that can make any difference.
> I see many people have tried and failed, and based on the above documentation
> it seems like either missing documentation or an actual bug.
> Please allow that, as multiple setting.xml are not supported and
> enable/disable proxy is required for a single CI settings.xml.
> Thanks!
>
> [1] https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#settings
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MSHARED-800) Remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761992#comment-16761992
]
Michael Osipov edited comment on MSHARED-800 at 2/6/19 7:39 PM:
Sorry, my bad, but the fact remains. It is backed by a {{Hastable}}.
was (Author: michael-o):
Sorry, my bud, but the fact remains. It is backed by a {{Hastable}}.
> Remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6586) Allow proxy activation based on profile
[
https://issues.apache.org/jira/browse/MNG-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762180#comment-16762180
]
Michael Osipov commented on MNG-6586:
-
I think the wording is just bad. These profiles have likely nothing to do with
Maven Profile. Maybe the word configuration would be better suited.
> Allow proxy activation based on profile
> ---
>
> Key: MNG-6586
> URL: https://issues.apache.org/jira/browse/MNG-6586
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.6.0
>Reporter: Alon Bar-Lev
>Priority: Major
>
> Hello,
> In setting reference[1] it is written:
> """
> |{{proxies/[proxy|https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#class_proxy]*}}|{{List}}|*(Many)*
> Configuration for different proxy profiles. Multiple proxy profiles might
> come in handy for anyone working from a notebook or other mobile platform, to
> enable easy switching of entire proxy configurations by simply specifying the
> profile id, again either from the command line or from the defaults section
> below.|
> """
> So it should be possible to enable/disable proxy based on a profile. However,
> there is no instructions of how to do that.
> Adding ${property} automatically disables the entry, even if
> property is set to true, I verify this using help:effective-settings. I could
> not find any property that can make any difference.
> I see many people have tried and failed, and based on the above documentation
> it seems like either missing documentation or an actual bug.
> Please allow that, as multiple setting.xml are not supported and
> enable/disable proxy is required for a single CI settings.xml.
> Thanks!
>
> [1] https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#settings
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MANTRUN-216) CLONE - Use of AntRun during clean phase fails multiproject with intermodule dependencies
[ https://issues.apache.org/jira/browse/MANTRUN-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MANTRUN-216. -- Resolution: Duplicate > CLONE - Use of AntRun during clean phase fails multiproject with intermodule > dependencies > - > > Key: MANTRUN-216 > URL: https://issues.apache.org/jira/browse/MANTRUN-216 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.8 > Environment: Maven version: 3.6.0 > Java version: 11.0.2-open > OS name: ubuntu 18 x86-64 >Reporter: Mark >Priority: Major > > Can't re-open the original issue. The blocking issue MNG-3283 is said to be > fixed. Does the antrun plugin have the nesseray update for the upstream fix > to work? > Attaching the antrun plugin to the clean phase causes it to interfere with > local dependency resolution for sibling projects. > An example is attached to MANTRUN-78 . > The project consists of project 'test' with modules 'test-a' and test-b'. > 'test-a' depends on 'test-b'. > If you run "mvn clean" on the root POM, the clean succeeds. > If you run "mvn clean -Pbuild-failure" it fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-800) Remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761992#comment-16761992
]
Michael Osipov commented on MSHARED-800:
Sorry, my bud, but the fact remains. It is backed by a {{Hastable}}.
> Remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-462) if a proxy is not reachable, don't use it instead of failing
[ https://issues.apache.org/jira/browse/MNG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761896#comment-16761896 ] Alon Bar-Lev commented on MNG-462: -- Lots of dups and no main bug to track? There is no way to enable/disable proxy by profiles/environment/properties yet in 2019? > if a proxy is not reachable, don't use it instead of failing > > > Key: MNG-462 > URL: https://issues.apache.org/jira/browse/MNG-462 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Brett Porter >Priority: Minor > > while profiles are available for working in different environments, this > would be convenient to allow multiple proxies to be configured, and search > for one that is needed in the current environment for people on the road a > lot. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6586) Allow proxy activation based on profile
Alon Bar-Lev created MNG-6586:
-
Summary: Allow proxy activation based on profile
Key: MNG-6586
URL: https://issues.apache.org/jira/browse/MNG-6586
Project: Maven
Issue Type: Bug
Components: Settings
Affects Versions: 3.6.0
Reporter: Alon Bar-Lev
Hello,
In setting reference[1] it is written:
"""
|{{proxies/[proxy|https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#class_proxy]*}}|{{List}}|*(Many)*
Configuration for different proxy profiles. Multiple proxy profiles might come
in handy for anyone working from a notebook or other mobile platform, to enable
easy switching of entire proxy configurations by simply specifying the profile
id, again either from the command line or from the defaults section below.|
"""
So it should be possible to enable/disable proxy based on a profile. However,
there is no instructions of how to do that.
Adding ${property} automatically disables the entry, even if
property is set to true, I verify this using help:effective-settings. I could
not find any property that can make any difference.
I see many people have tried and failed, and based on the above documentation
it seems like either missing documentation or an actual bug.
Please allow that, as multiple setting.xml are not supported and enable/disable
proxy is required for a single CI settings.xml.
Thanks!
[1] https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#settings
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-575) 8 fails when module-info.java exists
[ https://issues.apache.org/jira/browse/MJAVADOC-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762190#comment-16762190 ] Markus Karg commented on MJAVADOC-575: -- Also fails in 3.1.0-SNAPSHOT. > 8 fails when module-info.java exists > - > > Key: MJAVADOC-575 > URL: https://issues.apache.org/jira/browse/MJAVADOC-575 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Markus Karg >Priority: Major > > Some projects are written for Java 8 but include a module-info.java class > cross-compiled using JDK 9. On JDK 11.0.2 the Maven Javadoc Plugin does fail > with the following message: > error: option --module-path not allowed with target 1.8 > In fact, it is wrong that the Javadoc plugin uses the "--module-path" option > once 8 is provided. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAVADOC-575) 8 fails when module-info.java exists
Markus Karg created MJAVADOC-575: Summary: 8 fails when module-info.java exists Key: MJAVADOC-575 URL: https://issues.apache.org/jira/browse/MJAVADOC-575 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 3.0.1 Reporter: Markus Karg Some projects are written for Java 8 but include a module-info.java class cross-compiled using JDK 9. On JDK 11.0.2 the Maven Javadoc Plugin does fail with the following message: error: option --module-path not allowed with target 1.8 In fact, it is wrong that the Javadoc plugin uses the "--module-path" option once 8 is provided. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6124) Add section in settings.xml
[ https://issues.apache.org/jira/browse/MNG-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6124: Fix Version/s: waiting-for-feedback > Add section in settings.xml > -- > > Key: MNG-6124 > URL: https://issues.apache.org/jira/browse/MNG-6124 > Project: Maven > Issue Type: New Feature > Components: Settings >Affects Versions: 3.3.9 >Reporter: Anthony Vanelverdinghe >Priority: Major > Fix For: waiting-for-feedback > > > Maven uses the login name (i.e. the system property user.name). In > particular, it uses it in the Maven Archiver, to set the "Built-By" manifest > entry. However, in my opinion this is problematic (see also > [MSHARED-362|https://issues.apache.org/jira/browse/MSHARED-362]), because: > - login names can typically only be traced back to a person within an > organization > - outside of an organization, login names may be ridiculous, embarrassing, > ... and I'd guess many people are unaware of the fact that their login name > is disclosed in any artifact they build > Other systems, such as git and hg, actually use the login name as well by > default. However, they allow to set the username in their global > configuration. Maven should allow the same, setting both a username and an > e-mail. Either by having 2 properties username and user e-mail, like git. Or > by having a single property username, where the e-mail can be appended (e.g. > Anthony ) like hg. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6586) Allow proxy activation based on profile
[
https://issues.apache.org/jira/browse/MNG-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762192#comment-16762192
]
Michael Osipov commented on MNG-6586:
-
I will double-check before changing the docs.
> Allow proxy activation based on profile
> ---
>
> Key: MNG-6586
> URL: https://issues.apache.org/jira/browse/MNG-6586
> Project: Maven
> Issue Type: Bug
> Components: Documentation: General, Settings
>Affects Versions: 3.6.0
>Reporter: Alon Bar-Lev
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.1
>
>
> Hello,
> In setting reference[1] it is written:
> """
> |{{proxies/[proxy|https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#class_proxy]*}}|{{List}}|*(Many)*
> Configuration for different proxy profiles. Multiple proxy profiles might
> come in handy for anyone working from a notebook or other mobile platform, to
> enable easy switching of entire proxy configurations by simply specifying the
> profile id, again either from the command line or from the defaults section
> below.|
> """
> So it should be possible to enable/disable proxy based on a profile. However,
> there is no instructions of how to do that.
> Adding ${property} automatically disables the entry, even if
> property is set to true, I verify this using help:effective-settings. I could
> not find any property that can make any difference.
> I see many people have tried and failed, and based on the above documentation
> it seems like either missing documentation or an actual bug.
> Please allow that, as multiple setting.xml are not supported and
> enable/disable proxy is required for a single CI settings.xml.
> Thanks!
>
> [1] https://maven.apache.org/ref/3.6.0/maven-settings/settings.html#settings
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6124) Add section in settings.xml
[ https://issues.apache.org/jira/browse/MNG-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762193#comment-16762193 ] Michael Osipov commented on MNG-6124: - Do we still need this? > Add section in settings.xml > -- > > Key: MNG-6124 > URL: https://issues.apache.org/jira/browse/MNG-6124 > Project: Maven > Issue Type: New Feature > Components: Settings >Affects Versions: 3.3.9 >Reporter: Anthony Vanelverdinghe >Priority: Major > Fix For: waiting-for-feedback > > > Maven uses the login name (i.e. the system property user.name). In > particular, it uses it in the Maven Archiver, to set the "Built-By" manifest > entry. However, in my opinion this is problematic (see also > [MSHARED-362|https://issues.apache.org/jira/browse/MSHARED-362]), because: > - login names can typically only be traced back to a person within an > organization > - outside of an organization, login names may be ridiculous, embarrassing, > ... and I'd guess many people are unaware of the fact that their login name > is disclosed in any artifact they build > Other systems, such as git and hg, actually use the login name as well by > default. However, they allow to set the username in their global > configuration. Maven should allow the same, setting both a username and an > e-mail. Either by having 2 properties username and user e-mail, like git. Or > by having a single property username, where the e-mail can be appended (e.g. > Anthony ) like hg. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNG-3655) Allow multiple local repositories
[
https://issues.apache.org/jira/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762203#comment-16762203
]
Michael Osipov edited comment on MNG-3655 at 2/6/19 10:32 PM:
--
Why can't you just use a separate settings file and {{-Dmaven.repo.local}}?
was (Author: michael-o):
Why can't you just use a separatesettings file and {{-Dmaven.repo.local}}
> Allow multiple local repositories
> -
>
> Key: MNG-3655
> URL: https://issues.apache.org/jira/browse/MNG-3655
> Project: Maven
> Issue Type: New Feature
> Components: Reactor and workspace
>Reporter: Ittay Dror
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> In some environments, branches are rarely used. This means that if a
> developer wishes to work in parallel on two features, he checks out HEAD into
> two different locations. The problem is that using 'mvn install' in one
> checkout will overwrite the result of 'mvn install' in another. Of course one
> can write poms so that the version contains some classifier and then use 'mvn
> -Dartifact-classifier=first-checkout install', or, read from a file. Both are
> tedious.
> Instead, it would be good to be able to tell maven to first consider some
> path under the checkout before trying a global local repository (for external
> artifacts).
> To make this work when running mvn from a module subdir, maybe allow to write
> settings.xml in the root directory of the checkout. Then, maven should climb
> the directory structure until locating settings.xml (or reaching the global
> root directory) and read there. Using settings.xml in such a way has other
> benefits that it can be under version control. settings.xml will then be able
> to specify a list of local repositories, some absolute paths, some relative
> to it.
> Another approach could be to allow this list of local repositories in the
> global settings.xml file and have an entry in each module's pom indicating
> where it is relative to the local repository (like the parent path attribute)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-3655) Allow multiple local repositories
[
https://issues.apache.org/jira/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762203#comment-16762203
]
Michael Osipov commented on MNG-3655:
-
Why can't you just use a separatesettings file and {{-Dmaven.repo.local}}
> Allow multiple local repositories
> -
>
> Key: MNG-3655
> URL: https://issues.apache.org/jira/browse/MNG-3655
> Project: Maven
> Issue Type: New Feature
> Components: Reactor and workspace
>Reporter: Ittay Dror
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> In some environments, branches are rarely used. This means that if a
> developer wishes to work in parallel on two features, he checks out HEAD into
> two different locations. The problem is that using 'mvn install' in one
> checkout will overwrite the result of 'mvn install' in another. Of course one
> can write poms so that the version contains some classifier and then use 'mvn
> -Dartifact-classifier=first-checkout install', or, read from a file. Both are
> tedious.
> Instead, it would be good to be able to tell maven to first consider some
> path under the checkout before trying a global local repository (for external
> artifacts).
> To make this work when running mvn from a module subdir, maybe allow to write
> settings.xml in the root directory of the checkout. Then, maven should climb
> the directory structure until locating settings.xml (or reaching the global
> root directory) and read there. Using settings.xml in such a way has other
> benefits that it can be under version control. settings.xml will then be able
> to specify a list of local repositories, some absolute paths, some relative
> to it.
> Another approach could be to allow this list of local repositories in the
> global settings.xml file and have an entry in each module's pom indicating
> where it is relative to the local repository (like the parent path attribute)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-575) 8 fails when module-info.java exists
[ https://issues.apache.org/jira/browse/MJAVADOC-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762402#comment-16762402 ] Markus Karg commented on MJAVADOC-575: -- I assume this is caused by Maven Javadoc Plugin adding --module-path as soon as it finds a module-info.java file in the src folder. This should be modified in a way that the existence of that file is to be ignored by the plugin as soon as the provided is 8 or older, because the aim of such a feature / files combination simply is to have JavaDocs created "as if" the used JDK "would be" 8 - and JDK 8's JavaDoc tool simply ignores that file. > 8 fails when module-info.java exists > - > > Key: MJAVADOC-575 > URL: https://issues.apache.org/jira/browse/MJAVADOC-575 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Markus Karg >Priority: Major > > Some projects are written for Java 8 but include a module-info.java class > cross-compiled using JDK 9. On JDK 11.0.2 the Maven Javadoc Plugin does fail > with the following message: > error: option --module-path not allowed with target 1.8 > In fact, it is wrong that the Javadoc plugin uses the "--module-path" option > once 8 is provided. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNG-6571) Maven memory consumption issue
[
https://issues.apache.org/jira/browse/MNG-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761555#comment-16761555
]
Hervé Boutemy edited comment on MNG-6571 at 2/6/19 8:06 AM:
reopening: {{VersionRange.createFromVersion("1.0")}} and
{{VersionRange.createFromVersionSpec("1.0")}} do not exactly return the same
object
- {{VersionRange.createFromVersionSpec("1.0")}} returns a range with a
restriction that defines no checks
- {{VersionRange.createFromVersion("1.0")}} returns a range with no restriction
this is catched by unit tests: need to define if this difference is important
to maintain or the unit test has to be made more tolerant
was (Author: hboutemy):
reopening: {{VersionRange.createFromVersion("1.0")}} should not return the same
result as {{VersionRange.createFromVersionSpec("1.0")}}
- {{VersionRange.createFromVersionSpec("1.0")}} returns a range with a
restriction that defines no checks
- {{VersionRange.createFromVersion("1.0")}} returns a range with no restriction
> Maven memory consumption issue
> --
>
> Key: MNG-6571
> URL: https://issues.apache.org/jira/browse/MNG-6571
> Project: Maven
> Issue Type: Wish
>Affects Versions: 3.6.0
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.6.1
>
> Attachments: Maven-Reactor-Dump-Patched.png, Maven-Reactor-Dump.png
>
>
> as reported on Users list:
> https://lists.apache.org/thread.html/7d75142448b3c234742bdfd3c743e2f62065fe8e0a313905cbbb2523@%3Cusers.maven.apache.org%3E
> then with details on Dev list:
> https://lists.apache.org/thread.html/34b64295238594e554f1f2f119848bce3b60d4e1e22e09f26aa64166@%3Cdev.maven.apache.org%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-156) generatePom=false not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761572#comment-16761572
]
Karl Heinz Marbaise commented on MINSTALL-156:
--
Can you explain why you want to install an artifact without a pom file ?
> generatePom=false not working with 3.0.0-M1
> ---
>
> Key: MINSTALL-156
> URL: https://issues.apache.org/jira/browse/MINSTALL-156
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Robert Lieske
>Priority: Major
>
> Steps to reproduce:
> {{mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT}}
>
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:2.5.2:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO]
>
> {quote}
>
> changing the version of the maven-install-plugin in pom.xml to
> {{}}
> {{ maven-install-plugin}}
> {{ 3.0.0-M1}}
> {{ }}
>
> the same call to
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO] Installing
> C:\Users\xxx\AppData\Local\Temp\test1-1.0-SNAPSHOT7157743325898943802.pom to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
> [INFO]
>
> {quote}
>
> Which also installs a POM - which is not what we want!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6571) Maven memory consumption issue
[ https://issues.apache.org/jira/browse/MNG-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761571#comment-16761571 ] Hudson commented on MNG-6571: - Build unstable in Jenkins: Maven TLP » maven » master #168 See https://builds.apache.org/job/maven-box/job/maven/job/master/168/ > Maven memory consumption issue > -- > > Key: MNG-6571 > URL: https://issues.apache.org/jira/browse/MNG-6571 > Project: Maven > Issue Type: Wish >Affects Versions: 3.6.0 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy >Priority: Major > Fix For: 3.6.1 > > Attachments: Maven-Reactor-Dump-Patched.png, Maven-Reactor-Dump.png > > > as reported on Users list: > https://lists.apache.org/thread.html/7d75142448b3c234742bdfd3c743e2f62065fe8e0a313905cbbb2523@%3Cusers.maven.apache.org%3E > then with details on Dev list: > https://lists.apache.org/thread.html/34b64295238594e554f1f2f119848bce3b60d4e1e22e09f26aa64166@%3Cdev.maven.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-917) Implement scm:untag for Subversion provider
[ https://issues.apache.org/jira/browse/SCM-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761581#comment-16761581 ] Clemens Quoß commented on SCM-917: -- Hello Michael, hopefully followed your guide correctly: [https://github.com/apache/maven-scm/pull/88] Regards, Clemens > Implement scm:untag for Subversion provider > --- > > Key: SCM-917 > URL: https://issues.apache.org/jira/browse/SCM-917 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-svn >Affects Versions: 1.11.1 >Reporter: Clemens Quoß >Priority: Critical > Fix For: waiting-for-feedback > > Attachments: git-diff-master.out, image-2019-02-02-16-57-33-664.png > > Time Spent: 10m > Remaining Estimate: 0h > > In order to work on MRELEASE-229, I would like to provide a PR for SCM to > enable remote removal for provider svn. > Short outline: > Introducing new parameter on scm:remove "remoteRemove" (alternative: use > pushChanges for this for svn, but this might be confusing). > Implementation: > New execute method in SvnRemoveCommand using a new ScmRemoveParameters > carrying this new parameter. If true, use url from repository as base to > construct targets from scm file set in command line. > [UPDATE] - Implementation of scm:untag command will now be the target of this > issue (follow comment discussion) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MSHARED-800) remove Maven version from pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761545#comment-16761545
]
Michael Osipov edited comment on MSHARED-800 at 2/6/19 8:27 AM:
I think we should leave {{# Created by Apache Maven}} only at most. Everything
else is duplicate information since it can be provided via {{MANIFEST.MF}}.
Though, I dislike the {{Created by}} value because it contradicts the base
value in {{MANIFEST.MF}}.
was (Author: michael-o):
I think we should leave {{# Created by Apache Maven}} only at most. Everything
else is duplicate information since it can be provided via {{MANIFEST.MF}}.
Though, I dislike the {{Created by}} value because it contradicts the prefix in
{{MANIFEST.MF}}.
> remove Maven version from pom.properties
>
>
> Key: MSHARED-800
> URL: https://issues.apache.org/jira/browse/MSHARED-800
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Currently, generated
> {{META-INF/maven/$\{groupId\}/$\{artifactId\}/pom.properties}} contains
> {{#Created by Apache Maven $\{maven.version\}}}, which is not a reproducible
> value
> we should either remove the version, either use the same value as the
> {{Created-By}} manifest entry as defined in MSHARED-799
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-917) Implement scm:untag for Subversion provider
[ https://issues.apache.org/jira/browse/SCM-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761559#comment-16761559 ] Michael Osipov commented on SCM-917: Let me guide you: * Fork the repo on GH * Clone the repo locally * Create the branch SCM-917 * Do the magic * Review and create a PR Magic: Change/add the code which is necessary to solve the problem. Tests are requires. You can use the Git tests (flow) or any other Subversion test as an example. That will suffice. Don't change unrelated parts. I. .e, if you want to fix the JGit stuff, create another ticket and branch for it. > Implement scm:untag for Subversion provider > --- > > Key: SCM-917 > URL: https://issues.apache.org/jira/browse/SCM-917 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-svn >Affects Versions: 1.11.1 >Reporter: Clemens Quoß >Priority: Critical > Fix For: waiting-for-feedback > > Attachments: git-diff-master.out, image-2019-02-02-16-57-33-664.png > > > In order to work on MRELEASE-229, I would like to provide a PR for SCM to > enable remote removal for provider svn. > Short outline: > Introducing new parameter on scm:remove "remoteRemove" (alternative: use > pushChanges for this for svn, but this might be confusing). > Implementation: > New execute method in SvnRemoveCommand using a new ScmRemoveParameters > carrying this new parameter. If true, use url from repository as base to > construct targets from scm file set in command line. > [UPDATE] - Implementation of scm:untag command will now be the target of this > issue (follow comment discussion) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] cquoss opened a new pull request #88: SCM-917 add untag for svn
cquoss opened a new pull request #88: SCM-917 add untag for svn URL: https://github.com/apache/maven-scm/pull/88 Hello everyone, first time handing in a pull request, please be gentle. PR targets untag functionality for provider subversion in maven-scm. Implementation tests are provided, though intention of tck test classes not understood. Provided 'normal' ScmTests insted that are executed during build. Changes made on Provider API, Manager API left unchanged (intention of Manager API unclear, seems outdated). Anything missing, please advise. Regards, Clemens This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (MNG-6571) Maven memory consumption issue
[
https://issues.apache.org/jira/browse/MNG-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761555#comment-16761555
]
Hervé Boutemy edited comment on MNG-6571 at 2/6/19 8:50 AM:
reopening: {{VersionRange.createFromVersion("1.0")}} and
{{VersionRange.createFromVersionSpec("1.0")}} do not exactly return the same
object
- {{VersionRange.createFromVersionSpec("1.0")}} returns a range with one
restriction that defines no checks
- {{VersionRange.createFromVersion("1.0")}} returns a range with no restriction
this is catched by unit tests: need to define if this difference is important
to maintain or the unit test has to be made more tolerant
was (Author: hboutemy):
reopening: {{VersionRange.createFromVersion("1.0")}} and
{{VersionRange.createFromVersionSpec("1.0")}} do not exactly return the same
object
- {{VersionRange.createFromVersionSpec("1.0")}} returns a range with a
restriction that defines no checks
- {{VersionRange.createFromVersion("1.0")}} returns a range with no restriction
this is catched by unit tests: need to define if this difference is important
to maintain or the unit test has to be made more tolerant
> Maven memory consumption issue
> --
>
> Key: MNG-6571
> URL: https://issues.apache.org/jira/browse/MNG-6571
> Project: Maven
> Issue Type: Wish
>Affects Versions: 3.6.0
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.6.1
>
> Attachments: Maven-Reactor-Dump-Patched.png, Maven-Reactor-Dump.png
>
>
> as reported on Users list:
> https://lists.apache.org/thread.html/7d75142448b3c234742bdfd3c743e2f62065fe8e0a313905cbbb2523@%3Cusers.maven.apache.org%3E
> then with details on Dev list:
> https://lists.apache.org/thread.html/34b64295238594e554f1f2f119848bce3b60d4e1e22e09f26aa64166@%3Cdev.maven.apache.org%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-156) generatePom=false not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761601#comment-16761601
]
Robert Lieske commented on MINSTALL-156:
Hi Karl Heinz,
Actually I don't care much about the Install, its the deploy that bothers me.
The issue is just similar.
I want to deploy both the created JAR and the JAR-with-dependencies to the
repository. As the release repository does not allow to upload the same POM
twice, I have to configure the maven-deploy-plugin to skip generation of POM
when uploading the JAR-with-dependencies.
As a side note: the uploaded artifacts have to have a different name, so I need
to configure everything by hand:
{code:java}
blabla
...
org.apache.maven.plugins
maven-install-plugin
default-install
true
install-small-file
install
install-file
${project.build.directory}/${project.build.finalName}.jar
${project.build.finalName}
${project.groupId}
${project.version}
install-fat-file
install
install-file
${project.build.directory}/${project.build.finalName}-jar-with-dependencies.jar
false
${project.build.finalName}
${project.groupId}
${project.version}
jar-with-dependencies
org.apache.maven.plugins
maven-deploy-plugin
default-deploy
true
deploy-small-file
deploy
deploy-file
${targetrepositoryId}
${targetrepositoryUrl}
${project.build.directory}/${project.build.finalName}.jar
${project.build.finalName}
${project.groupId}
${project.version}
deploy-fat-file
deploy
deploy-file
${targetrepositoryId}
${targetrepositoryUrl}
${project.build.directory}/${project.build.finalName}-jar-with-dependencies.jar
false
${project.build.finalName}
${project.groupId}
${project.version}
jar-with-dependencies
{code}
> generatePom=false not working with 3.0.0-M1
> ---
>
> Key: MINSTALL-156
> URL: https://issues.apache.org/jira/browse/MINSTALL-156
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Robert Lieske
>Priority: Major
>
> Steps to reproduce:
> {{mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT}}
>
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:2.5.2:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO]
>
> {quote}
>
> changing the version of the maven-install-plugin in pom.xml to
> {{}}
> {{ maven-install-plugin}}
> {{ 3.0.0-M1}}
> {{ }}
>
> the same call to
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO] Installing
> C:\Users\xxx\AppData\Local\Temp\test1-1.0-SNAPSHOT7157743325898943802.pom to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
> [INFO]
>
> {quote}
>
> Which also installs a POM - which is not what we want!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MINSTALL-156) generatePom=false not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761613#comment-16761613
]
Karl Heinz Marbaise edited comment on MINSTALL-156 at 2/6/19 9:30 AM:
--
In a Maven project you usually do {{mvn clean deploy}} and never call
{{install:install-file}} separately. This is true for install which means
simply {{mvn clean install}} as well as for deploy so you have to configure the
creation of the jar-with-dependencies via maven-assembly-plugin correctly which
results in just calling {{mvn clean deploy}} and it does not matter if you do
that for a {{SNAPSHO}} or for an release.
Update: Based on your configuration to install/deploy the jar-with-dependencies
is simply wrong. I assume you have created the jar-with-dependencies via
maven-assembly-plugin Please make a test project on Github so I can take a look
into it...
was (Author: khmarbaise):
In a Maven project you usually do {{mvn clean deploy}} and never call
{{install:install-file}} separately. This is true for install which means
simply {{mvn clean install}} as well as for deploy so you have to configure the
creation of the jar-with-dependencies via maven-assembly-plugin correctly which
results in just calling {{mvn clean deploy}} and it does not matter if you do
that for a {{SNAPSHO}} or for an release.
> generatePom=false not working with 3.0.0-M1
> ---
>
> Key: MINSTALL-156
> URL: https://issues.apache.org/jira/browse/MINSTALL-156
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Robert Lieske
>Priority: Major
>
> Steps to reproduce:
> {{mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT}}
>
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:2.5.2:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO]
>
> {quote}
>
> changing the version of the maven-install-plugin in pom.xml to
> {{}}
> {{ maven-install-plugin}}
> {{ 3.0.0-M1}}
> {{ }}
>
> the same call to
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO] Installing
> C:\Users\xxx\AppData\Local\Temp\test1-1.0-SNAPSHOT7157743325898943802.pom to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
> [INFO]
>
> {quote}
>
> Which also installs a POM - which is not what we want!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-156) generatePom=false not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761613#comment-16761613
]
Karl Heinz Marbaise commented on MINSTALL-156:
--
In a Maven project you usually do {{mvn clean deploy}} and never call
{{install:install-file}} separately. This is true for install which means
simply {{mvn clean install}} as well as for deploy so you have to configure the
creation of the jar-with-dependencies via maven-assembly-plugin correctly which
results in just calling {{mvn clean deploy}} and it does not matter if you do
that for a {{SNAPSHO}} or for an release.
> generatePom=false not working with 3.0.0-M1
> ---
>
> Key: MINSTALL-156
> URL: https://issues.apache.org/jira/browse/MINSTALL-156
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Robert Lieske
>Priority: Major
>
> Steps to reproduce:
> {{mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT}}
>
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:2.5.2:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO]
>
> {quote}
>
> changing the version of the maven-install-plugin in pom.xml to
> {{}}
> {{ maven-install-plugin}}
> {{ 3.0.0-M1}}
> {{ }}
>
> the same call to
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO] Installing
> C:\Users\xxx\AppData\Local\Temp\test1-1.0-SNAPSHOT7157743325898943802.pom to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
> [INFO]
>
> {quote}
>
> Which also installs a POM - which is not what we want!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MINSTALL-156) generatePom=false not working with 3.0.0-M1
[
https://issues.apache.org/jira/browse/MINSTALL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761613#comment-16761613
]
Karl Heinz Marbaise edited comment on MINSTALL-156 at 2/6/19 9:40 AM:
--
In a Maven project you usually do {{mvn clean deploy}} and never call
{{install:install-file}} separately. This is true for install which means
simply {{mvn clean install}} as well as for deploy so you have to configure the
creation of the jar-with-dependencies via maven-assembly-plugin correctly which
results in just calling {{mvn clean deploy}} and it does not matter if you do
that for a {{SNAPSHOT}} or for an release.
Update: Based on your configuration to install/deploy the jar-with-dependencies
is simply wrong. I assume you have created the jar-with-dependencies via
maven-assembly-plugin Please make a test project on Github so I can take a look
into it...
was (Author: khmarbaise):
In a Maven project you usually do {{mvn clean deploy}} and never call
{{install:install-file}} separately. This is true for install which means
simply {{mvn clean install}} as well as for deploy so you have to configure the
creation of the jar-with-dependencies via maven-assembly-plugin correctly which
results in just calling {{mvn clean deploy}} and it does not matter if you do
that for a {{SNAPSHO}} or for an release.
Update: Based on your configuration to install/deploy the jar-with-dependencies
is simply wrong. I assume you have created the jar-with-dependencies via
maven-assembly-plugin Please make a test project on Github so I can take a look
into it...
> generatePom=false not working with 3.0.0-M1
> ---
>
> Key: MINSTALL-156
> URL: https://issues.apache.org/jira/browse/MINSTALL-156
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Robert Lieske
>Priority: Major
>
> Steps to reproduce:
> {{mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DgroupId=test1 -DartifactId=test1 -Dversion=1.0-SNAPSHOT}}
>
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:2.5.2:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO]
>
> {quote}
>
> changing the version of the maven-install-plugin in pom.xml to
> {{}}
> {{ maven-install-plugin}}
> {{ 3.0.0-M1}}
> {{ }}
>
> the same call to
> {{mvn clean package install:install-file -Dfile=target/test1-1.0-SNAPSHOT.jar
> -DgeneratePom=false}}
> produces:
> {quote}[INFO] --- maven-install-plugin:3.0.0-M1:install-file (default-cli) @
> test1 ---
> [INFO] Installing D:\Workarea\sample\test1\target\test1-1.0-SNAPSHOT.jar to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.jar
> [INFO] Installing
> C:\Users\xxx\AppData\Local\Temp\test1-1.0-SNAPSHOT7157743325898943802.pom to
> C:\Users\xxx\.m2\repository\test1\test1\1.0-SNAPSHOT\test1-1.0-SNAPSHOT.pom
> [INFO]
>
> {quote}
>
> Which also installs a POM - which is not what we want!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
