[GitHub] solomax commented on issue #8: [MPIR-380] contributor email rendering is fixed
solomax commented on issue #8: [MPIR-380] contributor email rendering is fixed URL: https://github.com/apache/maven-project-info-reports-plugin/pull/8#issuecomment-464426404 Thanks @rfscholte, should be fixed now 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] (MCHECKSTYLE-368) Missing test-jar on mvn compile
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770300#comment-16770300
]
Adam Hornáček commented on MCHECKSTYLE-368:
---
Plugin definition from the top level pom.xml:
{code}
...
org.apache.maven.plugins
maven-checkstyle-plugin
3.0.0
com.puppycrawl.tools
checkstyle
8.17
checkstyle
validate
/dev/checkstyle/style.xml
UTF-8
true
true
/dev/checkstyle/suppressions.xml
/dev/checkstyle/fileheader.txt
${project.build.sourceDirectory}
check
{code}
Dependency that is causing the issue:
{code}
${project.groupId}
opengrok
${project.version}
test-jar
test
{code}
I also uploaded `mvn_debug.out` file.
Please let me know if you need any other information.
Thanks :)
> Missing test-jar on mvn compile
> ---
>
> Key: MCHECKSTYLE-368
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-368
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Adam Hornáček
>Priority: Minor
> Attachments: mvn_debug.out
>
>
> Hello,
> we have a multi-module Maven project. One of the subprojects depends on
> test-jar. Everything seems to work fine until I enable Maven Checkstyle
> Plugin in this subproject. Then `mvn compile` target fails; however, `mvn
> package` works fine.
> The error message:
> {code}
> [ERROR] Failed to execute goal on project opengrok-web: Could not resolve
> dependencies for project org.opengrok:opengrok-web:war:1.2.1: Failure to find
> org.opengrok:opengrok:jar:tests:1.2.1 in http://repo.maven.apache.org/maven2/
> was cached in the local repository, resolution will not be reattempted until
> the update interval of maven.org has elapsed or updates are forced -> [Help 1]
> {code}
> PR containing changes that cause this issue:
> https://github.com/oracle/opengrok/pull/2259
> Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MCHECKSTYLE-368) Missing test-jar on mvn compile
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Hornáček updated MCHECKSTYLE-368:
--
Attachment: mvn_debug.out
> Missing test-jar on mvn compile
> ---
>
> Key: MCHECKSTYLE-368
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-368
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Adam Hornáček
>Priority: Minor
> Attachments: mvn_debug.out
>
>
> Hello,
> we have a multi-module Maven project. One of the subprojects depends on
> test-jar. Everything seems to work fine until I enable Maven Checkstyle
> Plugin in this subproject. Then `mvn compile` target fails; however, `mvn
> package` works fine.
> The error message:
> {code}
> [ERROR] Failed to execute goal on project opengrok-web: Could not resolve
> dependencies for project org.opengrok:opengrok-web:war:1.2.1: Failure to find
> org.opengrok:opengrok:jar:tests:1.2.1 in http://repo.maven.apache.org/maven2/
> was cached in the local repository, resolution will not be reattempted until
> the update interval of maven.org has elapsed or updates are forced -> [Help 1]
> {code}
> PR containing changes that cause this issue:
> https://github.com/oracle/opengrok/pull/2259
> Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCHECKSTYLE-368) Missing test-jar on mvn compile
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770256#comment-16770256
]
Michael Osipov commented on MCHECKSTYLE-368:
Can you please provide debug log output?
> Missing test-jar on mvn compile
> ---
>
> Key: MCHECKSTYLE-368
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-368
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Adam Hornáček
>Priority: Minor
>
> Hello,
> we have a multi-module Maven project. One of the subprojects depends on
> test-jar. Everything seems to work fine until I enable Maven Checkstyle
> Plugin in this subproject. Then `mvn compile` target fails; however, `mvn
> package` works fine.
> The error message:
> {code}
> [ERROR] Failed to execute goal on project opengrok-web: Could not resolve
> dependencies for project org.opengrok:opengrok-web:war:1.2.1: Failure to find
> org.opengrok:opengrok:jar:tests:1.2.1 in http://repo.maven.apache.org/maven2/
> was cached in the local repository, resolution will not be reattempted until
> the update interval of maven.org has elapsed or updates are forced -> [Help 1]
> {code}
> PR containing changes that cause this issue:
> https://github.com/oracle/opengrok/pull/2259
> Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o opened a new pull request #10: [MASSEMBLY-871] Descriptor ref "bin" causes error messages in the bui…
michael-o opened a new pull request #10: [MASSEMBLY-871] Descriptor ref "bin" causes error messages in the bui… URL: https://github.com/apache/maven-assembly-plugin/pull/10 …ld log on Windows 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] [Updated] (SUREFIRE-1628) Plugins fail to execute on Maven 3.0.5 and Java 8
[
https://issues.apache.org/jira/browse/SUREFIRE-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SUREFIRE-1628:
-
Component/s: Maven Surefire Plugin
> Plugins fail to execute on Maven 3.0.5 and Java 8
> -
>
> Key: SUREFIRE-1628
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1628
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
> Environment: maven 3.0.5
> jdk 1.8u111
> sles 12
>Reporter: Jörg Sesterhenn
>Priority: Major
> Attachments: surefire-1628-mwe.zip
>
>
> The plugin seems to require plexus-java which cannot be found.
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> (default-integration-test) on project MyParentPOM: Execution
> default-integration-test of goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> failed: Unable to load the mojo 'integration-test' (or one of its required
> components) from the plugin
> 'org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3':
> com.google.inject.ProvisionException: Guice provision errors:
> [ERROR] 1) No implementation for
> org.codehaus.plexus.languages.java.jpms.LocationManager was bound.
> [ERROR] while locating org.apache.maven.plugin.failsafe.IntegrationTestMojo
> [ERROR] at
> ClassRealm[plugin>org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [ERROR] while locating org.apache.maven.plugin.Mojo annotated with
> @com.google.inject.name.Named(value=org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test)
> [ERROR] 1 error
> [ERROR] role: org.apache.maven.plugin.Mojo
> [ERROR] roleHint:
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> [ERROR] -> [Help 1]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-871) Descriptor ref "bin" causes error messages in the build log on Windows
[
https://issues.apache.org/jira/browse/MASSEMBLY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770251#comment-16770251
]
Michael Osipov commented on MASSEMBLY-871:
--
Pushed an updated branch. This should do. [~khmarbaise], does this look good to
you?
> Descriptor ref "bin" causes error messages in the build log on Windows
> --
>
> Key: MASSEMBLY-871
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-871
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Stefan Ferstl
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.1.2
>
>
> When using the builtin assembly descriptor {{bin}}, the build output contains
> ERRORs when run on Windows:
> {code}
> [INFO] --- maven-assembly-plugin:3.1.0:single (create-bin-distro) @
> descriptor-ref-demo ---
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.gz
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.bz2
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> However, the build succeeds and produces valid archives (tar.bz2, tar.gz and
> zip).
> The problem should rather be logged as WARN than as ERROR.
> To reproduce this issue, I created a demo project on GitHub:
> https://github.com/ferstl/MASSEMBLY-871 .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (DOXIA-575) Add support for (X)HTML5
[ https://issues.apache.org/jira/browse/DOXIA-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned DOXIA-575: Assignee: Michael Osipov > 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 >Assignee: Michael Osipov >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] [Commented] (SUREFIRE-1628) Plugins fail to execute on Maven 3.0.5 and Java 8
[
https://issues.apache.org/jira/browse/SUREFIRE-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770248#comment-16770248
]
Michael Osipov commented on SUREFIRE-1628:
--
I can confirm this now. [~tibor17], it seems like that Surefire does not work
on Maven 3.0.x. It does work on 3.1.x+.
> Plugins fail to execute on Maven 3.0.5 and Java 8
> -
>
> Key: SUREFIRE-1628
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1628
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
> Environment: maven 3.0.5
> jdk 1.8u111
> sles 12
>Reporter: Jörg Sesterhenn
>Priority: Major
> Attachments: surefire-1628-mwe.zip
>
>
> The plugin seems to require plexus-java which cannot be found.
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> (default-integration-test) on project MyParentPOM: Execution
> default-integration-test of goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> failed: Unable to load the mojo 'integration-test' (or one of its required
> components) from the plugin
> 'org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3':
> com.google.inject.ProvisionException: Guice provision errors:
> [ERROR] 1) No implementation for
> org.codehaus.plexus.languages.java.jpms.LocationManager was bound.
> [ERROR] while locating org.apache.maven.plugin.failsafe.IntegrationTestMojo
> [ERROR] at
> ClassRealm[plugin>org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [ERROR] while locating org.apache.maven.plugin.Mojo annotated with
> @com.google.inject.name.Named(value=org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test)
> [ERROR] 1 error
> [ERROR] role: org.apache.maven.plugin.Mojo
> [ERROR] roleHint:
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> [ERROR] -> [Help 1]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1628) Plugins fail to execute on Maven 3.0.5 and Java 8
[
https://issues.apache.org/jira/browse/SUREFIRE-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SUREFIRE-1628:
-
Summary: Plugins fail to execute on Maven 3.0.5 and Java 8 (was:
maven-failsafe-plugin fails to execute on Maven 3.0.5 and Java 8)
> Plugins fail to execute on Maven 3.0.5 and Java 8
> -
>
> Key: SUREFIRE-1628
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1628
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M3
> Environment: maven 3.0.5
> jdk 1.8u111
> sles 12
>Reporter: Jörg Sesterhenn
>Priority: Major
> Attachments: surefire-1628-mwe.zip
>
>
> The plugin seems to require plexus-java which cannot be found.
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> (default-integration-test) on project MyParentPOM: Execution
> default-integration-test of goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> failed: Unable to load the mojo 'integration-test' (or one of its required
> components) from the plugin
> 'org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3':
> com.google.inject.ProvisionException: Guice provision errors:
> [ERROR] 1) No implementation for
> org.codehaus.plexus.languages.java.jpms.LocationManager was bound.
> [ERROR] while locating org.apache.maven.plugin.failsafe.IntegrationTestMojo
> [ERROR] at
> ClassRealm[plugin>org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [ERROR] while locating org.apache.maven.plugin.Mojo annotated with
> @com.google.inject.name.Named(value=org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test)
> [ERROR] 1 error
> [ERROR] role: org.apache.maven.plugin.Mojo
> [ERROR] roleHint:
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> [ERROR] -> [Help 1]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1628) maven-failsafe-plugin fails to execute on Maven 3.0.5 and Java 8
[
https://issues.apache.org/jira/browse/SUREFIRE-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SUREFIRE-1628:
-
Summary: maven-failsafe-plugin fails to execute on Maven 3.0.5 and Java 8
(was: maven-failsafe-plugin fails to execute on maven 3.0.5 and java 8)
> maven-failsafe-plugin fails to execute on Maven 3.0.5 and Java 8
>
>
> Key: SUREFIRE-1628
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1628
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M3
> Environment: maven 3.0.5
> jdk 1.8u111
> sles 12
>Reporter: Jörg Sesterhenn
>Priority: Major
> Attachments: surefire-1628-mwe.zip
>
>
> The plugin seems to require plexus-java which cannot be found.
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> (default-integration-test) on project MyParentPOM: Execution
> default-integration-test of goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> failed: Unable to load the mojo 'integration-test' (or one of its required
> components) from the plugin
> 'org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3':
> com.google.inject.ProvisionException: Guice provision errors:
> [ERROR] 1) No implementation for
> org.codehaus.plexus.languages.java.jpms.LocationManager was bound.
> [ERROR] while locating org.apache.maven.plugin.failsafe.IntegrationTestMojo
> [ERROR] at
> ClassRealm[plugin>org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [ERROR] while locating org.apache.maven.plugin.Mojo annotated with
> @com.google.inject.name.Named(value=org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test)
> [ERROR] 1 error
> [ERROR] role: org.apache.maven.plugin.Mojo
> [ERROR] roleHint:
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> [ERROR] -> [Help 1]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MPIR-376) LightweightHttpsWagon is always used
[
https://issues.apache.org/jira/browse/MPIR-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-376:
Fix Version/s: waiting-for-feedback
> LightweightHttpsWagon is always used
>
>
> Key: MPIR-376
> URL: https://issues.apache.org/jira/browse/MPIR-376
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies, dependency-management, plugin-management
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.5.4
> (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T20:33:14+02:00)
> Maven home: /opt/apache-maven
> Java version: 1.8.0_152, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
>Reporter: Jan Gerken
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: build.log, pom.xml
>
>
> For all dependencies, one of the plugins needs to download always the
> {{LightweightHttpsWagon}} is used. Independent of the wagon provider
> configuration in the {{settings.xml}} or via {{-Dmaven.wagon.provider.https}}
> and {{-Dmaven.wagon.provider.http}}.
> Starting with Maven 3.0.4 the {{httpclient}} is the default wagon provider
> used for http and https connections. Therefore, I added add
> {{httpConfiguration}} for all servers I access in my {{settings.xml}} to
> reduce the timeout. This works well with all other plugins but for this
> plugin in version 3.0.0 it generates the following warning for each download:
> {code:java}
> [WARNING] Could not apply configuration for central to wagon
> org.apache.maven.wagon.providers.http.LightweightHttpsWagon:Cannot find
> 'httpConfiguration' in class
> org.apache.maven.wagon.providers.http.LightweightHttpsWagon{code}
> I tried to explicitly define the wagon provider to be {{httpclient}} for each
> server in my {{settings.xml}} and I tried to force the client via the command
> line arguments. None of this changes was successful.
> Please make this plugin use the configured wagon provider for each server and
> use the same default provider as the Maven version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPIR-376) LightweightHttpsWagon is always used
[
https://issues.apache.org/jira/browse/MPIR-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770246#comment-16770246
]
Michael Osipov commented on MPIR-376:
-
I see the issue, this is caused by adding the Wagon implementation to the POM.
[~rfscholte], this has been introduced by MPIR-366. Do we really need that
runtime dependency? Maven comes with a HTTP transport by default.
[~jan-apache-issues], can you build MPIR yourself from Git and remove the
dependency on Lightweight Wagon? Does this work for you?
> LightweightHttpsWagon is always used
>
>
> Key: MPIR-376
> URL: https://issues.apache.org/jira/browse/MPIR-376
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies, dependency-management, plugin-management
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.5.4
> (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T20:33:14+02:00)
> Maven home: /opt/apache-maven
> Java version: 1.8.0_152, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
>Reporter: Jan Gerken
>Priority: Major
> Attachments: build.log, pom.xml
>
>
> For all dependencies, one of the plugins needs to download always the
> {{LightweightHttpsWagon}} is used. Independent of the wagon provider
> configuration in the {{settings.xml}} or via {{-Dmaven.wagon.provider.https}}
> and {{-Dmaven.wagon.provider.http}}.
> Starting with Maven 3.0.4 the {{httpclient}} is the default wagon provider
> used for http and https connections. Therefore, I added add
> {{httpConfiguration}} for all servers I access in my {{settings.xml}} to
> reduce the timeout. This works well with all other plugins but for this
> plugin in version 3.0.0 it generates the following warning for each download:
> {code:java}
> [WARNING] Could not apply configuration for central to wagon
> org.apache.maven.wagon.providers.http.LightweightHttpsWagon:Cannot find
> 'httpConfiguration' in class
> org.apache.maven.wagon.providers.http.LightweightHttpsWagon{code}
> I tried to explicitly define the wagon provider to be {{httpclient}} for each
> server in my {{settings.xml}} and I tried to force the client via the command
> line arguments. None of this changes was successful.
> Please make this plugin use the configured wagon provider for each server and
> use the same default provider as the Maven version.
--
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=16770244#comment-16770244 ] Michael Osipov commented on DOXIA-575: -- This is scheduled next to be reviewed...hold thight! > 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] [Comment Edited] (MASSEMBLY-871) Descriptor ref "bin" causes error messages in the build log on Windows
[
https://issues.apache.org/jira/browse/MASSEMBLY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770237#comment-16770237
]
Michael Osipov edited comment on MASSEMBLY-871 at 2/16/19 10:05 PM:
Pushed a branch with a possible fix. Please validate. Passes on Windows. Need
to see have it behaves on non-Windows. I have just noticed that this
anti-pattern is used in many ITs.
was (Author: michael-o):
Pushed a branch with a possible fix. Please validate. Passes on Windows. Need
to see have it behaves on non-Windows.
> Descriptor ref "bin" causes error messages in the build log on Windows
> --
>
> Key: MASSEMBLY-871
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-871
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Stefan Ferstl
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.1.2
>
>
> When using the builtin assembly descriptor {{bin}}, the build output contains
> ERRORs when run on Windows:
> {code}
> [INFO] --- maven-assembly-plugin:3.1.0:single (create-bin-distro) @
> descriptor-ref-demo ---
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.gz
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.bz2
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> However, the build succeeds and produces valid archives (tar.bz2, tar.gz and
> zip).
> The problem should rather be logged as WARN than as ERROR.
> To reproduce this issue, I created a demo project on GitHub:
> https://github.com/ferstl/MASSEMBLY-871 .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MASSEMBLY-871) Descriptor ref "bin" causes error messages in the build log on Windows
[
https://issues.apache.org/jira/browse/MASSEMBLY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MASSEMBLY-871:
-
Fix Version/s: 3.1.2
> Descriptor ref "bin" causes error messages in the build log on Windows
> --
>
> Key: MASSEMBLY-871
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-871
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Stefan Ferstl
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.1.2
>
>
> When using the builtin assembly descriptor {{bin}}, the build output contains
> ERRORs when run on Windows:
> {code}
> [INFO] --- maven-assembly-plugin:3.1.0:single (create-bin-distro) @
> descriptor-ref-demo ---
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.gz
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.bz2
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> However, the build succeeds and produces valid archives (tar.bz2, tar.gz and
> zip).
> The problem should rather be logged as WARN than as ERROR.
> To reproduce this issue, I created a demo project on GitHub:
> https://github.com/ferstl/MASSEMBLY-871 .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-871) Descriptor ref "bin" causes error messages in the build log on Windows
[
https://issues.apache.org/jira/browse/MASSEMBLY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770237#comment-16770237
]
Michael Osipov commented on MASSEMBLY-871:
--
Pushed a branch with a possible fix. Please validate. Passes on Windows. Need
to see have it behaves on non-Windows.
> Descriptor ref "bin" causes error messages in the build log on Windows
> --
>
> Key: MASSEMBLY-871
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-871
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Stefan Ferstl
>Assignee: Michael Osipov
>Priority: Minor
>
> When using the builtin assembly descriptor {{bin}}, the build output contains
> ERRORs when run on Windows:
> {code}
> [INFO] --- maven-assembly-plugin:3.1.0:single (create-bin-distro) @
> descriptor-ref-demo ---
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.gz
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.bz2
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> However, the build succeeds and produces valid archives (tar.bz2, tar.gz and
> zip).
> The problem should rather be logged as WARN than as ERROR.
> To reproduce this issue, I created a demo project on GitHub:
> https://github.com/ferstl/MASSEMBLY-871 .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MASSEMBLY-871) Descriptor ref "bin" causes error messages in the build log on Windows
[
https://issues.apache.org/jira/browse/MASSEMBLY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MASSEMBLY-871:
Assignee: Michael Osipov
> Descriptor ref "bin" causes error messages in the build log on Windows
> --
>
> Key: MASSEMBLY-871
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-871
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Stefan Ferstl
>Assignee: Michael Osipov
>Priority: Minor
>
> When using the builtin assembly descriptor {{bin}}, the build output contains
> ERRORs when run on Windows:
> {code}
> [INFO] --- maven-assembly-plugin:3.1.0:single (create-bin-distro) @
> descriptor-ref-demo ---
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.gz
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.bz2
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> However, the build succeeds and produces valid archives (tar.bz2, tar.gz and
> zip).
> The problem should rather be logged as WARN than as ERROR.
> To reproduce this issue, I created a demo project on GitHub:
> https://github.com/ferstl/MASSEMBLY-871 .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MASSEMBLY-871) Descriptor ref "bin" causes error messages in the build log on Windows
[
https://issues.apache.org/jira/browse/MASSEMBLY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MASSEMBLY-871:
-
Summary: Descriptor ref "bin" causes error messages in the build log on
Windows (was: Descriptor Ref "bin" causes Errors in the build log on Windows)
> Descriptor ref "bin" causes error messages in the build log on Windows
> --
>
> Key: MASSEMBLY-871
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-871
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Stefan Ferstl
>Priority: Minor
>
> When using the builtin assembly descriptor {{bin}}, the build output contains
> ERRORs when run on Windows:
> {code}
> [INFO] --- maven-assembly-plugin:3.1.0:single (create-bin-distro) @
> descriptor-ref-demo ---
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.gz
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.bz2
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> However, the build succeeds and produces valid archives (tar.bz2, tar.gz and
> zip).
> The problem should rather be logged as WARN than as ERROR.
> To reproduce this issue, I created a demo project on GitHub:
> https://github.com/ferstl/MASSEMBLY-871 .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6495) ModelResolver cannot be null
[
https://issues.apache.org/jira/browse/MNG-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6495.
---
Resolution: Fixed
Fixed with
[c674bcfb426be6425471c541769b161ccef84586|https://gitbox.apache.org/repos/asf?p=maven-archiver.git;a=commit;h=c674bcfb426be6425471c541769b161ccef84586].
> ModelResolver cannot be null
>
>
> Key: MNG-6495
> URL: https://issues.apache.org/jira/browse/MNG-6495
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.5.4
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.1
>
>
> Got this exception stacktrace while writing some of my own code today:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException:
> request.modelResolver cannot be null (parent POM
> com.google.guava:guava-parent:26.0-jre and POM
> com.google.guava:guava:[unknown-version])
> at org.apache.commons.lang3.Validate.notNull(Validate.java:225)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1046)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:830)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:332)
> at
> com.google.cloud.tools.opensource.dependencies.MetadataExplorer.main(MetadataExplorer.java:50)
> {noformat}
> No big deal except that the JavaDoc at
> [ModelBuildingRequest|http://maven.apache.org/ref/3.5.4/maven-model-builder/apidocs/org/apache/maven/model/building/ModelBuildingRequest.html]
> says "The model resolver to use, may be null."
> Not sure whether to update the docs or the code here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DOXIASITETOOLS-193) Upgrade maven-parent to version 33
Karl Heinz Marbaise created DOXIASITETOOLS-193: -- Summary: Upgrade maven-parent to version 33 Key: DOXIASITETOOLS-193 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-193 Project: Maven Doxia Sitetools Issue Type: Dependency upgrade Affects Versions: 1.9 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 1.9 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DOXIASITETOOLS-192) Change to consistency three digit numbering schema
Karl Heinz Marbaise created DOXIASITETOOLS-192:
--
Summary: Change to consistency three digit numbering schema
Key: DOXIASITETOOLS-192
URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-192
Project: Maven Doxia Sitetools
Issue Type: Wish
Affects Versions: 1.9
Reporter: Karl Heinz Marbaise
I would suggest to follow a three digit numbering schema . WDYT [~hboutemy] ?
Instead of {{1.9}} going to {{1.9.0}} ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MASSEMBLY-871) Descriptor Ref "bin" causes Errors in the build log on Windows
[
https://issues.apache.org/jira/browse/MASSEMBLY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MASSEMBLY-871:
-
Affects Version/s: 3.1.1
> Descriptor Ref "bin" causes Errors in the build log on Windows
> --
>
> Key: MASSEMBLY-871
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-871
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Stefan Ferstl
>Priority: Minor
>
> When using the builtin assembly descriptor {{bin}}, the build output contains
> ERRORs when run on Windows:
> {code}
> [INFO] --- maven-assembly-plugin:3.1.0:single (create-bin-distro) @
> descriptor-ref-demo ---
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.gz
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.bz2
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> However, the build succeeds and produces valid archives (tar.bz2, tar.gz and
> zip).
> The problem should rather be logged as WARN than as ERROR.
> To reproduce this issue, I created a demo project on GitHub:
> https://github.com/ferstl/MASSEMBLY-871 .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEP-626) Upgrade struts and xerces due to CVEs
[
https://issues.apache.org/jira/browse/MDEP-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770234#comment-16770234
]
Karl Heinz Marbaise commented on MDEP-626:
--
So I have taken a look into the dependency tree:
{code}
[INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @
maven-dependency-plugin ---
[INFO]
org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:3.1.2-SNAPSHOT
[INFO] +- org.apache.maven:maven-compat:jar:3.0:test
[INFO] | +- org.apache.maven:maven-model-builder:jar:3.0:compile
[INFO] | +- org.apache.maven:maven-settings:jar:3.0:compile
[INFO] | +- org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[INFO] | | \- org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[INFO] | | \- org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
[INFO] | +- org.codehaus.plexus:plexus-component-annotations:jar:1.7.1:compile
[INFO] | \- org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-6:compile
[INFO] +- org.apache.maven:maven-artifact:jar:3.0:compile
[INFO] +- org.apache.maven:maven-plugin-api:jar:3.0:compile
[INFO] +- org.apache.maven:maven-model:jar:3.0:compile
[INFO] +- org.apache.maven:maven-core:jar:3.0:compile
[INFO] | +- org.apache.maven:maven-settings-builder:jar:3.0:compile
[INFO] | +- org.apache.maven:maven-aether-provider:jar:3.0:runtime
[INFO] | +- org.sonatype.aether:aether-impl:jar:1.7:compile
[INFO] | +- org.sonatype.aether:aether-api:jar:1.7:compile
[INFO] | +- org.sonatype.aether:aether-util:jar:1.7:compile
[INFO] | +- org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[INFO] | \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
[INFO] | \- org.sonatype.plexus:plexus-cipher:jar:1.4:compile
[INFO] +- org.apache.maven:maven-repository-metadata:jar:3.0:compile
[INFO] +- org.apache.maven.reporting:maven-reporting-api:jar:3.0:compile
[INFO] +- org.apache.maven.reporting:maven-reporting-impl:jar:2.3:compile
[INFO] | +- org.apache.maven.doxia:doxia-core:jar:1.2:compile
[INFO] | | +- xerces:xercesImpl:jar:2.9.1:compile
[INFO] | | | \- xml-apis:xml-apis:jar:1.3.04:compile
[INFO] | | \- org.apache.httpcomponents:httpclient:jar:4.0.2:compile
[INFO] | | \- org.apache.httpcomponents:httpcore:jar:4.0.1:compile
[INFO] | \- commons-validator:commons-validator:jar:1.3.1:compile
[INFO] | +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
[INFO] | +- commons-digester:commons-digester:jar:1.6:compile
[INFO] | \- commons-logging:commons-logging:jar:1.0.4:compile
[INFO] +- commons-io:commons-io:jar:2.5:compile
[INFO] +- org.apache.maven.doxia:doxia-sink-api:jar:1.4:compile
[INFO] | \- org.apache.maven.doxia:doxia-logging-api:jar:1.4:compile
[INFO] +- org.apache.maven.doxia:doxia-site-renderer:jar:1.4:compile
[INFO] | +- org.apache.maven.doxia:doxia-decoration-model:jar:1.4:compile
[INFO] | +- org.apache.maven.doxia:doxia-module-xhtml:jar:1.4:compile
[INFO] | +- org.apache.maven.doxia:doxia-module-fml:jar:1.4:compile
[INFO] | +- org.codehaus.plexus:plexus-i18n:jar:1.0-beta-7:compile
[INFO] | +-
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-30:compile
[INFO] | +- org.codehaus.plexus:plexus-velocity:jar:1.1.7:compile
[INFO] | +- org.apache.velocity:velocity:jar:1.5:compile
[INFO] | | \- oro:oro:jar:2.0.8:compile
[INFO] | \- org.apache.velocity:velocity-tools:jar:2.0:compile
[INFO] | +- commons-chain:commons-chain:jar:1.1:compile
[INFO] | +- dom4j:dom4j:jar:1.1:compile
[INFO] | +- sslext:sslext:jar:1.2-0:compile
[INFO] | +- org.apache.struts:struts-core:jar:1.3.8:compile
[INFO] | | \- antlr:antlr:jar:2.7.2:compile
[INFO] | +- org.apache.struts:struts-taglib:jar:1.3.8:compile
[INFO] | \- org.apache.struts:struts-tiles:jar:1.3.8:compile
[INFO] +- org.codehaus.plexus:plexus-archiver:jar:3.7.0:compile
[INFO] | +- org.apache.commons:commons-compress:jar:1.18:compile
[INFO] | +- org.iq80.snappy:snappy:jar:0.4:compile
[INFO] | \- org.tukaani:xz:jar:1.8:runtime
[INFO] +- org.codehaus.plexus:plexus-utils:jar:3.1.0:compile
[INFO] +- org.apache.maven.shared:file-management:jar:3.0.0:compile
[INFO] | \- org.apache.maven.shared:maven-shared-io:jar:3.0.0:compile
[INFO] +- org.codehaus.plexus:plexus-io:jar:3.1.0:compile
[INFO] +- org.apache.maven.shared:maven-dependency-analyzer:jar:1.11.1:compile
[INFO] | \- org.ow2.asm:asm:jar:7.0:compile
[INFO] +- org.apache.maven.shared:maven-dependency-tree:jar:3.0.1:compile
[INFO] | \- org.eclipse.aether:aether-util:jar:0.9.0.M2:compile
[INFO] +-
org.apache.maven.shared:maven-common-artifact-filters:jar:3.0.1:compile
[INFO] +- org.apache.maven.shared:maven-artifact-transfer:jar:0.9.1:compile
[INFO] | +- commons-codec:commons-codec:jar:1.6:compile
[INFO] | \- org.slf4j:slf4j-api:jar:1.7.5:compile
[INFO] +- org.apache.maven.shared:maven-shared-utils:jar:3.2.1:compile
[INFO] +- commons-lang:commons-lang:jar:2.6:compile
[INFO] +-
[jira] [Created] (DOXIA-586) Upgrade maven version to 3.0
Karl Heinz Marbaise created DOXIA-586: - Summary: Upgrade maven version to 3.0 Key: DOXIA-586 URL: https://issues.apache.org/jira/browse/DOXIA-586 Project: Maven Doxia Issue Type: Dependency upgrade Affects Versions: 1.9 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 1.9 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6225) Maven should warn users to use MAVEN_OPTS instead of passing system properties to mvn
[
https://issues.apache.org/jira/browse/MNG-6225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770226#comment-16770226
]
Michael Osipov commented on MNG-6225:
-
You can clone the Git repo and build yourself. Module {{apache-maven}} contains
the distribution.
> Maven should warn users to use MAVEN_OPTS instead of passing system
> properties to mvn
> -
>
> Key: MNG-6225
> URL: https://issues.apache.org/jira/browse/MNG-6225
> Project: Maven
> Issue Type: Bug
> Components: Command Line, core
>Affects Versions: 3.5.0
>Reporter: Gili
>Priority: Major
>
> I'm not sure which Maven component this bug report belongs to (please
> reassign if needed).
> This is a follow-up to https://issues.apache.org/jira/browse/SUREFIRE-1369
> To recap: someone (probably Maven core) is redirecting the native stdout
> handle when running plugins such as Surefire. This prevents applications from
> outputting ANSI colors under Windows 10 because:
> * Applications must explicitly enable ANSI support using JNI.
> * The JNI calls fail if the stdout handle has been redirected.
> If I run the exact same application outside of Maven, JNI no longer detects
> that stdout has been redirected and ANSI colors as expected.
> Any idea who is doing the redirection, and how to disable it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-871) Descriptor Ref "bin" causes Errors in the build log on Windows
[
https://issues.apache.org/jira/browse/MASSEMBLY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770228#comment-16770228
]
Michael Osipov commented on MASSEMBLY-871:
--
I can reproduce it. How would you solve this issue?
> Descriptor Ref "bin" causes Errors in the build log on Windows
> --
>
> Key: MASSEMBLY-871
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-871
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Stefan Ferstl
>Priority: Minor
>
> When using the builtin assembly descriptor {{bin}}, the build output contains
> ERRORs when run on Windows:
> {code}
> [INFO] --- maven-assembly-plugin:3.1.0:single (create-bin-distro) @
> descriptor-ref-demo ---
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.gz
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [INFO] Building tar:
> C:\path\to\my\project\target\descriptor-ref-demo-1.0.0-SNAPSHOT.tar.bz2
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> However, the build succeeds and produces valid archives (tar.bz2, tar.gz and
> zip).
> The problem should rather be logged as WARN than as ERROR.
> To reproduce this issue, I created a demo project on GitHub:
> https://github.com/ferstl/MASSEMBLY-871 .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MASSEMBLY-450) manifestEntries ignored when manfestFile is specified
[
https://issues.apache.org/jira/browse/MASSEMBLY-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MASSEMBLY-450:
-
Affects Version/s: 3.1.1
> manifestEntries ignored when manfestFile is specified
> -
>
> Key: MASSEMBLY-450
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-450
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: manifest
>Affects Versions: 2.2-beta-4, 3.1.1
>Reporter: Robert Cauble
>Priority: Major
> Attachments: example.zip
>
>
> The maven jar plugin supports the behavior of manifestEntries overriding the
> manifestFile as indicated here:
> http://maven.apache.org/guides/mini/guide-manifest.html
> However, within the maven assembly plugin, if manifestFile is specified,
> manifestEntries is ignored.
> Reproduction
>
> {noformat}
> > unzip example.zip
> > cd example
> > mvn package
> > cd target
> > unzip example-4.2-plugin.jar
> > cat META-INF/MANFEST
> {noformat}
> Results:
> {noformat}
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Created-By: 14.0-b16 (Sun Microsystems Inc.)
> Bundle-ManifestVersion: 2
> Bundle-Name: example
> Bundle-SymbolicName: example; singleton:=true
> Bundle-Version: 1.0
> {noformat}
> Expected:
> {noformat}
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Created-By: 14.0-b16 (Sun Microsystems Inc.)
> Bundle-ManifestVersion: 2
> Bundle-Name: example
> Bundle-SymbolicName: example; singleton:=true
> Bundle-Version: 4.2
> {noformat}
> The problem appears to be in the class ManifestConfigurationFinalizer:
> {code:java}
> if ( manifestFile != null )
> {
>...
>manifest = new Manifest( manifestFileReader );
>...
> }
> else
> {
>manifest = mavenArchiver.getManifest( project,
> archiveConfiguration.getManifest() );
> }
> {code}
> I believe the fix is to change to the following (this already handles merging
> the manifest file with the configured manifestEntries)
> {code:java}
> manifest = mavenArchiver.getManifest( project, archiveConfiguration );
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MASSEMBLY-450) manifestEntries ignored when manfestFile is specified
[
https://issues.apache.org/jira/browse/MASSEMBLY-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MASSEMBLY-450:
-
Affects Version/s: (was: 3.1.1)
> manifestEntries ignored when manfestFile is specified
> -
>
> Key: MASSEMBLY-450
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-450
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: manifest
>Affects Versions: 2.2-beta-4
>Reporter: Robert Cauble
>Priority: Major
> Attachments: example.zip
>
>
> The maven jar plugin supports the behavior of manifestEntries overriding the
> manifestFile as indicated here:
> http://maven.apache.org/guides/mini/guide-manifest.html
> However, within the maven assembly plugin, if manifestFile is specified,
> manifestEntries is ignored.
> Reproduction
>
> {noformat}
> > unzip example.zip
> > cd example
> > mvn package
> > cd target
> > unzip example-4.2-plugin.jar
> > cat META-INF/MANFEST
> {noformat}
> Results:
> {noformat}
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Created-By: 14.0-b16 (Sun Microsystems Inc.)
> Bundle-ManifestVersion: 2
> Bundle-Name: example
> Bundle-SymbolicName: example; singleton:=true
> Bundle-Version: 1.0
> {noformat}
> Expected:
> {noformat}
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Created-By: 14.0-b16 (Sun Microsystems Inc.)
> Bundle-ManifestVersion: 2
> Bundle-Name: example
> Bundle-SymbolicName: example; singleton:=true
> Bundle-Version: 4.2
> {noformat}
> The problem appears to be in the class ManifestConfigurationFinalizer:
> {code:java}
> if ( manifestFile != null )
> {
>...
>manifest = new Manifest( manifestFileReader );
>...
> }
> else
> {
>manifest = mavenArchiver.getManifest( project,
> archiveConfiguration.getManifest() );
> }
> {code}
> I believe the fix is to change to the following (this already handles merging
> the manifest file with the configured manifestEntries)
> {code:java}
> manifest = mavenArchiver.getManifest( project, archiveConfiguration );
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-546) Change groupId from org.apache.maven to org.apache.maven.shared
[
https://issues.apache.org/jira/browse/MSHARED-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770214#comment-16770214
]
Karl Heinz Marbaise commented on MSHARED-546:
-
>From a formal perspective I would say yes we have to wait for 4.0.0...
> Change groupId from org.apache.maven to org.apache.maven.shared
> ---
>
> Key: MSHARED-546
> URL: https://issues.apache.org/jira/browse/MSHARED-546
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-2.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently the maven-archiver is located in the groupId {{org.apache.maven}}
> but it should be in {{org.apache.maven.shared.archiver}} as all other shared
> components.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MNG-5960) MojoExecutor overriding resolved artifacts of concurrently built MavenProject
[
https://issues.apache.org/jira/browse/MNG-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MNG-5960:
-
Assignee: Sylwester Lachiewicz
> MojoExecutor overriding resolved artifacts of concurrently built MavenProject
> -
>
> Key: MNG-5960
> URL: https://issues.apache.org/jira/browse/MNG-5960
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9, needing-scrub-3.4.0-fallout
> Environment: Linux 4.2.0-23-generic #28-Ubuntu SMP Sun Dec 27
> 17:47:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> (Ubuntu 15.10)
> Maven 3.3.9/3.4.0-SNAPSHOT
>Reporter: Fabian van der Veen
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> I have found an issue with respect to the {{MojoExecutor}} in {{maven-core}}
> when building with multiple threads (e.g. {{-T1C}}).
> I have created a small reproduction project here:
> https://github.com/fvanderveen/maven-mojo-jojo (in the readme is some more
> explanation of what I found to be the problem)
> The reproduction, using the above code:
> 1. Clone this repository (`git clone
> https://github.com/fvanderveen/maven-mojo-jojo.git`)
> 2. Make sure the clone works single-threaded: `mvn clean package`. (This
> should succeed)
> 3. Clean the workspace (`mvn clean`)
> 4. Attempt multi-threaded compilation with at least 2 threads (`mvn package
> -T2`)
> Boiled down, it seems like the {{MojoExecutor#ensureDependenciesAreResolved}}
> will cause an invocation to
> {{LifecycleDependencyResolver#resolveProjectDependencies}} for _all_ projects
> in the current {{MavenSession}} if it's configuring a plugin that defines
> {{@Mojo(aggregator = true)}} and
> {{DependencyContext#isResolutionRequiredForAggregatedProjects}} return true.
> This resolving may, if triggered at an unfortunate time, override resolved
> artifacts for projects that are being built concurrently.
> In our case, a {{test-compile}} execution of the {{maven-compiler-plugin}}
> was just configured (setting the resolved artifacts to the test-scope
> artifacts), and right before its execution, the resolved artifacts got set
> back to the compile-scope artifacts due to a aggregator plugin being
> configured at around the same time.
> Given the way the `ensureDependenciesAreResolved` is structured and what
> aggregator plugins should do/depend on, I think it would make more sense to
> _only_ invoke {{LifecycleDependencyResolver#resolveProjectDependencies}} for
> the modules that are a (grand-)child of the current project.
> I've created a maven extension (which can be placed in lib/ext) as a
> temporary workaround using said change; which may be found here if any one
> else is having the same problems:
> https://github.com/fvanderveen/maven-non-destructive-mojo-executor
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEP-639) Not showing omitted dependencies when running dependency:tree verbose
[
https://issues.apache.org/jira/browse/MDEP-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770223#comment-16770223
]
Karl Heinz Marbaise commented on MDEP-639:
--
Can you please make an example project which shows the behaviour.
> Not showing omitted dependencies when running dependency:tree verbose
> -
>
> Key: MDEP-639
> URL: https://issues.apache.org/jira/browse/MDEP-639
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 3.1.1
> Environment: Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux
> 4.15.0-44-generic x86_64
>Reporter: Grzegorz Solecki
>Priority: Major
>
> When you run:
> {code:sh}
> $ mvn dependency:tree -Dverbose
> {code}
> it does not show omitted dependencies.
> It happens for version 3+.
> When I change to 2.10 it is working flawlessly
> Environment details:
> {code:sh}
> $ mvn -version
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T14:41:47-04:00)
> Maven home: /home/grzsol1/dev/tls/mvn/current
> Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
> /home/grzsol1/dev/jdk/jdk1.8.0_191/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-44-generic", arch: "amd64", family: "unix"
> Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux 4.15.0-44-generic x86_64
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
[ https://issues.apache.org/jira/browse/MNG-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770215#comment-16770215 ] Michael Osipov edited comment on MNG-6236 at 2/16/19 8:45 PM: -- Have you tried my recommendation? was (Author: michael-o): Have you tried my recommendaton? > maven-metadata-local.xml polluted with whitespaces > -- > > Key: MNG-6236 > URL: https://issues.apache.org/jira/browse/MNG-6236 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Tomer Cohen >Priority: Major > Fix For: wontfix-candidate > > Attachments: maven-metadata-local.xml, stacktrace.txt > > > After starting to use Maven 3.5.0 multiple instances of the attached > exceptions started occurring when multiple builds are using and installing > modules of the same reactor. I sanitized the module name. > Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6225) Application cannot output ANSI colors when run by Maven
[ https://issues.apache.org/jira/browse/MNG-6225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770213#comment-16770213 ] Gili commented on MNG-6225: --- [~michael-o] How would I test this? I don't see where I can download 3.6.1-SNAPSHOT binaries for Windows. Here is a more concise testcase for you: # Create a Maven project with Surefire plugin configured with 0. # Run "mvn -Djava.library.path=X". # Try reading "java.library.path" from within a unit test. # Notice that the system property is not set. Expected behavior: Running "mvn -D" should trigger a build failure or warning indicating that users should use MAVEN_OPTS to set system properties. > Application cannot output ANSI colors when run by Maven > --- > > Key: MNG-6225 > URL: https://issues.apache.org/jira/browse/MNG-6225 > Project: Maven > Issue Type: Bug > Components: Command Line, core >Affects Versions: 3.5.0 >Reporter: Gili >Priority: Major > > I'm not sure which Maven component this bug report belongs to (please > reassign if needed). > This is a follow-up to https://issues.apache.org/jira/browse/SUREFIRE-1369 > To recap: someone (probably Maven core) is redirecting the native stdout > handle when running plugins such as Surefire. This prevents applications from > outputting ANSI colors under Windows 10 because: > * Applications must explicitly enable ANSI support using JNI. > * The JNI calls fail if the stdout handle has been redirected. > If I run the exact same application outside of Maven, JNI no longer detects > that stdout has been redirected and ANSI colors as expected. > Any idea who is doing the redirection, and how to disable it? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-804) Upgrade shared-component-parent to version 33.
[ https://issues.apache.org/jira/browse/MSHARED-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770222#comment-16770222 ] Hudson commented on MSHARED-804: Build succeeded in Jenkins: Maven TLP » maven-file-management » master #35 See https://builds.apache.org/job/maven-box/job/maven-file-management/job/master/35/ > Upgrade shared-component-parent to version 33. > -- > > Key: MSHARED-804 > URL: https://issues.apache.org/jira/browse/MSHARED-804 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: file-management >Affects Versions: file-management-3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: file-management-3.0.1 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-804) Upgrade shared-component-parent to version 33.
[ https://issues.apache.org/jira/browse/MSHARED-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770221#comment-16770221 ] Karl Heinz Marbaise commented on MSHARED-804: - Done in [4e0d57b22e7df35eb74baed0e35d6aa542ce5dee|https://gitbox.apache.org/repos?p=asf?p=maven-file-management.git;a=commitdiff;h=4e0d57b22e7df35eb74baed0e35d6aa542ce5dee] > Upgrade shared-component-parent to version 33. > -- > > Key: MSHARED-804 > URL: https://issues.apache.org/jira/browse/MSHARED-804 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: file-management >Affects Versions: file-management-3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: file-management-3.0.1 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MSHARED-804) Upgrade shared-component-parent to version 33.
[ https://issues.apache.org/jira/browse/MSHARED-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-804. --- Resolution: Done > Upgrade shared-component-parent to version 33. > -- > > Key: MSHARED-804 > URL: https://issues.apache.org/jira/browse/MSHARED-804 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: file-management >Affects Versions: file-management-3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: file-management-3.0.1 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MJAR-248) option to prevent META-INF/MANIFEST.MF creation
[
https://issues.apache.org/jira/browse/MJAR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MJAR-248.
---
Resolution: Won't Fix
I am closing this as won't fix for two reasons:
1. With the upcoming Maven Archiver version you can reduce the {{MANIFEST.MF}}
to a minimum
2. A valid JAR *must* contain a mainfest file as the first ZIP entry and a
{{Manifest-Version: 1.0}} entry
> option to prevent META-INF/MANIFEST.MF creation
> ---
>
> Key: MJAR-248
> URL: https://issues.apache.org/jira/browse/MJAR-248
> Project: Maven JAR Plugin
> Issue Type: New Feature
>Reporter: jieryn
>Priority: Minor
>
> The META-INF/MANIFEST.MF represents 20-25% of many of my highly-modularized
> project's byte size. It would be very nice to be able to prevent the creation
> of that file in my jars.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6329) SSL Truststore via MAVEN_OPTS fails
[
https://issues.apache.org/jira/browse/MNG-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6329.
---
Resolution: Incomplete
Fix Version/s: (was: waiting-for-feedback)
No reaction. The general approach is, like our company, the entire CA chain is
added `cacerts` to make this smoothly work. RHEL or FreeBSD pending port change
provide such facilities to modify cacerts and/or the OpenSSL PEM CA file.
> SSL Truststore via MAVEN_OPTS fails
> ---
>
> Key: MNG-6329
> URL: https://issues.apache.org/jira/browse/MNG-6329
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.2
> Environment: Apache Maven 3.5.2
> (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T15:58:13+08:00)
> Maven home: /usr/local/Cellar/maven/3.5.2/libexec
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre
> Default locale: en_SG, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.2", arch: "x86_64", family: "mac"
>Reporter: Yogendra Rampuria
>Priority: Major
>
> We use an internal self-signed CA certificate for our repository.
> Certificates for these internal CAs are distributed via a jks file. I set
> MAVEN_OPTS in .mavenrc file (and also tried on command line)
> {code:title=Shell|borderStyle=solid}
> $ export MAVEN_OPTS="-Djavax.net.ssl.trustStore=internalca.jks
> -Djavax.net.ssl.trustStorePassword=changeit"
> $ mvn clean install
> ...snip...
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> ...snip..
> $ unset MAVEN_OPTS
> $ mvn clean -Djavax.net.ssl.trustStore=internalca.jks
> -Djavax.net.ssl.trustStorePassword=changeit install
> ..snip..
> BUILD SUCESS
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MSHARED-804) Upgrade shared-parent to version 33.
Karl Heinz Marbaise created MSHARED-804: --- Summary: Upgrade shared-parent to version 33. Key: MSHARED-804 URL: https://issues.apache.org/jira/browse/MSHARED-804 Project: Maven Shared Components Issue Type: Dependency upgrade Components: file-management Affects Versions: file-management-3.0.1 Reporter: Karl Heinz Marbaise Fix For: file-management-3.0.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MSHARED-804) Upgrade shared-parent to version 33.
[ https://issues.apache.org/jira/browse/MSHARED-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MSHARED-804: --- Assignee: Karl Heinz Marbaise > Upgrade shared-parent to version 33. > > > Key: MSHARED-804 > URL: https://issues.apache.org/jira/browse/MSHARED-804 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: file-management >Affects Versions: file-management-3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: file-management-3.0.1 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHARED-804) Upgrade shared-component-parent to version 33.
[ https://issues.apache.org/jira/browse/MSHARED-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-804: Summary: Upgrade shared-component-parent to version 33. (was: Upgrade shared-parent to version 33.) > Upgrade shared-component-parent to version 33. > -- > > Key: MSHARED-804 > URL: https://issues.apache.org/jira/browse/MSHARED-804 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: file-management >Affects Versions: file-management-3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: file-management-3.0.1 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6425.
---
Resolution: Incomplete
Fix Version/s: (was: waiting-for-feedback)
Haven't received any rest feedback.
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425-wirelog-full.log, MNG-6425-wirelog.log,
> MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
[ https://issues.apache.org/jira/browse/MNG-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6236: Fix Version/s: wontfix-candidate > maven-metadata-local.xml polluted with whitespaces > -- > > Key: MNG-6236 > URL: https://issues.apache.org/jira/browse/MNG-6236 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Tomer Cohen >Priority: Major > Fix For: wontfix-candidate > > Attachments: maven-metadata-local.xml, stacktrace.txt > > > After starting to use Maven 3.5.0 multiple instances of the attached > exceptions started occurring when multiple builds are using and installing > modules of the same reactor. I sanitized the module name. > Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
[ https://issues.apache.org/jira/browse/MNG-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770215#comment-16770215 ] Michael Osipov commented on MNG-6236: - Have you tried my recommendaton? > maven-metadata-local.xml polluted with whitespaces > -- > > Key: MNG-6236 > URL: https://issues.apache.org/jira/browse/MNG-6236 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Tomer Cohen >Priority: Major > Fix For: wontfix-candidate > > Attachments: maven-metadata-local.xml, stacktrace.txt > > > After starting to use Maven 3.5.0 multiple instances of the attached > exceptions started occurring when multiple builds are using and installing > modules of the same reactor. I sanitized the module name. > Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6225) Maven should warn users to use MAVEN_OPTS instead of passing system properties to mvn
[ https://issues.apache.org/jira/browse/MNG-6225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gili updated MNG-6225: -- Summary: Maven should warn users to use MAVEN_OPTS instead of passing system properties to mvn (was: Application cannot output ANSI colors when run by Maven) > Maven should warn users to use MAVEN_OPTS instead of passing system > properties to mvn > - > > Key: MNG-6225 > URL: https://issues.apache.org/jira/browse/MNG-6225 > Project: Maven > Issue Type: Bug > Components: Command Line, core >Affects Versions: 3.5.0 >Reporter: Gili >Priority: Major > > I'm not sure which Maven component this bug report belongs to (please > reassign if needed). > This is a follow-up to https://issues.apache.org/jira/browse/SUREFIRE-1369 > To recap: someone (probably Maven core) is redirecting the native stdout > handle when running plugins such as Surefire. This prevents applications from > outputting ANSI colors under Windows 10 because: > * Applications must explicitly enable ANSI support using JNI. > * The JNI calls fail if the stdout handle has been redirected. > If I run the exact same application outside of Maven, JNI no longer detects > that stdout has been redirected and ANSI colors as expected. > Any idea who is doing the redirection, and how to disable it? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-522) Kerberos support doesn't work
[ https://issues.apache.org/jira/browse/WAGON-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770212#comment-16770212 ] Michael Osipov commented on WAGON-522: -- I have explicitly configured Basic, Digest and NTLM authenticators for Wagon because nothing else is supported by us and the SPNEGO authenticator is broken. > Kerberos support doesn't work > - > > Key: WAGON-522 > URL: https://issues.apache.org/jira/browse/WAGON-522 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.1.0 > Environment: Windows, OSX >Reporter: Bader Boland >Priority: Major > > Maven does not seem to work with a repository protected by Kerberos, unless > using the lightweight wagon provider. Using the lightweight provider is not > an option for us because it doesn't work with Artifactory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6433) Maven does not authenticate
[
https://issues.apache.org/jira/browse/MNG-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6433.
---
Resolution: Incomplete
Fix Version/s: (was: waiting-for-feedback)
No debug logs provided.
> Maven does not authenticate
>
>
> Key: MNG-6433
> URL: https://issues.apache.org/jira/browse/MNG-6433
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.4
> Environment: Windows 10, JFrog artifactory
>Reporter: Martin Formanko
>Priority: Major
>
> I have set the username and password in settings.xml (encrypted and also
> plain-text the same behaviour). In debug logs I also see the following:
>
> {code:java}
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> http://[censored]/artifactory/repo with username=[censored], password=***
> Downloading from repo:
> http://[censored]/artifactory/repo/com/[censored].pom{code}
>
>
> but maven itself does not authenticate, from what I see in network dump:
>
> {code:java}
> GET /artifactory/[censored].pom HTTP/1.1
> Cache-control: no-cache
> Cache-store: no-store
> Pragma: no-cache
> Expires: 0
> Accept-Encoding: gzip
> User-Agent: Apache-Maven/3.5.4 (Java 1.8.0_161; Windows 10 10.0)
> Host: [censored]
> Connection: Keep-Alive
> HTTP/1.1 404 Not Found
> Server: Artifactory/5.11.1
> X-Artifactory-Id: [censored]c:-8000
> Content-Type: application/json;charset=ISO-8859-1
> Content-Length: 74
> Date: Mon, 25 Jun 2018 14:28:17 GMT
> {code}
>
> So... then I am getting
> {code:java}
> [FATAL] Non-resolvable parent POM for [censored]: Could not find
> artifact{code}
> Because Maven is awaiting maybe 407 authentication required or some similar
> status code. Is this correct behaviour? Should our artifactory request the
> username/password? Because what it does, is that it replies with 404 when
> authentication is not done.
> My settings.xml are not important I think, because as you can see in the log,
> there is BasicConnector which is using already the username/password, so the
> settings are correct, but maven simply does not use any credentials at all
> and tries to grab artifact directly which fails with FATAL error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-791) Upgrade plexus-utils to 3.1.1
[ https://issues.apache.org/jira/browse/MSHARED-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770208#comment-16770208 ] Hudson commented on MSHARED-791: Build succeeded in Jenkins: Maven TLP » maven-artifact-transfer » master #62 See https://builds.apache.org/job/maven-box/job/maven-artifact-transfer/job/master/62/ > Upgrade plexus-utils to 3.1.1 > - > > Key: MSHARED-791 > URL: https://issues.apache.org/jira/browse/MSHARED-791 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-artifact-transfer >Affects Versions: maven-artifact-transfer-0.11.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-artifact-transfer-0.11.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6015) Settings.xml server configuration not inyected to wagon extension
[
https://issues.apache.org/jira/browse/MNG-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6015.
---
Resolution: Incomplete
Fix Version/s: (was: waiting-for-feedback)
No reaction on MWE request.
> Settings.xml server configuration not inyected to wagon extension
> -
>
> Key: MNG-6015
> URL: https://issues.apache.org/jira/browse/MNG-6015
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.3
>Reporter: Rubén Suárez Alvarez
>Priority: Major
>
> I'm trying to pass configuration settings from _settings.xml_ to wagon
> extensions for _wagon-maven-plugin_.
> _Configuration_ properties from _server_ tag seems not to be passed anymore
> (I think those where passed on maven 2.x).
> I tried with _wagon-ssh_ and _wagon-ssh-external_ extensions.
> With _wagon-ssh_:
> {code:xml|title=settings.xml|borderStyle=solid}
>
> ssh-server
> sshuser
> sshpassword
>
>
> implementation="org.apache.maven.wagon.providers.ssh.knownhost.NullKnownHostProvider">
> no
>
>
>
> {code}
> {code:xml|title=pom.xml|borderStyle=solid}
>
>
>
> org.apache.maven.wagon
> wagon-ssh
> 2.10
>
>
> ...
>
>
> org.codehaus.mojo
> wagon-maven-plugin
> 1.0
>
>
> upload-javadoc
> install
>
> upload
>
>
> ${basedir}/target
>
> ${project.artifactId}*
>
> pom.xml
> scp://192.168.3.174
> /opt/doc
> ssh-server
>
>
>
>
>
>
> {code}
> *knownHostsProvider* is not passed to _wagon-ssh_. It's always *null*.
> With _wagon-ssh-external_:
> {code:xml|title=settings.xml|borderStyle=solid}
>
> ssh-server
> sshuser
> sshpassword
>
> -o 'StrictHostKeyChecking=no' -o
> 'UserKnownHostsFile=/dev/null'
>
>
> {code}
> {code:xml|title=pom.xml|borderStyle=solid}
>
>
>
> org.apache.maven.wagon
> wagon-ssh-external
> 2.10
>
>
> ...
>
>
> org.codehaus.mojo
> wagon-maven-plugin
> 1.0
>
>
> upload-javadoc
> install
>
> upload
>
>
> ${basedir}/target
>
> ${project.artifactId}*
>
> pom.xml
> scpexe://192.168.3.174
> /opt/doc
> ssh-server
>
>
>
>
>
>
> {code}
> *sshArgs* is not passed to _wagon-ssh-external_. It's always *null*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-5641) AbstractMavenLifecycleParticipant#afterSessionStart is never invoked
[
https://issues.apache.org/jira/browse/MNG-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5641.
---
Resolution: Incomplete
Fix Version/s: (was: waiting-for-feedback)
No reaction on question. Will reopen if information is provided.
> AbstractMavenLifecycleParticipant#afterSessionStart is never invoked
>
>
> Key: MNG-5641
> URL: https://issues.apache.org/jira/browse/MNG-5641
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Reporter: Cservenak, Tamas
>Priority: Major
>
> Seems this affects all released maven versions.
> The problem, is that
> {{org.apache.maven.DefaultMaven#getLifecycleParticipants}} is invoked with
> empty list, as there are no projects read up yet.
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/DefaultMaven.java#L233
> Moreover, there is a comment on class, suggesting to remove this method. So,
> maybe just remove it?
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java#L56
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MCLEAN-86) Unable to delete files because of umlauts
[
https://issues.apache.org/jira/browse/MCLEAN-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MCLEAN-86.
Resolution: Invalid
Reasoning provided, no reaction.
> Unable to delete files because of umlauts
> -
>
> Key: MCLEAN-86
> URL: https://issues.apache.org/jira/browse/MCLEAN-86
> Project: Maven Clean Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: fedora with maven and LOCALE=C
>Reporter: Phillip Wirth
>Priority: Major
>
> I am not able to delete some files with mvn clean
> The LOCALE vairable is set to \{{C}}
> Project properties:
> {code:java}
> UTF-8
> UTF-8
> utf-8
> {code}
>
> I am able to build the project (same locale setting) and deep inside the
> target folder I can see why it fails
> {code:java}
> zarathustra@wotan ..oesung/oms/xxx/xxx/coupons/domain/meta (git)-[master] %
> ll
> total 24
> -rw-rw-r--. 1 zarathustra zarathustra 1139 Apr 12 16:37
> 'MetaAdvertisementOutletCity$D'$'\303\274''sseldorfLiteral.class'
> -rw-rw-r--. 1 zarathustra zarathustra 1115 Apr 12 16:37
> 'MetaAdvertisementOutletCity$K'$'\303\266''lnLiteral.class'
> -rw-rw-r--. 1 zarathustra zarathustra 1127 Apr 12 16:37
> 'MetaAdvertisementOutletCity$M'$'\303\274''nchenLiteral.class'
> -rw-rw-r--. 1 zarathustra zarathustra 1127 Apr 12 16:37
> 'MetaAdvertisementOutletCity$M'$'\303\274''nsterLiteral.class'
> -rw-rw-r--. 1 zarathustra zarathustra 1131 Apr 12 16:37
> 'MetaAdvertisementOutletCity$N'$'\303\274''rnbergLiteral.class'
> -rw-rw-r--. 1 zarathustra zarathustra 1143 Apr 12 16:37
> 'MetaAdvertisementOutletCity$Saarbr'$'\303\274''ckenLiteral.class'
> {code}
>
> Running {{mvn -X clean}} results in the following error:
> {code:java}
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> at sun.reflect.NativeMethodAxxxssorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAxxxssorImpl.invoke(NativeMethodAxxxssorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAxxxssorImpl.invoke(DelegatingMethodAxxxssorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to clean
> project: Failed to delete
> /home/zarathustra/code/oms-xxx-xxx/coupons/coupons-domain/target/classes/com/wunschloesung/oms/xxx/xxx/coupons/domain/meta
> at org.apache.maven.plugins.clean.CleanMojo.execute(CleanMojo.java:212)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>
> ... 20 more
> Caused by: java.io.IOException: Failed to delete
> /home/zarathustra/code/oms-xxx-xxx/coupons/coupons-domain/target/classes/com/wunschloesung/oms/xxx/xxx/coupons/domain/meta
>
> at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:251)
> at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:193)
> at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160)
> at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160)
> at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160)
> at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160)
> at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160)
> at org.apache.maven.plugins.clean.Cleaner.delete(Cleaner.java:160)
> at
[jira] [Closed] (MPMD-267) Running maven-pmd-plugin fails on missing HttpServletResponse
[ https://issues.apache.org/jira/browse/MPMD-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPMD-267. --- Resolution: Incomplete No sample project provided. > Running maven-pmd-plugin fails on missing HttpServletResponse > - > > Key: MPMD-267 > URL: https://issues.apache.org/jira/browse/MPMD-267 > Project: Maven PMD Plugin > Issue Type: Bug >Affects Versions: 3.10.0 > Environment: Java 8, Windows Server 2012 r2 >Reporter: Vincent Jansen >Priority: Major > > During running the verify phase on our project we get the following error in > one of our modules > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.10.0:pmd (pmd) on project > blueriq-component-dashboard: Execution pmd of goal > org.apache.maven.plugins:maven-pmd-plugin:3.10.0:pmd failed: A required class > was missing while executing > org.apache.maven.plugins:maven-pmd-plugin:3.10.0:pmd: > javax/servlet/http/HttpServletResponse > [ERROR] - > [ERROR] realm =plugin>org.apache.maven.plugins:maven-pmd-plugin:3.10.0 > [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy > Could you check why this is? > In maven-PMD-plugin 3.9.0 we did not have this error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MASSEMBLY-889) Maven assembly not able to handle large capacity .tar.gz packaging
[ https://issues.apache.org/jira/browse/MASSEMBLY-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MASSEMBLY-889. Resolution: Incomplete Fix Version/s: (was: waiting-for-feedback) Failed to provide reasonable evidence. > Maven assembly not able to handle large capacity .tar.gz packaging > -- > > Key: MASSEMBLY-889 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-889 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Linux >Reporter: Sriram Kotni >Priority: Major > Labels: maven > Original Estimate: 0h > Remaining Estimate: 0h > > We are using Maven assembly to tar.gz file size of 2.5 gb is not able to > handle. Because of this we are not able support multi language Knowledge Base > support. There is a big impact for our business. > Any suggestions and alternate solutions are appreciated. > > Thanks, > Sriram -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MSHARED-791) Upgrade plexus-utils to 3.1.1
[ https://issues.apache.org/jira/browse/MSHARED-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-791. --- Resolution: Done > Upgrade plexus-utils to 3.1.1 > - > > Key: MSHARED-791 > URL: https://issues.apache.org/jira/browse/MSHARED-791 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-artifact-transfer >Affects Versions: maven-artifact-transfer-0.11.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-artifact-transfer-0.11.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6542) .mvn/maven.config is ignored when running "mvn dependency:tree"
[ https://issues.apache.org/jira/browse/MNG-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6542. --- Resolution: Incomplete No reaction to the request for a MWE. > .mvn/maven.config is ignored when running "mvn dependency:tree" > --- > > Key: MNG-6542 > URL: https://issues.apache.org/jira/browse/MNG-6542 > Project: Maven > Issue Type: Bug >Reporter: wei >Priority: Major > > Our project has dependencies defined in a profile which is activated by a > property, e.g. "-Dfoo". While adding "-Dfoo" to .mvn/maven.config works for > "mvn clean install". However, it is ignored when running "mvn > dependency:tree". We had to do "mvn dependency:tree -Dfoo" to get the right > dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRELEASE-1013) API inconpatibility with SCM Plugin v1.11.1
[
https://issues.apache.org/jira/browse/MRELEASE-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-1013:
-
Fix Version/s: waiting-for-feedback
> API inconpatibility with SCM Plugin v1.11.1
> ---
>
> Key: MRELEASE-1013
> URL: https://issues.apache.org/jira/browse/MRELEASE-1013
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Mark Vedder
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Upon upgrading the {{maven-scm-plugin}} from v1.10.0 to v1.11.1, the
> {{maven-release-plugin}} (v2.5.3) fails with an API incompatibility error.
> Specifically a {{java.lang.NoSuchMethodError:
> org.apache.maven.scm.ScmTagParameters.isSign()}}.
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on
> project redactedName-parent: Execution default-cli of goal
> org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare:
> java.lang.NoSuchMethodError: org.apache.maven.scm.ScmTagParameters.isSign()Z
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-release-plugin:2.5.3
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/C:/.m2/repository/org/apache/maven/plugins/maven-release-plugin/2.5.3/maven-release-plugin-2.5.3.jar
> [ERROR] urls[1] =
> file:/C:/.m2/repository/org/apache/maven/scm/maven-scm-provider-gitexe/1.11.1/maven-scm-provider-gitexe-1.11.1.jar
> [ERROR] urls[2] =
> file:/C:/.m2/repository/commons-io/commons-io/2.6/commons-io-2.6.jar
> [ERROR] urls[3] =
> file:/C:/.m2/repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar
> [ERROR] urls[4] =
> file:/C:/.m2/repository/org/apache/maven/scm/maven-scm-provider-git-commons/1.11.1/maven-scm-provider-git-commons-1.11.1.jar
> [ERROR] urls[5] =
> file:/C:/.m2/repository/org/apache/maven/release/maven-release-manager/2.5.3/maven-release-manager-2.5.3.jar
> [ERROR] urls[6] =
> file:/C:/.m2/repository/org/apache/maven/release/maven-release-api/2.5.3/maven-release-api-2.5.3.jar
> [ERROR] urls[7] =
> file:/C:/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
> [ERROR] urls[8] = file:/C:/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> [ERROR] urls[9] =
> file:/C:/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-6/plexus-interactivity-api-1.0-alpha-6.jar
> [ERROR] urls[10] =
> file:/C:/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> [ERROR] urls[11] =
> file:/C:/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[12] =
> file:/C:/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[13] =
> file:/C:/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> [ERROR] urls[14] =
> file:/C:/.m2/repository/org/apache/maven/shared/maven-invoker/2.2/maven-invoker-2.2.jar
> [ERROR] urls[15] =
> file:/C:/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[16] =
> file:/C:/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
> [ERROR] urls[17] =
> file:/C:/.m2/repository/org/apache/maven/scm/maven-scm-providers-standard/1.9.4/maven-scm-providers-standard-1.9.4.pom
> [ERROR] urls[18] =
> file:/C:/.m2/repository/org/apache/maven/scm/maven-scm-provider-accurev/1.9.4/maven-scm-provider-accurev-1.9.4.jar
> [ERROR] urls[19] =
> file:/C:/.m2/repository/org/apache/maven/scm/maven-scm-provider-bazaar/1.9.4/maven-scm-provider-bazaar-1.9.4.jar
> [ERROR] urls[20] =
> file:/C:/.m2/repository/org/apache/maven/scm/maven-scm-provider-clearcase/1.9.4/maven-scm-provider-clearcase-1.9.4.jar
> [ERROR] urls[21] =
> file:/C:/.m2/repository/org/apache/maven/scm/maven-scm-provider-cvsexe/1.9.4/maven-scm-provider-cvsexe-1.9.4.jar
> [ERROR] urls[22] =
> file:/C:/.m2/repository/org/apache/maven/scm/maven-scm-provider-cvs-commons/1.9.4/maven-scm-provider-cvs-commons-1.9.4.jar
> [ERROR] urls[23] =
> file:/C:/.m2/repository/org/apache/maven/scm/maven-scm-provider-cvsjava/1.9.4/maven-scm-provider-cvsjava-1.9.4.jar
> [ERROR] urls[24] =
> file:/C:/.m2/repository/org/netbeans/lib/cvsclient/20060125/cvsclient-20060125.jar
> [ERROR] urls[25] =
> file:/C:/.m2/repository/ch/ethz/ganymed/ganymed-ssh2/build210/ganymed-ssh2-build210.jar
> [ERROR] urls[26] =
> file:/C:/.m2/repository/org/apache/maven/scm/maven-scm-provider-hg/1.9.4/maven-scm-provider-hg-1.9.4.jar
> [ERROR]
[jira] [Updated] (MSHARED-627) Enhance the ArtifactResolver with a method to resolve versions of an Artifact
[
https://issues.apache.org/jira/browse/MSHARED-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MSHARED-627:
Fix Version/s: (was: maven-artifact-transfer-0.11.0)
maven-artifact-transfer
> Enhance the ArtifactResolver with a method to resolve versions of an Artifact
> -
>
> Key: MSHARED-627
> URL: https://issues.apache.org/jira/browse/MSHARED-627
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.9.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-artifact-transfer
>
>
> The maven-artifact-transfer should be enhanced having a method to resolve
> versions of artifacts like this:
> {code:java}
> public interface ArtifactResolver {
> ..
> List resolveArtifactVersions( ProjectBuildingRequest buildingRequest,
> Artifact mavenArtifact )
> throws ArtifactResolverException;
> ..
> }
> {code}
> I have a [working implementation|https://svn.apache.org/r1784464] but I'm not
> sure if it should return a list of versions as plain String ?
> This will help to use maven-artifact-transfer also in other plugin for
> example in versions-maven-plugin.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MSHARED-704) Option to create SHA256/SHA512
[ https://issues.apache.org/jira/browse/MSHARED-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-704: Fix Version/s: (was: maven-artifact-transfer-0.11.0) maven-artifact-transfer > Option to create SHA256/SHA512 > -- > > Key: MSHARED-704 > URL: https://issues.apache.org/jira/browse/MSHARED-704 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-artifact-transfer >Affects Versions: maven-artifact-transfer-0.10.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-artifact-transfer > > > we should prepare an option/configuration to be able to generate > sha256/sha512 checksums within the deploy project part. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MCOMPILER-371) RFE: support new javac option "-h"
[ https://issues.apache.org/jira/browse/MCOMPILER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MCOMPILER-371: - Fix Version/s: waiting-for-feedback > RFE: support new javac option "-h" > -- > > Key: MCOMPILER-371 > URL: https://issues.apache.org/jira/browse/MCOMPILER-371 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.0 >Reporter: Mark >Priority: Minor > Fix For: waiting-for-feedback > > > The javah command line utility to generate JNI header files was removed and > its functionality moved into javac in the form of a new command line option > "-h" which determines the output directory of the JNI header files. > Please add a configuration option to the plugin's pom.xml configuration > section to allow setting that option without having to resort to the > workaround described here: > [https://stackoverflow.com/questions/53186355/how-can-i-pass-h-argument-to-maven-compiler-plugin-to-create-jni-header-files] > TY! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNGSITE-355) super pom for Maven 3
[ https://issues.apache.org/jira/browse/MNGSITE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770199#comment-16770199 ] Michael Osipov commented on MNGSITE-355: Can you provide a PR for that? > super pom for Maven 3 > - > > Key: MNGSITE-355 > URL: https://issues.apache.org/jira/browse/MNGSITE-355 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > https://maven.apache.org/guides/introduction/introduction-to-the-pom.html > contains the super POM for Maven 2.0.x and 2.1.x but not anything later. This > should be upgraded to whatever we're using in 3.5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-791) Upgrade plexus-utils to 3.1.1
[ https://issues.apache.org/jira/browse/MSHARED-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770198#comment-16770198 ] Karl Heinz Marbaise commented on MSHARED-791: - Done in [295b3cc7d7f67e04251d6a3871df75cfc6bb4bd5|https://gitbox.apache.org/repos/asf?p=maven-artifact-transfer.git;a=commitdiff;h=295b3cc7d7f67e04251d6a3871df75cfc6bb4bd5] > Upgrade plexus-utils to 3.1.1 > - > > Key: MSHARED-791 > URL: https://issues.apache.org/jira/browse/MSHARED-791 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-artifact-transfer >Affects Versions: maven-artifact-transfer-0.11.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-artifact-transfer-0.11.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6495) ModelResolver cannot be null
[
https://issues.apache.org/jira/browse/MNG-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6495:
Fix Version/s: (was: 3.6.x-candidate)
3.6.1
> ModelResolver cannot be null
>
>
> Key: MNG-6495
> URL: https://issues.apache.org/jira/browse/MNG-6495
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.5.4
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.1
>
>
> Got this exception stacktrace while writing some of my own code today:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException:
> request.modelResolver cannot be null (parent POM
> com.google.guava:guava-parent:26.0-jre and POM
> com.google.guava:guava:[unknown-version])
> at org.apache.commons.lang3.Validate.notNull(Validate.java:225)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1046)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:830)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:332)
> at
> com.google.cloud.tools.opensource.dependencies.MetadataExplorer.main(MetadataExplorer.java:50)
> {noformat}
> No big deal except that the JavaDoc at
> [ModelBuildingRequest|http://maven.apache.org/ref/3.5.4/maven-model-builder/apidocs/org/apache/maven/model/building/ModelBuildingRequest.html]
> says "The model resolver to use, may be null."
> Not sure whether to update the docs or the code here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6536) Https api is not fulfilled while running the maven project from maven commands
[ https://issues.apache.org/jira/browse/MNG-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6536. --- Resolution: Invalid Fix Version/s: (was: waiting-for-feedback) I see no Maven bug here. > Https api is not fulfilled while running the maven project from maven commands > -- > > Key: MNG-6536 > URL: https://issues.apache.org/jira/browse/MNG-6536 > Project: Maven > Issue Type: Bug >Reporter: shruti >Priority: Major > > Hi, > Runnig a maven java project with rest assured dependency to test the server > for the https application. > I observe that the project perfectly runs the rest assured code and gives the > reponse when running the project as testNG from the eclipse manually. But on > running the same project from the command prompt as "mvn test -PTest" , where > Test is the same testNG file gives the 403 forbidden error for the same https > application link. > Weird is here that, how the clipse is able to run the project but why not > through maven command. > I feel it is something with the maven server that needs to bypass before I > call the https, some SSL certificate matching needs to be ignored. But I > don't know how we do that. > I am using Maven 3.3.9 and following is the pom.xml that contains all the > dependencies : > > http://maven.apache.org/POM/4.0.0; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > [http://maven.apache.org/xsd/maven-4.0.0.xsd];> > 4.0.0 > Framework.Vendor_API_System > IM_Vendor_API_System_TestSuite > 0.0.1-SNAPSHOT > jar > AutomationTesting > [http://maven.apache.org|http://maven.apache.org/] > > > Test > > > > org.apache.maven.plugins > maven-surefire-plugin > 2.18.1 > > > SuitesXMLPath/Test.xml > > > > > > > > > UTF-8 > > > > com.jayway.restassured > rest-assured > 2.9.0 > test > > > org.testng > testng > 6.11 > test > > > org.apache.poi > poi-ooxml > 3.13 > > > org.apache.poi > poi > 3.13 > > > org.seleniumhq.selenium > selenium-java > 3.6.0 > > > org.seleniumhq.selenium > selenium-server > 3.6.0 > > > com.aventstack > extentreports > 3.1.3 > > > > org.apache.commons > commons-email > 1.2 > > > > > > Thanks > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MWAR-421) Overlay WEB-INF/lib jars have either really old or really futuristic timestamps
[
https://issues.apache.org/jira/browse/MWAR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MWAR-421.
---
Resolution: Incomplete
No MWE or anything else provided.
> Overlay WEB-INF/lib jars have either really old or really futuristic
> timestamps
>
>
> Key: MWAR-421
> URL: https://issues.apache.org/jira/browse/MWAR-421
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 3.2.2
> Environment: mac (high sierra) n Oracle linux 7 (redhat)
>Reporter: Barry McGillin
>Priority: Major
> Labels: jars, overlay, timestamp, web-inf
> Attachments: Screen Shot 2018-12-18 at 18.51.52.png, Screen Shot
> 2018-12-18 at 18.54.07.png, Screen Shot 2018-12-18 at 18.56.17.png
>
>
> We are building a war file which is a superset of one of the overlays. Ie
> we're adding some jars to the WEB-INF/lib with overlays.
> On doing the overlay the dates of the files in the war get changed with no
> reason. Building locally is sort of ok, but the dates on the libs are in the
> future. however, on our build machine, the dates are way in the past like
> may 1940's!!!
>
> Heres the relevant parts of the pom. its pretty simple, with a dependent war
> getting deps added and reshipped as a new war.
>
> war
> example
>
> sdw
> ${project.build.directory}/${productName}.war
>
>
>
> oracle.dbtools.modeler
> dbtools-modeler-common
> 18.4.0-SNAPSHOT
>
>
> *
> *
>
>
>
>
> oracle.dbtools.sdw
> sdw-server
> ${project.version}
>
>
> *
> *
>
>
>
>
> oracle.dbtools.sdw
> sdw-client
> ${project.version}
>
>
> *
> *
>
>
>
>
> oracle.dbtools.ords
> ords
> ${project.version}
> war
>
>
> *
> *
>
>
>
>
>
>
>
> maven-war-plugin
> 3.2.2
>
>
>
> ords-base
> oracle.dbtools.ords
> ords
> false
>
>
>
>
>
> oracle.dbtools.jarcl.Entrypoint
>
>
>
>
>
>
>
> $
> $ ls -al
> total 165624
> drwxr-xr-x 64 bamcgill staff 2048 18 Dec 17:47 .
> drwxr-xr-x 7 bamcgill staff 224 18 Dec 17:47 ..
> -rw-r--r-- 1 bamcgill staff 70604 1 Feb 2077 commons-fileupload-1.3.3.jar
> ...
> -rw-r--r-- 1 bamcgill staff 1889279 1 Feb 2077
> xmlparserv2-sans-jaxp-services-18.3.0.0.jar
> war/work/oracle.dbtools.ords/ords/WEB-INF/lib/
> bamcgill master ... orahub sql-developer-web ords-sdw ls -al
> total 124032
> drwxr-xr-x 61 bamcgill staff 1952 18 Dec 17:47 .
> drwxr-xr-x 7 bamcgill staff 224 18 Dec 17:47 ..
> -rw-r--r-- 1 bamcgill staff 70604 1 Feb 2077 commons-fileupload-1.3.3.jar
> ...
> -rw-r--r-- 1 bamcgill staff 88535 1 Feb 2077 sdodep3prt-19.1.0.0.0-180607.jar
> -rw-r--r-- 1 bamcgill staff 391988 1 Feb 2077 sdoutl-18.1.0.0.0-170918.jar
> -rw-r--r-- 1 bamcgill staff 1398331 1 Feb 2077 ucp-18.3.0.0.jar
> -rw-r--r-- 1 bamcgill staff 262415 1 Feb 2077 xdb6-18.3.0.0.jar
> This seems to be something in the overlay code which is setting these
> aggressively rather than just taking what was in the overlay war.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MSHARED-793) Support for default value
[
https://issues.apache.org/jira/browse/MSHARED-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-793:
---
Fix Version/s: waiting-for-feedback
> Support for default value
> -
>
> Key: MSHARED-793
> URL: https://issues.apache.org/jira/browse/MSHARED-793
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-filtering
>Affects Versions: maven-filtering-3.1.2
>Reporter: Jean-Charles Manoury
>Priority: Major
> Labels: pull-request-available
> Fix For: waiting-for-feedback
>
>
> The goal is to manage default value like ${toto:tutu} where tutu is used when
> no value for toto is found.
> It is the same behavior as Spring's
> [PropertyPlaceholderConfigurer|https://www.mkyong.com/spring/spring-propertyplaceholderconfigurer-example/]
> This will make properties files from a Spring project compatible with
> maven-filtering.
> A pull request had been created on Github :
> https://github.com/apache/maven-filtering/pull/1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-793) Support for default value
[
https://issues.apache.org/jira/browse/MSHARED-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770193#comment-16770193
]
Michael Osipov commented on MSHARED-793:
Can we close this since I have provided a reasonable solution for that issue?!
> Support for default value
> -
>
> Key: MSHARED-793
> URL: https://issues.apache.org/jira/browse/MSHARED-793
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-filtering
>Affects Versions: maven-filtering-3.1.2
>Reporter: Jean-Charles Manoury
>Priority: Major
> Labels: pull-request-available
> Fix For: waiting-for-feedback
>
>
> The goal is to manage default value like ${toto:tutu} where tutu is used when
> no value for toto is found.
> It is the same behavior as Spring's
> [PropertyPlaceholderConfigurer|https://www.mkyong.com/spring/spring-propertyplaceholderconfigurer-example/]
> This will make properties files from a Spring project compatible with
> maven-filtering.
> A pull request had been created on Github :
> https://github.com/apache/maven-filtering/pull/1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5869.
---
Resolution: Auto Closed
Fix Version/s: (was: waiting-for-feedback)
> Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
>
>
> Key: MNG-5869
> URL: https://issues.apache.org/jira/browse/MNG-5869
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.5, 3.3.3
>Reporter: Arnaud HERITIER
>Priority: Major
> Attachments: settings.xml, threaddumps.log
>
>
> We recently discovered a strange bug of frozen dependencies downloads
> I didn't yet studied a lot the issue but I guess it may be something in
> recent versions of Wagon.
> I created few jobs to demonstrate the Maven issue and I would like to have
> some guidance to deeply analyse it.
> The project used is https://github.com/kenzanmedia/bowtie/ which has a really
> simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
> All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
> We are using some custom global and user maven settings but only to setup
> some mirrors, some credentials and to (re)define some repositories
> Here are my results jobs on https://aheritier.ci.cloudbees.com
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
> * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
> * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
> * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
> * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
> * (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
> * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
> Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
> 3.3.3 it works only if we use the https access to maven central
> For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
> after the timeout I defined (5 minutes - I did also a test with 1h)
> All builds are frozen at the same point in the download process to grab
> surefire artefacts
> DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
> {code}
> 06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
> ---
> 06:28:06 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
> 06:28:06 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
> (3 KB at 3.2 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
> (3 KB at 42.7 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
> (6 KB at 52.9 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
> (2 KB at 2.2 KB/sec)
> 06:28:07 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
> 06:28:07 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
> (16 KB at 154.9 KB/sec)
> 06:28:08 [INFO] Downloading:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
> 06:28:08 [INFO] Downloaded:
> http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
> (2 KB at 62.8 KB/sec)
> 06:28:08 [INFO] Downloading:
>
[jira] [Assigned] (MNG-6495) ModelResolver cannot be null
[
https://issues.apache.org/jira/browse/MNG-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6495:
---
Assignee: Michael Osipov
> ModelResolver cannot be null
>
>
> Key: MNG-6495
> URL: https://issues.apache.org/jira/browse/MNG-6495
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.5.4
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.x-candidate
>
>
> Got this exception stacktrace while writing some of my own code today:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException:
> request.modelResolver cannot be null (parent POM
> com.google.guava:guava-parent:26.0-jre and POM
> com.google.guava:guava:[unknown-version])
> at org.apache.commons.lang3.Validate.notNull(Validate.java:225)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1046)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:830)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:332)
> at
> com.google.cloud.tools.opensource.dependencies.MetadataExplorer.main(MetadataExplorer.java:50)
> {noformat}
> No big deal except that the JavaDoc at
> [ModelBuildingRequest|http://maven.apache.org/ref/3.5.4/maven-model-builder/apidocs/org/apache/maven/model/building/ModelBuildingRequest.html]
> says "The model resolver to use, may be null."
> Not sure whether to update the docs or the code here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6495) ModelResolver cannot be null
[
https://issues.apache.org/jira/browse/MNG-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770192#comment-16770192
]
Michael Osipov commented on MNG-6495:
-
I will simply update the Javadoc content.
> ModelResolver cannot be null
>
>
> Key: MNG-6495
> URL: https://issues.apache.org/jira/browse/MNG-6495
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.5.4
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.1
>
>
> Got this exception stacktrace while writing some of my own code today:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException:
> request.modelResolver cannot be null (parent POM
> com.google.guava:guava-parent:26.0-jre and POM
> com.google.guava:guava:[unknown-version])
> at org.apache.commons.lang3.Validate.notNull(Validate.java:225)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1046)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:830)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:332)
> at
> com.google.cloud.tools.opensource.dependencies.MetadataExplorer.main(MetadataExplorer.java:50)
> {noformat}
> No big deal except that the JavaDoc at
> [ModelBuildingRequest|http://maven.apache.org/ref/3.5.4/maven-model-builder/apidocs/org/apache/maven/model/building/ModelBuildingRequest.html]
> says "The model resolver to use, may be null."
> Not sure whether to update the docs or the code here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6268) When a reactor build fails Maven should include -f (if used) in command line suggestion
[
https://issues.apache.org/jira/browse/MNG-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6268:
Issue Type: Improvement (was: Bug)
> When a reactor build fails Maven should include -f (if used) in command line
> suggestion
> ---
>
> Key: MNG-6268
> URL: https://issues.apache.org/jira/browse/MNG-6268
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Andreas Sewe
>Priority: Trivial
> Fix For: 3.6.x-candidate
>
>
> When a reactor build fails, Maven prints out a helpful suggestion on how to
> resume.
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :example
> {noformat}
> Unfortunately, when running {{mvn}} with {{-f}}, this suggestion is wrong;
> Maven will either pick the wrong {{pom.xml}} or simply won’t find any; in
> either case, the {{pom.xml}} specified with {{-f}} is *crucial* information
> that was left out of the suggestion.
> FYI, this is related to MNG-6028, but covers a different bit of info that
> IMHO should be part of the suggestion. Hence this separate issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6268) When a reactor build fails Maven should include -f (if used) in command line suggestion
[
https://issues.apache.org/jira/browse/MNG-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770191#comment-16770191
]
Michael Osipov commented on MNG-6268:
-
Do you think you can come up with a PR for that?
> When a reactor build fails Maven should include -f (if used) in command line
> suggestion
> ---
>
> Key: MNG-6268
> URL: https://issues.apache.org/jira/browse/MNG-6268
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Andreas Sewe
>Priority: Trivial
> Fix For: 3.6.x-candidate
>
>
> When a reactor build fails, Maven prints out a helpful suggestion on how to
> resume.
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :example
> {noformat}
> Unfortunately, when running {{mvn}} with {{-f}}, this suggestion is wrong;
> Maven will either pick the wrong {{pom.xml}} or simply won’t find any; in
> either case, the {{pom.xml}} specified with {{-f}} is *crucial* information
> that was left out of the suggestion.
> FYI, this is related to MNG-6028, but covers a different bit of info that
> IMHO should be part of the suggestion. Hence this separate issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6225) Application cannot output ANSI colors when run by Maven
[ https://issues.apache.org/jira/browse/MNG-6225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6225: Fix Version/s: (was: 3.x / Backlog) > Application cannot output ANSI colors when run by Maven > --- > > Key: MNG-6225 > URL: https://issues.apache.org/jira/browse/MNG-6225 > Project: Maven > Issue Type: Bug > Components: Command Line, core >Affects Versions: 3.5.0 >Reporter: Gili >Priority: Major > > I'm not sure which Maven component this bug report belongs to (please > reassign if needed). > This is a follow-up to https://issues.apache.org/jira/browse/SUREFIRE-1369 > To recap: someone (probably Maven core) is redirecting the native stdout > handle when running plugins such as Surefire. This prevents applications from > outputting ANSI colors under Windows 10 because: > * Applications must explicitly enable ANSI support using JNI. > * The JNI calls fail if the stdout handle has been redirected. > If I run the exact same application outside of Maven, JNI no longer detects > that stdout has been redirected and ANSI colors as expected. > Any idea who is doing the redirection, and how to disable it? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6225) Application cannot output ANSI colors when run by Maven
[ https://issues.apache.org/jira/browse/MNG-6225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770189#comment-16770189 ] Michael Osipov commented on MNG-6225: - I guess this still applies for 3.6.1-SNAPSHOT? > Application cannot output ANSI colors when run by Maven > --- > > Key: MNG-6225 > URL: https://issues.apache.org/jira/browse/MNG-6225 > Project: Maven > Issue Type: Bug > Components: Command Line, core >Affects Versions: 3.5.0 >Reporter: Gili >Priority: Major > > I'm not sure which Maven component this bug report belongs to (please > reassign if needed). > This is a follow-up to https://issues.apache.org/jira/browse/SUREFIRE-1369 > To recap: someone (probably Maven core) is redirecting the native stdout > handle when running plugins such as Surefire. This prevents applications from > outputting ANSI colors under Windows 10 because: > * Applications must explicitly enable ANSI support using JNI. > * The JNI calls fail if the stdout handle has been redirected. > If I run the exact same application outside of Maven, JNI no longer detects > that stdout has been redirected and ANSI colors as expected. > Any idea who is doing the redirection, and how to disable it? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MJAVADOC-483) Needs support for https.proxySet etc.
[
https://issues.apache.org/jira/browse/MJAVADOC-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MJAVADOC-483.
---
Resolution: Duplicate
[~ljnelson], this is being merged in to the other ticket. Please follow the
discussion there and leave your comments.
> Needs support for https.proxySet etc.
> -
>
> Key: MJAVADOC-483
> URL: https://issues.apache.org/jira/browse/MJAVADOC-483
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Laird Nelson
>Priority: Major
>
> I work at a ginormous company that has a proxy server. I have an active
> {{}} in my {{.m2/settings.xml}} for the {{http}} protocol. The
> {{maven-javadoc-plugin}} picks this up fine.
> Weirdly, the {{javadoc}} invocation _also_ requires the {{https}} proxy to be
> set. There is no way to accomplish this with the {{maven-javadoc-plugin}}.
> IMHO it should see if there is an active {{}} element whose protocol
> is {{https}} as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SCM-916) Relative paths are not correctly inferred while creating the command line
[ https://issues.apache.org/jira/browse/SCM-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SCM-916: --- Fix Version/s: waiting-for-feedback > Relative paths are not correctly inferred while creating the command line > - > > Key: SCM-916 > URL: https://issues.apache.org/jira/browse/SCM-916 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.9.4 >Reporter: Carlo Marchiori >Priority: Major > Fix For: waiting-for-feedback > > > Suppose you have the following situation > my-proj/pom.xml > my-proj-child1/pom.xml > my-proj-child2/pom.xml > with child my-proj-child1, my-proj-child2 maven modules of root project > my-proj. > > Farther suppose using the maven-release-plugin to build a multi-project > release starting from my-proj project. The release plugin modifies poms and > then tries to check them in. The working directory becomes my-proj and the > file collection is > [my-proj/pom.xml, my-proj-child1/pom.xml, my-proj-child2/pom.xml] > > But while building the command line and removing the working directory from > file paths, the class GitCommandLineUtils in the method addTarget transforms > the file list in > [pom.xml, -child1/pom.xml, -child2/pom.xml] > which is wrong. The code should check if the prefix is a filesystem parent > directory, not just a string prefix. > > The problem gives rise to the following error > Caused by: org.apache.maven.shared.release.scm.ReleaseScmCommandException: > Unable to commit files > Provider message: > The git-add command failed. > Command output: > fatal: pathspec '-child1\pom.xml' did not match any files > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-916) Relative paths are not correctly inferred while creating the command line
[ https://issues.apache.org/jira/browse/SCM-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770187#comment-16770187 ] Michael Osipov commented on SCM-916: Please provide a sample project. > Relative paths are not correctly inferred while creating the command line > - > > Key: SCM-916 > URL: https://issues.apache.org/jira/browse/SCM-916 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-gitexe >Affects Versions: 1.9.4 >Reporter: Carlo Marchiori >Priority: Major > Fix For: waiting-for-feedback > > > Suppose you have the following situation > my-proj/pom.xml > my-proj-child1/pom.xml > my-proj-child2/pom.xml > with child my-proj-child1, my-proj-child2 maven modules of root project > my-proj. > > Farther suppose using the maven-release-plugin to build a multi-project > release starting from my-proj project. The release plugin modifies poms and > then tries to check them in. The working directory becomes my-proj and the > file collection is > [my-proj/pom.xml, my-proj-child1/pom.xml, my-proj-child2/pom.xml] > > But while building the command line and removing the working directory from > file paths, the class GitCommandLineUtils in the method addTarget transforms > the file list in > [pom.xml, -child1/pom.xml, -child2/pom.xml] > which is wrong. The code should check if the prefix is a filesystem parent > directory, not just a string prefix. > > The problem gives rise to the following error > Caused by: org.apache.maven.shared.release.scm.ReleaseScmCommandException: > Unable to commit files > Provider message: > The git-add command failed. > Command output: > fatal: pathspec '-child1\pom.xml' did not match any files > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6501) Maven always picks the JRE path as java.home
[
https://issues.apache.org/jira/browse/MNG-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6501.
---
Resolution: Not A Problem
Fix Version/s: (was: waiting-for-feedback)
The behavior has been clarified, there is no isseu with Maven.
> Maven always picks the JRE path as java.home
>
>
> Key: MNG-6501
> URL: https://issues.apache.org/jira/browse/MNG-6501
> Project: Maven
> Issue Type: Bug
> Components: Command Line, core
>Affects Versions: 3.2.3
>Reporter: Joseph
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Attachments: maven_jdk.png
>
>
> we set the proper JDK directory as JAVA_HOME in the environment variable. but
> the maven is forcefully picking up JRE_HOME.
> Even though the JAVA_HOME is pointing to the proper JDK path.
>
> $ echo $JAVA_HOME
> */apps/dftjenkins/local/java/jdk1.8.0_102*
> $ ls -lrt ${JAVA_HOME}/bin/javac
> -rwxr-xr-x. 1 dftjenkins cisco 7941 Jun 22 2016
> */apps/dftjenkins/local/java/jdk1.8.0_102/bin/javac*
> $ echo $M2_HOME
> /apps/dftjenkins/local/apache-maven/apache-maven-3.2.3
>
> Maven is picking the JRE path as java.home
>
> $ mvn -v
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m;
> support was removed in 8.0
> Picked up _JAVA_OPTIONS: -Djava.io.tmpdir=/apps/dftjenkins/jenkins_node/tmp
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-11T13:58:10-07:00)
> Maven home: /apps/dftjenkins/local/apache-maven/current
> Java version: 1.8.0_102, vendor: Oracle Corporation
> *Java home: /apps/dftjenkins/local/java/jdk1.8.0_102/jre*
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.11.6.el7.x86_64", arch: "amd64",
> family: "unix"
> This issue impact the ant call from maven execution . because java.home is
> pointing to JRE_HOME and the ant compilation fails with
>
> [ERROR] Perhaps JAVA_HOME does not point to the JDK.
> [ERROR] It is currently set to "/apps/dftjenkins/local/java/jdk1.8.0_102/jre"
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-572) Custom Tags don't seem to work with Java 9 or above
[
https://issues.apache.org/jira/browse/MJAVADOC-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-572:
Fix Version/s: waiting-for-feedback
> Custom Tags don't seem to work with Java 9 or above
> ---
>
> Key: MJAVADOC-572
> URL: https://issues.apache.org/jira/browse/MJAVADOC-572
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.1
> Environment: Windows
>Reporter: Werner Keil
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> According to the reference, custom tags like @apiNote etc. should work to
> configure in the POM:
> {code:xml}
>
> apiNote
> a
> API Note:
>
> {code}
> However, when the "site" goal is executed, the build fails with JavaDoc
> errors like
> {noformat}
> [INFO] Generating "Javadoc" report --- maven-javadoc-plugin:3.0.1:javadoc
> [INFO]
> 1 error
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 31.099 s
> [INFO] Finished at: 2019-01-28T19:27:02+01:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site) on
> project unit-api: Error generating maven-javadoc-plugin:3.0.1:javadoc report:
> [ERROR] Exit code: 1 -
> git_home\unit-api\src\main\java\javax\measure\quantity\Temperature.java:41:
> error: unknown tag: apiNote
> [ERROR] * @apiNote SI Base Unit
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was: "C:\Program Files\Java\jdk-9.0.4\bin\javadoc.exe"
> @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'git_home\unit-api\target\site\apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> [http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException]
> {noformat}
> Are there any other settings in the POM to make this work, or does it require
> custom Doclets now, too?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6477) Check dependency is already downloaded and up-to-date locally, instead of downloading each time on mvn update
[ https://issues.apache.org/jira/browse/MNG-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6477. --- Resolution: Incomplete Fix Version/s: (was: waiting-for-feedback) Nothing provided. > Check dependency is already downloaded and up-to-date locally, instead of > downloading each time on mvn update > - > > Key: MNG-6477 > URL: https://issues.apache.org/jira/browse/MNG-6477 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.5.0 >Reporter: chamarthi venkata hrudayanath >Priority: Critical > > Check whether the dependency is already downloaded in local system and is > up-to-date with latest one before downloading a new one from mvn repository > each time when doing a maven update. Thereby it improves the performance and > saves lot of data for all using maven project. > Approaches that can be used: > 1) when requested for a maven update, get the individual hash of dependencies > already downloaded locally and sent them to mvn repo server. then mvn server > should figure out the updated dependencies and new ones based on hashes. then > it must download only those which are updated and new ones. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNG-6587) Display full OS version for 'mvn -version'
[
https://issues.apache.org/jira/browse/MNG-6587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16763914#comment-16763914
]
Michael Osipov edited comment on MNG-6587 at 2/16/19 7:56 PM:
--
The output is {{uname -a}} is not portable and differs from operating system to
operating system. I am refusing to parse this piece of information given that
the native Java source code is already doing something like
[this|https://github.com/michael-o/msktutil/commit/108c866c18ce2fb27fb505f698486b4be5423bbb].
was (Author: michael-o):
The output is {{uname -a}} is not portable and differs from operating system to
operating system. I am refusing to parse this piece of information given that
the native Java source code is already doing
[this|https://github.com/michael-o/msktutil/commit/108c866c18ce2fb27fb505f698486b4be5423bbb].
> Display full OS version for 'mvn -version'
> --
>
> Key: MNG-6587
> URL: https://issues.apache.org/jira/browse/MNG-6587
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Reporter: Gary Gregory
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> Display full OS version for 'mvn -version'
> For example, on Windows 10, display {{10.0.16299.904}} instead of {{10.0}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MRESOLVER-55) Artifact download failures
[ https://issues.apache.org/jira/browse/MRESOLVER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MRESOLVER-55. --- Resolution: Incomplete Fix Version/s: (was: waiting-for-feedback) > Artifact download failures > -- > > Key: MRESOLVER-55 > URL: https://issues.apache.org/jira/browse/MRESOLVER-55 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 > Environment: Windows, Ubuntu >Reporter: Lasse Westh-Nielsen >Priority: Major > > Hey, > We often run Maven builds of [https://github.com/neo4j/neo4j] on machines > with cold caches/ empty ~/.m2/repository folders. > There are rather a lot of dependencies to download, so even though the > failure rate of individual artifact downloads is small, at our scale it > causes significant build failures. > I am working on seeding caches. Separately though it would be great to be > able to configure retries and timeouts for dependency downloads - optimise > for build throughput rather than latency as it were. > How do I do that? I can't find it documented anywhere, and trying to browse > "wagon" source code got me nowhere. > Regards, > Lasse > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-920) Maven SCM plugin issue with flat multi module relative paths
[
https://issues.apache.org/jira/browse/SCM-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770183#comment-16770183
]
Michael Osipov commented on SCM-920:
Please provide a sample project.
> Maven SCM plugin issue with flat multi module relative paths
>
>
> Key: SCM-920
> URL: https://issues.apache.org/jira/browse/SCM-920
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.11.1
>Reporter: Javier Peña
>Priority: Major
>
> Hi,
> I am trying to apply the [Tycho Release
> Workflow|https://wiki.eclipse.org/Tycho/Release_Workflow] and everything goes
> well as long as i use a tree structure for the project. As soon as I try to
> use a flat multi module structure the release fails because of the Maven SCM
> plugin can not find the files.
> Original configuration of the maven-scm-plugin as defined in the workflow is:
> {code:java}
>
>
> **/META-INF/MANIFEST.MF,
> **/feature.xml,
> */.product,
> **/category.xml
>
> */target/*
> Changing the Eclipse files versions
>
> {code}
>
> The structure is as follows:
> build -> pom.xml (parent pom)
> module1 -> pom.xml
> module2 -> pom.xml
>
> First attempt to fix the issue was to use relative paths to the include
> section so I try the follwoing:
>
> {code:java}
>
>
> ../module1/META-INF/MANIFEST.MF,
> ../module2/feature.xml,
> ../module4/*.product,
> ../module3/category.xml
>
> */target/*
> Changing the Eclipse files versions
>
> {code}
> maven-scm-plugin still could not find the files.
>
> Second attempt was to change the basedir instead:
>
> {code:java}
>
> ${basedir}/..
>
> **/META-INF/MANIFEST.MF,
> **/feature.xml,
> */.product,
> **/category.xml
>
> */target/*
> Changing the Eclipse files versions
>
> {code}
>
> This got me an step further because the files where found by the plugin the
> problem was that maven-scm-plugin was adding the build folder incorrectly in
> front of the path of the files being added. This was the output:
> {code:java}
> Executing: /bin/sh c cd '/srv/tools/jenkins/jobs/SSP(dev)/workspace/build/..'
> && 'git' 'add' '-' 'build/module3/category.xml' 'build/module2/feature.xml'
> 'build/module1/META-INF/MANIFEST.MF' 'build/module4/xyz.product'
> {code}
>
> After this I tried to also configured the workingDirectory but it only made
> it worst.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SCM-920) Maven SCM plugin issue with flat multi module relative paths
[
https://issues.apache.org/jira/browse/SCM-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Javier Peña updated SCM-920:
Description:
Hi,
I am trying to apply the [Tycho Release
Workflow|https://wiki.eclipse.org/Tycho/Release_Workflow] and everything goes
well as long as i use a tree structure for the project. As soon as I try to use
a flat multi module structure the release fails because of the Maven SCM plugin
can not find the files.
Original configuration of the maven-scm-plugin as defined in the workflow is:
{code:java}
**/META-INF/MANIFEST.MF,
**/feature.xml,
*/.product,
**/category.xml
*/target/*
Changing the Eclipse files versions
{code}
The structure is as follows:
build -> pom.xml (parent pom)
module1 -> pom.xml
module2 -> pom.xml
First attempt to fix the issue was to use relative paths to the include section
so I try the follwoing:
{code:java}
../module1/META-INF/MANIFEST.MF,
../module2/feature.xml,
../module4/*.product,
../module3/category.xml
*/target/*
Changing the Eclipse files versions
{code}
maven-scm-plugin still could not find the files.
Second attempt was to change the basedir instead:
{code:java}
${basedir}/..
**/META-INF/MANIFEST.MF,
**/feature.xml,
*/.product,
**/category.xml
*/target/*
Changing the Eclipse files versions
{code}
This got me an step further because the files where found by the plugin the
problem was that maven-scm-plugin was adding the build folder incorrectly in
front of the path of the files being added. This was the output:
{code:java}
Executing: /bin/sh c cd '/srv/tools/jenkins/jobs/SSP(dev)/workspace/build/..'
&& 'git' 'add' '-' 'build/module3/category.xml' 'build/module2/feature.xml'
'build/module1/META-INF/MANIFEST.MF' 'build/module4/xyz.product'
{code}
After this I tried to also configured the workingDirectory but it only made it
worst.
was:
Hi,
I am trying to apply the [Tycho Release
Workflow|https://wiki.eclipse.org/Tycho/Release_Workflow] and everything goes
well as long as i use a tree structure for the project. As soon as I try to use
a flat multi module structure the release fails because of the Maven SCM plugin
can not find the files.
Original configuration of the maven-scm-plugin as defined in the workflow is:
{code:java}
**/META-INF/MANIFEST.MF,
**/feature.xml,
*/.product,
**/category.xml
*/target/*
Changing the Eclipse files versions
{code}
The structure is as follows:
build -> pom.xml (parent pom)
module1 -> pom.xml
module2 -> pom.xml
First attempt to fix the issue was to use relative paths to the include section
so I try the follwoing:
{code:java}
../module1/META-INF/MANIFEST.MF,
../module2/feature.xml,
../module4/*.product,
../module3/category.xml
*/target/*
Changing the Eclipse files versions
{code}
maven-scm-plugin still could not find the files.
Second attempt was to change the basedir instead:
{code:java}
**/META-INF/MANIFEST.MF,
**/feature.xml,
*/.product,
**/category.xml
*/target/*
Changing the Eclipse files versions
{code}
This got me an step further because the files where found by the plugin the
problem was that maven-scm-plugin was adding the build folder incorrectly in
front of the path of the files being added. This was the output:
{code:java}
Executing: /bin/sh c cd '/srv/tools/jenkins/jobs/SSP(dev)/workspace/build/..'
&& 'git' 'add' '-' 'build/module3/category.xml' 'build/module2/feature.xml'
'build/module1/META-INF/MANIFEST.MF' 'build/module4/xyz.product'
{code}
After this I tried to also configured the workingDirectory but it only made it
worst.
> Maven SCM plugin issue with flat multi module relative paths
>
>
> Key: SCM-920
> URL: https://issues.apache.org/jira/browse/SCM-920
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.11.1
>Reporter: Javier Peña
>Priority: Major
>
> Hi,
> I am trying to apply the [Tycho Release
> Workflow|https://wiki.eclipse.org/Tycho/Release_Workflow] and everything goes
> well as long as i use a tree structure for the project. As soon as I try to
> use a flat multi module structure the release fails because of the Maven SCM
> plugin can not find the files.
> Original configuration of the maven-scm-plugin as defined in the workflow is:
> {code:java}
>
>
> **/META-INF/MANIFEST.MF,
>
[GitHub] rfscholte commented on issue #8: [MPIR-380] contributor email rendering is fixed
rfscholte commented on issue #8: [MPIR-380] contributor email rendering is fixed URL: https://github.com/apache/maven-project-info-reports-plugin/pull/8#issuecomment-464356032 https://builds.apache.org/job/maven-box/job/maven-project-info-reports-plugin/job/MPIR-380/ isn't happy. Seems to be a [code convention issue](https://maven.apache.org/developers/conventions/code.html). 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] (MJAVADOC-565) web proxy not configured for https
[
https://issues.apache.org/jira/browse/MJAVADOC-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770117#comment-16770117
]
Michael Osipov commented on MJAVADOC-565:
-
Bill, I have checked PR now and I am still not happy, but this isn't related to
your PR in particular. These days people assume that an HTTP proxy will also
handle HTTPS via {{CONNECT}}. I highly doubt that folks will configure a proxy
explicitly for {{https}}, in the case they do, our code is broken becaue
{{Settings#getActiveProxy()}} will not take that into consideration. I know
there is no perfect solution, but I would like to take this approach:
* Iterate over all proxies and collect active (first) ones for HTTP and HTTPS
* If HTTPS is availabe, use it for HTTPS as well as for non proxy hosts, but if
and only if proxy for HTTP is not available
* Else use HTTP proxy for both HTTP and HTTPS
Does this make sense? The only other protocol {{URLConnection}} supports is
FTP, but I think no one will use that protocol for Javadoc.
> web proxy not configured for https
> --
>
> Key: MJAVADOC-565
> URL: https://issues.apache.org/jira/browse/MJAVADOC-565
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Bill Shannon
>Assignee: Michael Osipov
>Priority: Major
>
> There seems to be some disagreement about how to configure web proxy servers.
> Maven seems to think that the "protocol" element specifies the protocol to
> use when talking to the web proxy server, and thus allows only one proxy to
> be configured in settings.xml. (Or rather, only the first configured proxy
> is used.) That's not the way proxy servers work.
> The JDK configures web proxy servers based on the protocol that's being
> proxied.
> For example, when using a to access the JDK javadocs, https is needed.
> The maven-javadoc-plugin invokes the external javadoc command with these
> arguments:
> {{-J-Dhttp.proxySet=true -J-Dhttp.proxyHost=
> -J-Dhttp.proxyPort=}}
> That only configures the proxy for the http protocol, not the https protocol,
> and thus the linked resource can not be accessed. To configure the proxy to
> be used for the https protocol, the following arguments are needed:
> {{-J-Dhttps.proxySet=true -J-Dhttps.proxyHost=
> -J-Dhttps.proxyPort=}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MCHECKSTYLE-368) Missing test-jar on mvn compile
Adam Hornáček created MCHECKSTYLE-368:
-
Summary: Missing test-jar on mvn compile
Key: MCHECKSTYLE-368
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-368
Project: Maven Checkstyle Plugin
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Adam Hornáček
Hello,
we have a multi-module Maven project. One of the subprojects depends on
test-jar. Everything seems to work fine until I enable Maven Checkstyle Plugin
in this subproject. Then `mvn compile` target fails; however, `mvn package`
works fine.
The error message:
{code}
[ERROR] Failed to execute goal on project opengrok-web: Could not resolve
dependencies for project org.opengrok:opengrok-web:war:1.2.1: Failure to find
org.opengrok:opengrok:jar:tests:1.2.1 in http://repo.maven.apache.org/maven2/
was cached in the local repository, resolution will not be reattempted until
the update interval of maven.org has elapsed or updates are forced -> [Help 1]
{code}
PR containing changes that cause this issue:
https://github.com/oracle/opengrok/pull/2259
Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-889) Jazz tag command creates snapshot in wrong workspace
[ https://issues.apache.org/jira/browse/SCM-889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770100#comment-16770100 ] Michael Osipov commented on SCM-889: [~ChrisGWarp], I'd like to close this ticket and kindly ask you to create a new one for the regression. > Jazz tag command creates snapshot in wrong workspace > > > Key: SCM-889 > URL: https://issues.apache.org/jira/browse/SCM-889 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jazz >Affects Versions: 1.9.5, 1.10.0 >Reporter: Sérgio Ozaki >Assignee: Chris Graham >Priority: Major > Fix For: 1.11.1 > > > Jazz provider tag command uses the jazz workspace set int the pom.xml scm > tag. When in other jazz workspace, the snapshot is not created based on the > current work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6567) Dependency resolution when repository defined
[
https://issues.apache.org/jira/browse/MNG-6567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6567:
Fix Version/s: waiting-for-feedback
> Dependency resolution when repository defined
> -
>
> Key: MNG-6567
> URL: https://issues.apache.org/jira/browse/MNG-6567
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.3, 3.6.0
>Reporter: Fred Bricon
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: build.txt
>
>
> With the following pom.xml, the Maven build fails with _Could not resolve
> dependencies for project foo.bar:test:jar:0.0.1-SNAPSHOT: Could not find
> artifact org.eclipse.xtend:org.eclipse.xtend.lib:jar:2.17.0.M1_:
> {noformat}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> foo.bar
> test
> 0.0.1-SNAPSHOT
>
>
> org.eclipse.lsp4j
> org.eclipse.lsp4j
> 0.6.0
>
>
>
>
> oss-jfrog-snapshots
> https://oss.jfrog.org/artifactory/libs-snapshot
>
> false
>
>
> true
>
>
>
>
> {noformat}
> If you remove the repository, the build works. That repo is configured to
> only fetch snapshots, so it makes no sense.
> The funny thing is if you add
> {noformat}
>
> org.eclipse.xtend
> org.eclipse.xtend.lib
> 2.17.0.M1
>
> {noformat}
> then Maven succeeds in resolving the transitive dependency.
--
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=16770091#comment-16770091
]
Michael Osipov commented on MSHARED-800:
[~hboutemy], please have a look at the branch, I'd like to finalize this
release.
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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-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=16770090#comment-16770090
]
Michael Osipov commented on MSHARED-362:
Everything has been adapted. You can configure Maven Archiver now to have
{{Manifest-Version}} only.
> 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] [Commented] (MSHARED-546) Change groupId from org.apache.maven to org.apache.maven.shared
[
https://issues.apache.org/jira/browse/MSHARED-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770093#comment-16770093
]
Michael Osipov commented on MSHARED-546:
Can we do this for 3.4 or do we have to wait for 4.0.0?
> Change groupId from org.apache.maven to org.apache.maven.shared
> ---
>
> Key: MSHARED-546
> URL: https://issues.apache.org/jira/browse/MSHARED-546
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-2.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently the maven-archiver is located in the groupId {{org.apache.maven}}
> but it should be in {{org.apache.maven.shared.archiver}} as all other shared
> components.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-798) Add addDefaultEntries option (true by default)
[
https://issues.apache.org/jira/browse/MSHARED-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770089#comment-16770089
]
Hudson commented on MSHARED-798:
Build succeeded in Jenkins: Maven TLP » maven-archiver » master #57
See https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/57/
> Add addDefaultEntries option (true by default)
> --
>
> 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
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Based on MSHARED-362, one should have the option to disable default manifest
> entries (currently {{Created-By}} and {{Build-Jdk-Spec}}), by setting the
> option {{addDefaultEntries}} to {{false}} (set to {{true}} by default)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (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:all-tabpanel ] Michael Osipov closed MSHARED-362. -- Resolution: Fixed > 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] [Closed] (MSHARED-798) Add addDefaultEntries option (true by default)
[
https://issues.apache.org/jira/browse/MSHARED-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSHARED-798.
--
Resolution: Fixed
Fixed with
[cbe8411b35bbddb2269ef99b5a8e517b9378b985|https://gitbox.apache.org/repos/asf?p=maven-archiver.git;a=commit;h=cbe8411b35bbddb2269ef99b5a8e517b9378b985].
> Add addDefaultEntries option (true by default)
> --
>
> 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
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Based on MSHARED-362, one should have the option to disable default manifest
> entries (currently {{Created-By}} and {{Build-Jdk-Spec}}), by setting the
> option {{addDefaultEntries}} to {{false}} (set to {{true}} by default)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
