[jira] [Commented] (MNG-5640) AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases
[
https://issues.apache.org/jira/browse/MNG-5640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082775#comment-17082775
]
Hudson commented on MNG-5640:
-
Build succeeded in Jenkins: Maven TLP » maven » master #395
See https://builds.apache.org/job/maven-box/job/maven/job/master/395/
> AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases
> --
>
> Key: MNG-5640
> URL: https://issues.apache.org/jira/browse/MNG-5640
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.2.1
>Reporter: Tamás Cservenák
>Assignee: Jason van Zyl
>Priority: Major
> Fix For: 3.2.2
>
> Attachments: aftersessionend.zip
>
>
> It seems that {{AbstractMavenLifecycleParticipant#afterSessionEnd}} is not
> invoked in some cases, at least one case for sure: when the build fails.
> Reproduce case:
> 1. unzip the attached project
> 2. build it but skip tests {{mvn clean install -Dtest=void
> -DfailIfNoTests=false}}
> 3. install the resulting jar in /lib/ext of your Maven 3.2.1
> 4. with JAR installed in Maven, build it again with skipped tests
> 5. verify console output (both {{afterProjectsRead OK}} and {{afterSessionEnd
> OK}} are printed on console)
> 6. with JAR installed in Maven, build it again with tests (there is one UT
> that always fails).
> 6. console output contains only {{afterProjectsRead OK}}, but afterSessionEnd
> method is NOT invoked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1658) TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
[
https://issues.apache.org/jira/browse/SUREFIRE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1658.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=5e3348cdf29d1d49ca615a893b9174563f62815c
> TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism
> for remote and local process communication.
>
>
> Key: SUREFIRE-1658
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1658
> Project: Maven Surefire
> Issue Type: New Feature
> Components: process forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement server socker in Maven process and client socket in forked JVM.
> Affected class {{ForkStarter}} and {{ForkingRunListener}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1638) untilFailureLoopCount property to run tests until failure
[
https://issues.apache.org/jira/browse/SUREFIRE-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082757#comment-17082757
]
Tibor Digana commented on SUREFIRE-1638:
[~ZKXnCa]
Such a feature already exists, see
https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html
> untilFailureLoopCount property to run tests until failure
> -
>
> Key: SUREFIRE-1638
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1638
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Galder Zamarreño
>Priority: Major
>
> This is a proposal to add surefire/failsafe property called
> `untilFailureLoopCount`.
> I often find myself in the situation where there's a random test failure
> happening in CI, and have to run the one or several tests continuously until
> it fails, maybe running them with TRACE logging.
> Normally, I'd wrap the `mvn test...` call with a script that calls it in a
> loop, but this can be quite "slow" since each iteration is a new JVM
> launch...etc.
> The idea behind `untilFailureLoopCount` is that you've give it a positive
> number, say 1000, and the test(s) would run continuously until either a
> failure happens or the test is executed that many times.
> I've created [this randomly failing
> test](https://github.com/galderz/surefire-until-failure-loop-count/blob/master/src/test/java/com/acme/maven/surefire/untilfailure/UntilFailureLoopCountTest.java)
> and I've run it with `mvn -Dsurefire.untilFailureLoopCount=10 test` and the
> output would be something like:
> {code}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034
> s - in com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Running com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001
> s - in com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Running com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s -
> in com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Running com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s -
> in com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Running com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.001
> s <<< FAILURE! - in
> com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [ERROR]
> com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest.testEventualFailure
> Time elapsed: 0.001 s <<< FAILURE!
> java.lang.AssertionError: Just messing with your testing
> at
> com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest.testEventualFailure(UntilFailureLoopCountTest.java:16)
> {code}
> If maintainers are interested in this, I can complete the PR with tests,
> documentation and support for other providers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 merged pull request #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
Tibor17 merged pull request #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (SUREFIRE-1772) Suppressed exceptions not shown in trimmed stack trace
[ https://issues.apache.org/jira/browse/SUREFIRE-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082739#comment-17082739 ] Tibor Digana commented on SUREFIRE-1772: [~joerg1985] The Opensource allows you to provide a fix. Feel free to open the pullrequest on GitHub and ping us and we will help you. > Suppressed exceptions not shown in trimmed stack trace > -- > > Key: SUREFIRE-1772 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1772 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M4 >Reporter: Jörg Sautter >Priority: Major > > Suppressed exceptions are not shown in the console output of the maven > plugin, this has been reported as #SUREFIRE-1029 before. It was rejected in > the past due to the expected Java sourcecode 1.6 expected in Maven 3.0 and > suppressed execptions are a 1.7 feature. > Maven 3 actually uses java 1.7 as minimum and this could be implemented now. > Additionally more frameworks are using the suppressed exceptions feature and > a the lack in reporting is more important than in the past, e.g. [JUnit5 is > using suppressed > exceptions|https://github.com/junit-team/junit5/issues/1602#issuecomment-427305459] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1773) ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[
https://issues.apache.org/jira/browse/SUREFIRE-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082737#comment-17082737
]
Tibor Digana edited comment on SUREFIRE-1773 at 4/13/20, 11:24 PM:
---
[~Tuxiaodong]
I think you have a problem that you use ArgLineFromJacocoUt without
property-interpolation in the process arg line.
You have to find out where it is coming from. It may be JAVA_OPTS or your build
process and system properties.
If you want to know how to configure the JaCoCo, see our
[POM|https://github.com/apache/maven-surefire/blob/master/pom.xml].
was (Author: tibor17):
[~Tuxiaodong]
I think you have a problem that you use ArgLineFromJacocoUt without
property-interpolation in the process arg line.
You have to find out where it is coming from. It may be JAVA_OPTS or your build
process and system properties.
If you want to know how to configure the JaCoCo, see out
[POM|https://github.com/apache/maven-surefire/blob/master/pom.xml].
> ExecutionException The forked VM terminated without properly saying goodbye.
> VM crash or System.exit called?
> -
>
> Key: SUREFIRE-1773
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1773
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.1
>Reporter: Tu,Xiaodong
>Priority: Major
> Attachments: 2020-04-13T21-43-24_857.dumpstream, FullErrorLog
>
>
> Attempting to run integration tests using maven-failsafe-plugin and get error
> below.
> {code:java}
> [ERROR] ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called? [ERROR] Command was /bin/sh -c cd
> /Users/xiaotu/Documents/WorkCode/modelinsightservice &&
> /Users/xiaotu/Documents/WorkEnviroment/ebay_jdk_1.8.221/1.8.221_mac/jre/bin/java
> -Djdk.attach.allowAttachSelf -Djava.locale.providers=JRE,SPI
> '${ArgLineFromJacocoUt}' -Xverify:none -Xmx1024m -XX:MaxMetaspaceSize=512m
> -jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire/surefirebooter7810841987757310542.jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire
> 2020-04-13T21-43-24_857-jvmRun2 surefire5674009295883666539tmp
> surefire_13303426714213707853tmp [ERROR] Error occurred in starting fork,
> check output in log [ERROR] Process Exit Code: 1 [ERROR] ExecutionException
> The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called? [ERROR] Command was /bin/sh -c cd
> /Users/xiaotu/Documents/WorkCode/modelinsightservice &&
> /Users/xiaotu/Documents/WorkEnviroment/ebay_jdk_1.8.221/1.8.221_mac/jre/bin/java
> -Djdk.attach.allowAttachSelf -Djava.locale.providers=JRE,SPI
> '${ArgLineFromJacocoUt}' -Xverify:none -Xmx1024m -XX:MaxMetaspaceSize=512m
> -jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire/surefirebooter1185519684559162293.jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire
> 2020-04-13T21-43-24_857-jvmRun4 surefire3761879713715389341tmp
> surefire_28680022230240461764tmp
> {code}
> using maven command : mvn clean install -P static-check,default-plugins.
> Related maven setting:
>
> {code:java}
>
> org.sonarsource.scanner.maven
> sonar-maven-plugin 3.4.0.905
> org.springframework.boot
> spring-boot-maven-plugin
> org.jacoco jacoco-maven-plugin
> ${jacoco.version}
> pre-unit-test prepare-agent
> ${project.build.directory}/jacoco-ut.exec surefireArgLine
>
> post-unit-test test report
>
> ${project.build.directory}/jacoco-ut.exec
> ${project.reporting.outputDirectory}/jacoco-ut
> pre-integration-test
> pre-integration-test prepare-agent
>
> ${project.build.directory}/jacoco-it.exec
> failsafeArgLine
>
> post-integration-test post-integration-test
> report
> ${project.build.directory}/jacoco-it.exec
> ${project.reporting.outputDirectory}/jacoco-it
>
> org.apache.maven.plugins
> maven-pmd-plugin 3.8
> rulesets/java/ali-comment.xml
> rulesets/java/ali-concurrent.xml
> rulesets/java/ali-constant.xml
> rulesets/java/ali-exception.xml
> rulesets/java/ali-flowcontrol.xml
> rulesets/java/ali-naming.xml
> rulesets/java/ali-oop.xml
> rulesets/java/ali-orm.xml
> rulesets/java/ali-other.xml
> rulesets/java/ali-set.xml
> true
> true
> 3
> package check
>
> com.ebay.marketing p3c-pmd
> 1.0.0-SNAPSHOT
> org.apache.maven.plugins
> maven-surefire-plugin 2.22.1
> once 1.0C
> false ${surefireArgLine} -Xverify:none
> -Xmx1024m -XX:MaxMetaspaceSize=512m
> org.apache.maven.plugins
> maven-failsafe-plugin 2.22.1
>
> integration-tests integration-test
> verify
> ${failsafeArgLine}
[jira] [Commented] (SUREFIRE-1773) ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[
https://issues.apache.org/jira/browse/SUREFIRE-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082737#comment-17082737
]
Tibor Digana commented on SUREFIRE-1773:
[~Tuxiaodong]
I think you have a problem that you use ArgLineFromJacocoUt without
property-interpolation in the process arg line.
You have to find out where it is coming from. It may be JAVA_OPTS or your build
process and system properties.
If you want to know how to configure the JaCoCo, see out
[POM|https://github.com/apache/maven-surefire/blob/master/pom.xml].
> ExecutionException The forked VM terminated without properly saying goodbye.
> VM crash or System.exit called?
> -
>
> Key: SUREFIRE-1773
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1773
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.1
>Reporter: Tu,Xiaodong
>Priority: Major
> Attachments: 2020-04-13T21-43-24_857.dumpstream, FullErrorLog
>
>
> Attempting to run integration tests using maven-failsafe-plugin and get error
> below.
> {code:java}
> [ERROR] ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called? [ERROR] Command was /bin/sh -c cd
> /Users/xiaotu/Documents/WorkCode/modelinsightservice &&
> /Users/xiaotu/Documents/WorkEnviroment/ebay_jdk_1.8.221/1.8.221_mac/jre/bin/java
> -Djdk.attach.allowAttachSelf -Djava.locale.providers=JRE,SPI
> '${ArgLineFromJacocoUt}' -Xverify:none -Xmx1024m -XX:MaxMetaspaceSize=512m
> -jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire/surefirebooter7810841987757310542.jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire
> 2020-04-13T21-43-24_857-jvmRun2 surefire5674009295883666539tmp
> surefire_13303426714213707853tmp [ERROR] Error occurred in starting fork,
> check output in log [ERROR] Process Exit Code: 1 [ERROR] ExecutionException
> The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called? [ERROR] Command was /bin/sh -c cd
> /Users/xiaotu/Documents/WorkCode/modelinsightservice &&
> /Users/xiaotu/Documents/WorkEnviroment/ebay_jdk_1.8.221/1.8.221_mac/jre/bin/java
> -Djdk.attach.allowAttachSelf -Djava.locale.providers=JRE,SPI
> '${ArgLineFromJacocoUt}' -Xverify:none -Xmx1024m -XX:MaxMetaspaceSize=512m
> -jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire/surefirebooter1185519684559162293.jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire
> 2020-04-13T21-43-24_857-jvmRun4 surefire3761879713715389341tmp
> surefire_28680022230240461764tmp
> {code}
> using maven command : mvn clean install -P static-check,default-plugins.
> Related maven setting:
>
> {code:java}
>
> org.sonarsource.scanner.maven
> sonar-maven-plugin 3.4.0.905
> org.springframework.boot
> spring-boot-maven-plugin
> org.jacoco jacoco-maven-plugin
> ${jacoco.version}
> pre-unit-test prepare-agent
> ${project.build.directory}/jacoco-ut.exec surefireArgLine
>
> post-unit-test test report
>
> ${project.build.directory}/jacoco-ut.exec
> ${project.reporting.outputDirectory}/jacoco-ut
> pre-integration-test
> pre-integration-test prepare-agent
>
> ${project.build.directory}/jacoco-it.exec
> failsafeArgLine
>
> post-integration-test post-integration-test
> report
> ${project.build.directory}/jacoco-it.exec
> ${project.reporting.outputDirectory}/jacoco-it
>
> org.apache.maven.plugins
> maven-pmd-plugin 3.8
> rulesets/java/ali-comment.xml
> rulesets/java/ali-concurrent.xml
> rulesets/java/ali-constant.xml
> rulesets/java/ali-exception.xml
> rulesets/java/ali-flowcontrol.xml
> rulesets/java/ali-naming.xml
> rulesets/java/ali-oop.xml
> rulesets/java/ali-orm.xml
> rulesets/java/ali-other.xml
> rulesets/java/ali-set.xml
> true
> true
> 3
> package check
>
> com.ebay.marketing p3c-pmd
> 1.0.0-SNAPSHOT
> org.apache.maven.plugins
> maven-surefire-plugin 2.22.1
> once 1.0C
> false ${surefireArgLine} -Xverify:none
> -Xmx1024m -XX:MaxMetaspaceSize=512m
> org.apache.maven.plugins
> maven-failsafe-plugin 2.22.1
>
> integration-tests integration-test
> verify
> ${failsafeArgLine}
> {code}
>
> Got more details in FullErrorLog and dump file.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1042) releaseProfiles get overriden by activeProfiles
[
https://issues.apache.org/jira/browse/MRELEASE-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082701#comment-17082701
]
Benoit GUERIN commented on MRELEASE-1042:
-
PR updated
> releaseProfiles get overriden by activeProfiles
> ---
>
> Key: MRELEASE-1042
> URL: https://issues.apache.org/jira/browse/MRELEASE-1042
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M2
>Reporter: Arnaud Heritier
>Assignee: Robert Scholte
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I tried to release a project with 3.0.0-M2 and potentially it is another
> problem related to MRELEASE-1038 [~rfscholte] [~olamy]
>
> In our corporate POM we have a pluginManagement entry:
> {code:java}
>
> maven-release-plugin
> 2.5.3
>
> forked-path
> false
> cloudbees-internal-release
>
>
> {code}
> My project extends it and has no settings related to the release plugin
> In my user settings I have
> {code:java}
>
> cloudbees-internal-deploy
> cloudbees-snapshots
> apache-staging
>
> {code}
> Then I release my project using 3.0.0-M2 with
> {code:java}
> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:prepare
> org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform
> {code}
> The perform step is taking my user profiles but not the ones from
> "releaseProfiles"
> {noformat}
> [INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
> /Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
> /var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings4094445863857985100.xml
> -f pom.xml deploy -P
> cloudbees-internal-deploy,cloudbees-snapshots,apache-staging -f
> pom.xml{noformat}
> Not sure if it could be because I call the release plugin with the full GAV
> but it is strange ...
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSKINS-165) Inconsistent parent pom in IT tests.
[
https://issues.apache.org/jira/browse/MSKINS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MSKINS-165:
Fix Version/s: fluido-2.0
> Inconsistent parent pom in IT tests.
> -
>
> Key: MSKINS-165
> URL: https://issues.apache.org/jira/browse/MSKINS-165
> Project: Maven Skins
> Issue Type: Improvement
> Components: Fluido Skin
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: fluido-2.0
>
>
> Why do you have parent defined as below in it-tests project (not in all -
> some projects haven't got parent):
> {code:java}
>
> org.apache.maven
> maven-parent
> @project.parent.version@
> {code}
> @project.parent.version@ is taken from project which has:
> {code:java}
>
> org.apache.maven.skins
> maven-skins
> 34
> ../../pom/maven/maven-skins/pom.xml
> {code}
> Generally those are different artifacts and can have different version.
> I see that both are build from one project where maven-skins is module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] famod commented on issue #310: [MNG-6843] - Parallel build fails due to missing JAR artifacts in compilePath
famod commented on issue #310: [MNG-6843] - Parallel build fails due to missing JAR artifacts in compilePath URL: https://github.com/apache/maven/pull/310#issuecomment-613078824 This is interesting and a bit frustating: neither this PR nor another approach I implemented locally (with `ThreadLocal`) are able to fix this problem for me. On the other hand it does not really surprise me, given all the mutating methods in `MavenProject` (`set*`) that seem like a bit of a mess in combination with concurrent access... @kodeva Can you verify that this PR fixes your problem? This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (MSKINS-165) Inconsistent parent pom in IT tests.
[
https://issues.apache.org/jira/browse/MSKINS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-165:
--
Fix Version/s: (was: fluido-1.9)
> Inconsistent parent pom in IT tests.
> -
>
> Key: MSKINS-165
> URL: https://issues.apache.org/jira/browse/MSKINS-165
> Project: Maven Skins
> Issue Type: Improvement
> Components: Fluido Skin
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
>
> Why do you have parent defined as below in it-tests project (not in all -
> some projects haven't got parent):
> {code:java}
>
> org.apache.maven
> maven-parent
> @project.parent.version@
> {code}
> @project.parent.version@ is taken from project which has:
> {code:java}
>
> org.apache.maven.skins
> maven-skins
> 34
> ../../pom/maven/maven-skins/pom.xml
> {code}
> Generally those are different artifacts and can have different version.
> I see that both are build from one project where maven-skins is module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1042) releaseProfiles get overriden by activeProfiles
[
https://issues.apache.org/jira/browse/MRELEASE-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082609#comment-17082609
]
Benoit GUERIN commented on MRELEASE-1042:
-
Right, I will change my PR
> releaseProfiles get overriden by activeProfiles
> ---
>
> Key: MRELEASE-1042
> URL: https://issues.apache.org/jira/browse/MRELEASE-1042
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M2
>Reporter: Arnaud Heritier
>Assignee: Robert Scholte
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I tried to release a project with 3.0.0-M2 and potentially it is another
> problem related to MRELEASE-1038 [~rfscholte] [~olamy]
>
> In our corporate POM we have a pluginManagement entry:
> {code:java}
>
> maven-release-plugin
> 2.5.3
>
> forked-path
> false
> cloudbees-internal-release
>
>
> {code}
> My project extends it and has no settings related to the release plugin
> In my user settings I have
> {code:java}
>
> cloudbees-internal-deploy
> cloudbees-snapshots
> apache-staging
>
> {code}
> Then I release my project using 3.0.0-M2 with
> {code:java}
> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:prepare
> org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform
> {code}
> The perform step is taking my user profiles but not the ones from
> "releaseProfiles"
> {noformat}
> [INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
> /Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
> /var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings4094445863857985100.xml
> -f pom.xml deploy -P
> cloudbees-internal-deploy,cloudbees-snapshots,apache-staging -f
> pom.xml{noformat}
> Not sure if it could be because I call the release plugin with the full GAV
> but it is strange ...
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1042) releaseProfiles get overriden by activeProfiles
[
https://issues.apache.org/jira/browse/MRELEASE-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082604#comment-17082604
]
Robert Scholte commented on MRELEASE-1042:
--
I came to to the same analysis. In general the release.properties contain the
correct properties and should not be overridden, but it seems that in case of
perform the profiles should be added.
I'd suggest to fix this in the DefaultReleaseManager.perform to keep the
ReleaseUtils.copyPropertiesToReleaseDescriptor as stupid as possible.
> releaseProfiles get overriden by activeProfiles
> ---
>
> Key: MRELEASE-1042
> URL: https://issues.apache.org/jira/browse/MRELEASE-1042
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M2
>Reporter: Arnaud Heritier
>Assignee: Robert Scholte
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I tried to release a project with 3.0.0-M2 and potentially it is another
> problem related to MRELEASE-1038 [~rfscholte] [~olamy]
>
> In our corporate POM we have a pluginManagement entry:
> {code:java}
>
> maven-release-plugin
> 2.5.3
>
> forked-path
> false
> cloudbees-internal-release
>
>
> {code}
> My project extends it and has no settings related to the release plugin
> In my user settings I have
> {code:java}
>
> cloudbees-internal-deploy
> cloudbees-snapshots
> apache-staging
>
> {code}
> Then I release my project using 3.0.0-M2 with
> {code:java}
> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:prepare
> org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform
> {code}
> The perform step is taking my user profiles but not the ones from
> "releaseProfiles"
> {noformat}
> [INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
> /Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
> /var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings4094445863857985100.xml
> -f pom.xml deploy -P
> cloudbees-internal-deploy,cloudbees-snapshots,apache-staging -f
> pom.xml{noformat}
> Not sure if it could be because I call the release plugin with the full GAV
> but it is strange ...
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6891) Improve support --fail-on-severity
Robert Scholte created MNG-6891:
---
Summary: Improve support --fail-on-severity
Key: MNG-6891
URL: https://issues.apache.org/jira/browse/MNG-6891
Project: Maven
Issue Type: Improvement
Reporter: Robert Scholte
Fix For: 3.7.0-candidate
MNG-6065 was a first implementation, but it is not user friendly enough.
1. When saying {{-fos}} the message is: No enum constant
org.slf4j.event.Level.warn
We should show at least all available values here
2. The prefix for warnings in Maven is [WARNING], due to
{{org.slf4j.simpleLogger.warnLevelString}} in
{{apache-maven/conf/logging/simplelogger.properties}}. It makes sense support
this custom value as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6357) Dependency order should be nearest first
[
https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824520#comment-16824520
]
Tomo Suzuki edited comment on MNG-6357 at 4/13/20, 6:14 PM:
I encountered this issue today. I had an assumption that Maven exec plugin
builds a class path in "nearest first" manner, but it actually treats it in
"depth first" manner.
Code to reproduce: [https://github.com/suztomo/triangle-linkage-error] .
Given this tree of transitive dependencies Artifact 1 - 5.
{{ suztomo:main:jar:0.0.1-SNAPSHOT}}
{{ +- suztomo:artifact1}}
{{ | +- suztomo:artifact4}}
{{ +- suztomo:artifact2}}
{{ | +- suztomo:artifact5}}
{{ +- suztomo:artifact3}}
I expected Maven exec plugin to build a class path of "artifact1, artifact2,
artifact3, artifact4, artifact5". However it builds a class path of "artifact1,
artifact*4*, artifact2, artifact*5*, artifact3".
In Github discussion [https://github.com/mojohaus/exec-maven-plugin/issues/91],
rfscholte wrote
_>Hervé confirmed that the "nearest wins" is only about version selection and
not about dependency order. This order is simply done by tree-walking. However,
we agreed that it would make sense to compile based on the direct dependencies
first, followed by first level, second level, etc._
Thank you. I also think that's intuitive behavior, in line with Maven's
dependency mediation algorithm.
was (Author: suztomo):
I encountered this issue today. I had an assumption that Maven exec plugin
builds a class path in "nearest first" manner, but it actually treats it in
"depth first" manner.
Code to reproduce: [https://github.com/suztomo/triangle-linkage-error] .
Given this tree of transitive dependencies Artifact 1 - 5.
{{ suztomo:main:jar:0.0.1-SNAPSHOT}}
{{ +- suztomo:artifact1}}
{{ | +- suztomo:artifact4}}
{{ +- suztomo:artifact2}}
{{ | +- suztomo:artifact5}}
{{ +- suztomo:artifact3}}
I expected Maven exec plugin to build a class path of "artifact1, artifact2,
artifact3, artifact4, artifact5". However it builds a class path of "artifact1,
artifact*4*, artifact2, artifact*5*, artifact3".
In Github discussion [https://github.com/mojohaus/exec-maven-plugin/issues/91],
rfscholte wrote
_>Hervé confirmed that the "nearest wins" is only about version selection and
not about dependency order. This order is simply done by tree-walking. However,
we agreed that it would make sense to compile based on the direct dependencies
first, followed by first level, second level, etc._
Thank you. I also think that's intuitive behavior, in line with Maven's
dependency mediation algorithm.
> Dependency order should be nearest first
> -
>
> Key: MNG-6357
> URL: https://issues.apache.org/jira/browse/MNG-6357
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In case of version conflicts, the nearest wins. However, the dependency order
> is simply based on tree walking. In the rare that a transitive dependency of
> the first direct dependency contains the same class as a latter direct
> dependency, the code is compiled against the first one, which is odd.
> It would make more sense if direct dependencies are the first ones on the
> classpath, followed by the first level transitive dependencies, etc. This
> will make the explanation equal to version conflict resolution: nearest wins.
> I don't expect real issues due to this change, otherwise we would have had
> this issue much earlier. This should become the new default order, however
> there should be a system property to get the original order, just in case
> somebody needs it.
>
> Current workaround: make the critical dependency the first direct dependency.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6357) Dependency order should be nearest first
[ https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082550#comment-17082550 ] Tomo Suzuki commented on MNG-6357: -- For building a class path for different artifactIDs, it does not. > Dependency order should be nearest first > - > > Key: MNG-6357 > URL: https://issues.apache.org/jira/browse/MNG-6357 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > In case of version conflicts, the nearest wins. However, the dependency order > is simply based on tree walking. In the rare that a transitive dependency of > the first direct dependency contains the same class as a latter direct > dependency, the code is compiled against the first one, which is odd. > It would make more sense if direct dependencies are the first ones on the > classpath, followed by the first level transitive dependencies, etc. This > will make the explanation equal to version conflict resolution: nearest wins. > I don't expect real issues due to this change, otherwise we would have had > this issue much earlier. This should become the new default order, however > there should be a system property to get the original order, just in case > somebody needs it. > > Current workaround: make the critical dependency the first direct dependency. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNGSITE-393) Remove references to Maven 2.x
[ https://issues.apache.org/jira/browse/MNGSITE-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082535#comment-17082535 ] Hudson commented on MNGSITE-393: Build succeeded in Jenkins: Maven TLP » maven-jar-plugin » master #44 See https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/master/44/ > Remove references to Maven 2.x > -- > > Key: MNGSITE-393 > URL: https://issues.apache.org/jira/browse/MNGSITE-393 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > Time Spent: 3h 40m > Remaining Estimate: 0h > > Maven 3.x is over a decade old now and we're talking about Maven 4. It's time > to clean out all the random discussion here and there about how Maven 2.x did > things, differences between Maven 2 and 3, what works in Maven 3 but not 2, > etc. > Assume Maven 3.0 as the minimum, probably Maven 3.1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHARED-881) try with resources in FileUtils
[ https://issues.apache.org/jira/browse/MSHARED-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082533#comment-17082533 ] Hudson commented on MSHARED-881: Build succeeded in Jenkins: Maven TLP » maven-shared-utils » master #53 See https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/53/ > try with resources in FileUtils > --- > > Key: MSHARED-881 > URL: https://issues.apache.org/jira/browse/MSHARED-881 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Minor > Labels: up-for-grabs > Time Spent: 20m > Remaining Estimate: 0h > > FileUtils and other classes can no use try with resource instead of > IOUtils.closeeQuietly -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-shared-utils] elharo merged pull request #27: [MSHARED-881] use try with resources
elharo merged pull request #27: [MSHARED-881] use try with resources URL: https://github.com/apache/maven-shared-utils/pull/27 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-jar-plugin] elharo merged pull request #8: [MNGSITE-393] remove more pre Maven 3 content
elharo merged pull request #8: [MNGSITE-393] remove more pre Maven 3 content URL: https://github.com/apache/maven-jar-plugin/pull/8 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MNG-6275:
---
Labels: intern (was: )
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Stephen Connolly
>Priority: Critical
> Labels: intern
> Fix For: 3.x / Backlog
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (MPLUGIN-349) Create a javadoc tags to Java5 annotations converter
[ https://issues.apache.org/jira/browse/MPLUGIN-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reopened MPLUGIN-349: --- > Create a javadoc tags to Java5 annotations converter > > > Key: MPLUGIN-349 > URL: https://issues.apache.org/jira/browse/MPLUGIN-349 > Project: Maven Plugin Tools > Issue Type: New Feature > Components: Plugin Plugin >Reporter: QualiteSys QualiteSys >Priority: Major > > I am working on source code CI tool chains. I would need to convert the old > Javadoc tags notation for @goal, @phase, etc to the Java5 annotation provided > since version 3.0 > ([https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html]) > Is it possible to create a special goal to manipulate the orginal source code > files and process the conversions ? > > Thanks for your help > Didier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MPLUGIN-349) Create a javadoc tags to Java5 annotations converter
[ https://issues.apache.org/jira/browse/MPLUGIN-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MPLUGIN-349. - > Create a javadoc tags to Java5 annotations converter > > > Key: MPLUGIN-349 > URL: https://issues.apache.org/jira/browse/MPLUGIN-349 > Project: Maven Plugin Tools > Issue Type: New Feature > Components: Plugin Plugin >Reporter: QualiteSys QualiteSys >Priority: Major > Labels: intern > > I am working on source code CI tool chains. I would need to convert the old > Javadoc tags notation for @goal, @phase, etc to the Java5 annotation provided > since version 3.0 > ([https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html]) > Is it possible to create a special goal to manipulate the orginal source code > files and process the conversions ? > > Thanks for your help > Didier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MPLUGIN-349) Create a javadoc tags to Java5 annotations converter
[ https://issues.apache.org/jira/browse/MPLUGIN-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MPLUGIN-349. --- Resolution: Won't Fix > Create a javadoc tags to Java5 annotations converter > > > Key: MPLUGIN-349 > URL: https://issues.apache.org/jira/browse/MPLUGIN-349 > Project: Maven Plugin Tools > Issue Type: New Feature > Components: Plugin Plugin >Reporter: QualiteSys QualiteSys >Priority: Major > Labels: intern > > I am working on source code CI tool chains. I would need to convert the old > Javadoc tags notation for @goal, @phase, etc to the Java5 annotation provided > since version 3.0 > ([https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html]) > Is it possible to create a special goal to manipulate the orginal source code > files and process the conversions ? > > Thanks for your help > Didier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPLUGIN-349) Create a javadoc tags to Java5 annotations converter
[ https://issues.apache.org/jira/browse/MPLUGIN-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MPLUGIN-349: -- Labels: (was: intern) > Create a javadoc tags to Java5 annotations converter > > > Key: MPLUGIN-349 > URL: https://issues.apache.org/jira/browse/MPLUGIN-349 > Project: Maven Plugin Tools > Issue Type: New Feature > Components: Plugin Plugin >Reporter: QualiteSys QualiteSys >Priority: Major > > I am working on source code CI tool chains. I would need to convert the old > Javadoc tags notation for @goal, @phase, etc to the Java5 annotation provided > since version 3.0 > ([https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html]) > Is it possible to create a special goal to manipulate the orginal source code > files and process the conversions ? > > Thanks for your help > Didier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6840) Update commons-lang3
[ https://issues.apache.org/jira/browse/MNG-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MNG-6840: --- Issue Type: Dependency upgrade (was: Improvement) > Update commons-lang3 > > > Key: MNG-6840 > URL: https://issues.apache.org/jira/browse/MNG-6840 > Project: Maven > Issue Type: Dependency upgrade > Components: core >Affects Versions: 3.6.3 >Reporter: Krosheninnikov Artem >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > > While it's not clear whether to remove/replace commons-lang dependency, it's > worth having it up-to-date -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPOM-168) JDK 9 requires updates to plugins
[ https://issues.apache.org/jira/browse/MPOM-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MPOM-168: --- Issue Type: Dependency upgrade (was: Improvement) > JDK 9 requires updates to plugins > - > > Key: MPOM-168 > URL: https://issues.apache.org/jira/browse/MPOM-168 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Affects Versions: ASF-19 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: ASF-24 > > > The following plugins needed to be updated to work with JDK 9: > * The maven-enforcer-plugin should be updated to final 3.0.0 release to make > the pom working with JDK 9... > * maven-shade-plugin should be upgraded to 3.0.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DOXIA-60) Use a external XML Pull parser instead of plexus one
[
https://issues.apache.org/jira/browse/DOXIA-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated DOXIA-60:
---
Labels: intern (was: )
> Use a external XML Pull parser instead of plexus one
>
>
> Key: DOXIA-60
> URL: https://issues.apache.org/jira/browse/DOXIA-60
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Carlos Sanchez Gonzalez
>Priority: Major
> Labels: intern
> Fix For: 2.0
>
>
> To avoid maintaining the plexus XMLPullParser we should move to a standard
> implementation like Codehaus StaX http://stax.codehaus.org
> {code:xml}
> stax
> stax
> 1.2.0_rc2-dev
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (MNG-6357) Dependency order should be nearest first
[ https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reopened MNG-6357: > Dependency order should be nearest first > - > > Key: MNG-6357 > URL: https://issues.apache.org/jira/browse/MNG-6357 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > In case of version conflicts, the nearest wins. However, the dependency order > is simply based on tree walking. In the rare that a transitive dependency of > the first direct dependency contains the same class as a latter direct > dependency, the code is compiled against the first one, which is odd. > It would make more sense if direct dependencies are the first ones on the > classpath, followed by the first level transitive dependencies, etc. This > will make the explanation equal to version conflict resolution: nearest wins. > I don't expect real issues due to this change, otherwise we would have had > this issue much earlier. This should become the new default order, however > there should be a system property to get the original order, just in case > somebody needs it. > > Current workaround: make the critical dependency the first direct dependency. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6357) Dependency order should be nearest first
[ https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082482#comment-17082482 ] Elliotte Rusty Harold commented on MNG-6357: Wait, I'm confused. I thought this is how it did work already. > Dependency order should be nearest first > - > > Key: MNG-6357 > URL: https://issues.apache.org/jira/browse/MNG-6357 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > In case of version conflicts, the nearest wins. However, the dependency order > is simply based on tree walking. In the rare that a transitive dependency of > the first direct dependency contains the same class as a latter direct > dependency, the code is compiled against the first one, which is odd. > It would make more sense if direct dependencies are the first ones on the > classpath, followed by the first level transitive dependencies, etc. This > will make the explanation equal to version conflict resolution: nearest wins. > I don't expect real issues due to this change, otherwise we would have had > this issue much earlier. This should become the new default order, however > there should be a system property to get the original order, just in case > somebody needs it. > > Current workaround: make the critical dependency the first direct dependency. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MNG-6357) Dependency order should be nearest first
[ https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MNG-6357. Resolution: Not A Bug There's no way we could change dependency mediation like this at this point in time without breaking the world. > Dependency order should be nearest first > - > > Key: MNG-6357 > URL: https://issues.apache.org/jira/browse/MNG-6357 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > In case of version conflicts, the nearest wins. However, the dependency order > is simply based on tree walking. In the rare that a transitive dependency of > the first direct dependency contains the same class as a latter direct > dependency, the code is compiled against the first one, which is odd. > It would make more sense if direct dependencies are the first ones on the > classpath, followed by the first level transitive dependencies, etc. This > will make the explanation equal to version conflict resolution: nearest wins. > I don't expect real issues due to this change, otherwise we would have had > this issue much earlier. This should become the new default order, however > there should be a system property to get the original order, just in case > somebody needs it. > > Current workaround: make the critical dependency the first direct dependency. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MLINKCHECK-35) Migrate plugin to Maven 3.0
[ https://issues.apache.org/jira/browse/MLINKCHECK-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MLINKCHECK-35: Issue Type: Dependency upgrade (was: Improvement) > Migrate plugin to Maven 3.0 > --- > > Key: MLINKCHECK-35 > URL: https://issues.apache.org/jira/browse/MLINKCHECK-35 > Project: Maven Linkcheck Plugin > Issue Type: Dependency upgrade >Reporter: Robert Scholte >Priority: Major > Fix For: 3.0.0 > > > Migrate plugin as described at > https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-307) Ensure some default transformers and filters are set up if none is configured
[ https://issues.apache.org/jira/browse/MSHADE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082476#comment-17082476 ] Romain Manni-Bucau commented on MSHADE-307: --- [~elharo] first "agreed" step was to use defaults only when no custom transformer was set up. That said another pass was needed to ensure we can also have some merge strategy not requiring as much config as setting up all transformers (guess it was [https://github.com/apache/maven-shade-plugin/pull/11/files#diff-aad819f3f09a8e462cbca09c51bef146R762]). > Ensure some default transformers and filters are set up if none is configured > - > > Key: MSHADE-307 > URL: https://issues.apache.org/jira/browse/MSHADE-307 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > If no configuration for transformer (1) and filter (2) then these defaults > would be used > 1. services and manifest transformers added if not set by the user > 2. META-INF/*SF|DSA|RSA excluded in all jars -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-release] bguerin opened a new pull request #50: [MRELEASE-1042] - releaseProfiles get overriden by activeProfiles
bguerin opened a new pull request #50: [MRELEASE-1042] - releaseProfiles get overriden by activeProfiles URL: https://github.com/apache/maven-release/pull/50 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (MPLUGINTESTING-62) use maven API 3.6.0 and Plexus 2.0.0
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MPLUGINTESTING-62: Issue Type: Dependency upgrade (was: Improvement) > use maven API 3.6.0 and Plexus 2.0.0 > > > Key: MPLUGINTESTING-62 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-62 > Project: Maven Plugin Testing > Issue Type: Dependency upgrade >Reporter: Samael Bate >Priority: Major > > Along with updating to use Java 7 (MPLUGINTESTING-61) the plugin should use a > recent maven API. > As there is no 3.6.0 for maven-aether-provider it will need be set to 3.3.9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] famod commented on issue #310: [MNG-6843] - Parallel build fails due to missing JAR artifacts in compilePath
famod commented on issue #310: [MNG-6843] - Parallel build fails due to missing JAR artifacts in compilePath URL: https://github.com/apache/maven/pull/310#issuecomment-612982701 > This was added 10 years ago: [0ce5541#diff-2d99239b7db610b69d251224cdf93dc6R269-R277](https://github.com/apache/maven/commit/0ce5541bb5c92b87e2425efceee1aad53f415128#diff-2d99239b7db610b69d251224cdf93dc6R269-R277) > Ticket: [MNG-4795 "[regression] Dependencies in forked reactor projects are not resolved when aggregator bound to lifecycle forks"](https://issues.apache.org/jira/browse/MNG-4795) I need to correct myself: This is the first commit that added the filter handling: https://github.com/apache/maven/commit/d0d3f58fff0434dc2c3e708c411cd731c0b3bf65 Ticket: [MNG-4526 [regression] Shade plugin includes too much (relative to 2.2.1)](https://issues.apache.org/jira/browse/MNG-4526) This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (MCHANGELOG-151) Migrate plugin to Maven 3.0.5
[ https://issues.apache.org/jira/browse/MCHANGELOG-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MCHANGELOG-151: - Issue Type: Dependency upgrade (was: Improvement) > Migrate plugin to Maven 3.0.5 > - > > Key: MCHANGELOG-151 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-151 > Project: Maven Changelog Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Major > > * Replacing usage of deprecated APIs > * Renaming the packages to org.apache.maven.plugins > * Removing Maven 2 specific code > * Fixing Javadoc comments > * Removing the use of raw types where possible -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DOXIASITETOOLS-224) Update Plexus
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated DOXIASITETOOLS-224: - Issue Type: Dependency upgrade (was: Improvement) > Update Plexus > - > > Key: DOXIASITETOOLS-224 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-224 > Project: Maven Doxia Sitetools > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > > We have multiple versions of different plexus artifacts, all very old. E.g. > we pull in both > > > org.codehaus.plexus > plexus-container-default > 1.0-alpha-9 > > > and > > > org.codehaus.plexus > plexus-container-default > 1.0-alpha-30 > > > The current version is 2.1.0. Get these upgraded. Some code changes are > probably required. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-5987) Document the algorithm calculating the order of plugin executions.
[ https://issues.apache.org/jira/browse/MNG-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MNG-5987: --- Component/s: Documentation: General > Document the algorithm calculating the order of plugin executions. > -- > > Key: MNG-5987 > URL: https://issues.apache.org/jira/browse/MNG-5987 > Project: Maven > Issue Type: Improvement > Components: Documentation: General >Reporter: Christian Schulte >Priority: Critical > > Users continuously report issues regarding the order of plugin executions: > repeating that this order is not expected to be guaranteed inside a phase is > not convincing for them. > The algorithm used to calculate the order of executions performed by Maven > needs to be documented: > - declaration order in the POM > - inheritance merging from parent POM, > - merging of profiles and other plugin containers, > - the order of executions of multiple executions in the same lifecycle phase, > etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MENFORCER-267) Upgrade to make Maven 3+
[ https://issues.apache.org/jira/browse/MENFORCER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MENFORCER-267: Issue Type: Dependency upgrade (was: Improvement) > Upgrade to make Maven 3+ > > > Key: MENFORCER-267 > URL: https://issues.apache.org/jira/browse/MENFORCER-267 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0-M3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0 > > > * maven-dependency-tree needs to be updated to 3.0.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DOXIA-545) Mediawiki module
[
https://issues.apache.org/jira/browse/DOXIA-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated DOXIA-545:
Labels: intern (was: )
> Mediawiki module
>
>
> Key: DOXIA-545
> URL: https://issues.apache.org/jira/browse/DOXIA-545
> Project: Maven Doxia
> Issue Type: New Feature
>Affects Versions: 1.7
>Reporter: Alex Zbarcea
>Priority: Minor
> Labels: intern
>
> [Mediawiki|https://en.wikipedia.org/wiki/Help:Wiki_markup] is the most
> widespread wikitext language. There are many
> [MediaWiki|https://www.mediawiki.org/wiki/MediaWiki] instances that serve as
> knowledgebase.
> Allowing documentation to be written in {{Mediawiki}} syntax, would empower
> collaboration over documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-645) List classes in a given artifact
[
https://issues.apache.org/jira/browse/MDEP-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-645:
---
Labels: intern (was: )
> List classes in a given artifact
>
>
> Key: MDEP-645
> URL: https://issues.apache.org/jira/browse/MDEP-645
> Project: Maven Dependency Plugin
> Issue Type: New Feature
>Reporter: John Lin
>Priority: Minor
> Labels: intern
>
> When I want to list all the classes in a given artifact, I have to use
> {{jar}} command to show files in the corresponding .jar file.
> For example, I want to list all the classes in the artifact
> {code}
> org.apache.commons:commons-lang3:3.6
> {code}
> I have to run
> {code}
> jar tf
> ~/.m2/repository/org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar
> {code}
> This method has some disadvantages:
> # The jar file may not be downloaded, so it may not be in
> {{~/.m2/repository}}.
> # It's kind of tedious to type such a long filename.
> # The output is shown in raw filenames, e.g.,
> {{org/apache/commons/lang3/SystemUtils.class}}, but I generally want a
> package + class name {{org.apache.commons.lang3.SystemUtils}}.
> So I would expect a goal called {{show}} with an argument {{artifact}}, so I
> can type
> {code}
> mvn dependency:show -Dartifact=org.apache.commons:commons-lang3:3.6
> {code}
> to show
> {code}
> org.apache.commons.lang3.CharUtils
> org.apache.commons.lang3.RandomStringUtils
> ...
> {code}
> What do you guys think? Thanks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6556) Packaging 'maven-plugin' binding plugin upgrades
[ https://issues.apache.org/jira/browse/MNG-6556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082463#comment-17082463 ] Michael Osipov commented on MNG-6556: - MJAR 3.2.0 does not fail anymore. > Packaging 'maven-plugin' binding plugin upgrades > > > Key: MNG-6556 > URL: https://issues.apache.org/jira/browse/MNG-6556 > Project: Maven > Issue Type: Sub-task > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0-candidate > > Attachments: diff in mc.png > > > This affects: > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging]||target > version|| > |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| > |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| > |org.apache.maven.plugins|maven-plugin-plugin|3.2|3.6.0| > |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M4| > |org.apache.maven.plugins|maven-jar-plugin|2.4|3.2.0| > |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| > |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJAVADOC-625) Support for multiple stylesheets
[ https://issues.apache.org/jira/browse/MJAVADOC-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MJAVADOC-625: --- Labels: features intern newbie (was: features newbie) > Support for multiple stylesheets > > > Key: MJAVADOC-625 > URL: https://issues.apache.org/jira/browse/MJAVADOC-625 > Project: Maven Javadoc Plugin > Issue Type: New Feature >Affects Versions: 3.1.1 >Reporter: Martin Schelldorfer >Priority: Minor > Labels: features, intern, newbie > Time Spent: 10m > Remaining Estimate: 0h > > Support for multiple stylesheets in javadoc was added to OpenJDK 10 as > JDK-8189217 [1]. > > Add a new configuration parameter "addStylesheet" to Maven Javadoc Plugin. > This value should be passed as parameter "--add-stylesheet" to javadoc > command line. > > See Oracle javadoc documentation for details about "--add-stylesheet" > parameter [2]. > > [1] [https://bugs.openjdk.java.net/browse/JDK-8189217] > [2] > [https://docs.oracle.com/javase/10/tools/javadoc.htm#JSWOR-GUID-9D532574-1CDB-4D30-99F3-A308DCAEE55F] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCHECKSTYLE-91) Different checkstyle rules for main and test source
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MCHECKSTYLE-91: - Priority: Minor (was: Major) > Different checkstyle rules for main and test source > --- > > Key: MCHECKSTYLE-91 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-91 > Project: Maven Checkstyle Plugin > Issue Type: New Feature >Reporter: Ricky Hazelwood >Priority: Minor > Attachments: MCHECKSTYLE-91-2009-01-02-20-30-00.diff > > > It would be nice if the plugin can accept different configuration for test > source and produce separate reports for main and test code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJAVADOC-289) generate javadoc warnings report
[ https://issues.apache.org/jira/browse/MJAVADOC-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MJAVADOC-289: --- Labels: intern (was: ) > generate javadoc warnings report > > > Key: MJAVADOC-289 > URL: https://issues.apache.org/jira/browse/MJAVADOC-289 > Project: Maven Javadoc Plugin > Issue Type: New Feature >Reporter: Lukas Theussl >Priority: Major > Labels: intern > > A la m1, eg > http://maven.apache.org/maven-1.x/plugins/javadoc/javadoc-warnings-report.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MCLEAN-54) Support moving instead of deleting directories
[ https://issues.apache.org/jira/browse/MCLEAN-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MCLEAN-54. --- > Support moving instead of deleting directories > -- > > Key: MCLEAN-54 > URL: https://issues.apache.org/jira/browse/MCLEAN-54 > Project: Maven Clean Plugin > Issue Type: New Feature >Affects Versions: 2.5 >Reporter: Leandro de Oliveira >Priority: Major > Fix For: more-investigation > > Attachments: MCLEAN-54.patch > > > It'd be helpful if the plugin moved target directories to java.io.tmpdir > instead of delete them because directory deletion on Windows takes a lot of > time if there are many small files to delete. A less than ideal workaround is > described here: > http://bosy.dailydev.org/2009/02/speed-up-your-maven-build-four-times.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPLUGIN-349) Create a javadoc tags to Java5 annotations converter
[ https://issues.apache.org/jira/browse/MPLUGIN-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MPLUGIN-349: - Labels: intern (was: ) > Create a javadoc tags to Java5 annotations converter > > > Key: MPLUGIN-349 > URL: https://issues.apache.org/jira/browse/MPLUGIN-349 > Project: Maven Plugin Tools > Issue Type: New Feature > Components: Plugin Plugin >Reporter: QualiteSys QualiteSys >Priority: Major > Labels: intern > > I am working on source code CI tool chains. I would need to convert the old > Javadoc tags notation for @goal, @phase, etc to the Java5 annotation provided > since version 3.0 > ([https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html]) > Is it possible to create a special goal to manipulate the orginal source code > files and process the conversions ? > > Thanks for your help > Didier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MCLEAN-54) Support moving instead of deleting directories
[ https://issues.apache.org/jira/browse/MCLEAN-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MCLEAN-54. - Resolution: Won't Fix They have to be deleted some time. > Support moving instead of deleting directories > -- > > Key: MCLEAN-54 > URL: https://issues.apache.org/jira/browse/MCLEAN-54 > Project: Maven Clean Plugin > Issue Type: New Feature >Affects Versions: 2.5 >Reporter: Leandro de Oliveira >Priority: Major > Fix For: more-investigation > > Attachments: MCLEAN-54.patch > > > It'd be helpful if the plugin moved target directories to java.io.tmpdir > instead of delete them because directory deletion on Windows takes a lot of > time if there are many small files to delete. A less than ideal workaround is > described here: > http://bosy.dailydev.org/2009/02/speed-up-your-maven-build-four-times.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPLUGIN-349) Create a javadoc tags to Java5 annotations converter
[ https://issues.apache.org/jira/browse/MPLUGIN-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082461#comment-17082461 ] Sylwester Lachiewicz commented on MPLUGIN-349: -- We have lots of plugins, specially in ITs with old pre annotation javadoc tags. > Create a javadoc tags to Java5 annotations converter > > > Key: MPLUGIN-349 > URL: https://issues.apache.org/jira/browse/MPLUGIN-349 > Project: Maven Plugin Tools > Issue Type: New Feature > Components: Plugin Plugin >Reporter: QualiteSys QualiteSys >Priority: Major > > I am working on source code CI tool chains. I would need to convert the old > Javadoc tags notation for @goal, @phase, etc to the Java5 annotation provided > since version 3.0 > ([https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html]) > Is it possible to create a special goal to manipulate the orginal source code > files and process the conversions ? > > Thanks for your help > Didier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-5661) Make MavenProject instances immutable after initial construction
[ https://issues.apache.org/jira/browse/MNG-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MNG-5661: --- Issue Type: Improvement (was: New Feature) > Make MavenProject instances immutable after initial construction > > > Key: MNG-5661 > URL: https://issues.apache.org/jira/browse/MNG-5661 > Project: Maven > Issue Type: Improvement >Reporter: Jason van Zyl >Priority: Major > Attachments: Maven-Reactor-Dump.png > > > When a MavenProject is initially constructed it is not immutable and > requires subsequent mutation to be complete in different circumstance. This > makes the logic in MavenProject complex and makes MavenProject hard to > understand. We need to move toward being complete and immutable after > construction. > This not being the case has a number of consequences two of which are: > 1) Components are required in MavenProject in order to lazily construct > certain values. This complicates MavenProject when it simply should be a > configuration, or data. The logic to construct anything should be moved to > the ProjectBuilder, take the small hit in performance, and all construction > should happen up-front. > 2) The lifecycle needs to be executed in order for a MavenProject instance to > be fully populated with respect to source directories and project resources. > This makes it particularly hard for systems like IDEs to integrate without > resorting to weird tricks to figure out generated source directories without > executing Maven itself. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (MPLUGIN-349) Create a javadoc tags to Java5 annotations converter
[ https://issues.apache.org/jira/browse/MPLUGIN-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reopened MPLUGIN-349: -- > Create a javadoc tags to Java5 annotations converter > > > Key: MPLUGIN-349 > URL: https://issues.apache.org/jira/browse/MPLUGIN-349 > Project: Maven Plugin Tools > Issue Type: New Feature > Components: Plugin Plugin >Reporter: QualiteSys QualiteSys >Priority: Major > > I am working on source code CI tool chains. I would need to convert the old > Javadoc tags notation for @goal, @phase, etc to the Java5 annotation provided > since version 3.0 > ([https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html]) > Is it possible to create a special goal to manipulate the orginal source code > files and process the conversions ? > > Thanks for your help > Didier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRELEASE-1042) releaseProfiles get overriden by activeProfiles
[
https://issues.apache.org/jira/browse/MRELEASE-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082460#comment-17082460
]
Benoit GUERIN commented on MRELEASE-1042:
-
{quote}Thus when the release.properties is generated we are supposed to add the
"releaseProfiles" but "getAdditionalProfiles()" returns null in the prepare
Mojo (it's only implemented in perform) thus we completely lost the info
{quote}
Yep, but the release descriptor is reconstructed from scratch on perform :
[https://github.com/apache/maven-release/blob/master/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PerformReleaseMojo.java#L170]
and the perform goals has the correct overload to append additional profiles :
[https://github.com/apache/maven-release/blob/master/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PerformReleaseMojo.java#L140]
BUT this descriptor is then passed to the ReleaseManager, through the request
argument :
[https://github.com/apache/maven-release/blob/master/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PerformReleaseMojo.java#L195]
which merge it with the properties from the temporary release.properties file :
[https://github.com/apache/maven-release/blob/master/maven-release-manager/src/main/java/org/apache/maven/shared/release/DefaultReleaseManager.java#L303]
[https://github.com/apache/maven-release/blob/master/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/PropertiesReleaseDescriptorStore.java#L78]
in this method you will see that :
# we load properties from the release.properties file (2nd arg)
# we reuse the descriptorBuilder passed from the perform MOJO
# we override existing values in the builder which values from the properties.
This IS WHERE we lost additional profiles.
I think we should change (again) how
ReleaseUtils.copyPropertiesToReleaseDescriptor handle activateProfiles :
[https://github.com/apache/maven-release/blob/master/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java#L132]
and do a merge between existing values if any and those from properties
> releaseProfiles get overriden by activeProfiles
> ---
>
> Key: MRELEASE-1042
> URL: https://issues.apache.org/jira/browse/MRELEASE-1042
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M2
>Reporter: Arnaud Heritier
>Assignee: Robert Scholte
>Priority: Major
>
> I tried to release a project with 3.0.0-M2 and potentially it is another
> problem related to MRELEASE-1038 [~rfscholte] [~olamy]
>
> In our corporate POM we have a pluginManagement entry:
> {code:java}
>
> maven-release-plugin
> 2.5.3
>
> forked-path
> false
> cloudbees-internal-release
>
>
> {code}
> My project extends it and has no settings related to the release plugin
> In my user settings I have
> {code:java}
>
> cloudbees-internal-deploy
> cloudbees-snapshots
> apache-staging
>
> {code}
> Then I release my project using 3.0.0-M2 with
> {code:java}
> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:prepare
> org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform
> {code}
> The perform step is taking my user profiles but not the ones from
> "releaseProfiles"
> {noformat}
> [INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
> /Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
> /var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings4094445863857985100.xml
> -f pom.xml deploy -P
> cloudbees-internal-deploy,cloudbees-snapshots,apache-staging -f
> pom.xml{noformat}
> Not sure if it could be because I call the release plugin with the full GAV
> but it is strange ...
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MPDF-81) Override the copyright footer
[ https://issues.apache.org/jira/browse/MPDF-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MPDF-81: -- Labels: intern (was: ) > Override the copyright footer > - > > Key: MPDF-81 > URL: https://issues.apache.org/jira/browse/MPDF-81 > Project: Maven PDF Plugin > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Alex O'Ree >Priority: Major > Labels: intern > Fix For: 1.5.0 > > Attachments: maven-pdf-plugin2.pdf > > > As of right now, it doesn't look possible to override the content of the > footer which is on all non-title page pages. It currently reads (c) year - > organization All rights reserved. > I don't see anywhere in the code where this is defined or in any of the > resource files. It is in the generated fo files but it's not obvious where > the xslt is. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHADE-268) improving inclusion of open source code referenced by java projects.
[ https://issues.apache.org/jira/browse/MSHADE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHADE-268. > improving inclusion of open source code referenced by java projects. > - > > Key: MSHADE-268 > URL: https://issues.apache.org/jira/browse/MSHADE-268 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Sunil Kumar Singh >Priority: Major > Fix For: waiting-for-feedback > > > All the details are on git hub at: > https://github.com/ksunilsingh/code-collector > This is an idea on improving inclusion of open source code referenced by java > projects. Currently when we use a java build system (such as maven or > gradle), the build system downloads the jar files referenced by a java > project. What I am proposing here is a replacement for that: > Find out all the classes referenced by the classes in a java project (say, > project A). > Download the source code for these dependencies recursively and include the > downloaded source code in the source tree of project A. > Remove the dependency(ies) from project build configuration file (e.g. > pom.xml) and build the project. > The resulting jar file would be smaller in size than if the full jar for the > dependency is included as is. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MSHADE-268) improving inclusion of open source code referenced by java projects.
[ https://issues.apache.org/jira/browse/MSHADE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHADE-268. -- Resolution: Not A Problem > improving inclusion of open source code referenced by java projects. > - > > Key: MSHADE-268 > URL: https://issues.apache.org/jira/browse/MSHADE-268 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Sunil Kumar Singh >Priority: Major > Fix For: waiting-for-feedback > > > All the details are on git hub at: > https://github.com/ksunilsingh/code-collector > This is an idea on improving inclusion of open source code referenced by java > projects. Currently when we use a java build system (such as maven or > gradle), the build system downloads the jar files referenced by a java > project. What I am proposing here is a replacement for that: > Find out all the classes referenced by the classes in a java project (say, > project A). > Download the source code for these dependencies recursively and include the > downloaded source code in the source tree of project A. > Remove the dependency(ies) from project build configuration file (e.g. > pom.xml) and build the project. > The resulting jar file would be smaller in size than if the full jar for the > dependency is included as is. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJLINK-9) Add support for multi module projects
[
https://issues.apache.org/jira/browse/MJLINK-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MJLINK-9:
---
Labels: intern multimodule (was: )
> Add support for multi module projects
> -
>
> Key: MJLINK-9
> URL: https://issues.apache.org/jira/browse/MJLINK-9
> Project: Maven JLink Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0-alpha-1
>Reporter: Vladimir Tsanev
>Priority: Major
> Labels: intern, multimodule
>
> I would like to have a multi module project something like
> {code:java}
> parent
> lib
> pom.xml
> app
> pom.xml
> dist
> pom.xml{code}
> where app is my application module that depends on a lib module and dist is a
> jlink module that depends on app.
>
> Currently I see a NPE because it cannot find app's jar. Seems like jars from
> reactor are not resolved
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project dist: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project dist: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> 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:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:564)
> 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.PluginExecutionException: Execution
> default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:145)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> 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:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at
[jira] [Updated] (DOXIA-569) add Markdown Sink, to be able to convert anything to Markdown
[ https://issues.apache.org/jira/browse/DOXIA-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated DOXIA-569: Labels: intern (was: ) > add Markdown Sink, to be able to convert anything to Markdown > - > > Key: DOXIA-569 > URL: https://issues.apache.org/jira/browse/DOXIA-569 > Project: Maven Doxia > Issue Type: New Feature > Components: Module - Markdown >Affects Versions: 1.8 >Reporter: Herve Boutemy >Priority: Major > Labels: intern > > Markdown is well known: having Markdown Sink would help people transform > existing content to Markdown -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6351) Version range resolution for build plugins
[ https://issues.apache.org/jira/browse/MNG-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082452#comment-17082452 ] Elliotte Rusty Harold commented on MNG-6351: Version ranges are a real problem. I'd be more inclined to remove them from dependencies than add them to plugins. But, yes, we could update the docs here. > Version range resolution for build plugins > -- > > Key: MNG-6351 > URL: https://issues.apache.org/jira/browse/MNG-6351 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.5.2 > Environment: Windows 10 >Reporter: Max S. >Priority: Minor > Labels: documentation, features, maven, patch > > Hi, > Maven's version range resolution does not work for build plugins, but for > dependencies. Why? Our build process is depending on these plugins. Now we > want to include Minor-Version-Bugfixes into our on these dependent > applications. But somehow the previously so easy used version ranges for > dependencies do not work for plugins. Why? Why you repeat yourself by not > using the same code-basis for the same problem? There is also no way to > resolve a version from a given version range string for a given artifact in > the whole Maven API. Why? If it's so, why is that with the > plugin-not-able-to-resolve-version-ranges not CLEARLY stated in the > documentation? This very bad.. > What to do now? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6351) Version range resolution for build plugins
[ https://issues.apache.org/jira/browse/MNG-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MNG-6351: --- Priority: Minor (was: Major) > Version range resolution for build plugins > -- > > Key: MNG-6351 > URL: https://issues.apache.org/jira/browse/MNG-6351 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.5.2 > Environment: Windows 10 >Reporter: Max S. >Priority: Minor > Labels: documentation, features, maven, patch > > Hi, > Maven's version range resolution does not work for build plugins, but for > dependencies. Why? Our build process is depending on these plugins. Now we > want to include Minor-Version-Bugfixes into our on these dependent > applications. But somehow the previously so easy used version ranges for > dependencies do not work for plugins. Why? Why you repeat yourself by not > using the same code-basis for the same problem? There is also no way to > resolve a version from a given version range string for a given artifact in > the whole Maven API. Why? If it's so, why is that with the > plugin-not-able-to-resolve-version-ranges not CLEARLY stated in the > documentation? This very bad.. > What to do now? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6351) Version range resolution for build plugins
[ https://issues.apache.org/jira/browse/MNG-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MNG-6351: --- Issue Type: Improvement (was: New Feature) > Version range resolution for build plugins > -- > > Key: MNG-6351 > URL: https://issues.apache.org/jira/browse/MNG-6351 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.5.2 > Environment: Windows 10 >Reporter: Max S. >Priority: Major > Labels: documentation, features, maven, patch > > Hi, > Maven's version range resolution does not work for build plugins, but for > dependencies. Why? Our build process is depending on these plugins. Now we > want to include Minor-Version-Bugfixes into our on these dependent > applications. But somehow the previously so easy used version ranges for > dependencies do not work for plugins. Why? Why you repeat yourself by not > using the same code-basis for the same problem? There is also no way to > resolve a version from a given version range string for a given artifact in > the whole Maven API. Why? If it's so, why is that with the > plugin-not-able-to-resolve-version-ranges not CLEARLY stated in the > documentation? This very bad.. > What to do now? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSOURCES-113) Store source encoding info in a standard file
[ https://issues.apache.org/jira/browse/MSOURCES-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082451#comment-17082451 ] Elliotte Rusty Harold commented on MSOURCES-113: Would it make sense for Maven to always write sources in UTF-8? > Store source encoding info in a standard file > - > > Key: MSOURCES-113 > URL: https://issues.apache.org/jira/browse/MSOURCES-113 > Project: Maven Source Plugin > Issue Type: New Feature >Reporter: Fred Bricon >Assignee: Karl Heinz Marbaise >Priority: Major > Labels: intern > Fix For: next-release > > > It'd be nice if IDEs were able to automatically set proper source encoding > when attaching sources to project dependencies. > In eclipse/m2e, we tried to automatically detect encoding but it didn't work > out [https://git.eclipse.org/r/#/c/116390/] > A more reliable way would be to ensure the encoding info was stored inside > the source archive, so that IDEs could peek into it and ensure proper > settings. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSOURCES-113) Store source encoding info in a standard file
[ https://issues.apache.org/jira/browse/MSOURCES-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSOURCES-113: --- Labels: intern (was: ) > Store source encoding info in a standard file > - > > Key: MSOURCES-113 > URL: https://issues.apache.org/jira/browse/MSOURCES-113 > Project: Maven Source Plugin > Issue Type: New Feature >Reporter: Fred Bricon >Assignee: Karl Heinz Marbaise >Priority: Major > Labels: intern > Fix For: next-release > > > It'd be nice if IDEs were able to automatically set proper source encoding > when attaching sources to project dependencies. > In eclipse/m2e, we tried to automatically detect encoding but it didn't work > out [https://git.eclipse.org/r/#/c/116390/] > A more reliable way would be to ensure the encoding info was stored inside > the source archive, so that IDEs could peek into it and ensure proper > settings. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5640) AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases
[
https://issues.apache.org/jira/browse/MNG-5640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082450#comment-17082450
]
Hudson commented on MNG-5640:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #41
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/41/
> AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases
> --
>
> Key: MNG-5640
> URL: https://issues.apache.org/jira/browse/MNG-5640
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.2.1
>Reporter: Tamás Cservenák
>Assignee: Jason van Zyl
>Priority: Major
> Fix For: 3.2.2
>
> Attachments: aftersessionend.zip
>
>
> It seems that {{AbstractMavenLifecycleParticipant#afterSessionEnd}} is not
> invoked in some cases, at least one case for sure: when the build fails.
> Reproduce case:
> 1. unzip the attached project
> 2. build it but skip tests {{mvn clean install -Dtest=void
> -DfailIfNoTests=false}}
> 3. install the resulting jar in /lib/ext of your Maven 3.2.1
> 4. with JAR installed in Maven, build it again with skipped tests
> 5. verify console output (both {{afterProjectsRead OK}} and {{afterSessionEnd
> OK}} are printed on console)
> 6. with JAR installed in Maven, build it again with tests (there is one UT
> that always fails).
> 6. console output contains only {{afterProjectsRead OK}}, but afterSessionEnd
> method is NOT invoked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6579) Externalize org.apache.maven.repository.internal.MavenRepositorySystemUtils
[ https://issues.apache.org/jira/browse/MNG-6579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MNG-6579: --- Labels: intern (was: ) > Externalize org.apache.maven.repository.internal.MavenRepositorySystemUtils > --- > > Key: MNG-6579 > URL: https://issues.apache.org/jira/browse/MNG-6579 > Project: Maven > Issue Type: New Feature >Reporter: Elliotte Rusty Harold >Priority: Major > Labels: intern > Fix For: 3.x / Backlog > > > org.apache.maven.repository.internal.MavenRepositorySystemUtils is > essentially mandatory for using the resolver. Without it you can't create a > RepositorySystem, a ServiceLocator, or a RepositorySystemSession; all of > which are needed before you can resolve an artifact. > This functionality should be available in a non-internal package. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6454) Introduce option to allow non-pom packaging types to also support the modules-tag
[
https://issues.apache.org/jira/browse/MNG-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082447#comment-17082447
]
Elliotte Rusty Harold commented on MNG-6454:
I suspect we need a full proposal for multi-release jar handling first.
> Introduce option to allow non-pom packaging types to also support the
> modules-tag
> -
>
> Key: MNG-6454
> URL: https://issues.apache.org/jira/browse/MNG-6454
> Project: Maven
> Issue Type: New Feature
>Reporter: Robert Scholte
>Priority: Major
> Labels: intern, multirelease
>
> While working on the multirelease jars I noticed we're missing a feature in
> Maven. At JCrete after talking with [~sanne] he had a similar request for a
> different reason. In his case it is about having a jar where all Drivers are
> optional, so developers only have to add this jar. However, it would be great
> it code could be isolated per Driver.
> The idea is to allow packaging:jar to specify modules in the pom. These
> submodules follow the normal lifecycle, but are never installed or deployed.
> Instead the root-project will embed these files in the main jar.
> To support this, Maven first of all recognize if modules are allowed for a
> specific packaging type. The
> {{org.apache.maven.artifact.handler.ArtifactHandler}} looks close, but that
> should be about artifacts (dependencies). So most likely we need a new
> ProjectHandler here.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6454) Introduce option to allow non-pom packaging types to also support the modules-tag
[
https://issues.apache.org/jira/browse/MNG-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MNG-6454:
---
Labels: intern multirelease (was: )
> Introduce option to allow non-pom packaging types to also support the
> modules-tag
> -
>
> Key: MNG-6454
> URL: https://issues.apache.org/jira/browse/MNG-6454
> Project: Maven
> Issue Type: New Feature
>Reporter: Robert Scholte
>Priority: Major
> Labels: intern, multirelease
>
> While working on the multirelease jars I noticed we're missing a feature in
> Maven. At JCrete after talking with [~sanne] he had a similar request for a
> different reason. In his case it is about having a jar where all Drivers are
> optional, so developers only have to add this jar. However, it would be great
> it code could be isolated per Driver.
> The idea is to allow packaging:jar to specify modules in the pom. These
> submodules follow the normal lifecycle, but are never installed or deployed.
> Instead the root-project will embed these files in the main jar.
> To support this, Maven first of all recognize if modules are allowed for a
> specific packaging type. The
> {{org.apache.maven.artifact.handler.ArtifactHandler}} looks close, but that
> should be about artifacts (dependencies). So most likely we need a new
> ProjectHandler here.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MASSEMBLY-895) Use a Custom 'xar' Format for the Maven Assembly
[ https://issues.apache.org/jira/browse/MASSEMBLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MASSEMBLY-895. - Resolution: Information Provided > Use a Custom 'xar' Format for the Maven Assembly > > > Key: MASSEMBLY-895 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-895 > Project: Maven Assembly Plugin > Issue Type: New Feature > Components: maven-archiver >Affects Versions: 3.1.0 >Reporter: ocean >Priority: Major > > We would like to use the Maven Assembly plugin to generate a custom format. > The format is called 'xar' (see > [https://en.wikipedia.org/wiki/Xar_(archiver)] for more details). > We would like to additionally add the ability to cryptographically sign > generated Xar archives. > There's a library also called 'xar' that makes it easy to generate and > cryptographically sign Xar archives from Java. (see > [https://github.com/gino0631/xar).] > The challenge now is just figuring out how to wire this up into the assembly > plugin so that people can specify 'xar' and also provide > signing keys and the assembly plugin will produce a single '.xar' file. > > Can anybody point us in the right direction? Where might we find the code for > an existing format? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MASSEMBLY-895) Use a Custom 'xar' Format for the Maven Assembly
[ https://issues.apache.org/jira/browse/MASSEMBLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MASSEMBLY-895. --- > Use a Custom 'xar' Format for the Maven Assembly > > > Key: MASSEMBLY-895 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-895 > Project: Maven Assembly Plugin > Issue Type: New Feature > Components: maven-archiver >Affects Versions: 3.1.0 >Reporter: ocean >Priority: Major > > We would like to use the Maven Assembly plugin to generate a custom format. > The format is called 'xar' (see > [https://en.wikipedia.org/wiki/Xar_(archiver)] for more details). > We would like to additionally add the ability to cryptographically sign > generated Xar archives. > There's a library also called 'xar' that makes it easy to generate and > cryptographically sign Xar archives from Java. (see > [https://github.com/gino0631/xar).] > The challenge now is just figuring out how to wire this up into the assembly > plugin so that people can specify 'xar' and also provide > signing keys and the assembly plugin will produce a single '.xar' file. > > Can anybody point us in the right direction? Where might we find the code for > an existing format? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-895) Use a Custom 'xar' Format for the Maven Assembly
[ https://issues.apache.org/jira/browse/MASSEMBLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082446#comment-17082446 ] Elliotte Rusty Harold commented on MASSEMBLY-895: - Please ask on the users or dev mailing list. > Use a Custom 'xar' Format for the Maven Assembly > > > Key: MASSEMBLY-895 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-895 > Project: Maven Assembly Plugin > Issue Type: New Feature > Components: maven-archiver >Affects Versions: 3.1.0 >Reporter: ocean >Priority: Major > > We would like to use the Maven Assembly plugin to generate a custom format. > The format is called 'xar' (see > [https://en.wikipedia.org/wiki/Xar_(archiver)] for more details). > We would like to additionally add the ability to cryptographically sign > generated Xar archives. > There's a library also called 'xar' that makes it easy to generate and > cryptographically sign Xar archives from Java. (see > [https://github.com/gino0631/xar).] > The challenge now is just figuring out how to wire this up into the assembly > plugin so that people can specify 'xar' and also provide > signing keys and the assembly plugin will produce a single '.xar' file. > > Can anybody point us in the right direction? Where might we find the code for > an existing format? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MSHADE-307) Ensure some default transformers and filters are set up if none is configured
[ https://issues.apache.org/jira/browse/MSHADE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHADE-307. -- Resolution: Won't Fix Possible. The tricky question here is what if someone adds a different transformer? Are the default transformers removed? Is that what's expected? If not, then how are they removed? I'm going to close this absent a more complete proposal with consensus from the maintainers. > Ensure some default transformers and filters are set up if none is configured > - > > Key: MSHADE-307 > URL: https://issues.apache.org/jira/browse/MSHADE-307 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > If no configuration for transformer (1) and filter (2) then these defaults > would be used > 1. services and manifest transformers added if not set by the user > 2. META-INF/*SF|DSA|RSA excluded in all jars -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHADE-307) Ensure some default transformers and filters are set up if none is configured
[ https://issues.apache.org/jira/browse/MSHADE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHADE-307. > Ensure some default transformers and filters are set up if none is configured > - > > Key: MSHADE-307 > URL: https://issues.apache.org/jira/browse/MSHADE-307 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > If no configuration for transformer (1) and filter (2) then these defaults > would be used > 1. services and manifest transformers added if not set by the user > 2. META-INF/*SF|DSA|RSA excluded in all jars -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MPLUGIN-349) Create a javadoc tags to Java5 annotations converter
[ https://issues.apache.org/jira/browse/MPLUGIN-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MPLUGIN-349. --- Resolution: Workaround We're focusing on Maven 4 now and not supporting pre 3.0 features. > Create a javadoc tags to Java5 annotations converter > > > Key: MPLUGIN-349 > URL: https://issues.apache.org/jira/browse/MPLUGIN-349 > Project: Maven Plugin Tools > Issue Type: New Feature > Components: Plugin Plugin >Reporter: QualiteSys QualiteSys >Priority: Major > > I am working on source code CI tool chains. I would need to convert the old > Javadoc tags notation for @goal, @phase, etc to the Java5 annotation provided > since version 3.0 > ([https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html]) > Is it possible to create a special goal to manipulate the orginal source code > files and process the conversions ? > > Thanks for your help > Didier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MPLUGIN-349) Create a javadoc tags to Java5 annotations converter
[ https://issues.apache.org/jira/browse/MPLUGIN-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MPLUGIN-349. - > Create a javadoc tags to Java5 annotations converter > > > Key: MPLUGIN-349 > URL: https://issues.apache.org/jira/browse/MPLUGIN-349 > Project: Maven Plugin Tools > Issue Type: New Feature > Components: Plugin Plugin >Reporter: QualiteSys QualiteSys >Priority: Major > > I am working on source code CI tool chains. I would need to convert the old > Javadoc tags notation for @goal, @phase, etc to the Java5 annotation provided > since version 3.0 > ([https://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html]) > Is it possible to create a special goal to manipulate the orginal source code > files and process the conversions ? > > Thanks for your help > Didier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5640) AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases
[
https://issues.apache.org/jira/browse/MNG-5640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082424#comment-17082424
]
Hudson commented on MNG-5640:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6169/MNG-6553 #36
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/36/
> AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases
> --
>
> Key: MNG-5640
> URL: https://issues.apache.org/jira/browse/MNG-5640
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.2.1
>Reporter: Tamás Cservenák
>Assignee: Jason van Zyl
>Priority: Major
> Fix For: 3.2.2
>
> Attachments: aftersessionend.zip
>
>
> It seems that {{AbstractMavenLifecycleParticipant#afterSessionEnd}} is not
> invoked in some cases, at least one case for sure: when the build fails.
> Reproduce case:
> 1. unzip the attached project
> 2. build it but skip tests {{mvn clean install -Dtest=void
> -DfailIfNoTests=false}}
> 3. install the resulting jar in /lib/ext of your Maven 3.2.1
> 4. with JAR installed in Maven, build it again with skipped tests
> 5. verify console output (both {{afterProjectsRead OK}} and {{afterSessionEnd
> OK}} are printed on console)
> 6. with JAR installed in Maven, build it again with tests (there is one UT
> that always fails).
> 6. console output contains only {{afterProjectsRead OK}}, but afterSessionEnd
> method is NOT invoked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MENFORCER-325) Add binary compatibility check to dependencyConvergence rule
[ https://issues.apache.org/jira/browse/MENFORCER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MENFORCER-325. --- > Add binary compatibility check to dependencyConvergence rule > > > Key: MENFORCER-325 > URL: https://issues.apache.org/jira/browse/MENFORCER-325 > Project: Maven Enforcer Plugin > Issue Type: New Feature >Reporter: Marquis Wang >Priority: Major > > The dependencyConvergence rule is too strict to use in practice most of the > time. If you have a project with even a medium number of dependencies, they > are pretty much guaranteed to have transitive dependencies that do not > converge. > For some very common dependencies like Guava, the maintainers of the project > are very careful to maintain binary compatibility with new releases. For > these dependencies, a dependency divergence is okay if the included node is > binary compatible with all of the diverging nodes. > For example, if you have two dependencies, one if which depends on Guava 27 > and the other depends on Guava 26, you can safely run with Guava 27 because > you know that it is compatible with 26. > It would be really helpful if the dependencyConvergence rule were able to > check for binary compatibility and take it into account. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MENFORCER-325) Add binary compatibility check to dependencyConvergence rule
[ https://issues.apache.org/jira/browse/MENFORCER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MENFORCER-325. - Resolution: Won't Fix That would weaken dependencyConvergence considerably but do see [https://github.com/GoogleCloudPlatform/cloud-opensource-java/wiki/Linkage-Checker-Enforcer-Rule-Tutorial] which I think does what you want. > Add binary compatibility check to dependencyConvergence rule > > > Key: MENFORCER-325 > URL: https://issues.apache.org/jira/browse/MENFORCER-325 > Project: Maven Enforcer Plugin > Issue Type: New Feature >Reporter: Marquis Wang >Priority: Major > > The dependencyConvergence rule is too strict to use in practice most of the > time. If you have a project with even a medium number of dependencies, they > are pretty much guaranteed to have transitive dependencies that do not > converge. > For some very common dependencies like Guava, the maintainers of the project > are very careful to maintain binary compatibility with new releases. For > these dependencies, a dependency divergence is okay if the included node is > binary compatible with all of the diverging nodes. > For example, if you have two dependencies, one if which depends on Guava 27 > and the other depends on Guava 26, you can safely run with Guava 27 because > you know that it is compatible with 26. > It would be really helpful if the dependencyConvergence rule were able to > check for binary compatibility and take it into account. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1638) untilFailureLoopCount property to run tests until failure
[
https://issues.apache.org/jira/browse/SUREFIRE-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082420#comment-17082420
]
Elliotte Rusty Harold commented on SUREFIRE-1638:
-
It's a useful idea, though the name could be much better. Perhaps retryCount?
> untilFailureLoopCount property to run tests until failure
> -
>
> Key: SUREFIRE-1638
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1638
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Galder Zamarreño
>Priority: Major
>
> This is a proposal to add surefire/failsafe property called
> `untilFailureLoopCount`.
> I often find myself in the situation where there's a random test failure
> happening in CI, and have to run the one or several tests continuously until
> it fails, maybe running them with TRACE logging.
> Normally, I'd wrap the `mvn test...` call with a script that calls it in a
> loop, but this can be quite "slow" since each iteration is a new JVM
> launch...etc.
> The idea behind `untilFailureLoopCount` is that you've give it a positive
> number, say 1000, and the test(s) would run continuously until either a
> failure happens or the test is executed that many times.
> I've created [this randomly failing
> test](https://github.com/galderz/surefire-until-failure-loop-count/blob/master/src/test/java/com/acme/maven/surefire/untilfailure/UntilFailureLoopCountTest.java)
> and I've run it with `mvn -Dsurefire.untilFailureLoopCount=10 test` and the
> output would be something like:
> {code}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034
> s - in com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Running com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001
> s - in com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Running com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s -
> in com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Running com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s -
> in com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [INFO] Running com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.001
> s <<< FAILURE! - in
> com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest
> [ERROR]
> com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest.testEventualFailure
> Time elapsed: 0.001 s <<< FAILURE!
> java.lang.AssertionError: Just messing with your testing
> at
> com.acme.maven.surefire.untilfailure.UntilFailureLoopCountTest.testEventualFailure(UntilFailureLoopCountTest.java:16)
> {code}
> If maintainers are interested in this, I can complete the PR with tests,
> documentation and support for other providers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-801) Add functionality to collect raw dependencies in Maven 3+
[ https://issues.apache.org/jira/browse/MSHARED-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082421#comment-17082421 ] Elliotte Rusty Harold commented on MSHARED-801: --- What do you mean by raw dependencies? > Add functionality to collect raw dependencies in Maven 3+ > - > > Key: MSHARED-801 > URL: https://issues.apache.org/jira/browse/MSHARED-801 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-artifact-transfer >Affects Versions: maven-artifact-transfer-0.11.0 >Reporter: Gabriel Belingueres >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add funcionality allowing to collect raw project dependencies. > This can be used to implement dependencyConvergence and requireUpperBoundDeps > enforcer rules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHARED-801) Add functionality to collect raw dependencies in Maven 3+
[ https://issues.apache.org/jira/browse/MSHARED-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHARED-801: -- Labels: intern (was: ) > Add functionality to collect raw dependencies in Maven 3+ > - > > Key: MSHARED-801 > URL: https://issues.apache.org/jira/browse/MSHARED-801 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-artifact-transfer >Affects Versions: maven-artifact-transfer-0.11.0 >Reporter: Gabriel Belingueres >Priority: Major > Labels: intern > Time Spent: 10m > Remaining Estimate: 0h > > Add funcionality allowing to collect raw project dependencies. > This can be used to implement dependencyConvergence and requireUpperBoundDeps > enforcer rules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MDEPLOY-252) Deploy current archive without creating new archive (jar, war, ear)
[ https://issues.apache.org/jira/browse/MDEPLOY-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MDEPLOY-252. - > Deploy current archive without creating new archive (jar, war, ear) > --- > > Key: MDEPLOY-252 > URL: https://issues.apache.org/jira/browse/MDEPLOY-252 > Project: Maven Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.8.2 >Reporter: Ivica Mikic >Priority: Major > Labels: features, maven > Fix For: waiting-for-feedback > > > It would be great to be able to deploy current archive file (jar, war, ear) > without creating a new one, to preserve timestamp from previous package or > install run. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MDEPLOY-252) Deploy current archive without creating new archive (jar, war, ear)
[ https://issues.apache.org/jira/browse/MDEPLOY-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MDEPLOY-252. --- Resolution: Won't Fix project.buildTimestamp addresses this need in a different and more reproducible way > Deploy current archive without creating new archive (jar, war, ear) > --- > > Key: MDEPLOY-252 > URL: https://issues.apache.org/jira/browse/MDEPLOY-252 > Project: Maven Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.8.2 >Reporter: Ivica Mikic >Priority: Major > Labels: features, maven > Fix For: waiting-for-feedback > > > It would be great to be able to deploy current archive file (jar, war, ear) > without creating a new one, to preserve timestamp from previous package or > install run. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-644) Reintroduce the verbose option for dependency:tree
[ https://issues.apache.org/jira/browse/MDEP-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-644: --- Labels: intern (was: ) > Reintroduce the verbose option for dependency:tree > -- > > Key: MDEP-644 > URL: https://issues.apache.org/jira/browse/MDEP-644 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: John Lin >Priority: Major > Labels: intern > > The verbose option for dependency:tree is removed in maven-dependency-plugin > 3.0. This issue is to reintroduce the option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5640) AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases
[
https://issues.apache.org/jira/browse/MNG-5640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082417#comment-17082417
]
Hudson commented on MNG-5640:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #36
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/36/
> AbstractMavenLifecycleParticipant#afterSessionEnd is not invoked in some cases
> --
>
> Key: MNG-5640
> URL: https://issues.apache.org/jira/browse/MNG-5640
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.2.1
>Reporter: Tamás Cservenák
>Assignee: Jason van Zyl
>Priority: Major
> Fix For: 3.2.2
>
> Attachments: aftersessionend.zip
>
>
> It seems that {{AbstractMavenLifecycleParticipant#afterSessionEnd}} is not
> invoked in some cases, at least one case for sure: when the build fails.
> Reproduce case:
> 1. unzip the attached project
> 2. build it but skip tests {{mvn clean install -Dtest=void
> -DfailIfNoTests=false}}
> 3. install the resulting jar in /lib/ext of your Maven 3.2.1
> 4. with JAR installed in Maven, build it again with skipped tests
> 5. verify console output (both {{afterProjectsRead OK}} and {{afterSessionEnd
> OK}} are printed on console)
> 6. with JAR installed in Maven, build it again with tests (there is one UT
> that always fails).
> 6. console output contains only {{afterProjectsRead OK}}, but afterSessionEnd
> method is NOT invoked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6654) Resolve version ranges to the lower inclusive bound
[ https://issues.apache.org/jira/browse/MNG-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MNG-6654. -- > Resolve version ranges to the lower inclusive bound > --- > > Key: MNG-6654 > URL: https://issues.apache.org/jira/browse/MNG-6654 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Affects Versions: 3.6.0 >Reporter: Koritako Alana >Priority: Major > > Version ranges result in non-repeatable builds because, and only because, > Maven chooses the greatest version within the range. > If we instead choose the lower inclusive bound of the range, then the build > will always be the same. > eg. [1.2.0,2.0.0.min) > Resolving to lower inclusive bound means taking 1.2.0 here. Always. Even > after 1.3.0 is released. > Taking the lower inclusive bound means there are no holes that can later be > filled in, resulting in non-repeatable builds. eg. If we took the lowest > existing version in the range, then there would be a possibility of someone > later adding a lower version. Taking the lower inclusive bound requires the > lower inclusive bound to exist from day 1. > Version ranges are actually for defining compatibility ranges. Conceptually, > there are 2 version numbers: the version you compile against and the version > range your code is compatible with. Even if you declare a version range, > javac only ever compiles against 1 specific version. > For repeatable builds, you want the version number you compile against to be > the same. However, you also want to be able to declare a range of dependency > versions with which your library is compatible. As Maven is now, you can't > have both. By resolving version ranges to the lower inclusive bound, we can. > This should be obvious, but to be clear: If I am writing a library liba which > depends on library libb with range [1.2.0,2.0.0.min) and someone writes an > app including my library liba, then the app should get version 1.2.0 of libb. > The app is free to declare a direct dependency on version 1.3.0 or 1.8.5 etc > of libb, any version that falls into the range [1.2.0,2.0.0.min). If the app > declares a direct dependency on version 2.2.0 of libb, Maven should report a > dependency resolution error like it currently does. > But not all version ranges have a lower inclusive bound? Well, maybe they > should. I honestly cant figure out a valid use for an exclusive lower bound - > maybe for the lack of my imagination. Either way, I don't imagine that it > would be possible to convince Maven devs to change existing behavior, so this > should probably be implemented in a new version range spec scheme. ie. New > version range type with new syntax that always has lower inclusive bound and > always resolves to lower inclusive bound. > Without this, I am forced to accept either non-reproducible builds or to give > up strict dependency convergence assistance from Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MNG-6654) Resolve version ranges to the lower inclusive bound
[ https://issues.apache.org/jira/browse/MNG-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MNG-6654. Resolution: Won't Fix Users tend to expect version ranges to choose the later version. That's indeed the purpose of the damn things, irreporducible as that is. > Resolve version ranges to the lower inclusive bound > --- > > Key: MNG-6654 > URL: https://issues.apache.org/jira/browse/MNG-6654 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Affects Versions: 3.6.0 >Reporter: Koritako Alana >Priority: Major > > Version ranges result in non-repeatable builds because, and only because, > Maven chooses the greatest version within the range. > If we instead choose the lower inclusive bound of the range, then the build > will always be the same. > eg. [1.2.0,2.0.0.min) > Resolving to lower inclusive bound means taking 1.2.0 here. Always. Even > after 1.3.0 is released. > Taking the lower inclusive bound means there are no holes that can later be > filled in, resulting in non-repeatable builds. eg. If we took the lowest > existing version in the range, then there would be a possibility of someone > later adding a lower version. Taking the lower inclusive bound requires the > lower inclusive bound to exist from day 1. > Version ranges are actually for defining compatibility ranges. Conceptually, > there are 2 version numbers: the version you compile against and the version > range your code is compatible with. Even if you declare a version range, > javac only ever compiles against 1 specific version. > For repeatable builds, you want the version number you compile against to be > the same. However, you also want to be able to declare a range of dependency > versions with which your library is compatible. As Maven is now, you can't > have both. By resolving version ranges to the lower inclusive bound, we can. > This should be obvious, but to be clear: If I am writing a library liba which > depends on library libb with range [1.2.0,2.0.0.min) and someone writes an > app including my library liba, then the app should get version 1.2.0 of libb. > The app is free to declare a direct dependency on version 1.3.0 or 1.8.5 etc > of libb, any version that falls into the range [1.2.0,2.0.0.min). If the app > declares a direct dependency on version 2.2.0 of libb, Maven should report a > dependency resolution error like it currently does. > But not all version ranges have a lower inclusive bound? Well, maybe they > should. I honestly cant figure out a valid use for an exclusive lower bound - > maybe for the lack of my imagination. Either way, I don't imagine that it > would be possible to convince Maven devs to change existing behavior, so this > should probably be implemented in a new version range spec scheme. ie. New > version range type with new syntax that always has lower inclusive bound and > always resolves to lower inclusive bound. > Without this, I am forced to accept either non-reproducible builds or to give > up strict dependency convergence assistance from Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6556) Packaging 'maven-plugin' binding plugin upgrades
[ https://issues.apache.org/jira/browse/MNG-6556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6556: Description: This affects: ||groupId||artifactId||[previous version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging]||target version|| |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| |org.apache.maven.plugins|maven-plugin-plugin|3.2|3.6.0| |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M4| |org.apache.maven.plugins|maven-jar-plugin|2.4|3.2.0| |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| was: This affects: ||groupId||artifactId||[previous version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging]||target version|| |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| |org.apache.maven.plugins|maven-plugin-plugin|3.2|3.6.0| |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M3| |org.apache.maven.plugins|maven-jar-plugin|2.4|3.2.0| |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| > Packaging 'maven-plugin' binding plugin upgrades > > > Key: MNG-6556 > URL: https://issues.apache.org/jira/browse/MNG-6556 > Project: Maven > Issue Type: Sub-task > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0-candidate > > Attachments: diff in mc.png > > > This affects: > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging]||target > version|| > |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| > |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| > |org.apache.maven.plugins|maven-plugin-plugin|3.2|3.6.0| > |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M4| > |org.apache.maven.plugins|maven-jar-plugin|2.4|3.2.0| > |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| > |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6556) Packaging 'maven-plugin' binding plugin upgrades
[ https://issues.apache.org/jira/browse/MNG-6556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6556: Description: This affects: ||groupId||artifactId||[previous version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging]||target version|| |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| |org.apache.maven.plugins|maven-plugin-plugin|3.2|3.6.0| |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M3| |org.apache.maven.plugins|maven-jar-plugin|2.4|3.2.0| |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| was: This affects: ||groupId||artifactId||[previous version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging]||target version|| |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| |org.apache.maven.plugins|maven-plugin-plugin|3.2|3.6.0| |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M3| |org.apache.maven.plugins|maven-jar-plugin|2.4|3.1.2| |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| > Packaging 'maven-plugin' binding plugin upgrades > > > Key: MNG-6556 > URL: https://issues.apache.org/jira/browse/MNG-6556 > Project: Maven > Issue Type: Sub-task > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0-candidate > > Attachments: diff in mc.png > > > This affects: > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging]||target > version|| > |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| > |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| > |org.apache.maven.plugins|maven-plugin-plugin|3.2|3.6.0| > |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M3| > |org.apache.maven.plugins|maven-jar-plugin|2.4|3.2.0| > |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| > |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRESOLVER-90) HTML content in POM: Maven should validate content before storing in local repo
[
https://issues.apache.org/jira/browse/MRESOLVER-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MRESOLVER-90:
---
Labels: intern (was: )
> HTML content in POM: Maven should validate content before storing in local
> repo
> ---
>
> Key: MRESOLVER-90
> URL: https://issues.apache.org/jira/browse/MRESOLVER-90
> Project: Maven Resolver
> Issue Type: New Feature
>Affects Versions: 1.4.0
> Environment: both with maven 3.6.0 in CMD or in Eclipse 4.9.0
>Reporter: Jörg Hohwiller
>Priority: Major
> Labels: intern
>
> For some odd reasons somethimes errors just happen and a maven repo delivers
> an HTML error or login page for a request of a POM or JAR file. It seems as
> if the status code is valid then Maven (might be anything under the hood,
> maybe even ether?) is saving the result without any sanity check or
> validation.
> Therefore I frequently end up with "POM" or "JAR" files in my local repo that
> are no XML but HTML nonsens.
>
> Example:
> {code:java}
>
>
>
>
> Please Wait While Redirecting to Login page
>
>
>
>
>
>
> {code}
> I would expect maven to verify the content before officially placing it in
> the correct location inside the local maven repository on my disc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6763) Restrict repositories to specific groupIds
[ https://issues.apache.org/jira/browse/MNG-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MNG-6763: --- Labels: intern (was: ) > Restrict repositories to specific groupIds > -- > > Key: MNG-6763 > URL: https://issues.apache.org/jira/browse/MNG-6763 > Project: Maven > Issue Type: New Feature >Reporter: dennis lucero >Priority: Major > Labels: intern > > It should be possible to restrict the repositories specified in settings.xml > to specific groupIds. Looking at > [https://maven.apache.org/ref/3.6.2/maven-settings/settings.html#class_repository], > it seems this is currently not the case. > Background: We use Nexus to host our own artifacts. The settings.xml contains > our Nexus repository with always because > sometimes a project is built while a dependency is not yet in our Nexus repo > – without updatePolicy, it would take 24 hours or manual deletion of metadata > to make Maven re-check for the missing dependency. > Additionally, we use versions-maven-plugin:2.7:display-dependency-updates in > our build process. > This results in lots of queries (more than 300 in a simple Dropwizard > project) to our repo which will never succeed. If we could specify that our > repo only supplies groupIds beginning with org.example, Maven could skip > update checks for groupIds starting with com.fasterxml.jackson and so on, > speeding up the build process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MSHADE-328) Implement 'automatic relocation of dependencies'
[ https://issues.apache.org/jira/browse/MSHADE-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHADE-328. -- Resolution: Not A Problem > Implement 'automatic relocation of dependencies' > > > Key: MSHADE-328 > URL: https://issues.apache.org/jira/browse/MSHADE-328 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 3.2.1 >Reporter: Peng Cheng >Priority: Major > Labels: gradle, relocation, shading > Original Estimate: 672h > Remaining Estimate: 672h > > This feature intend to introduce the same feature in shadow plugin for gradle: > > [https://imperceptiblethoughts.com/shadow/configuration/relocation/#automatically-relocating-dependencies] > > package relocation is the only reliable defense against jar hell and usually > can only be done at the final assembly stage (before that it is impossible to > determine which package requires relocation). Thus, it cannot be conducted in > a divide-and-conquer manner and requires enormous effort and a very complex > process to be configured manually. > > Maven should automate this process by analyzing the dependency tree and > relocate package whenever there is a version conflict -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHADE-328) Implement 'automatic relocation of dependencies'
[ https://issues.apache.org/jira/browse/MSHADE-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHADE-328. > Implement 'automatic relocation of dependencies' > > > Key: MSHADE-328 > URL: https://issues.apache.org/jira/browse/MSHADE-328 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 3.2.1 >Reporter: Peng Cheng >Priority: Major > Labels: gradle, relocation, shading > Original Estimate: 672h > Remaining Estimate: 672h > > This feature intend to introduce the same feature in shadow plugin for gradle: > > [https://imperceptiblethoughts.com/shadow/configuration/relocation/#automatically-relocating-dependencies] > > package relocation is the only reliable defense against jar hell and usually > can only be done at the final assembly stage (before that it is impossible to > determine which package requires relocation). Thus, it cannot be conducted in > a divide-and-conquer manner and requires enormous effort and a very complex > process to be configured manually. > > Maven should automate this process by analyzing the dependency tree and > relocate package whenever there is a version conflict -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHADE-344) Check linkage when shading
[ https://issues.apache.org/jira/browse/MSHADE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHADE-344: - Labels: intern (was: ) > Check linkage when shading > -- > > Key: MSHADE-344 > URL: https://issues.apache.org/jira/browse/MSHADE-344 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Elliotte Rusty Harold >Priority: Major > Labels: intern > > Could/should we check whether shading is likely to introduce linkage errors > and warn the developer? > > see > https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1092#issuecomment-574097868 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-shared-utils] elharo opened a new pull request #27: [MSHARED-881] use try with resources
elharo opened a new pull request #27: [MSHARED-881] use try with resources URL: https://github.com/apache/maven-shared-utils/pull/27 @michael-o This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (MRELEASE-935) Support for expression in 'version' tag
[
https://issues.apache.org/jira/browse/MRELEASE-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MRELEASE-935:
---
Priority: Minor (was: Critical)
> Support for expression in 'version' tag
> ---
>
> Key: MRELEASE-935
> URL: https://issues.apache.org/jira/browse/MRELEASE-935
> Project: Maven Release Plugin
> Issue Type: New Feature
>Affects Versions: 2.5.3
>Reporter: Andrea Scarpino
>Priority: Minor
> Attachments: support_for_revision_in_version.patch
>
>
> The release plugin doesn't support a version value that points to a property
> which define the version.
> Everytime I use the plugin, the version in the current POM loose the
> expression. Maybe it could work using the property to which it points?
> {noformat}
> $ grep '' pom.xml
> ${parent.project.version}
> $ grep '' pom.xml
> 0.0.1-SNAPSHOT
> {noformat}
> Could you please implement this or point me to the files that handle this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6553) Packaging 'war' binding plugin upgrades
[ https://issues.apache.org/jira/browse/MNG-6553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6553: Description: This affects: ||groupId||artifactId||[previous version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging]||target version|| |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M4| |org.apache.maven.plugins|maven-war-plugin|2.4|3.2.3| |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| was: This affects: ||groupId||artifactId||[previous version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging]||target version|| |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M3| |org.apache.maven.plugins|maven-war-plugin|2.4|3.2.3| |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| > Packaging 'war' binding plugin upgrades > --- > > Key: MNG-6553 > URL: https://issues.apache.org/jira/browse/MNG-6553 > Project: Maven > Issue Type: Sub-task > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0-candidate > > > This affects: > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging]||target > version|| > |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| > |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| > |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M4| > |org.apache.maven.plugins|maven-war-plugin|2.4|3.2.3| > |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| > |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1773) ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[
https://issues.apache.org/jira/browse/SUREFIRE-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SUREFIRE-1773.
Resolution: Invalid
This is not a support forum. Post your problem to SO or users@.
> ExecutionException The forked VM terminated without properly saying goodbye.
> VM crash or System.exit called?
> -
>
> Key: SUREFIRE-1773
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1773
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.1
>Reporter: Tu,Xiaodong
>Priority: Major
> Attachments: 2020-04-13T21-43-24_857.dumpstream, FullErrorLog
>
>
> Attempting to run integration tests using maven-failsafe-plugin and get error
> below.
> {code:java}
> [ERROR] ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called? [ERROR] Command was /bin/sh -c cd
> /Users/xiaotu/Documents/WorkCode/modelinsightservice &&
> /Users/xiaotu/Documents/WorkEnviroment/ebay_jdk_1.8.221/1.8.221_mac/jre/bin/java
> -Djdk.attach.allowAttachSelf -Djava.locale.providers=JRE,SPI
> '${ArgLineFromJacocoUt}' -Xverify:none -Xmx1024m -XX:MaxMetaspaceSize=512m
> -jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire/surefirebooter7810841987757310542.jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire
> 2020-04-13T21-43-24_857-jvmRun2 surefire5674009295883666539tmp
> surefire_13303426714213707853tmp [ERROR] Error occurred in starting fork,
> check output in log [ERROR] Process Exit Code: 1 [ERROR] ExecutionException
> The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called? [ERROR] Command was /bin/sh -c cd
> /Users/xiaotu/Documents/WorkCode/modelinsightservice &&
> /Users/xiaotu/Documents/WorkEnviroment/ebay_jdk_1.8.221/1.8.221_mac/jre/bin/java
> -Djdk.attach.allowAttachSelf -Djava.locale.providers=JRE,SPI
> '${ArgLineFromJacocoUt}' -Xverify:none -Xmx1024m -XX:MaxMetaspaceSize=512m
> -jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire/surefirebooter1185519684559162293.jar
> /Users/xiaotu/Documents/WorkCode/modelinsightservice/target/surefire
> 2020-04-13T21-43-24_857-jvmRun4 surefire3761879713715389341tmp
> surefire_28680022230240461764tmp
> {code}
> using maven command : mvn clean install -P static-check,default-plugins.
> Related maven setting:
>
> {code:java}
>
> org.sonarsource.scanner.maven
> sonar-maven-plugin 3.4.0.905
> org.springframework.boot
> spring-boot-maven-plugin
> org.jacoco jacoco-maven-plugin
> ${jacoco.version}
> pre-unit-test prepare-agent
> ${project.build.directory}/jacoco-ut.exec surefireArgLine
>
> post-unit-test test report
>
> ${project.build.directory}/jacoco-ut.exec
> ${project.reporting.outputDirectory}/jacoco-ut
> pre-integration-test
> pre-integration-test prepare-agent
>
> ${project.build.directory}/jacoco-it.exec
> failsafeArgLine
>
> post-integration-test post-integration-test
> report
> ${project.build.directory}/jacoco-it.exec
> ${project.reporting.outputDirectory}/jacoco-it
>
> org.apache.maven.plugins
> maven-pmd-plugin 3.8
> rulesets/java/ali-comment.xml
> rulesets/java/ali-concurrent.xml
> rulesets/java/ali-constant.xml
> rulesets/java/ali-exception.xml
> rulesets/java/ali-flowcontrol.xml
> rulesets/java/ali-naming.xml
> rulesets/java/ali-oop.xml
> rulesets/java/ali-orm.xml
> rulesets/java/ali-other.xml
> rulesets/java/ali-set.xml
> true
> true
> 3
> package check
>
> com.ebay.marketing p3c-pmd
> 1.0.0-SNAPSHOT
> org.apache.maven.plugins
> maven-surefire-plugin 2.22.1
> once 1.0C
> false ${surefireArgLine} -Xverify:none
> -Xmx1024m -XX:MaxMetaspaceSize=512m
> org.apache.maven.plugins
> maven-failsafe-plugin 2.22.1
>
> integration-tests integration-test
> verify
> ${failsafeArgLine}
> {code}
>
> Got more details in FullErrorLog and dump file.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6552) Packaging 'ejb' binding plugin upgrades
[ https://issues.apache.org/jira/browse/MNG-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6552: Description: This affects: ||groupId||artifactId||[previous version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging]||target version|| |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M4| |org.apache.maven.plugins|maven-ejb-plugin|2.4|3.0.1| |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| was: This affects: ||groupId||artifactId||[previous version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging]||target version|| |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M3| |org.apache.maven.plugins|maven-ejb-plugin|2.4|3.0.1| |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| > Packaging 'ejb' binding plugin upgrades > --- > > Key: MNG-6552 > URL: https://issues.apache.org/jira/browse/MNG-6552 > Project: Maven > Issue Type: Sub-task > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0-candidate > > > This affects: > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging]||target > version|| > |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0| > |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| > |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M4| > |org.apache.maven.plugins|maven-ejb-plugin|2.4|3.0.1| > |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| > |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-6890) MavenITmng5669ReadPomsOnce is unreliable
Michael Osipov created MNG-6890:
---
Summary: MavenITmng5669ReadPomsOnce is unreliable
Key: MNG-6890
URL: https://issues.apache.org/jira/browse/MNG-6890
Project: Maven
Issue Type: Bug
Components: Integration Tests
Affects Versions: 3.7.0
Reporter: Michael Osipov
Assignee: Robert Scholte
The unreliability comes from the fact that no plugin has been fixed (version)
in the parent POM of the test project. As soon as you update Maven from
MNG-6169 the test starts to fail that lengths do not match. So this test relies
on implicit declaration of plugin versions.
Reproducer:
1. Build Maven from MNG-6169/MNG-6551
2. Run ITs from MNG-6551
3. See it fail
One needs to remove {{-q}}, scan for plugins and fix their versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-jar-plugin] elharo opened a new pull request #8: [MNGSITE-393] remove more pre Maven 3 content
elharo opened a new pull request #8: [MNGSITE-393] remove more pre Maven 3 content URL: https://github.com/apache/maven-jar-plugin/pull/8 @eolivelli This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
