[jira] [Commented] (MPH-160) add source location in comments to effective pom.xml
[
https://issues.apache.org/jira/browse/MPH-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816849#comment-16816849
]
Hudson commented on MPH-160:
Build succeeded in Jenkins: Maven TLP » maven-help-plugin » master #5
See https://builds.apache.org/job/maven-box/job/maven-help-plugin/job/master/5/
> add source location in comments to effective pom.xml
>
>
> Key: MPH-160
> URL: https://issues.apache.org/jira/browse/MPH-160
> Project: Maven Help Plugin
> Issue Type: New Feature
> Components: effective-pom
>Affects Versions: 3.1.0
>Reporter: Hervé Boutemy
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> during in-memory effective pom building (by maven-model-builder), the source
> location of content is kept in memory: see [Modello documentation on location
> tracking|https://codehaus-plexus.github.io/modello/location-tracking.html]
> and MNG-1803 for its integration into Maven model
> adding this information as comment on every line of generated XML would ease
> tracking for end users (and not only m2e users, who get "Jump to location"
> hint when editing their pom.xml in Eclipse...)
> This will require a Modello enhancement (see [Modello
> #28|https://github.com/codehaus-plexus/modello/issues/28]) then integration
> (idea found during Devoxx 2018 Maven BoF, since users were missing ways to
> diagnose unexpected result in effective pom)
> Sample result is the addition of comments with modelId and "line xxx" at the
> end of each line of generated XML:
> {code:xml}$ mvn -Dverbose
> org.apache.maven.plugins:maven-help-plugin:3.1.2-SNAPSHOT:effective-pom
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.apache.maven.plugins:maven-help-plugin
> >-
> [INFO] Building Apache Maven Help Plugin 3.1.2-SNAPSHOT
> [INFO] [ maven-plugin
> ]
> [INFO]
> [INFO] --- maven-help-plugin:3.1.2-SNAPSHOT:effective-pom (default-cli) @
> maven-help-plugin ---
> [INFO]
> Effective POMs, after inheritance, interpolation, and profiles are applied:
>
>
>
>
>
>
>
>
>
>
>
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
>
> maven-plugins
> org.apache.maven.plugins
> 33
> ../../pom/maven/maven-plugins/pom.xml
>
> org.apache.maven.plugins
> maven-help-plugin
> 3.1.2-SNAPSHOT
> maven-plugin
> Apache Maven Help Plugin
> The Maven Help plugin provides goals aimed at helping to make
> sense out of
> the build environment. It includes the ability to view the effective
> POM and settings files, after inheritance and active profiles
> have been applied, as well as a describe a particular plugin goal to give
> usage information.
> https://maven.apache.org/plugins/maven-help-plugin/
> 2001
>
> The Apache Software Foundation
> https://www.apache.org/
>
>
>
> Apache License, Version 2.0
> https://www.apache.org/licenses/LICENSE-2.0.txt
> repo
>
>
> ...{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-help-plugin] asfgit closed pull request #4: MPH-160
asfgit closed pull request #4: MPH-160 URL: https://github.com/apache/maven-help-plugin/pull/4 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] jglick edited a comment on issue #225: [MNG-6405] Fix basedir in MavenProject.deepCopy
jglick edited a comment on issue #225: [MNG-6405] Fix basedir in MavenProject.deepCopy URL: https://github.com/apache/maven/pull/225#issuecomment-482770176 I can add a unit test if you like. I am not sure that is going to be the most convincing demonstration that the reported bug is fixed, but it is something. 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] jglick commented on issue #225: [MNG-6405] Fix basedir in MavenProject.deepCopy
jglick commented on issue #225: [MNG-6405] Fix basedir in MavenProject.deepCopy URL: https://github.com/apache/maven/pull/225#issuecomment-482770176 I can add a unit test if you like. I am not sure that is going to the most convincing demonstration that the reported bug is fixed, but it is something. 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-indexer] fuss86 edited a comment on issue #26: ability to set index temp directory
fuss86 edited a comment on issue #26: ability to set index temp directory URL: https://github.com/apache/maven-indexer/pull/26#issuecomment-482734190 I'll be back to this PR soon :) (Just realized I almost repeated myself after 27 days :) ) 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-indexer] fuss86 commented on issue #26: ability to set index temp directory
fuss86 commented on issue #26: ability to set index temp directory URL: https://github.com/apache/maven-indexer/pull/26#issuecomment-482734190 I'll be back to this PR soon :) 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] [Closed] (MINDEXER-114) Extend JarFileContentsIndexCreator to support zip files
[ https://issues.apache.org/jira/browse/MINDEXER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MINDEXER-114. - Resolution: Fixed > Extend JarFileContentsIndexCreator to support zip files > --- > > Key: MINDEXER-114 > URL: https://issues.apache.org/jira/browse/MINDEXER-114 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 6.0.0 >Reporter: Przemysław Fusik >Assignee: Sylwester Lachiewicz >Priority: Minor > Labels: pull-request-available > Fix For: 6.0.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we are able to index Java class names from a Maven artifacts stored > as _.jar_ or _.war_. We can support _.zip_ as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINDEXER-114) Extend JarFileContentsIndexCreator to support zip files
[ https://issues.apache.org/jira/browse/MINDEXER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816679#comment-16816679 ] Sylwester Lachiewicz commented on MINDEXER-114: --- Done in [915530e242b9e5b509b8d2ead796b6a79258ec23|https://gitbox.apache.org/repos/asf?p=maven-indexer.git;a=commit;h=915530e242b9e5b509b8d2ead796b6a79258ec23] > Extend JarFileContentsIndexCreator to support zip files > --- > > Key: MINDEXER-114 > URL: https://issues.apache.org/jira/browse/MINDEXER-114 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 6.0.0 >Reporter: Przemysław Fusik >Assignee: Sylwester Lachiewicz >Priority: Minor > Labels: pull-request-available > Fix For: 6.0.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we are able to index Java class names from a Maven artifacts stored > as _.jar_ or _.war_. We can support _.zip_ as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINDEXER-114) Extend JarFileContentsIndexCreator to support zip files
[ https://issues.apache.org/jira/browse/MINDEXER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MINDEXER-114: -- Fix Version/s: 6.0.1 > Extend JarFileContentsIndexCreator to support zip files > --- > > Key: MINDEXER-114 > URL: https://issues.apache.org/jira/browse/MINDEXER-114 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 6.0.0 >Reporter: Przemysław Fusik >Assignee: Sylwester Lachiewicz >Priority: Minor > Labels: pull-request-available > Fix For: 6.0.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we are able to index Java class names from a Maven artifacts stored > as _.jar_ or _.war_. We can support _.zip_ as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINDEXER-114) Extend JarFileContentsIndexCreator to support zip files
[ https://issues.apache.org/jira/browse/MINDEXER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816677#comment-16816677 ] Hudson commented on MINDEXER-114: - Build succeeded in Jenkins: Maven TLP » maven-indexer » master #7 See https://builds.apache.org/job/maven-box/job/maven-indexer/job/master/7/ > Extend JarFileContentsIndexCreator to support zip files > --- > > Key: MINDEXER-114 > URL: https://issues.apache.org/jira/browse/MINDEXER-114 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 6.0.0 >Reporter: Przemysław Fusik >Assignee: Sylwester Lachiewicz >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Currently we are able to index Java class names from a Maven artifacts stored > as _.jar_ or _.war_. We can support _.zip_ as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[ https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816672#comment-16816672 ] Tibor Digana commented on SUREFIRE-1546: [~marcphilipp] [~Srdo] This code extracts display name of method and display name of class. https://github.com/apache/maven-surefire/blob/1546-1222/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java#L225 > JUnit 5 runner does not honor JUnit 5 display names > --- > > Key: SUREFIRE-1546 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1546 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Affects Versions: 2.22.0 >Reporter: Romain Manni-Bucau >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Time Spent: 20m > Remaining Estimate: 0h > > JUnit 5 runner should respect the test @DisplayName instead of displaying the > classname if any is defined. Seems last release doesn't support that feature > of JUnit 5 making the console output and reports not the expected ones. > > Origin: https://github.com/junit-team/junit5/issues/990 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-indexer] asfgit closed pull request #25: [MINDEXER-114] Extend JarFileContentsIndexCreator to support zip files
asfgit closed pull request #25: [MINDEXER-114] Extend JarFileContentsIndexCreator to support zip files URL: https://github.com/apache/maven-indexer/pull/25 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-indexer] slachiewicz commented on issue #25: [MINDEXER-114] Extend JarFileContentsIndexCreator to support zip files
slachiewicz commented on issue #25: [MINDEXER-114] Extend JarFileContentsIndexCreator to support zip files URL: https://github.com/apache/maven-indexer/pull/25#issuecomment-482728214 Build passed ok LGTM 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] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816668#comment-16816668
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/12/19 9:24 PM:
-
[~marcphilipp]
[~Srdo]
We differenciate display name between class and method in Surefire.
These are two therefore for us.
Which of {{com.somepackage.TestClass > bar(int) > myDisplayName}} is the
method's display name?
It is obvious that {{com.somepackage.TestClass}} is the display name for the
test class.
[~Srdo]
Regarding the configuration of Surefire in POM. Suppose this is hardware and we
do not recognize such a detail like parameterized test on the reporter level.
was (Author: tibor17):
[~marcphilipp]
[~Srdo]
We differenciate display name between class and method in Surefire.
These are two therefore for us.
Which of {{com.somepackage.TestClass > bar(int) > myDisplayName}} is the
method's display name?
It is obvious that {{com.somepackage.TestClass}} is the display name for the
test class.
[~Srdo]
Regarding the configuration of Surefire in POM. Suppose this is hardware and we
do not recognize such a detail like parameterized test in the reporter level.
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MINDEXER-114) Extend JarFileContentsIndexCreator to support zip files
[ https://issues.apache.org/jira/browse/MINDEXER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MINDEXER-114: - Assignee: Sylwester Lachiewicz > Extend JarFileContentsIndexCreator to support zip files > --- > > Key: MINDEXER-114 > URL: https://issues.apache.org/jira/browse/MINDEXER-114 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 6.0.0 >Reporter: Przemysław Fusik >Assignee: Sylwester Lachiewicz >Priority: Minor > Labels: pull-request-available > > Currently we are able to index Java class names from a Maven artifacts stored > as _.jar_ or _.war_. We can support _.zip_ as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816668#comment-16816668
]
Tibor Digana commented on SUREFIRE-1546:
[~marcphilipp]
[~Srdo]
We differenciate display name between class and method in Surefire.
These are two therefore for us.
Which of {{com.somepackage.TestClass > bar(int) > myDisplayName}} is the
method's display name?
It is obvious that {{com.somepackage.TestClass}} is the display name for the
test class.
[~Srdo]
Regarding the configuration of Surefire in POM. uppose this is hardware and we
do not recognize such a detail like parameterized test in the reporter level.
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816668#comment-16816668
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/12/19 9:23 PM:
-
[~marcphilipp]
[~Srdo]
We differenciate display name between class and method in Surefire.
These are two therefore for us.
Which of {{com.somepackage.TestClass > bar(int) > myDisplayName}} is the
method's display name?
It is obvious that {{com.somepackage.TestClass}} is the display name for the
test class.
[~Srdo]
Regarding the configuration of Surefire in POM. Suppose this is hardware and we
do not recognize such a detail like parameterized test in the reporter level.
was (Author: tibor17):
[~marcphilipp]
[~Srdo]
We differenciate display name between class and method in Surefire.
These are two therefore for us.
Which of {{com.somepackage.TestClass > bar(int) > myDisplayName}} is the
method's display name?
It is obvious that {{com.somepackage.TestClass}} is the display name for the
test class.
[~Srdo]
Regarding the configuration of Surefire in POM. uppose this is hardware and we
do not recognize such a detail like parameterized test in the reporter level.
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHADE-316) Explicit minijar includes
[ https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816652#comment-16816652 ] Markus Karg commented on MSHADE-316: [~rfscholte] It is definitively *not* possible with the existing plugin, as a single include _automatically excludes all other classes_. The fact that de-facto the existing plugin does that bad behavior, is the cause why I spend a day to implement it. You _cannot_ specify a single class exemption for the minijar filter without my PR (been there). > Explicit minijar includes > - > > Key: MSHADE-316 > URL: https://issues.apache.org/jira/browse/MSHADE-316 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Markus Karg >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Minijar currently respects includes, but these have a drawback: Once you > defined an include, the _default includes_ are gone! But what you actually > want to have when combining minijar with includes is just an "exception" to > minijar's filtering, not a complete replacement of the default includes! > So what we need to make this work intuitively is either "explicit minijar > exceptions", or a "useDefaultIncludes=true" option that turns the notion from > "replace default includes by the single given include" to "add the single > given include ontop of the default includes". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-shade-plugin] mkarg commented on issue #17: [MSHADE-313] - Keep Services
mkarg commented on issue #17: [MSHADE-313] - Keep Services URL: https://github.com/apache/maven-shade-plugin/pull/17#issuecomment-482719826 @rfscholte Squash done. :-) 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-indexer] fuss86 commented on issue #25: [MINDEXER-114] Extend JarFileContentsIndexCreator to support zip files
fuss86 commented on issue #25: [MINDEXER-114] Extend JarFileContentsIndexCreator to support zip files URL: https://github.com/apache/maven-indexer/pull/25#issuecomment-482716418 rebased :) 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-indexer] asfgit merged pull request #34: Correct errors with optional scope in dependency
asfgit merged pull request #34: Correct errors with optional scope in dependency URL: https://github.com/apache/maven-indexer/pull/34 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] rfscholte commented on issue #225: [MNG-6405] Fix basedir in MavenProject.deepCopy
rfscholte commented on issue #225: [MNG-6405] Fix basedir in MavenProject.deepCopy URL: https://github.com/apache/maven/pull/225#issuecomment-482691537 Looks like this is very easy to verify with a unittest, so can you add it? 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] jglick commented on issue #225: [MNG-6405] Fix basedir in MavenProject.deepCopy
jglick commented on issue #225: [MNG-6405] Fix basedir in MavenProject.deepCopy URL: https://github.com/apache/maven/pull/225#issuecomment-482684615 [Ping](https://lists.apache.org/thread.html/9de4c12707f48bfadaac1cc4d248d6f29f04843519655fe2f2ae571d@%3Cdev.maven.apache.org%3E) 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-shade-plugin] rfscholte commented on issue #17: [MSHADE-313] - Keep Services
rfscholte commented on issue #17: [MSHADE-313] - Keep Services URL: https://github.com/apache/maven-shade-plugin/pull/17#issuecomment-482684154 Can you squash these commits? 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-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816570#comment-16816570
]
Stig Rohde Døssing commented on SUREFIRE-1546:
--
[~marcphilipp] That would be nice. So for parameterized tests it could look like
{code}
com.somepackage.TestClass > bar(int) > [1] 54
{code}
if you were using the default DisplayName
(https://junit.org/junit5/docs/current/api/org/junit/jupiter/params/ParameterizedTest.html#DEFAULT_DISPLAY_NAME).
What if you set a custom DisplayName? Would it look like
{code}
com.somepackage.TestClass > bar(int) > myDisplayName
{code}
?
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHADE-316) Explicit minijar includes
[ https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816569#comment-16816569 ] Robert Scholte commented on MSHADE-316: --- Looks very much like [https://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html] . It sounds like xml config-based Spring, which should suffer with the same issues. I would need to analyze that, but I would expect it is already supported. > Explicit minijar includes > - > > Key: MSHADE-316 > URL: https://issues.apache.org/jira/browse/MSHADE-316 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Markus Karg >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Minijar currently respects includes, but these have a drawback: Once you > defined an include, the _default includes_ are gone! But what you actually > want to have when combining minijar with includes is just an "exception" to > minijar's filtering, not a complete replacement of the default includes! > So what we need to make this work intuitively is either "explicit minijar > exceptions", or a "useDefaultIncludes=true" option that turns the notion from > "replace default includes by the single given include" to "add the single > given include ontop of the default includes". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-shade-plugin] mkarg commented on issue #17: [MSHADE-313] - Keep Services
mkarg commented on issue #17: [MSHADE-313] - Keep Services URL: https://github.com/apache/maven-shade-plugin/pull/17#issuecomment-482663570 @rfscholte Fixed all you asked for. Please continue review. :-) 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] (MSHADE-316) Explicit minijar includes
[ https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816509#comment-16816509 ] Markus Karg commented on MSHADE-316: [~rfscholte] No, this is a misunderstanding. The idea is *not* to have full control over the classes being added. The idea is (see also my PR) is to *prevent minjar's removal of explicitly marked classes*. Use case: A dependency shall get included into a shaded jar, but that dependency is loaded by *Reflection*, so the original artifact does not directly reference the *Class* to load, but only holds a *String* with the class name. The Minijar filter will remove that class, so the shaded JAR will be broken. With my PR, you can add an _explicit minijar exemption_ on that single class name (or pattern), so minijar will keep that file even *without a technically detectable* need. This cannot be done with the existing include filters, because once _at least one_ include is explictly defined, the default (include _all_) is switched off so _all_ other classes would be _excluded_. The solution is my PR which simply provides an *exemption* for Minijar. There is a rather popular real-life scenario: Minijar breaks _Eclipse Jersey_ because one of Jersey's dependency is loaded by Reflection. > Explicit minijar includes > - > > Key: MSHADE-316 > URL: https://issues.apache.org/jira/browse/MSHADE-316 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Markus Karg >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Minijar currently respects includes, but these have a drawback: Once you > defined an include, the _default includes_ are gone! But what you actually > want to have when combining minijar with includes is just an "exception" to > minijar's filtering, not a complete replacement of the default includes! > So what we need to make this work intuitively is either "explicit minijar > exceptions", or a "useDefaultIncludes=true" option that turns the notion from > "replace default includes by the single given include" to "add the single > given include ontop of the default includes". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MRESOLVER-85) Avoid ByteBuffer incompatibility when compiling with JDK9+
[
https://issues.apache.org/jira/browse/MRESOLVER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MRESOLVER-85:
-
Assignee: (was: Sylwester Lachiewicz)
> Avoid ByteBuffer incompatibility when compiling with JDK9+
> --
>
> Key: MRESOLVER-85
> URL: https://issues.apache.org/jira/browse/MRESOLVER-85
> Project: Maven Resolver
> Issue Type: Improvement
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Sylwester Lachiewicz
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Restore possibility to create a release with Java9+
>
> The explanation for this is given in
> [apache/felix#114|https://github.com/apache/felix/pull/114] :
> Java 9 introduces overridden methods with covariant return types for the
> following methods in java.nio.ByteBuffer:
> position (int newPosition)
> limit (int newLimit)
> flip ()
> clear ()
> mark ()
> reset ()
> rewind ()
> In Java 9 they all now return ByteBuffer, whereas the methods they override
> return Buffer,
> resulting in exceptions like this when executing on Java 8 and lower:
> {{java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer}}
> This is because the generated byte code includes the static return type of
> the method, which is not found on Java 8 and lower because the overloaded
> methods with covariant return types don't exist (the issue appears even with
> source and target 8 or lower in compilation parameters).
> The solution is to cast ByteBuffer instances to Buffer before calling the
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MRESOLVER-85) Avoid ByteBuffer incompatibility when compiling with JDK9+
[
https://issues.apache.org/jira/browse/MRESOLVER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz closed MRESOLVER-85.
-
Resolution: Not A Problem
> Avoid ByteBuffer incompatibility when compiling with JDK9+
> --
>
> Key: MRESOLVER-85
> URL: https://issues.apache.org/jira/browse/MRESOLVER-85
> Project: Maven Resolver
> Issue Type: Improvement
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Sylwester Lachiewicz
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Restore possibility to create a release with Java9+
>
> The explanation for this is given in
> [apache/felix#114|https://github.com/apache/felix/pull/114] :
> Java 9 introduces overridden methods with covariant return types for the
> following methods in java.nio.ByteBuffer:
> position (int newPosition)
> limit (int newLimit)
> flip ()
> clear ()
> mark ()
> reset ()
> rewind ()
> In Java 9 they all now return ByteBuffer, whereas the methods they override
> return Buffer,
> resulting in exceptions like this when executing on Java 8 and lower:
> {{java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer}}
> This is because the generated byte code includes the static return type of
> the method, which is not found on Java 8 and lower because the overloaded
> methods with covariant return types don't exist (the issue appears even with
> source and target 8 or lower in compilation parameters).
> The solution is to cast ByteBuffer instances to Buffer before calling the
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-resolver] slachiewicz closed pull request #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support
slachiewicz closed pull request #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support URL: https://github.com/apache/maven-resolver/pull/32 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] (MRESOLVER-85) Avoid ByteBuffer incompatibility when compiling with JDK9+
[
https://issues.apache.org/jira/browse/MRESOLVER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816502#comment-16816502
]
Sylwester Lachiewicz commented on MRESOLVER-85:
---
ok, thank you for explanations. So no more reasons to implement this change -
closing the ticket.
> Avoid ByteBuffer incompatibility when compiling with JDK9+
> --
>
> Key: MRESOLVER-85
> URL: https://issues.apache.org/jira/browse/MRESOLVER-85
> Project: Maven Resolver
> Issue Type: Improvement
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Restore possibility to create a release with Java9+
>
> The explanation for this is given in
> [apache/felix#114|https://github.com/apache/felix/pull/114] :
> Java 9 introduces overridden methods with covariant return types for the
> following methods in java.nio.ByteBuffer:
> position (int newPosition)
> limit (int newLimit)
> flip ()
> clear ()
> mark ()
> reset ()
> rewind ()
> In Java 9 they all now return ByteBuffer, whereas the methods they override
> return Buffer,
> resulting in exceptions like this when executing on Java 8 and lower:
> {{java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer}}
> This is because the generated byte code includes the static return type of
> the method, which is not found on Java 8 and lower because the overloaded
> methods with covariant return types don't exist (the issue appears even with
> source and target 8 or lower in compilation parameters).
> The solution is to cast ByteBuffer instances to Buffer before calling the
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6636) NPE on reporting convertion when inheritance of with no reports
[
https://issues.apache.org/jira/browse/MNG-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816496#comment-16816496
]
Hervé Boutemy commented on MNG-6636:
simply adding "" aovids the NPE, which is a good basic
workaround, but input location tracking is empty, then this NPE proves a deeper
and more subtle issue:
{noformat}$ mvn -Dverbose
org.apache.maven.plugins:maven-help-plugin:3.2.0-SNAPSHOT:effective-pom
[...}
true
/home/herve/projets/maven/sources/site/target/site
maven-project-info-reports-plugin
index
summary
dependency-info
modules
team
scm
issue-management
mailing-lists
dependency-management
dependencies
dependency-convergence
ci-management
plugin-management
plugins
distribution-management
true
false
[...]
{noformat}
> NPE on reporting convertion when inheritance of with no reports
> ---
>
> Key: MNG-6636
> URL: https://issues.apache.org/jira/browse/MNG-6636
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.6.1
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: 3.6.2
>
>
> when launching Maven on maven-site:
> {noformat}$ mvn clean
> [INFO] Scanning for projects...
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:606)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:243)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:213)
> at
> org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
> (DefaultReportingConverter.java:140)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:479)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:432)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:616){noformat}
> caused by the fact that there is no elements in following
> reportSet:
> {code:xml}
> true
> ${site.output}
>
>
> org.apache.maven.plugins
> maven-project-info-reports-plugin
>
>
>
> true
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6637) NPE while trying to build Maven Site
[
https://issues.apache.org/jira/browse/MNG-6637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816491#comment-16816491
]
Hervé Boutemy commented on MNG-6637:
sorry, MNG-6636 was recorded a few seconds earlier :)
> NPE while trying to build Maven Site
>
>
> Key: MNG-6637
> URL: https://issues.apache.org/jira/browse/MNG-6637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.2
>
>
> Using the maven-site repository and:
> {code}
> mvn site
> {code}
> It simply fails with the following error:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> 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:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:243)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:213)
> at
> org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
> (DefaultReportingConverter.java:140)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:479)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:432)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:616)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:385)
> at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
> at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
> at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:82)
> at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> 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:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6637) NPE while trying to build Maven Site
[
https://issues.apache.org/jira/browse/MNG-6637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MNG-6637.
--
Resolution: Duplicate
> NPE while trying to build Maven Site
>
>
> Key: MNG-6637
> URL: https://issues.apache.org/jira/browse/MNG-6637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.2
>
>
> Using the maven-site repository and:
> {code}
> mvn site
> {code}
> It simply fails with the following error:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> 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:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:243)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:213)
> at
> org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
> (DefaultReportingConverter.java:140)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:479)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:432)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:616)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:385)
> at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
> at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
> at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:82)
> at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> 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:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[ https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816480#comment-16816480 ] Marc Philipp commented on SUREFIRE-1546: FWIW dynamic tests provide another way to deeply nest tests below a method. At least for the console, one solution would be to print all test tree elements below the test class, e.g. _com.somepackage.TestClass > bar(int) >_ [1]. > JUnit 5 runner does not honor JUnit 5 display names > --- > > Key: SUREFIRE-1546 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1546 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Affects Versions: 2.22.0 >Reporter: Romain Manni-Bucau >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Time Spent: 20m > Remaining Estimate: 0h > > JUnit 5 runner should respect the test @DisplayName instead of displaying the > classname if any is defined. Seems last release doesn't support that feature > of JUnit 5 making the console output and reports not the expected ones. > > Origin: https://github.com/junit-team/junit5/issues/990 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRESOLVER-85) Avoid ByteBuffer incompatibility when compiling with JDK9+
[
https://issues.apache.org/jira/browse/MRESOLVER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816478#comment-16816478
]
Robert Scholte commented on MRESOLVER-85:
-
Different major Java versions might already generate different bytecode. When
Hervé verifies the reproducibility of a project, he ensures he's using the same
major version of Java.
> Avoid ByteBuffer incompatibility when compiling with JDK9+
> --
>
> Key: MRESOLVER-85
> URL: https://issues.apache.org/jira/browse/MRESOLVER-85
> Project: Maven Resolver
> Issue Type: Improvement
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Restore possibility to create a release with Java9+
>
> The explanation for this is given in
> [apache/felix#114|https://github.com/apache/felix/pull/114] :
> Java 9 introduces overridden methods with covariant return types for the
> following methods in java.nio.ByteBuffer:
> position (int newPosition)
> limit (int newLimit)
> flip ()
> clear ()
> mark ()
> reset ()
> rewind ()
> In Java 9 they all now return ByteBuffer, whereas the methods they override
> return Buffer,
> resulting in exceptions like this when executing on Java 8 and lower:
> {{java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer}}
> This is because the generated byte code includes the static return type of
> the method, which is not found on Java 8 and lower because the overloaded
> methods with covariant return types don't exist (the issue appears even with
> source and target 8 or lower in compilation parameters).
> The solution is to cast ByteBuffer instances to Buffer before calling the
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6637) NPE while trying to build Maven Site
Karl Heinz Marbaise created MNG-6637:
Summary: NPE while trying to build Maven Site
Key: MNG-6637
URL: https://issues.apache.org/jira/browse/MNG-6637
Project: Maven
Issue Type: Bug
Affects Versions: 3.6.1
Reporter: Karl Heinz Marbaise
Fix For: 3.6.2
Using the maven-site repository and:
{code}
mvn site
{code}
It simply fails with the following error:
{noformat}
[INFO] Scanning for projects...
[ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
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:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
Caused by: java.lang.NullPointerException
at org.apache.maven.model.plugin.DefaultReportingConverter.convert
(DefaultReportingConverter.java:243)
at org.apache.maven.model.plugin.DefaultReportingConverter.convert
(DefaultReportingConverter.java:213)
at org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
(DefaultReportingConverter.java:140)
at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:479)
at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:432)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:616)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:385)
at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
(DefaultGraphBuilder.java:414)
at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
(DefaultGraphBuilder.java:405)
at org.apache.maven.graph.DefaultGraphBuilder.build
(DefaultGraphBuilder.java:82)
at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
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:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6636) NPE on reporting convertion when inheritance of with no reports
Hervé Boutemy created MNG-6636:
--
Summary: NPE on reporting convertion when inheritance of with no
reports
Key: MNG-6636
URL: https://issues.apache.org/jira/browse/MNG-6636
Project: Maven
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.6.1
Reporter: Hervé Boutemy
Fix For: 3.6.2
when launching Maven on maven-site:
{noformat}$ mvn clean
[INFO] Scanning for projects...
[ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
Caused by: java.lang.NullPointerException
at org.apache.maven.model.plugin.DefaultReportingConverter.convert
(DefaultReportingConverter.java:243)
at org.apache.maven.model.plugin.DefaultReportingConverter.convert
(DefaultReportingConverter.java:213)
at org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
(DefaultReportingConverter.java:140)
at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:479)
at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:432)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:616){noformat}
caused by the fact that there is no elements in following
reportSet:
{code:xml}
true
${site.output}
org.apache.maven.plugins
maven-project-info-reports-plugin
true
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816459#comment-16816459
]
Stig Rohde Døssing commented on SUREFIRE-1546:
--
Thanks for responding [~tibor17].
The reporter configuration idea looks good. Will there be a way to
differentiate between parameterized tests and other tests? I'm not sure how to
get reasonable behavior out of the displayname for parameterized tests
alongside regular tests.
For example, if you have a test with
{code}
@Test
@DisplayName("cool test")
void test() {}
@Test
void foo() {}
@ParameterizedTest
@ValueSource(intValue = {15, 54})
void bar(int x) {}
{code}
My preference here would be output like
{quote}
[ERROR] cool test
[ERROR] com.somepackage.TestClass.foo
[ERROR] com.somepackage.TestClass.bar[0] 15
[ERROR] com.somepackage.TestClass.bar[1] 54
{quote}
Won't I have to either choose to set PHRASED, giving me
{quote}
[ERROR] cool test
[ERROR] com.somepackage.TestClass.foo
[ERROR] com.somepackage.TestClass.[0] 15
[ERROR] com.somepackage.TestClass.[1] 54
{quote}
i.e. losing the ParameterizedTest method names, or DEFAULT
{quote}
[ERROR] com.somepackage.TestClass.test
[ERROR] com.somepackage.TestClass.foo
[ERROR] com.somepackage.TestClass.bar[0] 15
[ERROR] com.somepackage.TestClass.bar[1] 54
{quote}
i.e. losing the DisplayName?
Also I'm just saying that for parameterized tests specifically, defaulting to a
behavior where the console doesn't print the test method name for parameterized
tests is not great. I can see why the JUnit guys don't include it by default,
since it is useful to be able to leave it off in a hierarchical view in an IDE
(since e.g. having a single com.somepackage.TestClass.bar header, and then
points "[0] 15" and "[1] 54" under that header makes sense). The console output
in Surefire is flat though, and ends up lacking information about which test
method failed.
Maybe this is something I should ask about on the JUnit project? I'm not sure
how Surefire would know whether to include the parameterized test method name
or not, since users may also set a custom DisplayName, in which case the method
name shouldn't be there?
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816403#comment-16816403
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/12/19 4:12 PM:
-
[~Srdo]
We are aware of this. I want to make you sure that we do not want to break
backwards compatibility in version 3.0.0-M4 (broken in M6).
Therefore a complex configuration is required and every user may change this
behavior on the level of:
1. POM configuration
2. Java implementation like a plugin to Surefire plugin (Open Closed Design
Principle) done by user - see the XML attribute {{implementation}}
Here is an example of stateless XML reporter
{code:xml}
maven-surefire-plugin
3.0.0-SNAPSHOT
true
DEFAULT
PHRASED
PHRASED
{code}
and there are next two reporters. For more information see
https://github.com/apache/maven-surefire/pull/226#issuecomment-480264926
The aim of version {{3.0.0}} is to have such of these extensions which open
possibility for the user to change the behavior of this plugin without asking
us development team. This brings a certain freedom for everyone.
We do not want to break behavior in versions but we have to break only few
config parameters that will be moved to a block like the above, and one will be
removed, and filtering of classes would not be like
{{\*\*/\*\*/\*Some\*Test.java}} but it will follow fully classified class names
e.g. {{\*\*.\*\*.\*Some\*Test}}. More extensions will be added.
was (Author: tibor17):
[~Srdo]
We are aware of this. I want to make you sure that we do not want to break
backwards compatibility in version 3.0.0-M4 (broken in M6).
Therefore a complex configuration is required and every user may change this
behavior on the level of:
1. POM configuration
2. Java implementation like a plugin to Surefire plugin (Open Closed Design
Principle) done by user - see the XML attribute {{implementation}}
Here is an example of stateless XML reporter
{code:xml}
maven-surefire-plugin
3.0.0-SNAPSHOT
true
DEFAULT
PHRASED
PHRASED
{code}
and there are next two reporters. For more information see
https://github.com/apache/maven-surefire/pull/226#issuecomment-480264926
The aim of version {{3.0.0}} is to have such of these extensions which open
possibility for the user to change the behavior of this plugin without asking
us development team. This brings a certain freedom for everyone.
We do not want to break behavior in versions but we have to break only few
config parameters that will be moved to a block like the above, and one will be
removed, and filtering of classes would not be like {{
\*\*/\*\*/\*Some\*Test.java}} but it will follow fully classified class names
e.g. {{\*\*.\*\*.\*Some\*Test}}. More extensions will be added.
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816403#comment-16816403
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/12/19 4:12 PM:
-
[~Srdo]
We are aware of this. I want to make you sure that we do not want to break
backwards compatibility in version 3.0.0-M4 (broken in M6).
Therefore a complex configuration is required and every user may change this
behavior on the level of:
1. POM configuration
2. Java implementation like a plugin to Surefire plugin (Open Closed Design
Principle) done by user - see the XML attribute {{implementation}}
Here is an example of stateless XML reporter
{code:xml}
maven-surefire-plugin
3.0.0-SNAPSHOT
true
DEFAULT
PHRASED
PHRASED
{code}
and there are next two reporters. For more information see
https://github.com/apache/maven-surefire/pull/226#issuecomment-480264926
The aim of version {{3.0.0}} is to have such of these extensions which open
possibility for the user to change the behavior of this plugin without asking
us development team. This brings a certain freedom for everyone.
We do not want to break behavior in versions but we have to break only few
config parameters that will be moved to a block like the above, and one will be
removed, and filtering of classes would not be like {{
\*\*/\*\*/\*Some\*Test.java}} but it will follow fully classified class names
e.g. {{\*\*.\*\*.\*Some\*Test}}. More extensions will be added.
was (Author: tibor17):
[~Srdo]
We are aware of this. I want to make you sure that we do not want to break
backwards compatibility in version 3.0.0-M4 (broken in M6).
Therefore a complex configuration is required and every user may change this
behavior on the level of:
1. POM configuration
2. Java implementation like a plugin to Surefire plugin (Open Closed Design
Principle) done by user - see the XML attribute {{implementation}}
Here is an example of stateless XML reporter
{code:xml}
maven-surefire-plugin
3.0.0-SNAPSHOT
true
DEFAULT
PHRASED
PHRASED
{code}
and there are next two reporters. For more information see
https://github.com/apache/maven-surefire/pull/226#issuecomment-480264926
The aim of version {{3.0.0}} is to have such of these extensions which open
possibility for the user to change the behavior of this plugin without asking
us development team. This brings a certain freedom for everyone.
We do not want to break behavior in versions but we have to break only few
config parameters that will be moved to a block like the above, and one will be
removed, and filtering of classes would not be like{{
\*\*/\*\*/\*Some\*Test.java}} but it will follow fully classified class names
e.g. {{\*\*.\*\*.\*Some\*Test}}. More extensions will be added.
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816403#comment-16816403
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/12/19 4:11 PM:
-
[~Srdo]
We are aware of this. I want to make you sure that we do not want to break
backwards compatibility in version 3.0.0-M4 (broken in M6).
Therefore a complex configuration is required and every user may change this
behavior on the level of:
1. POM configuration
2. Java implementation like a plugin to Surefire plugin (Open Closed Design
Principle) done by user - see the XML attribute {{implementation}}
Here is an example of stateless XML reporter
{code:xml}
maven-surefire-plugin
3.0.0-SNAPSHOT
true
DEFAULT
PHRASED
PHRASED
{code}
and there are next two reporters. For more information see
https://github.com/apache/maven-surefire/pull/226#issuecomment-480264926
The aim of version {{3.0.0}} is to have such of these extensions which open
possibility for the user to change the behavior of this plugin without asking
us development team. This brings a certain freedom for everyone.
We do not want to break behavior in versions but we have to break only few
config parameters that will be moved to a block like the above, and one will be
removed, and filtering of classes would not be like{{
\*\*/\*\*/\*Some\*Test.java}} but it will follow fully classified class names
e.g. {{\*\*.\*\*.\*Some\*Test}}. More extensions will be added.
was (Author: tibor17):
[~Srdo]
We are aware of this. I want to make you sure that we do not want to break
backwards compatibility in version 3.0.0-M4 (broken in M6).
Therefore a complex configuration is required and every user may change this
behavior on the level of:
1. POM configuration
2. Java implementation like a plugin to Surefire plugin (Open Closed Design
Principle) done by user - see the XML attribute {{implementation}}
Here is an example of stateless XML reporter
{code:xml}
maven-surefire-plugin
3.0.0-SNAPSHOT
true
DEFAULT
PHRASED
PHRASED
{code}
and there are next two reporters. For more information see
https://github.com/apache/maven-surefire/pull/226#issuecomment-480264926
The aim of version {{3.0.0}} is to have such of these extensions which open
possibility for the user to change the behavior of this plugin without asking
us development team. This brings a certain freedom for everyone.
We do not want to break behavior in versions but we have to break only few
config parameters that will be moved to a block like the above, and one will be
removed, and filtering of classes would not be like **/**/*Some*Test.java but
it will follow fully classified class names e.g. **.**.*Some*Test. More
extensions will be added.
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816403#comment-16816403
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/12/19 4:11 PM:
-
[~Srdo]
We are aware of this. I want to make you sure that we do not want to break
backwards compatibility in version 3.0.0-M4 (broken in M6).
Therefore a complex configuration is required and every user may change this
behavior on the level of:
1. POM configuration
2. Java implementation like a plugin to Surefire plugin (Open Closed Design
Principle) done by user - see the XML attribute {{implementation}}
Here is an example of stateless XML reporter
{code:xml}
maven-surefire-plugin
3.0.0-SNAPSHOT
true
DEFAULT
PHRASED
PHRASED
{code}
and there are next two reporters. For more information see
https://github.com/apache/maven-surefire/pull/226#issuecomment-480264926
The aim of version {{3.0.0}} is to have such of these extensions which open
possibility for the user to change the behavior of this plugin without asking
us development team. This brings a certain freedom for everyone.
We do not want to break behavior in versions but we have to break only few
config parameters that will be moved to a block like the above, and one will be
removed, and filtering of classes would not be like **/**/*Some*Test.java but
it will follow fully classified class names e.g. **.**.*Some*Test. More
extensions will be added.
was (Author: tibor17):
[~Srdo]
We are aware of this. I want to make you sure that we do not want to break
backwards compatibility in version 3.0.0-M4 (broken in M6).
Therefore a complex configuration is required and every user may change this
behavior on the level of:
1. POM configuration
2. Java implementation like a plugin to Surefire plugin (Open Closed Design
Pattern) done by user - see the XML attribute {{implementation}}
Here is an example of stateless XML reporter
{code:xml}
maven-surefire-plugin
3.0.0-SNAPSHOT
true
DEFAULT
PHRASED
PHRASED
{code}
and there are next two reporters. For more information see
https://github.com/apache/maven-surefire/pull/226#issuecomment-480264926
The aim of version {{3.0.0}} is to have such of these extensions which open
possibility for the user to change the behavior of this plugin without asking
us development team. This brings a certain freedom for everyone.
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816403#comment-16816403
]
Tibor Digana commented on SUREFIRE-1546:
[~Srdo]
We are aware of this. I want to make you sure that we do not want to break
backwards compatibility in version 3.0.0-M4 (broken in M6).
Therefore a complex configuration is required and every user may change this
behavior on the level of:
1. POM configuration
2. Java implementation like a plugin to Surefire plugin (Open Closed Design
Pattern) done by user - see the XML attribute {{implementation}}
Here is an example of stateless XML reporter
{code:xml}
maven-surefire-plugin
3.0.0-SNAPSHOT
true
DEFAULT
PHRASED
PHRASED
{code}
and there are next two reporters. For more information see
https://github.com/apache/maven-surefire/pull/226#issuecomment-480264926
The aim of version {{3.0.0}} is to have such of these extensions which open
possibility for the user to change the behavior of this plugin without asking
us development team. This brings a certain freedom for everyone.
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816383#comment-16816383
]
Stig Rohde Døssing commented on SUREFIRE-1546:
--
This change causes parameterized tests to lose the method name in the console
output.
For example, running a parameterized test called TestWindowCount declared as
{code}
@ParameterizedTest
@MethodSource(value = "generateCountWindows")
public void testWindowCount(int windowSize, int slideSize) throws Exception
{code}
gives this output
{quote}
[ERROR] org.apache.storm.st.tests.window.SlidingWindowTest.[7] 5, 10 Time
elapsed: 88.167 s <<< FAILURE!
{quote}
Note the missing method name. I don't think this is a good default behavior.
The discussion at
https://github.com/junit-team/junit5/issues/1496#issuecomment-404178095 seems
to imply that excluding the method name is intentional. I think it would be
nicer if the method name were included by default, but I'm not sure if the
issue belongs here (since Surefire could include the method name in the
output), or in JUnit (since the default displayName for parameterized tests
could be changed). What do you think?
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-resolver] slachiewicz commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support
slachiewicz commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support URL: https://github.com/apache/maven-resolver/pull/32#issuecomment-482621164 > Indeed, but the `+` is still wrong. so all our builds should be wrong https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpStdBuild.groovy;h=8bf4492dd33d5a226ed0f05b549d6f48f20767ad;hb=HEAD#l55 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-resolver] michael-o commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support
michael-o commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support URL: https://github.com/apache/maven-resolver/pull/32#issuecomment-482619582 Indeed, but the `+` is still wrong. 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-resolver] slachiewicz commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support
slachiewicz commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support URL: https://github.com/apache/maven-resolver/pull/32#issuecomment-482614782 > That's nonsense, look into the POM. There is no such profile. But you asked to run its :) here is profile.. https://github.com/apache/maven-resolver/blob/master/maven-resolver-demos/maven-resolver-demo-maven-plugin/pom.xml#L87 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-resolver] michael-o commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support
michael-o commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support URL: https://github.com/apache/maven-resolver/pull/32#issuecomment-482613179 That's nonsense, look into the POM. There is no such profile. 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-resolver] slachiewicz commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support
slachiewicz commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support URL: https://github.com/apache/maven-resolver/pull/32#issuecomment-482611884 run-its - i used the value from command line in latest Jenkins build log. > >[Pipeline] bat >Commit message: "[MRESOLVER-7] Download dependency POMs in parallel" > >f:\jenkins\jenkins-slave\workspace\maven-box_maven-resolver_master\m>mvn -P+run-its -Dmaven.test.failure.ignore=true -Dfindbugs.failOnError=false -Dfindbugs.skip=true clean verify >- withMaven Wrapper script - > >f:\jenkins\jenkins-slave\workspace\maven-box_maven-resolver_master@2\m>mvn -P+run-its -Dmaven.test.failure.ignore=true -Dfindbugs.failOnError=false -Dfindbugs.skip=true clean verify >- withMaven Wrapper script - >Cleaning workspace >git clean -fdx # timeout=10 >Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) >Maven home: F:\jenkins\tools\maven\apache-maven-3.5.2\bin\.. 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] (MRESOLVER-85) Avoid ByteBuffer incompatibility when compiling with JDK9+
[
https://issues.apache.org/jira/browse/MRESOLVER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816333#comment-16816333
]
Sylwester Lachiewicz commented on MRESOLVER-85:
---
I thought that we are trying to have reproducible builds that will be somehow
independent of JDK version - that's why I proposed to add this workaround with
casting. I hope in the near future more developers will use LTS JDK 11 to
develop code and also our release managers will drop older JDK (and probably
only use CI to run compatibility tests).
I also reverted to a state where we need JDK 7/8 to release maven-resolver.
If you think that this change is not necessary, then we can close the issue -
no problem.
> Avoid ByteBuffer incompatibility when compiling with JDK9+
> --
>
> Key: MRESOLVER-85
> URL: https://issues.apache.org/jira/browse/MRESOLVER-85
> Project: Maven Resolver
> Issue Type: Improvement
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Restore possibility to create a release with Java9+
>
> The explanation for this is given in
> [apache/felix#114|https://github.com/apache/felix/pull/114] :
> Java 9 introduces overridden methods with covariant return types for the
> following methods in java.nio.ByteBuffer:
> position (int newPosition)
> limit (int newLimit)
> flip ()
> clear ()
> mark ()
> reset ()
> rewind ()
> In Java 9 they all now return ByteBuffer, whereas the methods they override
> return Buffer,
> resulting in exceptions like this when executing on Java 8 and lower:
> {{java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer}}
> This is because the generated byte code includes the static return type of
> the method, which is not found on Java 8 and lower because the overloaded
> methods with covariant return types don't exist (the issue appears even with
> source and target 8 or lower in compilation parameters).
> The solution is to cast ByteBuffer instances to Buffer before calling the
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MRESOLVER-85) Avoid ByteBuffer incompatibility when compiling with JDK9+
[
https://issues.apache.org/jira/browse/MRESOLVER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MRESOLVER-85:
-
Assignee: Sylwester Lachiewicz
> Avoid ByteBuffer incompatibility when compiling with JDK9+
> --
>
> Key: MRESOLVER-85
> URL: https://issues.apache.org/jira/browse/MRESOLVER-85
> Project: Maven Resolver
> Issue Type: Improvement
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Restore possibility to create a release with Java9+
>
> The explanation for this is given in
> [apache/felix#114|https://github.com/apache/felix/pull/114] :
> Java 9 introduces overridden methods with covariant return types for the
> following methods in java.nio.ByteBuffer:
> position (int newPosition)
> limit (int newLimit)
> flip ()
> clear ()
> mark ()
> reset ()
> rewind ()
> In Java 9 they all now return ByteBuffer, whereas the methods they override
> return Buffer,
> resulting in exceptions like this when executing on Java 8 and lower:
> {{java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer}}
> This is because the generated byte code includes the static return type of
> the method, which is not found on Java 8 and lower because the overloaded
> methods with covariant return types don't exist (the issue appears even with
> source and target 8 or lower in compilation parameters).
> The solution is to cast ByteBuffer instances to Buffer before calling the
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-resolver] michael-o commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support
michael-o commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support URL: https://github.com/apache/maven-resolver/pull/32#issuecomment-482607364 This is wrong, you should be able to do so. Can you raise this on the dev list? 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-resolver] slachiewicz commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support
slachiewicz commented on issue #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support URL: https://github.com/apache/maven-resolver/pull/32#issuecomment-482605654 I don't have rights to push to maven-resolver branch to run in ASF Jenkins, but all test passed locally with Java 12. Also, tests running on Linux with Travis CI - passed without issues for OpenJDK 7, 8, 11, 12. https://travis-ci.org/slachiewicz/maven-resolver/builds/519294192 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-resolver] slachiewicz commented on a change in pull request #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support
slachiewicz commented on a change in pull request #32: [MRESOLVER-85] Cast
ByteBuffer to Byte for JDK8 support
URL: https://github.com/apache/maven-resolver/pull/32#discussion_r274938990
##
File path:
maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/ChecksumCalculator.java
##
@@ -199,9 +201,10 @@ public void update( ByteBuffer data )
{
for ( Checksum checksum : checksums )
{
-data.mark();
+// Cast ByteBuffer to Byte for JDK8 support
+( ( Buffer ) data ).mark();
Review comment:
ok, updated.
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-resolver] michael-o commented on a change in pull request #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support
michael-o commented on a change in pull request #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support URL: https://github.com/apache/maven-resolver/pull/32#discussion_r274937255 ## File path: .travis.yml ## @@ -19,7 +19,7 @@ before_script: true install: true script: - - mvn verify + - mvn -V -P+run-its clean verify Review comment: `+run-its`? 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] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816273#comment-16816273
]
Michael Osipov commented on MNG-6604:
-
Glad, the workaround works for you. This issue isn't resolve, I will leave it
open until someone can fix this.
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-resolver] michael-o commented on a change in pull request #32: [MRESOLVER-85] Cast ByteBuffer to Byte for JDK8 support
michael-o commented on a change in pull request #32: [MRESOLVER-85] Cast
ByteBuffer to Byte for JDK8 support
URL: https://github.com/apache/maven-resolver/pull/32#discussion_r274909149
##
File path:
maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/ChecksumCalculator.java
##
@@ -199,9 +201,10 @@ public void update( ByteBuffer data )
{
for ( Checksum checksum : checksums )
{
-data.mark();
+// Cast ByteBuffer to Byte for JDK8 support
+( ( Buffer ) data ).mark();
Review comment:
The spaces around `Buffer` aren't necessary.
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-resolver] asfgit closed pull request #30: Fixes MRESOLVER-7, third try
asfgit closed pull request #30: Fixes MRESOLVER-7, third try URL: https://github.com/apache/maven-resolver/pull/30 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] [Closed] (MRESOLVER-7) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MRESOLVER-7. -- Resolution: Fixed Fixed with [9d3b324e82d9b934bf51bb8818c83caf776e6faf|https://gitbox.apache.org/repos/asf?p=mavenre-resolver.git;a=commit;h=9d3b324e82d9b934bf51bb8818c83caf776e6faf]. > Download dependency POMs in parallel > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann >Assignee: Michael Osipov >Priority: Major > Fix For: 1.4.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816267#comment-16816267
]
Martin Todorov commented on MNG-6604:
-
Many thanks for your help, [~michael-o] and [~igorf]!
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOLVER-85) Avoid ByteBuffer incompatibility when compiling with JDK9+
[
https://issues.apache.org/jira/browse/MRESOLVER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816249#comment-16816249
]
Robert Scholte commented on MRESOLVER-85:
-
I guess it is a matter of taste. I don't like class casting, hence prefer to
release it with the target Java version
> Avoid ByteBuffer incompatibility when compiling with JDK9+
> --
>
> Key: MRESOLVER-85
> URL: https://issues.apache.org/jira/browse/MRESOLVER-85
> Project: Maven Resolver
> Issue Type: Improvement
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Sylwester Lachiewicz
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Restore possibility to create a release with Java9+
>
> The explanation for this is given in
> [apache/felix#114|https://github.com/apache/felix/pull/114] :
> Java 9 introduces overridden methods with covariant return types for the
> following methods in java.nio.ByteBuffer:
> position (int newPosition)
> limit (int newLimit)
> flip ()
> clear ()
> mark ()
> reset ()
> rewind ()
> In Java 9 they all now return ByteBuffer, whereas the methods they override
> return Buffer,
> resulting in exceptions like this when executing on Java 8 and lower:
> {{java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer}}
> This is because the generated byte code includes the static return type of
> the method, which is not found on Java 8 and lower because the overloaded
> methods with covariant return types don't exist (the issue appears even with
> source and target 8 or lower in compilation parameters).
> The solution is to cast ByteBuffer instances to Buffer before calling the
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOLVER-85) Avoid ByteBuffer incompatibility when compiling with JDK9+
[
https://issues.apache.org/jira/browse/MRESOLVER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816230#comment-16816230
]
Sylwester Lachiewicz commented on MRESOLVER-85:
---
Yes Robert, in one of the commits in the PR I reverted special profile.
> Avoid ByteBuffer incompatibility when compiling with JDK9+
> --
>
> Key: MRESOLVER-85
> URL: https://issues.apache.org/jira/browse/MRESOLVER-85
> Project: Maven Resolver
> Issue Type: Improvement
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Sylwester Lachiewicz
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Restore possibility to create a release with Java9+
>
> The explanation for this is given in
> [apache/felix#114|https://github.com/apache/felix/pull/114] :
> Java 9 introduces overridden methods with covariant return types for the
> following methods in java.nio.ByteBuffer:
> position (int newPosition)
> limit (int newLimit)
> flip ()
> clear ()
> mark ()
> reset ()
> rewind ()
> In Java 9 they all now return ByteBuffer, whereas the methods they override
> return Buffer,
> resulting in exceptions like this when executing on Java 8 and lower:
> {{java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer}}
> This is because the generated byte code includes the static return type of
> the method, which is not found on Java 8 and lower because the overloaded
> methods with covariant return types don't exist (the issue appears even with
> source and target 8 or lower in compilation parameters).
> The solution is to cast ByteBuffer instances to Buffer before calling the
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5577) Convert the core to use JSR 330 and remove the use of Plexus
[ https://issues.apache.org/jira/browse/MNG-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5577: Description: Remove the use of Plexus annotations and use JSR330 annotations throughout the core. *NOTE:* The descriptor must still be generated, since Maven doesn't do annotation scanning for performance reason. It simply reads the descriptor file(s). was:Remove the use of Plexus annotations and use JSR330 annotations throughout the core. > Convert the core to use JSR 330 and remove the use of Plexus > > > Key: MNG-5577 > URL: https://issues.apache.org/jira/browse/MNG-5577 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Jason van Zyl >Priority: Major > Fix For: 3.6.x-candidate > > Time Spent: 20m > Remaining Estimate: 0h > > Remove the use of Plexus annotations and use JSR330 annotations throughout > the core. > *NOTE:* The descriptor must still be generated, since Maven doesn't do > annotation scanning for performance reason. It simply reads the descriptor > file(s). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6635) Syntax error in Maven
[ https://issues.apache.org/jira/browse/MNG-6635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-6635. --- Resolution: Not A Problem Assignee: Robert Scholte I'm won't work on Windows either. You're letting a main class depend on a test-class within the same project. That is not possible. Earlier versions of Eclipse didn't had the notion of main classes and test classes, all were considered "classes" and were compiled at the same time. However, when running Maven from commandline it would break. So this is not a problem, but a problem with the structure of your source files. ps. Next time please use Stack Overflow for these kind of questions. > Syntax error in Maven > - > > Key: MNG-6635 > URL: https://issues.apache.org/jira/browse/MNG-6635 > Project: Maven > Issue Type: Bug >Reporter: Shweta Soni >Assignee: Robert Scholte >Priority: Major > Attachments: Appium.png > > > I have created Maven project in Macbook. > I have created classes with package structure in src/main/java and > src/test/java. > I am trying to access methods from src/test/java to src/main/java but i am > getting syntax error. > What could be the possible reason. Please help. > Note : I have check with project cleanup but its not working. > *Same code is working on windows machine.* > Attaching screenshot for reference -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Moved] (MNG-6635) Syntax error in Maven
[ https://issues.apache.org/jira/browse/MNG-6635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte moved MASFRES-24 to MNG-6635: Issue Type: Bug (was: Improvement) Key: MNG-6635 (was: MASFRES-24) Project: Maven (was: Apache Maven Resource Bundles) > Syntax error in Maven > - > > Key: MNG-6635 > URL: https://issues.apache.org/jira/browse/MNG-6635 > Project: Maven > Issue Type: Bug >Reporter: Shweta Soni >Priority: Major > Attachments: Appium.png > > > I have created Maven project in Macbook. > I have created classes with package structure in src/main/java and > src/test/java. > I am trying to access methods from src/test/java to src/main/java but i am > getting syntax error. > What could be the possible reason. Please help. > Note : I have check with project cleanup but its not working. > *Same code is working on windows machine.* > Attaching screenshot for reference -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MNG-5001) @readonly Mojo parameter annotation doesn't work
[
https://issues.apache.org/jira/browse/MNG-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MNG-5001:
-
Assignee: Sylwester Lachiewicz
> @readonly Mojo parameter annotation doesn't work
>
>
> Key: MNG-5001
> URL: https://issues.apache.org/jira/browse/MNG-5001
> Project: Maven
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0.2
>Reporter: Jochen Ehret
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.2
>
> Attachments: log-maven-2.2.1.txt, log-maven-3.0.2.txt,
> readonlytest.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Maven 2.2.1, the @readonly annotation works as described: You can't
> configure a Mojo parameter in the pom section. If you do, the
> build will fail:
> {noformat}[INFO] Error configuring: test:test-plugin. Reason: ERROR: Cannot
> override read-only parameter: testParameter in goal:
> test:dumpParameter{noformat}
> In Maven 3.0.2, the @readonly seems to have no effect:
> {noformat}[INFO] --- test-plugin:0.0.1-SNAPSHOT:dumpParameter (test-exec) @
> test-project ---
> testParameter: readonly parameter configured in pom{noformat}
> You can reproduce the behaviour with the attached example project. Log
> outputs for Maven 2.2.1 and 3.0.2 are also attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5001) @readonly Mojo parameter annotation doesn't work
[
https://issues.apache.org/jira/browse/MNG-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-5001:
--
Fix Version/s: (was: Issues to be reviewed for 4.x)
3.6.2
> @readonly Mojo parameter annotation doesn't work
>
>
> Key: MNG-5001
> URL: https://issues.apache.org/jira/browse/MNG-5001
> Project: Maven
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0.2
>Reporter: Jochen Ehret
>Priority: Major
> Fix For: 3.6.2
>
> Attachments: log-maven-2.2.1.txt, log-maven-3.0.2.txt,
> readonlytest.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Maven 2.2.1, the @readonly annotation works as described: You can't
> configure a Mojo parameter in the pom section. If you do, the
> build will fail:
> {noformat}[INFO] Error configuring: test:test-plugin. Reason: ERROR: Cannot
> override read-only parameter: testParameter in goal:
> test:dumpParameter{noformat}
> In Maven 3.0.2, the @readonly seems to have no effect:
> {noformat}[INFO] --- test-plugin:0.0.1-SNAPSHOT:dumpParameter (test-exec) @
> test-project ---
> testParameter: readonly parameter configured in pom{noformat}
> You can reproduce the behaviour with the attached example project. Log
> outputs for Maven 2.2.1 and 3.0.2 are also attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MASFRES-24) Syntax error in Maven
Shweta Soni created MASFRES-24: -- Summary: Syntax error in Maven Key: MASFRES-24 URL: https://issues.apache.org/jira/browse/MASFRES-24 Project: Apache Maven Resource Bundles Issue Type: Improvement Reporter: Shweta Soni Attachments: Appium.png I have created Maven project in Macbook. I have created classes with package structure in src/main/java and src/test/java. I am trying to access methods from src/test/java to src/main/java but i am getting syntax error. What could be the possible reason. Please help. Note : I have check with project cleanup but its not working. *Same code is working on windows machine.* Attaching screenshot for reference -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHADE-316) Explicit minijar includes
[ https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816031#comment-16816031 ] Robert Scholte commented on MSHADE-316: --- So if I read this correctly, you have control which classes under target/classes should be part of the minified jar? What's the idea behind this? Shouldn't simply all these files be added? > Explicit minijar includes > - > > Key: MSHADE-316 > URL: https://issues.apache.org/jira/browse/MSHADE-316 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Markus Karg >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Minijar currently respects includes, but these have a drawback: Once you > defined an include, the _default includes_ are gone! But what you actually > want to have when combining minijar with includes is just an "exception" to > minijar's filtering, not a complete replacement of the default includes! > So what we need to make this work intuitively is either "explicit minijar > exceptions", or a "useDefaultIncludes=true" option that turns the notion from > "replace default includes by the single given include" to "add the single > given include ontop of the default includes". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
