[jira] [Updated] (MDEP-652) display-ancestors should allow a parameter for outputFile
[ https://issues.apache.org/jira/browse/MDEP-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darius Cooper updated MDEP-652: --- Description: It would be useful for display-ancestors to allow a parameter for outputFile, as is available for the "list" goal. Edit: After creating this, I realize that one can use the "list" goal, with the "includeParents" option. Please close this JIRA. was: It would be useful for display-ancestors to allow a parameter for outputFile, as is available for the "list" goal. We currently use that option with list, to add a file to target, and package it with the app, so that the app can self-report on its dependencies...even at run time. It would be useful to do the same for ancestors... or even the single, immediate parent POM > display-ancestors should allow a parameter for outputFile > - > > Key: MDEP-652 > URL: https://issues.apache.org/jira/browse/MDEP-652 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: Darius Cooper >Priority: Minor > > It would be useful for display-ancestors to allow a parameter for outputFile, > as is available for the "list" goal. > Edit: After creating this, I realize that one can use the "list" goal, with > the "includeParents" option. > Please close this JIRA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MDEP-652) display-ancestors should allow a parameter for outputFile
Darius Cooper created MDEP-652: -- Summary: display-ancestors should allow a parameter for outputFile Key: MDEP-652 URL: https://issues.apache.org/jira/browse/MDEP-652 Project: Maven Dependency Plugin Issue Type: Improvement Reporter: Darius Cooper It would be useful for display-ancestors to allow a parameter for outputFile, as is available for the "list" goal. We currently use that option with list, to add a file to target, and package it with the app, so that the app can self-report on its dependencies...even at run time. It would be useful to do the same for ancestors... or even the single, immediate parent POM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-shade-plugin] belingueres opened a new pull request #21: [MSHADE-319] - Add distinctive color to excluded artifacts...
belingueres opened a new pull request #21: [MSHADE-319] - Add distinctive color to excluded artifacts... URL: https://github.com/apache/maven-shade-plugin/pull/21 - Added Warning color to Exclusions. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MSHADE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MSHADE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSHADE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). 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] [Created] (MSHADE-319) Add distinctive color to excluded artifacts to easily identify them
Gabriel Belingueres created MSHADE-319: -- Summary: Add distinctive color to excluded artifacts to easily identify them Key: MSHADE-319 URL: https://issues.apache.org/jira/browse/MSHADE-319 Project: Maven Shade Plugin Issue Type: Improvement Reporter: Gabriel Belingueres Add distinctive color for excluded artifacts to easily identify them at first sight from those included, in the list of Including/Excluding artifacts in the output on the plugin execution. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6573) Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI
[ https://issues.apache.org/jira/browse/MNG-6573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833390#comment-16833390 ] Hudson commented on MNG-6573: - Build failed in Jenkins: Maven TLP » maven-deploy-plugin » master #11 See https://builds.apache.org/job/maven-box/job/maven-deploy-plugin/job/master/11/ > Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI > -- > > Key: MNG-6573 > URL: https://issues.apache.org/jira/browse/MNG-6573 > Project: Maven > Issue Type: Task > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Maven Core Integration Test passed ok for Linux and Windows for Java 7, 8, > 11, 12-ea, 13-ea. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-207) Remove @Deprecated marked code about repository layout
[
https://issues.apache.org/jira/browse/MDEPLOY-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833391#comment-16833391
]
Hudson commented on MDEPLOY-207:
Build failed in Jenkins: Maven TLP » maven-deploy-plugin » master #11
See
https://builds.apache.org/job/maven-box/job/maven-deploy-plugin/job/master/11/
> Remove @Deprecated marked code about repository layout
> --
>
> Key: MDEPLOY-207
> URL: https://issues.apache.org/jira/browse/MDEPLOY-207
> Project: Maven Deploy Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> The {{layout}} which is defined in parameter {{altDeploymentRepository}} is a
> candidate to remove cause we support only Maven 3, that support only Maven 2
> repository layout (layout = {{default}}) and not Maven 1 repository layout
> (layout = {{legacy}}) anymore which makes the layout part superfluous.
> Furthermore the {{repositoryLayout}} parameter of {{deploy-file}} goals is
> marked as deprecated and should be removed as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSKINS-145) Google+ Shutdown - remove code from skins
[ https://issues.apache.org/jira/browse/MSKINS-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833372#comment-16833372 ] Hervé Boutemy commented on MSKINS-145: -- done in https://gitbox.apache.org/repos/asf?p=maven-fluido-skin.git=commit=2a3e4a090edd5a53b84266284e5f3eca7523c6c0 > Google+ Shutdown - remove code from skins > - > > Key: MSKINS-145 > URL: https://issues.apache.org/jira/browse/MSKINS-145 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Labels: up-for-grabs > Fix For: fluido-1.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Due to Google shutdown of all APIs related to Google+ we should remove our > code generation logic to display GooglePlus buttons. > https://developers.google.com/+/integrations-shutdown -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSKINS-137) Enable "Hamburger menu" with top-nav only
[ https://issues.apache.org/jira/browse/MSKINS-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833370#comment-16833370 ] Hervé Boutemy commented on MSKINS-137: -- merged in https://github.com/apache/maven-fluido-skin/commit/ec4b18a33ed4212761c05aa077a54797f25d0652 > Enable "Hamburger menu" with top-nav only > - > > Key: MSKINS-137 > URL: https://issues.apache.org/jira/browse/MSKINS-137 > Project: Maven Skins > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: fluido-1.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Revitalizing this old PR https://github.com/apache/maven-skins/pull/4 > Still an issue for us down in HBase. Changes seem to apply and have worked in > local testing on the HBase site. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MPOM-220) Update ASF logo property to the latest version
[ https://issues.apache.org/jira/browse/MPOM-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MPOM-220: --- Summary: Update ASF logo property to the latest version (was: Update ASF logo to the latest version) > Update ASF logo property to the latest version > -- > > Key: MPOM-220 > URL: https://issues.apache.org/jira/browse/MPOM-220 > Project: Maven POMs > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > > Based on ASF press kit - update link to existing logo > https://www.apache.org/images/asf_logo_wide.gif to new > https://www.apache.org/images/asf_logo_wide_2016.png -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPOM-220) Update ASF logo to the latest version
[ https://issues.apache.org/jira/browse/MPOM-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833369#comment-16833369 ] Hervé Boutemy commented on MPOM-220: I can see the property in pom.xml https://github.com/apache/maven-apache-parent/blob/apache-21/pom.xml#L85 but I can't understand where is it used: do you know? > Update ASF logo to the latest version > - > > Key: MPOM-220 > URL: https://issues.apache.org/jira/browse/MPOM-220 > Project: Maven POMs > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > > Based on ASF press kit - update link to existing logo > https://www.apache.org/images/asf_logo_wide.gif to new > https://www.apache.org/images/asf_logo_wide_2016.png -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MPOM-219) upgrade maven-help-plugin to 3.2.0 (to get verbose effective-pom)
[ https://issues.apache.org/jira/browse/MPOM-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MPOM-219. -- Resolution: Fixed done in https://gitbox.apache.org/repos/asf?p=maven-apache-parent.git=commit=f4bfc53a4de86c487149823f3115096c0b468cc6 > upgrade maven-help-plugin to 3.2.0 (to get verbose effective-pom) > - > > Key: MPOM-219 > URL: https://issues.apache.org/jira/browse/MPOM-219 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Affects Versions: ASF-21 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy >Priority: Major > Fix For: ASF-22 > > > Release Notes - Maven Help Plugin - Version 3.2.0 > New Feature > * [MPH-160] - help:effective-pom -Dverbose: add source location as comments > in effective pom.xml > Improvement > * [MPH-161] - add color to goal or plugin description -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-compiler-plugin] rhowe commented on issue #17: Miscellaneous code cleanups
rhowe commented on issue #17: Miscellaneous code cleanups URL: https://github.com/apache/maven-compiler-plugin/pull/17#issuecomment-489425123 OK, I made 4 tickets for the 4 classes of change & rewrote the commit messages. Also I took out the dos->unix line ending change because I didn't end up touching that class in the end. There are a bunch of DOS format files in the repo - any objection to a PR that converts them all to unix line ending and then leave git to do the right thing for all platforms? 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-6650) BOM + profile: Transitive dependencies not resolved
[
https://issues.apache.org/jira/browse/MNG-6650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6650:
Summary: BOM + profile: Transitive dependencies not resolved (was: Java11
Regression Bug: Transitive dependencies not resolved)
> BOM + profile: Transitive dependencies not resolved
> ---
>
> Key: MNG-6650
> URL: https://issues.apache.org/jira/browse/MNG-6650
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.6.0
> Environment: Works with Java 1.8
> Fails with Java 11
> Reproduced on Mac and Windows as well as in travis-ci (linux).
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: MNG-6650.tgz
>
>
> I have found a strange situation where maven seems to be unable to resolve
> transitive dependencies for a particular dependency but only in Java11+
> The failing build can be found here with all the analysis:
> [https://github.com/devonfw/devon4j/pull/82]
> As you can read there with all the details the error is related to a profile
> with
>
> [9,)
>
> That should fire on Java11 and seems to do but as a result all dependencies
> are eliminated in this case what seems like a strange maven bug.
> The Code to reproduce the issue locally can also be cloned from here:
> [https://github.com/hohwille/devon4j/tree/feature/16-java-11]
> (be sure to checkout this "feature/16-java-11" branch)
> After building you can even reduce and reproduce the error from
> {{templates/server/target/test-classes/projects/basic/project/basic}}
> Just "cd" there and run "mvn clean install" with Java1.8 and with Java11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1623) TempWmicBatchFile.bat is left in project dirs after surefire tests are run
[ https://issues.apache.org/jira/browse/SUREFIRE-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833348#comment-16833348 ] Chris Graham edited comment on SUREFIRE-1623 at 5/5/19 12:02 PM: - My intent in the above, perhaps would have been clearer if instead of 'paranoid', I wrote 'to program defensively', ie, only remove the file if the file was present before the execution. I have lots of issues getting 1.8 installed in this VM, so I've had to go back to 1.8.0_40 and then install newer versions after that (an initial install of 1.8.0_181 or 191 did not work). Simply running 'mvn clean install' on surefire itself produces the WMIC files left behind, and the next build fails on a rat check. So I have to skip tests whilst building surefire itself. I will try to get to a point where I can build surefire under 32 bit XP and then see if I can drill down deeper into the code to see what is triggering the issue. was (Author: chrisgwarp): My intent in the above, perhaps would have been clearer if instead of 'paranoid', I wrote 'to program defensively', ie, only remove the file if the file was present before the execution. I have lots of issues getting 1.8 installed in this VM, so I've had to go back to 1.8.0_40 and then install newer versions after that (an initial install of 1.8.0_181 or 191 did not work). Simply running 'mvn clean install' on surefire itself produces the WMIC files left behind, and the next build fails on a rat check. I will try to get to a point where I can build surefire under 32 bit XP and then see if I can drill down deeper into the code to see what is triggering the issue. > TempWmicBatchFile.bat is left in project dirs after surefire tests are run > -- > > Key: SUREFIRE-1623 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1623 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M3 >Reporter: Chris Graham >Assignee: Tibor Digana >Priority: Blocker > Attachments: reproduce-surefire-issue master.zip > > > WINDOWS ONLY: > When the WMIC command it run to obtain the process start time, the current > implementation leaves behind a batch file, TempWmicBatchFile.bat, which is > zero bytes long. > This file needs to be removed post execution. > Leaving it behind will interfere with the release plugin as a scm status call > will fail with files needing to be added. Simply ignoring the file is a very > sloppy approach. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1623) TempWmicBatchFile.bat is left in project dirs after surefire tests are run
[ https://issues.apache.org/jira/browse/SUREFIRE-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833348#comment-16833348 ] Chris Graham commented on SUREFIRE-1623: My intent in the above, perhaps would have been clearer if instead of 'paranoid', I wrote 'to program defensively', ie, only remove the file if the file was present before the execution. I have lots of issues getting 1.8 installed in this VM, so I've had to go back to 1.8.0_40 and then install newer versions after that (an initial install of 1.8.0_181 or 191 did not work). Simply running 'mvn clean install' on surefire itself produces the WMIC files left behind, and the next build fails on a rat check. I will try to get to a point where I can build surefire under 32 bit XP and then see if I can drill down deeper into the code to see what is triggering the issue. > TempWmicBatchFile.bat is left in project dirs after surefire tests are run > -- > > Key: SUREFIRE-1623 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1623 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M3 >Reporter: Chris Graham >Assignee: Tibor Digana >Priority: Blocker > Attachments: reproduce-surefire-issue master.zip > > > WINDOWS ONLY: > When the WMIC command it run to obtain the process start time, the current > implementation leaves behind a batch file, TempWmicBatchFile.bat, which is > zero bytes long. > This file needs to be removed post execution. > Leaving it behind will interfere with the release plugin as a scm status call > will fail with files needing to be added. Simply ignoring the file is a very > sloppy approach. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1665) JUnits fail with Java11: IllegalArgumentException: Stream stdin corrupted. Expected comma after third character in command 'FATAL ERROR in native method: processing
[
https://issues.apache.org/jira/browse/SUREFIRE-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1682#comment-1682
]
Jörg Hohwiller commented on SUREFIRE-1665:
--
Seems I am missing the permissions to close this ussue. Can you close this as
invalid. Thanks.
> JUnits fail with Java11: IllegalArgumentException: Stream stdin corrupted.
> Expected comma after third character in command 'FATAL ERROR in native
> method: processing of -javaagent failed'
> --
>
> Key: SUREFIRE-1665
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1665
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.20.1, 3.0.0-M2
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: 2019-05-03T18-10-11_458-jvmRun1.dumpstream,
> 2019-05-03T18-10-11_458.dumpstream
>
>
> As discussed in SUREFIRE-1601 I create a new issue.
> I want to make my project (java,maven,junit,surefire) to work with Java11.
> However, surefire fails to execute the tests when run with Java11 (works fine
> with Java 1.8).
> ```
> IllegalArgumentException: Stream stdin corrupted. Expected comma after third
> character in command 'FATAL ERROR in native method: processing of -javaagent
> failed'
> ```
> Attached are the surefire reports of the affected project (which is actually
> the test-case of a maven archetype). You can find the entire code here:
> [https://github.com/hohwille/devon4j/tree/feature/java-11-surefire]
> (When cloning please ensure you checkout the branch {{java-11-surefire}}).
> The github pull-request for it can be found here:
> [https://github.com/devonfw/devon4j/pull/84]
> As you can see we are using travis-ci and JDK 1.8 build is green while JDK 11
> build fails:
> [https://travis-ci.org/devonfw/devon4j/builds/527844661?utm_source=github_status_medium=notification]
> I hope to have served with all the information required for you to trace down
> and fix the issue. In case you are still missing any information do not
> hesitate to ask.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1665) JUnits fail with Java11: IllegalArgumentException: Stream stdin corrupted. Expected comma after third character in command 'FATAL ERROR in native method: processing
[
https://issues.apache.org/jira/browse/SUREFIRE-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1680#comment-1680
]
Jörg Hohwiller commented on SUREFIRE-1665:
--
I am sorry, the jacoco version was also present as 0.8.0 in another involved
POM. I fixed this and the error went away. Still the tests fail but not anymore
because of surefire.
Sorry, for the noise.
> JUnits fail with Java11: IllegalArgumentException: Stream stdin corrupted.
> Expected comma after third character in command 'FATAL ERROR in native
> method: processing of -javaagent failed'
> --
>
> Key: SUREFIRE-1665
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1665
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.20.1, 3.0.0-M2
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: 2019-05-03T18-10-11_458-jvmRun1.dumpstream,
> 2019-05-03T18-10-11_458.dumpstream
>
>
> As discussed in SUREFIRE-1601 I create a new issue.
> I want to make my project (java,maven,junit,surefire) to work with Java11.
> However, surefire fails to execute the tests when run with Java11 (works fine
> with Java 1.8).
> ```
> IllegalArgumentException: Stream stdin corrupted. Expected comma after third
> character in command 'FATAL ERROR in native method: processing of -javaagent
> failed'
> ```
> Attached are the surefire reports of the affected project (which is actually
> the test-case of a maven archetype). You can find the entire code here:
> [https://github.com/hohwille/devon4j/tree/feature/java-11-surefire]
> (When cloning please ensure you checkout the branch {{java-11-surefire}}).
> The github pull-request for it can be found here:
> [https://github.com/devonfw/devon4j/pull/84]
> As you can see we are using travis-ci and JDK 1.8 build is green while JDK 11
> build fails:
> [https://travis-ci.org/devonfw/devon4j/builds/527844661?utm_source=github_status_medium=notification]
> I hope to have served with all the information required for you to trace down
> and fix the issue. In case you are still missing any information do not
> hesitate to ask.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6650) Java11 Regression Bug: Transitive dependencies not resolved
[
https://issues.apache.org/jira/browse/MNG-6650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833318#comment-16833318
]
Jörg Hohwiller edited comment on MNG-6650 at 5/5/19 11:06 AM:
--
Thanks for this feedback. Seems you are right. I just wanted to upgrade my
project to Java11 and now it still works with Java 1.8 but it should work with
Java 9+ though it does not.
However, the actual reason seems to be related to a bug in the profile
triggered by jdk 9+ that for some yet unclear reason results in an empty list
of dependencies (so the direct dependencies as well as those added by the
profile and up as empty where as with Java 1.8 the direct dependencies are used
and the profile is not triggered).
What I also found out is that if I just create a maven project with two modules
A and B and in A I add the spring-security dependency containg the CsrfToken
and also add a copy of that Java9+ triggered profile and then in B do the same
as in the example project (depend on A and have a class requireing CsrfToken)
the error is not reproduced. So there is yet another circumstance that needs to
be added to cause this effect. However, I assume someone who is capable to run
Maven on the provided project in debug mode and set a breakpoint in the
dependency evaluation will easily be able to spot down this bug. I always
failed to properly debug maven core. If you have any working instructions
provide a link here and I might give it a try.
was (Author: hohwille):
Thanks for this feedback. Seems you are right. I just wanted to upgrade my
project to Java11 and now it still works with Java 1.8 but it should work with
Java 9+ though it does not.
However, the actual reason seems to be related to a bug in the profile
triggered by jdk 9+ that for some yet unclear reason results in an empty list
of dependencies (so the direct dependencies as well as those added by the
profile and up as empty where as with Java 1.8 the direct dependencies are used
and the profile is not triggered).
What I also found out is that if I just create a maven project with two modules
A and B and in A I add the spring-security dependency containg the CsrfToken
and also add a copy of that Java9+ triggered profile and then in B do the same
as in the example project (depend on A and have a class requireing CsrfToken)
the error is not reproduced. So there is yet another circumstance that needs to
be added to cause this effect. However, I assume someone who is capable do run
Maven on the provided project in debug mode and set a breakpoint in the
dependency evaluation will easily be able to spot down this bug. I always
failed to properly debug maven core. If you have any working instructions
provide a link here and I might give it a try.
> Java11 Regression Bug: Transitive dependencies not resolved
> ---
>
> Key: MNG-6650
> URL: https://issues.apache.org/jira/browse/MNG-6650
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.6.0
> Environment: Works with Java 1.8
> Fails with Java 11
> Reproduced on Mac and Windows as well as in travis-ci (linux).
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: MNG-6650.tgz
>
>
> I have found a strange situation where maven seems to be unable to resolve
> transitive dependencies for a particular dependency but only in Java11+
> The failing build can be found here with all the analysis:
> [https://github.com/devonfw/devon4j/pull/82]
> As you can read there with all the details the error is related to a profile
> with
>
> [9,)
>
> That should fire on Java11 and seems to do but as a result all dependencies
> are eliminated in this case what seems like a strange maven bug.
> The Code to reproduce the issue locally can also be cloned from here:
> [https://github.com/hohwille/devon4j/tree/feature/16-java-11]
> (be sure to checkout this "feature/16-java-11" branch)
> After building you can even reduce and reproduce the error from
> {{templates/server/target/test-classes/projects/basic/project/basic}}
> Just "cd" there and run "mvn clean install" with Java1.8 and with Java11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6650) Java11 Regression Bug: Transitive dependencies not resolved
[
https://issues.apache.org/jira/browse/MNG-6650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833318#comment-16833318
]
Jörg Hohwiller edited comment on MNG-6650 at 5/5/19 11:06 AM:
--
Thanks for this feedback. Seems you are right. I just wanted to upgrade my
project to Java11 and now it still works with Java 1.8 but it should work with
Java 9+ though it does not.
However, the actual reason seems to be related to a bug in the profile
triggered by jdk 9+ that for some yet unclear reason results in an empty list
of dependencies (so the direct dependencies as well as those added by the
profile and up as empty where as with Java 1.8 the direct dependencies are used
and the profile is not triggered).
What I also found out is that if I just create a maven project with two modules
A and B and in A I add the spring-security dependency containg the CsrfToken
and also add a copy of that Java9+ triggered profile and then in B do the same
as in the example project (depend on A and have a class requireing CsrfToken)
the error is not reproduced. So there is yet another circumstance that needs to
be added to cause this effect. However, I assume someone who is capable do run
Maven on the provided project in debug mode and set a breakpoint in the
dependency evaluation will easily be able to spot down this bug. I always
failed to properly debug maven core. If you have any working instructions
provide a link here and I might give it a try.
was (Author: hohwille):
Thanks for this feedback. Seems you are right. I just wanted to upgrade my
project to Java11 and now it still works with Java 1.8 but it should work with
Java 9+ though it does not.
However, the actual reason seems to be related to a bug in the profile
triggered by jdk 9+ that for some yet unclear reason results in an empty list
of dependencies (so the direct dependencies as well as those added by the
profile and up as empty where as with Java 1.8 the direct dependencies are used
and the profile is not triggered).
What I also found out is that if I just create a maven project with two modules
A and B and in A I add the spring-security dependency containg the CsrfToken
and also add a copy of that Java9+ triggered profile and then in B do the same
as in the example project (depend on A and have a class requireing CsrfToken)
the error is not reproduced. Some there is yet another circumstance that needs
to be added to cause this effect. However, I assume someone who is capable do
run Maven on the provided project in debug mode and set a breakpoint in the
dependency evaluation will easily be able to spot down this bug. I always
failed to properly debug maven core. If you have any working instructions
provide a link here and I might give it a try.
> Java11 Regression Bug: Transitive dependencies not resolved
> ---
>
> Key: MNG-6650
> URL: https://issues.apache.org/jira/browse/MNG-6650
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.6.0
> Environment: Works with Java 1.8
> Fails with Java 11
> Reproduced on Mac and Windows as well as in travis-ci (linux).
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: MNG-6650.tgz
>
>
> I have found a strange situation where maven seems to be unable to resolve
> transitive dependencies for a particular dependency but only in Java11+
> The failing build can be found here with all the analysis:
> [https://github.com/devonfw/devon4j/pull/82]
> As you can read there with all the details the error is related to a profile
> with
>
> [9,)
>
> That should fire on Java11 and seems to do but as a result all dependencies
> are eliminated in this case what seems like a strange maven bug.
> The Code to reproduce the issue locally can also be cloned from here:
> [https://github.com/hohwille/devon4j/tree/feature/16-java-11]
> (be sure to checkout this "feature/16-java-11" branch)
> After building you can even reduce and reproduce the error from
> {{templates/server/target/test-classes/projects/basic/project/basic}}
> Just "cd" there and run "mvn clean install" with Java1.8 and with Java11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6650) Java11 Regression Bug: Transitive dependencies not resolved
[
https://issues.apache.org/jira/browse/MNG-6650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833318#comment-16833318
]
Jörg Hohwiller commented on MNG-6650:
-
Thanks for this feedback. Seems you are right. I just wanted to upgrade my
project to Java11 and now it still works with Java 1.8 but it should work with
Java 9+ though it does not.
However, the actual reason seems to be related to a bug in the profile
triggered by jdk 9+ that for some yet unclear reason results in an empty list
of dependencies (so the direct dependencies as well as those added by the
profile and up as empty where as with Java 1.8 the direct dependencies are used
and the profile is not triggered).
What I also found out is that if I just create a maven project with two modules
A and B and in A I add the spring-security dependency containg the CsrfToken
and also add a copy of that Java9+ triggered profile and then in B do the same
as in the example project (depend on A and have a class requireing CsrfToken)
the error is not reproduced. Some there is yet another circumstance that needs
to be added to cause this effect. However, I assume someone who is capable do
run Maven on the provided project in debug mode and set a breakpoint in the
dependency evaluation will easily be able to spot down this bug. I always
failed to properly debug maven core. If you have any working instructions
provide a link here and I might give it a try.
> Java11 Regression Bug: Transitive dependencies not resolved
> ---
>
> Key: MNG-6650
> URL: https://issues.apache.org/jira/browse/MNG-6650
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.6.0
> Environment: Works with Java 1.8
> Fails with Java 11
> Reproduced on Mac and Windows as well as in travis-ci (linux).
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: MNG-6650.tgz
>
>
> I have found a strange situation where maven seems to be unable to resolve
> transitive dependencies for a particular dependency but only in Java11+
> The failing build can be found here with all the analysis:
> [https://github.com/devonfw/devon4j/pull/82]
> As you can read there with all the details the error is related to a profile
> with
>
> [9,)
>
> That should fire on Java11 and seems to do but as a result all dependencies
> are eliminated in this case what seems like a strange maven bug.
> The Code to reproduce the issue locally can also be cloned from here:
> [https://github.com/hohwille/devon4j/tree/feature/16-java-11]
> (be sure to checkout this "feature/16-java-11" branch)
> After building you can even reduce and reproduce the error from
> {{templates/server/target/test-classes/projects/basic/project/basic}}
> Just "cd" there and run "mvn clean install" with Java1.8 and with Java11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPLUGIN-350) Split @Parameter into @Input and @Output
[
https://issues.apache.org/jira/browse/MPLUGIN-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833287#comment-16833287
]
Robert Scholte commented on MPLUGIN-350:
After a small investigation, using in/out as elements won't work, since parsing
is done differently inside Maven.
{code:title=org.apache.maven.plugin.descriptor.PluginDescriptorBuilder#buildComponentDescriptor(PlexusConfiguration,PluginDescriptor)}
PlexusConfiguration[] parameterConfigurations = c.getChild( "parameters"
).getChildren( "parameter" );
{code}
However, it is only parsing known elements and attributes, the unknowns are
simple ignored.
And I noticed that Files will be challenging. In case a file refers to a
sourceDirectory, you probably want to very (a subset of) the sourceFiles.
In case a file simply points to basedir, you don't want to check every file or
directory underneath it. One conclusion could be that basedir alone is unwanted
and you probably want to refer to a specific file or directory instead. We need
to be very clear about the usage and implications.
> Split @Parameter into @Input and @Output
>
>
> Key: MPLUGIN-350
> URL: https://issues.apache.org/jira/browse/MPLUGIN-350
> Project: Maven Plugin Tools
> Issue Type: New Feature
>Reporter: Robert Scholte
>Priority: Major
>
> By knowing if parameters are input or output parameters, it is possible to
> improve our builds. It will be possible to create DAGs and chain the
> execution blocks much smarter.
> The Maven Extension created by Gradle heavily relies on this kind of
> information.
> It is probably easier to use new annotations instead of adding a (required)
> status-field to @Parameter
> Looking at the {{plugin.xml}} it looks quite easy to solve this and stay
> backwards compatible: the file looks now like:
> {code:xml}
>
>
> ...
>
>
> {code}
> With plexus-magic the following should still work:
> {code:xml}
>
>
> ...
>
>
> ...
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-593) Module not found
[
https://issues.apache.org/jira/browse/MJAVADOC-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833131#comment-16833131
]
Robert Scholte edited comment on MJAVADOC-593 at 5/5/19 8:12 AM:
-
[~Nibsi] The empty directory is created to be able to patch modules, so this is
intended behavior.
[~Warkdev] Your project contains named and automatic modules, which means some
patching needs to be done. In your case with {{mvn compile javadoc:javadoc}}
it'll work.
was (Author: rfscholte):
[~Nibsi] The empty directory is created to be able to patch modules, so this is
intended behavior.
[~Warkdev] Your project contains named and automatic modules, which means some
patching needs to be done. In your case with {{mvn package javadoc:javadoc}}
it'll work.
> Module not found
>
>
> Key: MJAVADOC-593
> URL: https://issues.apache.org/jira/browse/MJAVADOC-593
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
> Environment: Apache Netbeans 10
> OpenJDK 11
> OpenJFX 11
>Reporter: Cédric Servais
>Priority: Major
>
> Hello,
> I'm using the maven-javadoc-plugin version 3.1 to generate the javadoc for my
> Java 11 project. I currently have an issue "module not found" provided by the
> plugin:
> {code:java}
> // espace réservé du code
> Loading source file
> D:\Jangos\JaNGOSExtractor\src\main\java\module-info.java...
> [parsing started
> SimpleFileObject[D:\Jangos\JaNGOSExtractor\src\main\java\module-info.java]]
> [parsing completed 13ms]
> [loading
> C:\Users\Cedri\.m2\repository\com\github\warkdev\Utils\1.0\Utils-1.0.jar(/module-info.class)]
> [loading /modules/java.base/module-info.class]
> [loading
> C:\Users\Cedri\.m2\repository\org\openjfx\javafx-controls\11.0.2\javafx-controls-11.0.2-win.jar(/module-info.class)]
> [loading
> C:\Users\Cedri\.m2\repository\org\openjfx\javafx-graphics\11.0.2\javafx-graphics-11.0.2-win.jar(/module-info.class)]
> [loading
> C:\Users\Cedri\.m2\repository\org\openjfx\javafx-base\11.0.2\javafx-base-11.0.2-win.jar(/module-info.class)]
> [loading /modules/java.desktop/module-info.class]
> [loading /modules/java.xml/module-info.class]
> [loading /modules/java.datatransfer/module-info.class]
> [loading /modules/java.prefs/module-info.class]
> [loading /modules/jdk.unsupported/module-info.class]
> [loading
> C:\Users\Cedri\.m2\repository\com\github\warkdev\jmpq3\java9-module-dd4a82f438-1\jmpq3-java9-module-dd4a82f438-1.jar(/module-info.class)]
> [loading
> C:\Users\Cedri\.m2\repository\org\openjfx\javafx-swing\11.0.2\javafx-swing-11.0.2-win.jar(/module-info.class)]
> [loading /modules/jdk.unsupported.desktop/module-info.class]
> [done in 604 ms]
> 1 error
> Error while creating javadoc report:
> Exit code: 1 - error: module not found: eu.jangos.extractor
> Command line was: "C:\Program Files (x86)\Java\jdk-11.0.2\bin\javadoc.exe"
> @options @packages @argfile{code}
> I had a look to several possible solutions but I couldn't find any workaround
> for this. The project I'm using is the following:
> [https://github.com/Warkdev/JaNGOSExtractor]
> Could you please let me know if I'm doing something wrong ?
> Ps: I tested with the plugin version 3.0.1 but it seems that it doesn't
> support my 3rd party library compiled for Java 11. (Error Unsupported Class
> Version 55)
>
> Thanks in advance,
> Warkdev
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MCOMPILER-385) Minor performance improvements in CompilerMojo
Russell Howe created MCOMPILER-385: -- Summary: Minor performance improvements in CompilerMojo Key: MCOMPILER-385 URL: https://issues.apache.org/jira/browse/MCOMPILER-385 Project: Maven Compiler Plugin Issue Type: Improvement Reporter: Russell Howe There are a couple of opportunities to improve performance and simplify CompilerMojo's preparePaths() method. A StringBuilder is used to concatenate 3 strings. String.format() will be neater here. Secondly, the compilerArgs array is checked for null and initialised if so in two separate places. Since this check is always performed, doing it earlier will allow one check to be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MCOMPILER-384) Remove null checks in conjunction with instanceof
Russell Howe created MCOMPILER-384: -- Summary: Remove null checks in conjunction with instanceof Key: MCOMPILER-384 URL: https://issues.apache.org/jira/browse/MCOMPILER-384 Project: Maven Compiler Plugin Issue Type: Improvement Reporter: Russell Howe There are a few places where we check for nullity prior to checking type with instanceof. These null checks are redundant as per the Java language specification https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.20.2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MCOMPILER-383) Use Java 7 type inference more
Russell Howe created MCOMPILER-383: -- Summary: Use Java 7 type inference more Key: MCOMPILER-383 URL: https://issues.apache.org/jira/browse/MCOMPILER-383 Project: Maven Compiler Plugin Issue Type: Improvement Affects Versions: 3.8.1 Reporter: Russell Howe There are occasions where the Java generics system can perform type inference on object construction for us. Use the diamond syntax in these cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MCOMPILER-382) Remove superfluous exception declarations
Russell Howe created MCOMPILER-382: -- Summary: Remove superfluous exception declarations Key: MCOMPILER-382 URL: https://issues.apache.org/jira/browse/MCOMPILER-382 Project: Maven Compiler Plugin Issue Type: Improvement Affects Versions: 3.8.1 Reporter: Russell Howe Several test methods declare that they throw exceptions they never in fact throw. Remove these declarations. Offenders are CompilerManagerStub's getCompiler() method and several methods in CompilerStub which simply return fixed values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
