[jira] [Closed] (MNG-6202) Cannot pass nonProxyHosts to ITs making remote tests lock up when proxy rejects to proxy internal hosts
[
https://issues.apache.org/jira/browse/MNG-6202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6202.
---
Resolution: Fixed
Fixed with
[217d956edeb20c71db8c06883a24aecfff8497f4|https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=217d956edeb20c71db8c06883a24aecfff8497f4].
> Cannot pass nonProxyHosts to ITs making remote tests lock up when proxy
> rejects to proxy internal hosts
> ---
>
> Key: MNG-6202
> URL: https://issues.apache.org/jira/browse/MNG-6202
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Consider you have a Nexus mirror with the appropriate reroute for Central in
> your local {{settings.xml}}. If your corporate environment requires you to
> use a proxy to access the Internet, remote ITs ({{settings-remote.xml}})
> which also use the Nexus mirror requesting artifacts Wagon will pass these
> requests to the proxy too. Most internal proxies refuse to serve internal
> hosts/resources.
> Provide an option to pass {{-Dproxy.nonProxyHosts=...}} and set them in
> {{settings-remote.xml}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MINDEXER-101) Forward port OSGI improvements (MINDEXER-97) to master
[ https://issues.apache.org/jira/browse/MINDEXER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952404#comment-15952404 ] ASF GitHub Bot commented on MINDEXER-101: - Github user carlspring commented on the issue: https://github.com/apache/maven-indexer/pull/15 @sesuncedu, One thing to mention though -- (nothing critical, just cosmetic) -- you don't seem to be following convention, which is making the checkstyle plugin complain. > Forward port OSGI improvements (MINDEXER-97) to master > -- > > Key: MINDEXER-101 > URL: https://issues.apache.org/jira/browse/MINDEXER-101 > Project: Maven Indexer > Issue Type: Task >Reporter: Simon Spero > Fix For: 6.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1353) Integration tests testing jvm forks should use subprocess and not embedded mode
[ https://issues.apache.org/jira/browse/SUREFIRE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952390#comment-15952390 ] Hudson commented on SUREFIRE-1353: -- SUCCESS: Integrated in Jenkins build maven-surefire #1684 (See [https://builds.apache.org/job/maven-surefire/1684/]) [SUREFIRE-1353] Integration tests testing jvm forks should use (tibor17: [http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=9c417780b512533edbe20f630525f75c6248160c]) * (edit) surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/ForkConsoleOutputWithErrorsIT.java * (edit) surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/ForkConsoleOutputIT.java * (edit) surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/ForkModeIT.java > Integration tests testing jvm forks should use subprocess and not embedded > mode > --- > > Key: SUREFIRE-1353 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1353 > Project: Maven Surefire > Issue Type: Test >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > > This issue was found while testing on platform FreeBSD. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6202) Cannot pass nonProxyHosts to ITs making remote tests lock up when proxy rejects to proxy internal hosts
[
https://issues.apache.org/jira/browse/MNG-6202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6202:
Description:
Consider you have a Nexus mirror with the appropriate reroute for Central in
your local {{settings.xml}}. If your corporate environment requires you to use
a proxy to access the Internet, remote ITs ({{settings-remote.xml}}) which also
use the Nexus mirror requesting artifacts Wagon will pass these requests to the
proxy too. Most internal proxies refuse to serve internal hosts/resources.
Provide an option to pass {{-Dproxy.nonProxyHosts=...}} and set them in
{{settings-remote.xml}}.
was:
Consider you have a Nexus mirror with the appropriate reroute for Central in
your local {{settings.xml}}. If your corporate environment requires you to use
a proxy to access the Internet, remote ITs ({{settings-remote.xml}} which also
use the Nexus mirror requesting artifacts Wagon will route these requests to
the proxy too. Most internal proxies refuse to serve internal hosts/resources.
Provide an option to pass {{-Dproxy.nonProxyHosts=...}} and set them in
{{settings-remote.xml}}.
> Cannot pass nonProxyHosts to ITs making remote tests lock up when proxy
> rejects to proxy internal hosts
> ---
>
> Key: MNG-6202
> URL: https://issues.apache.org/jira/browse/MNG-6202
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Consider you have a Nexus mirror with the appropriate reroute for Central in
> your local {{settings.xml}}. If your corporate environment requires you to
> use a proxy to access the Internet, remote ITs ({{settings-remote.xml}})
> which also use the Nexus mirror requesting artifacts Wagon will pass these
> requests to the proxy too. Most internal proxies refuse to serve internal
> hosts/resources.
> Provide an option to pass {{-Dproxy.nonProxyHosts=...}} and set them in
> {{settings-remote.xml}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6202) Cannot pass nonProxyHosts to ITs making remote tests lock up when proxy rejects to proxy internal hosts
[
https://issues.apache.org/jira/browse/MNG-6202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6202:
Summary: Cannot pass nonProxyHosts to ITs making remote tests lock up when
proxy rejects to proxy internal hosts (was: Cannot pass nonProxyHosts to ITs
making remote tests lock up when proxy reject to proxy internal hosts)
> Cannot pass nonProxyHosts to ITs making remote tests lock up when proxy
> rejects to proxy internal hosts
> ---
>
> Key: MNG-6202
> URL: https://issues.apache.org/jira/browse/MNG-6202
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Consider you have a Nexus mirror with the appropriate reroute for Central in
> your local {{settings.xml}}. If your corporate environment requires you to
> use a proxy to access the Internet, remote ITs ({{settings-remote.xml}} which
> also use the Nexus mirror requesting artifacts Wagon will route these
> requests to the proxy too. Most internal proxies refuse to serve internal
> hosts/resources.
> Provide an option to pass {{-Dproxy.nonProxyHosts=...}} and set them in
> {{settings-remote.xml}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1350) Upgrade Version of maven-invoker-plugin to 2.0.0
[ https://issues.apache.org/jira/browse/SUREFIRE-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1350: --- Issue Type: Improvement (was: Bug) > Upgrade Version of maven-invoker-plugin to 2.0.0 > > > Key: SUREFIRE-1350 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1350 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Trivial > Fix For: 2.19.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1353) Integration tests testing jvm forks should use subprocess and not embedded mode
[ https://issues.apache.org/jira/browse/SUREFIRE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1353: --- Labels: (was: test) > Integration tests testing jvm forks should use subprocess and not embedded > mode > --- > > Key: SUREFIRE-1353 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1353 > Project: Maven Surefire > Issue Type: Test >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > > This issue was found while testing on platform FreeBSD. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1353) Integration tests testing jvm forks should use subprocess and not embedded mode
[ https://issues.apache.org/jira/browse/SUREFIRE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1353: --- Issue Type: Test (was: Bug) > Integration tests testing jvm forks should use subprocess and not embedded > mode > --- > > Key: SUREFIRE-1353 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1353 > Project: Maven Surefire > Issue Type: Test >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > > This issue was found while testing on platform FreeBSD. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1351) Performance unit tests should GC to free limited memory size.
[ https://issues.apache.org/jira/browse/SUREFIRE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1351: --- Labels: (was: test) > Performance unit tests should GC to free limited memory size. > - > > Key: SUREFIRE-1351 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1351 > Project: Maven Surefire > Issue Type: Test > Components: Junit 4.7+ (parallel) support >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > > ParallelComputerBuilderTest > ParallelComputerUtilTest -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1351) Performance unit tests should GC to free limited memory size.
[ https://issues.apache.org/jira/browse/SUREFIRE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1351: --- Issue Type: Test (was: Bug) > Performance unit tests should GC to free limited memory size. > - > > Key: SUREFIRE-1351 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1351 > Project: Maven Surefire > Issue Type: Test > Components: Junit 4.7+ (parallel) support >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > > ParallelComputerBuilderTest > ParallelComputerUtilTest -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1348) Documentation of parameter "argLine" for goal "surefire:test" lacks mention of a key change made in v2.17
[
https://issues.apache.org/jira/browse/SUREFIRE-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1348:
---
Labels: (was: documentation)
> Documentation of parameter "argLine" for goal "surefire:test" lacks mention
> of a key change made in v2.17
> -
>
> Key: SUREFIRE-1348
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1348
> Project: Maven Surefire
> Issue Type: Documentation
> Components: Maven Surefire Plugin
>Affects Versions: 2.12, 2.12.1, 2.12.2, 2.12.3, 2.12.4, 2.13, 2.14,
> 2.14.1, 2.15, 2.16
>Reporter: Gordon Daugherty
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 2.19.2
>
>
> The documentation for the argLine parameter
> [here|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html]
> indicates "since v2.1" and the description refers to the @{argLine} syntax
> but doesn't mention that you have to be using surefire-maven-plugin v2.17 or
> greater for that functionality to work. See "SUREFIRE-1047 - Add @{...}
> property evaluation for the argLine".
> Probably the [goal arguments
> page|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html]
> plus the FAQ page that it links to should be updated with a mention of the
> minimum required maven-surefire-plugin version.
> I noticed this while experiencing issue "SUREFIRE-1273". Resolution of that
> issue should have been simple but I was on surefire-maven-plugin v2.12 and
> the documentation made it appear that @{argLine} was supported since v2.1. I
> needed to upgrade but there wasn't any obvious indication of that.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1348) Documentation of parameter "argLine" for goal "surefire:test" lacks mention of a key change made in v2.17
[
https://issues.apache.org/jira/browse/SUREFIRE-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1348:
---
Labels: documentation (was: )
> Documentation of parameter "argLine" for goal "surefire:test" lacks mention
> of a key change made in v2.17
> -
>
> Key: SUREFIRE-1348
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1348
> Project: Maven Surefire
> Issue Type: Documentation
> Components: Maven Surefire Plugin
>Affects Versions: 2.12, 2.12.1, 2.12.2, 2.12.3, 2.12.4, 2.13, 2.14,
> 2.14.1, 2.15, 2.16
>Reporter: Gordon Daugherty
>Assignee: Tibor Digana
>Priority: Minor
> Labels: documentation
> Fix For: 2.19.2
>
>
> The documentation for the argLine parameter
> [here|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html]
> indicates "since v2.1" and the description refers to the @{argLine} syntax
> but doesn't mention that you have to be using surefire-maven-plugin v2.17 or
> greater for that functionality to work. See "SUREFIRE-1047 - Add @{...}
> property evaluation for the argLine".
> Probably the [goal arguments
> page|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html]
> plus the FAQ page that it links to should be updated with a mention of the
> minimum required maven-surefire-plugin version.
> I noticed this while experiencing issue "SUREFIRE-1273". Resolution of that
> issue should have been simple but I was on surefire-maven-plugin v2.12 and
> the documentation made it appear that @{argLine} was supported since v2.1. I
> needed to upgrade but there wasn't any obvious indication of that.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1348) Documentation of parameter "argLine" for goal "surefire:test" lacks mention of a key change made in v2.17
[
https://issues.apache.org/jira/browse/SUREFIRE-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952363#comment-15952363
]
Tibor Digana commented on SUREFIRE-1348:
I will mention Version {{2.17}}.
> Documentation of parameter "argLine" for goal "surefire:test" lacks mention
> of a key change made in v2.17
> -
>
> Key: SUREFIRE-1348
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1348
> Project: Maven Surefire
> Issue Type: Documentation
> Components: Maven Surefire Plugin
>Affects Versions: 2.12, 2.12.1, 2.12.2, 2.12.3, 2.12.4, 2.13, 2.14,
> 2.14.1, 2.15, 2.16
>Reporter: Gordon Daugherty
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 2.19.2
>
>
> The documentation for the argLine parameter
> [here|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html]
> indicates "since v2.1" and the description refers to the @{argLine} syntax
> but doesn't mention that you have to be using surefire-maven-plugin v2.17 or
> greater for that functionality to work. See "SUREFIRE-1047 - Add @{...}
> property evaluation for the argLine".
> Probably the [goal arguments
> page|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html]
> plus the FAQ page that it links to should be updated with a mention of the
> minimum required maven-surefire-plugin version.
> I noticed this while experiencing issue "SUREFIRE-1273". Resolution of that
> issue should have been simple but I was on surefire-maven-plugin v2.12 and
> the documentation made it appear that @{argLine} was supported since v2.1. I
> needed to upgrade but there wasn't any obvious indication of that.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1348) Documentation of parameter "argLine" for goal "surefire:test" lacks mention of a key change made in v2.17
[
https://issues.apache.org/jira/browse/SUREFIRE-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1348:
---
Fix Version/s: 2.19.2
> Documentation of parameter "argLine" for goal "surefire:test" lacks mention
> of a key change made in v2.17
> -
>
> Key: SUREFIRE-1348
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1348
> Project: Maven Surefire
> Issue Type: Documentation
> Components: Maven Surefire Plugin
>Affects Versions: 2.12, 2.12.1, 2.12.2, 2.12.3, 2.12.4, 2.13, 2.14,
> 2.14.1, 2.15, 2.16
>Reporter: Gordon Daugherty
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 2.19.2
>
>
> The documentation for the argLine parameter
> [here|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html]
> indicates "since v2.1" and the description refers to the @{argLine} syntax
> but doesn't mention that you have to be using surefire-maven-plugin v2.17 or
> greater for that functionality to work. See "SUREFIRE-1047 - Add @{...}
> property evaluation for the argLine".
> Probably the [goal arguments
> page|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html]
> plus the FAQ page that it links to should be updated with a mention of the
> minimum required maven-surefire-plugin version.
> I noticed this while experiencing issue "SUREFIRE-1273". Resolution of that
> issue should have been simple but I was on surefire-maven-plugin v2.12 and
> the documentation made it appear that @{argLine} was supported since v2.1. I
> needed to upgrade but there wasn't any obvious indication of that.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MNG-6202) Cannot pass nonProxyHosts to ITs making remote tests lock up when proxy reject to proxy internal hosts
Michael Osipov created MNG-6202:
---
Summary: Cannot pass nonProxyHosts to ITs making remote tests lock
up when proxy reject to proxy internal hosts
Key: MNG-6202
URL: https://issues.apache.org/jira/browse/MNG-6202
Project: Maven
Issue Type: Bug
Components: Integration Tests
Reporter: Michael Osipov
Assignee: Michael Osipov
Consider you have a Nexus mirror with the appropriate reroute for Central in
your local {{settings.xml}}. If your corporate environment requires you to use
a proxy to access the Internet, remote ITs ({{settings-remote.xml}} which also
use the Nexus mirror requesting artifacts Wagon will route these requests to
the proxy too. Most internal proxies refuse to serve internal hosts/resources.
Provide an option to pass {{-Dproxy.nonProxyHosts=...}} and set them in
{{settings-remote.xml}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1352) Dump file [date]-jvmRun[N] where N should be real fork number
[
https://issues.apache.org/jira/browse/SUREFIRE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952356#comment-15952356
]
Hudson commented on SUREFIRE-1352:
--
SUCCESS: Integrated in Jenkins build maven-surefire #1683 (See
[https://builds.apache.org/job/maven-surefire/1683/])
[SUREFIRE-1352] Dump file [date]-jvmRun[N] where N should be real fork
(tibor17:
[http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=b08627f0fd21ab16b682badbc205cd2823f64656])
* (edit)
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
> Dump file [date]-jvmRun[N] where N should be real fork number
> -
>
> Key: SUREFIRE-1352
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1352
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> Currently N is {{AtomicInteger}} and not the fork Number.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines
[
https://issues.apache.org/jira/browse/SUREFIRE-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1222:
---
Fix Version/s: (was: 2.19.2)
2.20.1
> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
>
> This month the [Weld
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: -1
> at java.lang.String.substring(String.java:1911)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}}
> operation.
> I think the protocol should be robust enough to avoid similar collisions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1353) Integration tests testing jvm forks should use subprocess and not embedded mode
[ https://issues.apache.org/jira/browse/SUREFIRE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1353. -- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=9c417780b512533edbe20f630525f75c6248160c > Integration tests testing jvm forks should use subprocess and not embedded > mode > --- > > Key: SUREFIRE-1353 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1353 > Project: Maven Surefire > Issue Type: Bug >Reporter: Tibor Digana >Assignee: Tibor Digana > Labels: test > Fix For: 2.19.2 > > > This issue was found while testing on platform FreeBSD. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1353) Integration tests testing jvm forks should use subprocess and not embedded mode
[ https://issues.apache.org/jira/browse/SUREFIRE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1353: --- Labels: test (was: ) > Integration tests testing jvm forks should use subprocess and not embedded > mode > --- > > Key: SUREFIRE-1353 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1353 > Project: Maven Surefire > Issue Type: Bug >Reporter: Tibor Digana >Assignee: Tibor Digana > Labels: test > Fix For: 2.19.2 > > > This issue was found while testing on platform FreeBSD. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1353) Integration tests testing jvm forks should use subprocess and not embedded mode
[ https://issues.apache.org/jira/browse/SUREFIRE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1353: --- Description: This issue was found while testing on platform FreeBSD. > Integration tests testing jvm forks should use subprocess and not embedded > mode > --- > > Key: SUREFIRE-1353 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1353 > Project: Maven Surefire > Issue Type: Bug >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > > This issue was found while testing on platform FreeBSD. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SUREFIRE-1353) Integration tests testing jvm forks should use subprocess and not embedded mode
Tibor Digana created SUREFIRE-1353: -- Summary: Integration tests testing jvm forks should use subprocess and not embedded mode Key: SUREFIRE-1353 URL: https://issues.apache.org/jira/browse/SUREFIRE-1353 Project: Maven Surefire Issue Type: Bug Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 2.19.2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1352) Dump file [date]-jvmRun[N] where N should be real fork number
[
https://issues.apache.org/jira/browse/SUREFIRE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1352.
--
Resolution: Fixed
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=b08627f0fd21ab16b682badbc205cd2823f64656
> Dump file [date]-jvmRun[N] where N should be real fork number
> -
>
> Key: SUREFIRE-1352
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1352
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> Currently N is {{AtomicInteger}} and not the fork Number.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1352) Dump file [date]-jvmRun[N] where N should be real fork number
[
https://issues.apache.org/jira/browse/SUREFIRE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1352:
---
Description: Currently N is {{AtomicInteger}} and not the fork Number.
> Dump file [date]-jvmRun[N] where N should be real fork number
> -
>
> Key: SUREFIRE-1352
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1352
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> Currently N is {{AtomicInteger}} and not the fork Number.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SUREFIRE-1352) Dump file [date]-jvmRun[N] where N should be real fork number
Tibor Digana created SUREFIRE-1352: -- Summary: Dump file [date]-jvmRun[N] where N should be real fork number Key: SUREFIRE-1352 URL: https://issues.apache.org/jira/browse/SUREFIRE-1352 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 2.19.2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MINDEXER-97) Add OSGi 5.0 MANIFEST headers to OsgiArtifactIndexCreator
[ https://issues.apache.org/jira/browse/MINDEXER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952313#comment-15952313 ] ASF GitHub Bot commented on MINDEXER-97: Github user sesuncedu commented on the issue: https://github.com/apache/maven-indexer/pull/13 @cstamas Squashbasing gives the cleanest trees. Just make sure to give yourself credit for the commits of yours that were cherry-picked. index-reader should be identical for both branches. There's only a single package, and I bumped the OSGI package version to 5.2.0, since the additional public static fields are a minor API change over 5.1.2 . Since nexus is using karaf features / pax-aether-url , this isn't as necessary or helpful or as it might be, but it does mean that the feature assembly can safely refer to the 6.0 index-reader snapshot, since the osgi package version is explicitly backwards compatible. I actually ended up doing a third version of the changes as kludges on top of the nexus-public maven repository plugin. The main annoyance with index-reader was having to subclass Expander / Compactor to handle the additional fields, where a default mapping would have been simple. Since I needed to build some mapping tables anyway to stash the relevant manifest headers in an asset child map where they wouldn't get in the way, doing Expander/Compactor wasn't that much of an extra hassle, but if the index-reader is used to build federations, it is useful to be able to have unrecognized fields be passed through as strings (e.g. if jigsaw is released, exchanging headers from module-info.class (and now possibly the manifest?) will be useful for federated systems). > Add OSGi 5.0 MANIFEST headers to OsgiArtifactIndexCreator > - > > Key: MINDEXER-97 > URL: https://issues.apache.org/jira/browse/MINDEXER-97 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Balazs Zsoldos > > It would be extremely useful if the following MANIFEST headers were added to > the index: > - Require-Capability > - Provide-Capability > - DynamicImport-Package > Especially the first two would be necessary to be able to build up a database > that helps finding dependencies for unsatisfied bundles. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MNG-6200) Some IT fails if proxy is configured
[
https://issues.apache.org/jira/browse/MNG-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6200.
---
Resolution: Fixed
Second problem fixed with
[0e1fc366a404341b24a4fd32773fa876e9a15252|https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=0e1fc366a404341b24a4fd32773fa876e9a15252].
> Some IT fails if proxy is configured
>
>
> Key: MNG-6200
> URL: https://issues.apache.org/jira/browse/MNG-6200
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Two problem types:
> # If a proxy is configured with {{maven-integration-testing}} some ITs fails
> because they have {{127.0.0.1}} in the URL. This is passed to the proxy and
> the proxy is -- of course -- not able to resolve this.
> It has to be changed to {{localhost}} to be exempted by the proxy have to
> have a direct connection.
> # ITs {{MavenITmng0507ArtifactRelocationTest}} and
> {{MavenIT0041ArtifactTypeFromPluginExtensionTest}} define a local
> {{settings.xml}} but fails to require global {{settings-remote.xml}} to route
> through a proxy. Result is no route to host.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6200) Some IT fails if proxy is configured
[
https://issues.apache.org/jira/browse/MNG-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6200:
Summary: Some IT fails if proxy is configured (was: Some ITs fails if
proxy is configured)
> Some IT fails if proxy is configured
>
>
> Key: MNG-6200
> URL: https://issues.apache.org/jira/browse/MNG-6200
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Two problem types:
> # If a proxy is configured with {{maven-integration-testing}} some ITs fails
> because they have {{127.0.0.1}} in the URL. This is passed to the proxy and
> the proxy is -- of course -- not able to resolve this.
> It has to be changed to {{localhost}} to be exempted by the proxy have to
> have a direct connection.
> # ITs {{MavenITmng0507ArtifactRelocationTest}} and
> {{MavenIT0041ArtifactTypeFromPluginExtensionTest}} define a local
> {{settings.xml}} but fails to require global {{settings-remote.xml}} to route
> through a proxy. Result is no route to host.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEPLOY-218) deploy-file is inconsistent with install-file behavior.
[
https://issues.apache.org/jira/browse/MDEPLOY-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952265#comment-15952265
]
Robert Scholte commented on MDEPLOY-218:
Just trying to understand: you want a different pom to be installed/deployed
then the one used to build the project? Call your solution creative, but you
should want to have a look at the
[flatten-maven-plugin|http://www.mojohaus.org/flatten-maven-plugin/].
> deploy-file is inconsistent with install-file behavior.
> ---
>
> Key: MDEPLOY-218
> URL: https://issues.apache.org/jira/browse/MDEPLOY-218
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy-file
>Affects Versions: 2.8.2
>Reporter: Yujue Li
> Labels: build
>
> The following configuration, install-file will take effect, but deploy-file
> will not take effect.
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
> true
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
>
> core-install
> install
>
> install-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> false
> 2.8.2
>
> true
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> 2.8.2
> false
>
>
> core-deploy
> deploy
>
> deploy-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
> http://192.168.2.241:7001/nexus/content/repositories/releases
>
> platform-release
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1350) Upgrade Version of maven-invoker-plugin to 2.0.0
[ https://issues.apache.org/jira/browse/SUREFIRE-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952263#comment-15952263 ] Hudson commented on SUREFIRE-1350: -- SUCCESS: Integrated in Jenkins build maven-surefire #1682 (See [https://builds.apache.org/job/maven-surefire/1682/]) [SUREFIRE-1350] Upgrade Version of maven-invoker-plugin to 2.0.0 (tibor17: [http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=40f38c521b839d80a04f0f0de3deebb8009370f3]) * (edit) pom.xml > Upgrade Version of maven-invoker-plugin to 2.0.0 > > > Key: SUREFIRE-1350 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1350 > Project: Maven Surefire > Issue Type: Bug >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Trivial > Fix For: 2.19.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1351) Performance unit tests should GC to free limited memory size.
[ https://issues.apache.org/jira/browse/SUREFIRE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952264#comment-15952264 ] Hudson commented on SUREFIRE-1351: -- SUCCESS: Integrated in Jenkins build maven-surefire #1682 (See [https://builds.apache.org/job/maven-surefire/1682/]) [SUREFIRE-1351] Performance unit tests should GC to free limited memory (tibor17: [http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=dc3f3674e17c3502312a88385272c6add9d4b4ad]) * (edit) surefire-providers/surefire-junit47/pom.xml * (edit) surefire-providers/surefire-junit47/src/test/java/org/apache/maven/surefire/junitcore/pc/ParallelComputerBuilderTest.java * (edit) surefire-providers/surefire-junit47/src/test/java/org/apache/maven/surefire/junitcore/pc/ParallelComputerUtilTest.java > Performance unit tests should GC to free limited memory size. > - > > Key: SUREFIRE-1351 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1351 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Reporter: Tibor Digana >Assignee: Tibor Digana > Labels: test > Fix For: 2.19.2 > > > ParallelComputerBuilderTest > ParallelComputerUtilTest -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Moved] (MDEPLOY-218) deploy-file is inconsistent with install-file behavior.
[
https://issues.apache.org/jira/browse/MDEPLOY-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte moved MNG-6201 to MDEPLOY-218:
-
Affects Version/s: (was: 3.3.9)
2.8.2
Component/s: (was: Plugins and Lifecycle)
deploy:deploy-file
Key: MDEPLOY-218 (was: MNG-6201)
Project: Maven Deploy Plugin (was: Maven)
> deploy-file is inconsistent with install-file behavior.
> ---
>
> Key: MDEPLOY-218
> URL: https://issues.apache.org/jira/browse/MDEPLOY-218
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy-file
>Affects Versions: 2.8.2
>Reporter: Yujue Li
> Labels: build
>
> The following configuration, install-file will take effect, but deploy-file
> will not take effect.
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
> true
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
>
> core-install
> install
>
> install-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> false
> 2.8.2
>
> true
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> 2.8.2
> false
>
>
> core-deploy
> deploy
>
> deploy-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
> http://192.168.2.241:7001/nexus/content/repositories/releases
>
> platform-release
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MNG-6200) Some ITs fails if proxy is configured
[
https://issues.apache.org/jira/browse/MNG-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952235#comment-15952235
]
Michael Osipov edited comment on MNG-6200 at 4/1/17 2:54 PM:
-
First problem fixed with
[47d5885eb81fff13610b2b916655f45be978b638|https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=47d5885eb81fff13610b2b916655f45be978b638].
was (Author: michael-o):
Fixed with
[47d5885eb81fff13610b2b916655f45be978b638|https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=47d5885eb81fff13610b2b916655f45be978b638].
> Some ITs fails if proxy is configured
> -
>
> Key: MNG-6200
> URL: https://issues.apache.org/jira/browse/MNG-6200
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Two problem types:
> # If a proxy is configured with {{maven-integration-testing}} some ITs fails
> because they have {{127.0.0.1}} in the URL. This is passed to the proxy and
> the proxy is -- of course -- not able to resolve this.
> It has to be changed to {{localhost}} to be exempted by the proxy have to
> have a direct connection.
> # ITs {{MavenITmng0507ArtifactRelocationTest}} and
> {{MavenIT0041ArtifactTypeFromPluginExtensionTest}} define a local
> {{settings.xml}} but fails to require global {{settings-remote.xml}} to route
> through a proxy. Result is no route to host.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6200) Some ITs fails if proxy is configured
[
https://issues.apache.org/jira/browse/MNG-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6200:
Description:
Two problem types:
# If a proxy is configured with {{maven-integration-testing}} some ITs fails
because they have {{127.0.0.1}} in the URL. This is passed to the proxy and the
proxy is -- of course -- not able to resolve this.
It has to be changed to {{localhost}} to be exempted by the proxy have to have
a direct connection.
# ITs {{MavenITmng0507ArtifactRelocationTest}} and
{{MavenIT0041ArtifactTypeFromPluginExtensionTest}} define a local
{{settings.xml}} but fails to require global {{settings-remote.xml}} to route
through a proxy. Result is no route to host.
was:
If a proxy is configured with {{maven-integration-testing}} some ITs fails
because they have {{127.0.0.1}} in the URL. This is passed to the proxy and the
proxy is -- of course -- not able to resolve this. The tests fail.
It has to be changed to {{localhost}} to be exempted by the proxy have to have
a direct connection.
> Some ITs fails if proxy is configured
> -
>
> Key: MNG-6200
> URL: https://issues.apache.org/jira/browse/MNG-6200
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Two problem types:
> # If a proxy is configured with {{maven-integration-testing}} some ITs fails
> because they have {{127.0.0.1}} in the URL. This is passed to the proxy and
> the proxy is -- of course -- not able to resolve this.
> It has to be changed to {{localhost}} to be exempted by the proxy have to
> have a direct connection.
> # ITs {{MavenITmng0507ArtifactRelocationTest}} and
> {{MavenIT0041ArtifactTypeFromPluginExtensionTest}} define a local
> {{settings.xml}} but fails to require global {{settings-remote.xml}} to route
> through a proxy. Result is no route to host.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MNG-6200) Some ITs fails if proxy is configured
[
https://issues.apache.org/jira/browse/MNG-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened MNG-6200:
-
> Some ITs fails if proxy is configured
> -
>
> Key: MNG-6200
> URL: https://issues.apache.org/jira/browse/MNG-6200
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> If a proxy is configured with {{maven-integration-testing}} some ITs fails
> because they have {{127.0.0.1}} in the URL. This is passed to the proxy and
> the proxy is -- of course -- not able to resolve this. The tests fail.
> It has to be changed to {{localhost}} to be exempted by the proxy have to
> have a direct connection.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6201) deploy-file is inconsistent with install-file behavior.
[
https://issues.apache.org/jira/browse/MNG-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952239#comment-15952239
]
Yujue Li commented on MNG-6201:
---
I don't want to use multi profile mode, which does not meet my needs.
I want to cancel the default install and deploy processes, and then call
install-file and deploy-file to deploy the specified pom.xml file.
However, in accordance with the above configuration, install-file can correctly
install the specified pom-deployment.xml file to the local repository, but
deploy-file will still deploy the default pom.xml file.
Although I solved the problem in other ways, but i think it's a bug.
> deploy-file is inconsistent with install-file behavior.
> ---
>
> Key: MNG-6201
> URL: https://issues.apache.org/jira/browse/MNG-6201
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
>Reporter: Yujue Li
> Labels: build
>
> The following configuration, install-file will take effect, but deploy-file
> will not take effect.
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
> true
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
>
> core-install
> install
>
> install-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> false
> 2.8.2
>
> true
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> 2.8.2
> false
>
>
> core-deploy
> deploy
>
> deploy-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
> http://192.168.2.241:7001/nexus/content/repositories/releases
>
> platform-release
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Issue Comment Deleted] (MNG-6201) deploy-file is inconsistent with install-file behavior.
[
https://issues.apache.org/jira/browse/MNG-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yujue Li updated MNG-6201:
--
Comment: was deleted
(was: I don't want to use multi profile mode, which does not meet my needs.
I want to cancel the default install and deploy processes, and then call
install-file and deploy-file to deploy the specified pom.xml file.
However, in accordance with the above configuration, install-file can correctly
install the specified pom.xml file to the local repository, but deploy-file
will still deploy the default pom.xml file.)
> deploy-file is inconsistent with install-file behavior.
> ---
>
> Key: MNG-6201
> URL: https://issues.apache.org/jira/browse/MNG-6201
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
>Reporter: Yujue Li
> Labels: build
>
> The following configuration, install-file will take effect, but deploy-file
> will not take effect.
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
> true
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
>
> core-install
> install
>
> install-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> false
> 2.8.2
>
> true
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> 2.8.2
> false
>
>
> core-deploy
> deploy
>
> deploy-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
> http://192.168.2.241:7001/nexus/content/repositories/releases
>
> platform-release
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6201) deploy-file is inconsistent with install-file behavior.
[
https://issues.apache.org/jira/browse/MNG-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952238#comment-15952238
]
Yujue Li commented on MNG-6201:
---
I don't want to use multi profile mode, which does not meet my needs.
I want to cancel the default install and deploy processes, and then call
install-file and deploy-file to deploy the specified pom.xml file.
However, in accordance with the above configuration, install-file can correctly
install the specified pom.xml file to the local repository, but deploy-file
will still deploy the default pom.xml file.
> deploy-file is inconsistent with install-file behavior.
> ---
>
> Key: MNG-6201
> URL: https://issues.apache.org/jira/browse/MNG-6201
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
>Reporter: Yujue Li
> Labels: build
>
> The following configuration, install-file will take effect, but deploy-file
> will not take effect.
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
> true
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
>
> core-install
> install
>
> install-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> false
> 2.8.2
>
> true
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> 2.8.2
> false
>
>
> core-deploy
> deploy
>
> deploy-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
> http://192.168.2.241:7001/nexus/content/repositories/releases
>
> platform-release
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6200) Some ITs fails if proxy is configured
[
https://issues.apache.org/jira/browse/MNG-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6200.
---
Resolution: Fixed
Fixed with
[47d5885eb81fff13610b2b916655f45be978b638|https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=47d5885eb81fff13610b2b916655f45be978b638].
> Some ITs fails if proxy is configured
> -
>
> Key: MNG-6200
> URL: https://issues.apache.org/jira/browse/MNG-6200
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> If a proxy is configured with {{maven-integration-testing}} some ITs fails
> because they have {{127.0.0.1}} in the URL. This is passed to the proxy and
> the proxy is -- of course -- not able to resolve this. The tests fail.
> It has to be changed to {{localhost}} to be exempted by the proxy have to
> have a direct connection.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6170) NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/MNG-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6170:
-
Fix Version/s: 3.5.0
> NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
>
>
> Key: MNG-6170
> URL: https://issues.apache.org/jira/browse/MNG-6170
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.1, 3.2.5, 3.3.1, 3.3.9
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.0-beta-1, 3.5.0
>
>
> Based on the
> [issue|https://github.com/mojohaus/versions-maven-plugin/issues/54] marked
> for the versions-maven-plugin investigation shows that the real cause of this
> problem is located in maven-core.
> The short description of the problem is calling Maven via: {{mvn -T 20
> versions:set -DnewVersion=1.0-SNAPSHOT}} you will get an NPE.
> I identified the following point in code as culprit for the problem:
> MultiThreadedBuilder.java
> {code}
> // for each finished project
> for ( int i = 0; i < analyzer.getNumberOfBuilds(); i++ )
> {
> try
> {
> ProjectSegment projectBuild = service.take().get();
> if ( reactorContext.getReactorBuildStatus().isHalted() )
> {
> break;
> }
> final List newItemsThatCanBeBuilt =
> analyzer.markAsFinished( projectBuild.getProject() );
> for ( MavenProject mavenProject : newItemsThatCanBeBuilt )
> {
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> }
> }
> catch ( InterruptedException e )
> {
> rootSession.getResult().addException( e );
> break;
> }
> catch ( ExecutionException e )
> {
> // TODO MNG-5766 changes likely made this redundant
> rootSession.getResult().addException( e );
> break;
> }
> }
> {code}
> And the problematic part is before the second debugging output line:
> {code}
> ProjectSegment scheduledDependent = projectBuildList.get(
> mavenProject );
> logger.debug( "Scheduling: " + scheduledDependent );
> Callable cb =
> createBuildCallable( rootSession, scheduledDependent,
> reactorContext, taskSegment, muxer );
> service.submit( cb );
> {code}
> Cause it happens that the {{scheduledDependent}} could be null which will
> cause the issue.
> This -looks like- is a regression, cause in Maven 3.0.5 it works without any
> issue.
> Update:
> I have found other examples where the NPE occurs:
> * {{mvn -T20 javadoc:aggregate}}
> * {{mvn -T20 install:install-file ...}}
> This can cause confusion if you are using {{mvn.config}} and put thing like
> {{-T X}} into it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1349) FreeBSD cross process communication needs to commit stdout data in forked JVM within a synchronized block
[
https://issues.apache.org/jira/browse/SUREFIRE-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952227#comment-15952227
]
Hudson commented on SUREFIRE-1349:
--
SUCCESS: Integrated in Jenkins build maven-surefire #1681 (See
[https://builds.apache.org/job/maven-surefire/1681/])
[SUREFIRE-1349] FreeBSD cross process communication needs to commit (tibor17:
[http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=67e61b07e35ce2ade82efc8e69240003b28fd83e])
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/booter/CommandReader.java
* (edit)
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkConfiguration.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/booter/ForkingRunListener.java
* (edit)
surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java
> FreeBSD cross process communication needs to commit stdout data in forked JVM
> within a synchronized block
> -
>
> Key: SUREFIRE-1349
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1349
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> In the branch {{2.19.2-experimental}} we discovered that less tests failed on
> the platform FreeBSD after we flushed {{stdout}}. Our old code did this
> already in some places but some missed this.
> As a negative side effect, closing stream, did not solve anything and stream
> could not be recovered.
> We were not sure if FreeBSD platform read the JAR file completely due to we
> did not close ZIP entry properly in JarOutputStream. We did all for finishing
> stream and we flushed FileOutputStream due to close() method does not
> explicitly flush stream, however flush/close contract is not documented, it's
> just sort of a known implicit behavior in Oracle's JRE that people generally
> trust. In specific cases where you know you need to call flush() before
> close() as been JRE platform independent.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6201) deploy-file is inconsistent with install-file behavior.
[
https://issues.apache.org/jira/browse/MNG-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952225#comment-15952225
]
Robert Scholte commented on MNG-6201:
-
Not sure what you mean here, but I recognize a bad pattern: using
install-file/deploy-file as part of a lifecycle. Seems to me what you are
trying to do is actually {{mvn deploy -f pom-deployment.xml}}
> deploy-file is inconsistent with install-file behavior.
> ---
>
> Key: MNG-6201
> URL: https://issues.apache.org/jira/browse/MNG-6201
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
>Reporter: Yujue Li
> Labels: build
>
> The following configuration, install-file will take effect, but deploy-file
> will not take effect.
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
> true
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5.2
> false
>
>
> core-install
> install
>
> install-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
>
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> false
> 2.8.2
>
> true
>
>
>
> org.apache.maven.plugins
> maven-deploy-plugin
> 2.8.2
> false
>
>
> core-deploy
> deploy
>
> deploy-file
>
>
>
> ${basedir}/pom-deployment.xml
>
> com.platform-dev.projects
> core
> ${c.version}
> pom
>
> http://192.168.2.241:7001/nexus/content/repositories/releases
>
> platform-release
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6201) deploy-file is inconsistent with install-file behavior.
[
https://issues.apache.org/jira/browse/MNG-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6201:
Description:
The following configuration, install-file will take effect, but deploy-file
will not take effect.
{code:xml}
org.apache.maven.plugins
maven-install-plugin
2.5.2
false
true
org.apache.maven.plugins
maven-install-plugin
2.5.2
false
core-install
install
install-file
${basedir}/pom-deployment.xml
com.platform-dev.projects
core
${c.version}
pom
org.apache.maven.plugins
maven-deploy-plugin
false
2.8.2
true
org.apache.maven.plugins
maven-deploy-plugin
2.8.2
false
core-deploy
deploy
deploy-file
${basedir}/pom-deployment.xml
com.platform-dev.projects
core
${c.version}
pom
http://192.168.2.241:7001/nexus/content/repositories/releases
platform-release
{code}
was:
The following configuration, install-file will take effect, but deploy-file
will not take effect.
org.apache.maven.plugins
maven-install-plugin
2.5.2
false
true
org.apache.maven.plugins
maven-install-plugin
2.5.2
false
core-install
install
install-file
${basedir}/pom-deployment.xml
com.platform-dev.projects
core
${c.version}
pom
org.apache.maven.plugins
maven-deploy-plugin
false
2.8.2
true
org.apache.maven.plugins
maven-deploy-plugin
2.8.2
false
core-deploy
[jira] [Closed] (SUREFIRE-1351) Performance unit tests should GC to free limited memory size.
[ https://issues.apache.org/jira/browse/SUREFIRE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1351. -- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=dc3f3674e17c3502312a88385272c6add9d4b4ad > Performance unit tests should GC to free limited memory size. > - > > Key: SUREFIRE-1351 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1351 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Reporter: Tibor Digana >Assignee: Tibor Digana > Labels: test > Fix For: 2.19.2 > > > ParallelComputerBuilderTest > ParallelComputerUtilTest -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1351) Performance unit tests should GC to free limited memory size.
[ https://issues.apache.org/jira/browse/SUREFIRE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1351: --- Labels: test (was: ) > Performance unit tests should GC to free limited memory size. > - > > Key: SUREFIRE-1351 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1351 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Reporter: Tibor Digana >Assignee: Tibor Digana > Labels: test > Fix For: 2.19.2 > > > ParallelComputerBuilderTest > ParallelComputerUtilTest -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1350) Upgrade Version of maven-invoker-plugin to 2.0.0
[ https://issues.apache.org/jira/browse/SUREFIRE-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1350. -- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=40f38c521b839d80a04f0f0de3deebb8009370f3 > Upgrade Version of maven-invoker-plugin to 2.0.0 > > > Key: SUREFIRE-1350 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1350 > Project: Maven Surefire > Issue Type: Bug >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Trivial > Fix For: 2.19.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SUREFIRE-1351) Performance unit tests should GC to free limited memory size.
Tibor Digana created SUREFIRE-1351: -- Summary: Performance unit tests should GC to free limited memory size. Key: SUREFIRE-1351 URL: https://issues.apache.org/jira/browse/SUREFIRE-1351 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 2.19.2 ParallelComputerBuilderTest ParallelComputerUtilTest -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SUREFIRE-1350) Upgrade Version of maven-invoker-plugin to 2.0.0
Tibor Digana created SUREFIRE-1350: -- Summary: Upgrade Version of maven-invoker-plugin to 2.0.0 Key: SUREFIRE-1350 URL: https://issues.apache.org/jira/browse/SUREFIRE-1350 Project: Maven Surefire Issue Type: Bug Reporter: Tibor Digana Assignee: Tibor Digana Priority: Trivial Fix For: 2.19.2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MNG-6201) deploy-file is inconsistent with install-file behavior.
Yujue Li created MNG-6201:
-
Summary: deploy-file is inconsistent with install-file behavior.
Key: MNG-6201
URL: https://issues.apache.org/jira/browse/MNG-6201
Project: Maven
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.3.9
Reporter: Yujue Li
The following configuration, install-file will take effect, but deploy-file
will not take effect.
org.apache.maven.plugins
maven-install-plugin
2.5.2
false
true
org.apache.maven.plugins
maven-install-plugin
2.5.2
false
core-install
install
install-file
${basedir}/pom-deployment.xml
com.platform-dev.projects
core
${c.version}
pom
org.apache.maven.plugins
maven-deploy-plugin
false
2.8.2
true
org.apache.maven.plugins
maven-deploy-plugin
2.8.2
false
core-deploy
deploy
deploy-file
${basedir}/pom-deployment.xml
com.platform-dev.projects
core
${c.version}
pom
http://192.168.2.241:7001/nexus/content/repositories/releases
platform-release
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1349) FreeBSD cross process communication needs to commit stdout data in forked JVM within a synchronized block
[
https://issues.apache.org/jira/browse/SUREFIRE-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1349.
--
Resolution: Fixed
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=67e61b07e35ce2ade82efc8e69240003b28fd83e
> FreeBSD cross process communication needs to commit stdout data in forked JVM
> within a synchronized block
> -
>
> Key: SUREFIRE-1349
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1349
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> In the branch {{2.19.2-experimental}} we discovered that less tests failed on
> the platform FreeBSD after we flushed {{stdout}}. Our old code did this
> already in some places but some missed this.
> As a negative side effect, closing stream, did not solve anything and stream
> could not be recovered.
> We were not sure if FreeBSD platform read the JAR file completely due to we
> did not close ZIP entry properly in JarOutputStream. We did all for finishing
> stream and we flushed FileOutputStream due to close() method does not
> explicitly flush stream, however flush/close contract is not documented, it's
> just sort of a known implicit behavior in Oracle's JRE that people generally
> trust. In specific cases where you know you need to call flush() before
> close() as been JRE platform independent.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SUREFIRE-1349) FreeBSD cross process communication needs to commit stdout data in forked JVM within a synchronized block
Tibor Digana created SUREFIRE-1349:
--
Summary: FreeBSD cross process communication needs to commit
stdout data in forked JVM within a synchronized block
Key: SUREFIRE-1349
URL: https://issues.apache.org/jira/browse/SUREFIRE-1349
Project: Maven Surefire
Issue Type: Bug
Reporter: Tibor Digana
Assignee: Tibor Digana
Fix For: 2.19.2
In the branch {{2.19.2-experimental}} we discovered that less tests failed on
the platform FreeBSD after we flushed {{stdout}}. Our old code did this already
in some places but some missed this.
As a negative side effect, closing stream, did not solve anything and stream
could not be recovered.
We were not sure if FreeBSD platform read the JAR file completely due to we did
not close ZIP entry properly in JarOutputStream. We did all for finishing
stream and we flushed FileOutputStream due to close() method does not
explicitly flush stream, however flush/close contract is not documented, it's
just sort of a known implicit behavior in Oracle's JRE that people generally
trust. In specific cases where you know you need to call flush() before close()
as been JRE platform independent.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARCHETYPE-521) Cannot specify remote repository for generate project from archetype
[ https://issues.apache.org/jira/browse/ARCHETYPE-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952187#comment-15952187 ] Hudson commented on ARCHETYPE-521: -- SUCCESS: Integrated in Jenkins build maven-archetype-m3 #268 (See [https://builds.apache.org/job/maven-archetype-m3/268/]) [ARCHETYPE-521] Cannot specify remote repository for generate project (rfscholte: rev ee96192df88a50cf90726ddfb95a72be4bdf2df0) * (add) maven-archetype-plugin/src/it/mrm/archetype-repository/3rdparty-archetype-1.0.pom * (edit) maven-archetype-plugin/src/it/mrm/settings.xml * (add) maven-archetype-plugin/src/it/mrm/archetype-repository/3rdparty-archetype-1.0.jar/archetype-resources/pom.xml * (edit) maven-archetype-plugin/pom.xml * (add) maven-archetype-plugin/src/it/projects/ARCHETYPE-521_archetype-repo/verify.groovy * (add) maven-archetype-plugin/src/it/mrm/archetype-repository/3rdparty-archetype-1.0.jar/META-INF/maven/archetype-metadata.xml * (add) maven-archetype-plugin/src/it/mrm/archetype-repository/archetype-catalog.xml * (add) maven-archetype-plugin/src/it/projects/ARCHETYPE-521_archetype-repo/invoker.properties * (add) maven-archetype-plugin/src/it/projects/ARCHETYPE-521_archetype-repo/test.properties > Cannot specify remote repository for generate project from archetype > > > Key: ARCHETYPE-521 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-521 > Project: Maven Archetype > Issue Type: Question > Components: Generator >Affects Versions: 3.0.0 > Environment: cmd >Reporter: Dmytro Sylaiev >Assignee: Robert Scholte > Labels: bug, command-line, question > Fix For: 3.0.1 > > > I wanted to create new project using mvn archetype:generate command. > Desired archetype was absent in the central repo, so I tried to use > -DarchetypeRepository=repo.url param. But this param is out of date in 3.0.0 > version of plugin. > So I needed to use mvn > org.apache.maven.plugins:maven-archetype-plugin:2.4:generate command. > Question: How can I specify specific repository for generating project > (without editing settings.xml file)? > (-DarchetypeCatalog=repo.url doesn't work too) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ARCHETYPE-521) Cannot specify remote repository for generate project from archetype
[ https://issues.apache.org/jira/browse/ARCHETYPE-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed ARCHETYPE-521. Resolution: Fixed Assignee: Robert Scholte Fix Version/s: 3.0.1 Confirmed with [ee96192df88a50cf90726ddfb95a72be4bdf2df0|http://git-wip-us.apache.org/repos/asf/maven-archetype/commit/ee96192d] > Cannot specify remote repository for generate project from archetype > > > Key: ARCHETYPE-521 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-521 > Project: Maven Archetype > Issue Type: Question > Components: Generator >Affects Versions: 3.0.0 > Environment: cmd >Reporter: Dmytro Sylaiev >Assignee: Robert Scholte > Labels: bug, command-line, question > Fix For: 3.0.1 > > > I wanted to create new project using mvn archetype:generate command. > Desired archetype was absent in the central repo, so I tried to use > -DarchetypeRepository=repo.url param. But this param is out of date in 3.0.0 > version of plugin. > So I needed to use mvn > org.apache.maven.plugins:maven-archetype-plugin:2.4:generate command. > Question: How can I specify specific repository for generating project > (without editing settings.xml file)? > (-DarchetypeCatalog=repo.url doesn't work too) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6195) Use consistent quoting forms in mvn launcher script
[
https://issues.apache.org/jira/browse/MNG-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952167#comment-15952167
]
Hudson commented on MNG-6195:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1587 (See
[https://builds.apache.org/job/maven-3.x/1587/])
[MNG-6195] Tidy up quoting and command substitution (stephen.alan.connolly:
[http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=96543b7c6ea52ad7ba3bcd559c38b159f8aa4c0d])
* (edit) apache-maven/src/bin/mvn
> Use consistent quoting forms in mvn launcher script
> ---
>
> Key: MNG-6195
> URL: https://issues.apache.org/jira/browse/MNG-6195
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.0-alpha-1, 3.5.0-beta-1
>Reporter: Stephen Connolly
>Assignee: Stephen Connolly
> Fix For: 3.5.0
>
>
> We have different forms of quoting in the shell script. We should pick a
> consistent policy and follow that.
> Specific areas of concern around backticks and {{$(...)}}
> Solaris 10 is known to have a true BourneShell which does not understand
> {{$(...)}} but the backtick style is very hard to quote effectively
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6198) mvn script fails to locate .mvn directory when pom location specified with -f
[
https://issues.apache.org/jira/browse/MNG-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15952168#comment-15952168
]
Hudson commented on MNG-6198:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1587 (See
[https://builds.apache.org/job/maven-3.x/1587/])
[MNG-6198] Use the directory specified by -f for searching with 'mvn'
(stephen.alan.connolly:
[http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=87cf1eeb7d2506e192da77f7d5b286fae2b20314])
* (edit) apache-maven/src/bin/mvn
> mvn script fails to locate .mvn directory when pom location specified with -f
> -
>
> Key: MNG-6198
> URL: https://issues.apache.org/jira/browse/MNG-6198
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.0-alpha-1, 3.5.0-beta-1
>Reporter: Stephen Connolly
>Assignee: Stephen Connolly
> Fix For: 3.5.0
>
>
> Steps to reproduce
> {code}
> $ mkdir apache
> $ cd apache
> $ git clone https://git-wip-us.apache.org/repos/asf/maven.git
> $ mkdir .mvn
> $ cd .mvn
> $ echo -DskipTests > maven.config
> $ cd ../maven
> $ mvn install # notice tests are skipped
> $ cd ../..
> $ mvn install -f apache/maven/pom.xml # notice tests not skipped (bug)
> $ cd apache
> $ mvn install -f maven/pom.xml # notice tests are skipped (accident)
> {code}
> The issue is that we do not search for the .mvn folder from the directory
> specified from {{-f}} rather from the current working directory
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ARCHETYPE-522) Introduce MRM for archetype-maven-plugin ITs
[ https://issues.apache.org/jira/browse/ARCHETYPE-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed ARCHETYPE-522. Resolution: Fixed Fixed as part of ARCHETYPE-520 > Introduce MRM for archetype-maven-plugin ITs > > > Key: ARCHETYPE-522 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-522 > Project: Maven Archetype > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.0.1 > > > This should confirm that mirroring to a repository manager works. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MNG-6198) mvn script fails to locate .mvn directory when pom location specified with -f
[
https://issues.apache.org/jira/browse/MNG-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly resolved MNG-6198.
---
Resolution: Fixed
87cf1eeb7d2506e192da77f7d5b286fae2b20314
> mvn script fails to locate .mvn directory when pom location specified with -f
> -
>
> Key: MNG-6198
> URL: https://issues.apache.org/jira/browse/MNG-6198
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.0-alpha-1, 3.5.0-beta-1
>Reporter: Stephen Connolly
>Assignee: Stephen Connolly
> Fix For: 3.5.0
>
>
> Steps to reproduce
> {code}
> $ mkdir apache
> $ cd apache
> $ git clone https://git-wip-us.apache.org/repos/asf/maven.git
> $ mkdir .mvn
> $ cd .mvn
> $ echo -DskipTests > maven.config
> $ cd ../maven
> $ mvn install # notice tests are skipped
> $ cd ../..
> $ mvn install -f apache/maven/pom.xml # notice tests not skipped (bug)
> $ cd apache
> $ mvn install -f maven/pom.xml # notice tests are skipped (accident)
> {code}
> The issue is that we do not search for the .mvn folder from the directory
> specified from {{-f}} rather from the current working directory
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MNG-6191) mvn -f complains about illegal readlink option under macOS
[
https://issues.apache.org/jira/browse/MNG-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly resolved MNG-6191.
---
Resolution: Fixed
87cf1eeb7d2506e192da77f7d5b286fae2b20314
> mvn -f complains about illegal readlink option under macOS
> --
>
> Key: MNG-6191
> URL: https://issues.apache.org/jira/browse/MNG-6191
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0-alpha-1, 3.5.0-beta-1
> Environment: Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Andreas Sewe
>Assignee: Stephen Connolly
> Fix For: 3.5.0
>
>
> This is a *regression* from Maven 3.3.9. With 3.5.0-alpha-1, using {{mvn -f}}
> under OS X causes the following error to be printed out (similar to
> MNG-5688), before the command proceeds (AFAICT) without error:
> {noformat}
> > mvn clean package -f releng/repository/pom.xml
> readlink: illegal option -- f
> usage: readlink [-n] [file ...]
> usage: dirname path
> [INFO] Scanning for projects...
> {noformat}
> FWIW, I don’t get this error on a normal {{mvn clean package}} without the
> {{-f}} parameter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MNG-6195) Use consistent quoting forms in mvn launcher script
[
https://issues.apache.org/jira/browse/MNG-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly resolved MNG-6195.
---
Resolution: Fixed
87cf1eeb7d2506e192da77f7d5b286fae2b20314
> Use consistent quoting forms in mvn launcher script
> ---
>
> Key: MNG-6195
> URL: https://issues.apache.org/jira/browse/MNG-6195
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.0-alpha-1, 3.5.0-beta-1
>Reporter: Stephen Connolly
>Assignee: Stephen Connolly
> Fix For: 3.5.0
>
>
> We have different forms of quoting in the shell script. We should pick a
> consistent policy and follow that.
> Specific areas of concern around backticks and {{$(...)}}
> Solaris 10 is known to have a true BourneShell which does not understand
> {{$(...)}} but the backtick style is very hard to quote effectively
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ARCHETYPE-520) Following mirror configuration from settings.xml for downloading archetype metadata
[
https://issues.apache.org/jira/browse/ARCHETYPE-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed ARCHETYPE-520.
Resolution: Fixed
Assignee: Robert Scholte
Fix Version/s: 3.0.1
Fixed in
[f831932cef0709cf72609d8e23169b5a4c01649f|http://git-wip-us.apache.org/repos/asf/maven-archetype/commit/f831932c]
> Following mirror configuration from settings.xml for downloading archetype
> metadata
> ---
>
> Key: ARCHETYPE-520
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-520
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: Johannes Siebel
>Assignee: Robert Scholte
> Fix For: 3.0.1
>
> Attachments: maven-archetype-delay.TXT, out.txt, settings.xml
>
>
> Since using the maven-archetype-plugin with version 3.0.0 the plugin tries to
> connect to _both_ our internal nexus and to {{http://repo.maven.apache.org}}
> for downloading Maven artifacts used by Archetypes. Since we are using a
> proxy, the generation of the archetype is delayed until the download of the
> Maven artifacts times out.
> We'd expect the archetype to only contact our own artifact repository,
> without trying to connect to {{http://repo.maven.apache.org}} at all.
> I've attached a snippet with the debug output of the archetype:generate goal
> and the configuration of our mirror.
> We assume this problem is related to ARCHETYPE-358.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
