[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=16817574#comment-16817574
]
Marc Philipp commented on SUREFIRE-1546:
[~Srdo] Please correct me if I'm wrong, but I think you meant to write the
following that matches the test tree you posted:
{code:java}
@DisplayName(value = "a parameterized test (bar(int))") <-- This is the name
for the whole ParameterizedTest container
@ParameterizedTest(name = "bar({0})") <-- This is the individual invocation
name, where param index and value is available
{code}
[~tibor17] With the code above, the display name would be {{bar(15)}} for the
invocation and {{a parameterized test (bar(int))}} for the enclosing container.
> 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=16817556#comment-16817556 ] Markus Karg commented on MSHADE-316: [~rfscholte] All requested changes are implemented. Please continue review [https://github.com/apache/maven-shade-plugin/pull/19]. :) > 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: 20m > 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 #19: [MSHADE-316] - Configuration option
mkarg commented on issue #19: [MSHADE-316] - Configuration option URL: https://github.com/apache/maven-shade-plugin/pull/19#issuecomment-483105879 All requested changes done. 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
[GitHub] [maven-shade-plugin] mkarg commented on a change in pull request #19: [MSHADE-316] - Configuration option
mkarg commented on a change in pull request #19: [MSHADE-316] - Configuration
option
URL: https://github.com/apache/maven-shade-plugin/pull/19#discussion_r275205386
##
File path:
src/main/java/org/apache/maven/plugins/shade/filter/SimpleFilter.java
##
@@ -42,16 +42,19 @@
private Set excludes;
+private boolean excludeDefaults = true;
+
/**
* @param jars set of {@link File}s.
* @param includes set of includes.
* @param excludes set of excludes
*/
-public SimpleFilter( Set jars, Set includes, Set
excludes )
+public SimpleFilter( Set jars, Set includes, Set
excludes, boolean excludeDefaults )
Review comment:
Implemented additional constructor as you requested, see
https://github.com/apache/maven-shade-plugin/pull/19/commits/975615b596d7a99dd5ee782aa0b62400a2dd.
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-enforcer] rjatkins commented on issue #53: [MENFORCER-332] Dependency graph performance fix
rjatkins commented on issue #53: [MENFORCER-332] Dependency graph performance fix URL: https://github.com/apache/maven-enforcer/pull/53#issuecomment-483084822 The remaining test failures in RequireUpperBoundDeps needs a fix in mrm-maven-plugin to add support for mocking timestamped snapshots (fixed in https://github.com/mojohaus/mrm/pull/22 ), and another fix in maven-dependency-tree to restore support for annotating DependencyNodes with managed versions and scopes (tracked in https://issues.apache.org/jira/browse/MSHARED-816 with a fix in https://github.com/apache/maven-dependency-tree/pull/2 ). 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-dependency-tree] rjatkins opened a new pull request #2: [MSHARED-816] Add support for pre-managed metadata to Maven31Dependen…
rjatkins opened a new pull request #2: [MSHARED-816] Add support for pre-managed metadata to Maven31Dependen… URL: https://github.com/apache/maven-dependency-tree/pull/2 …cyGraphBuilder * Simply uncomment existing commented out code, and reformat again * Also update to maven-shared-components 33, and test against latest maven 3.0.5 bugfix release This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MSHARED-816) Annotate DependencyNodes with dependency management metadata
Richard Atkins created MSHARED-816: -- Summary: Annotate DependencyNodes with dependency management metadata Key: MSHARED-816 URL: https://issues.apache.org/jira/browse/MSHARED-816 Project: Maven Shared Components Issue Type: Improvement Components: maven-dependency-tree Affects Versions: maven-dependency-tree-3.0.1 Reporter: Richard Atkins Maven31DependencyGraphBuilder has commented out support for collecting the original versions and scopes from resolved DependencyNodes, when the underlying DependencyResolutionResult contains this info. This feature should be re-added, so that consumers like maven-enforcer-plugin can use this metadata in its RequireUpperBoundDeps rule when using maven-dependency-tree 3.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-339) DependencyGraphBuilder does not provide verbose tree
[ https://issues.apache.org/jira/browse/MSHARED-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817496#comment-16817496 ] Richard Atkins commented on MSHARED-339: This happens because the default RepositorySession uses a DependencyGraphTransformer (ConflictResolver) that automatically prunes the graph to match exactly what Maven resolves dependencies to, using its nearest-version algorithm. Callers of DependencyGraphBuilder can work around this by passing a customized DefaultRepositorySession with this transformer set to null, or set one of the ConflictResolver config properties like CONFIG_PROP_VERBOSE set to true (as long as the resultant artifact graph isn't then directly resolved before ignoring the marked duplicate nodes). It seems roughly as easy for the caller to do this as it is for DependencyGraphBuilder to do it itself. > DependencyGraphBuilder does not provide verbose tree > > > Key: MSHARED-339 > URL: https://issues.apache.org/jira/browse/MSHARED-339 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-2.1 >Reporter: Paul Gier >Priority: Major > > The dependency graph builder provides a dependency tree which has already > filtered out duplicate dependencies. In some cases such as testing > dependency convergence or viewing the verbose dependency tree, it's useful to > get information about the full tree including duplicates. > The dependency graph builder should provide an option for including the > unfiltered dependency tree. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MSHARED-339) DependencyGraphBuilder does not provide verbose tree
[ https://issues.apache.org/jira/browse/MSHARED-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817496#comment-16817496 ] Richard Atkins edited comment on MSHARED-339 at 4/15/19 1:43 AM: - This happens because the default RepositorySystemSession uses a DependencyGraphTransformer (ConflictResolver) that automatically prunes the graph to match exactly what Maven resolves dependencies to, using its nearest-version algorithm. Callers of DependencyGraphBuilder can work around this by passing a customized DefaultRepositorySystemSession with this transformer set to null, or set one of the ConflictResolver config properties like CONFIG_PROP_VERBOSE set to true (as long as the resultant artifact graph isn't then directly resolved before ignoring the marked duplicate nodes). It seems roughly as easy for the caller to do this as it is for DependencyGraphBuilder to do it itself. was (Author: richarda): This happens because the default RepositorySession uses a DependencyGraphTransformer (ConflictResolver) that automatically prunes the graph to match exactly what Maven resolves dependencies to, using its nearest-version algorithm. Callers of DependencyGraphBuilder can work around this by passing a customized DefaultRepositorySession with this transformer set to null, or set one of the ConflictResolver config properties like CONFIG_PROP_VERBOSE set to true (as long as the resultant artifact graph isn't then directly resolved before ignoring the marked duplicate nodes). It seems roughly as easy for the caller to do this as it is for DependencyGraphBuilder to do it itself. > DependencyGraphBuilder does not provide verbose tree > > > Key: MSHARED-339 > URL: https://issues.apache.org/jira/browse/MSHARED-339 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-2.1 >Reporter: Paul Gier >Priority: Major > > The dependency graph builder provides a dependency tree which has already > filtered out duplicate dependencies. In some cases such as testing > dependency convergence or viewing the verbose dependency tree, it's useful to > get information about the full tree including duplicates. > The dependency graph builder should provide an option for including the > unfiltered dependency tree. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-591) javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
[
https://issues.apache.org/jira/browse/MJAVADOC-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817461#comment-16817461
]
Hudson commented on MJAVADOC-591:
-
Build unstable in Jenkins: Maven TLP » maven-javadoc-plugin » master #21
See
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/21/
> javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
> -
>
> Key: MJAVADOC-591
> URL: https://issues.apache.org/jira/browse/MJAVADOC-591
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Robert Varga
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In a module, which defines an Automatic-Module-Name and (inherits)
> maven.compiler.release=8, but does not set source=8, javadoc generation fails
> with:
> {code:java}
> 16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
> target 8
> 16052 [ERROR] error: option --add-modules not allowed with target 8
> 16052 [ERROR] error: option --patch-module not allowed with target 8
> 16053 [ERROR]
> 16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options
> @packages
> {code}
> This occurs with both javadoc-11.0.2 and javadoc-12. Using either
> maven-javadoc-plugin-3.0.1, defining source=8 or removing
> Automatic-Module-Name works just fine.
> I think the problem is that maven.compiler.release is propagated to release
> property, but that is not taken into account when --add-modules is generated
> and propagated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MJAVADOC-591) javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
[
https://issues.apache.org/jira/browse/MJAVADOC-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MJAVADOC-591.
---
Resolution: Fixed
Assignee: Robert Scholte
Fix Version/s: 3.1.1
Fixed in
[56979750c1752c811da28ff058aebc83b1fd018b|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=56979750c1752c811da28ff058aebc83b1fd018b]
Thanks for the patch!
> javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
> -
>
> Key: MJAVADOC-591
> URL: https://issues.apache.org/jira/browse/MJAVADOC-591
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Robert Varga
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a module, which defines an Automatic-Module-Name and (inherits)
> maven.compiler.release=8, but does not set source=8, javadoc generation fails
> with:
> {code:java}
> 16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
> target 8
> 16052 [ERROR] error: option --add-modules not allowed with target 8
> 16052 [ERROR] error: option --patch-module not allowed with target 8
> 16053 [ERROR]
> 16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options
> @packages
> {code}
> This occurs with both javadoc-11.0.2 and javadoc-12. Using either
> maven-javadoc-plugin-3.0.1, defining source=8 or removing
> Automatic-Module-Name works just fine.
> I think the problem is that maven.compiler.release is propagated to release
> property, but that is not taken into account when --add-modules is generated
> and propagated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-javadoc-plugin] rfscholte closed pull request #25: [MJAVADOC-591] consider release for supportModulePath
rfscholte closed pull request #25: [MJAVADOC-591] consider release for supportModulePath URL: https://github.com/apache/maven-javadoc-plugin/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-javadoc-plugin] rfscholte commented on issue #25: [MJAVADOC-591] consider release for supportModulePath
rfscholte commented on issue #25: [MJAVADOC-591] consider release for supportModulePath URL: https://github.com/apache/maven-javadoc-plugin/pull/25#issuecomment-483060646 Fixed with https://github.com/apache/maven-javadoc-plugin/commit/56979750c1752c811da28ff058aebc83b1fd018b 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-fluido-skin] slachiewicz closed pull request #6: [MSKIN-137] Make the hamburger menu work with the top-navigation enab…
slachiewicz closed pull request #6: [MSKIN-137] Make the hamburger menu work with the top-navigation enab… URL: https://github.com/apache/maven-fluido-skin/pull/6 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] slachiewicz commented on issue #244: [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource
slachiewicz commented on issue #244: [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource URL: https://github.com/apache/maven/pull/244#issuecomment-483046663 The integration tests were successful: https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/MNG-6638/ 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] (MJAVADOC-516) Replace usage of deprecated HttpClient code
[
https://issues.apache.org/jira/browse/MJAVADOC-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817425#comment-16817425
]
Hudson commented on MJAVADOC-516:
-
Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-591 #3
See
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-591/3/
> Replace usage of deprecated HttpClient code
> ---
>
> Key: MJAVADOC-516
> URL: https://issues.apache.org/jira/browse/MJAVADOC-516
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Guillaume Boué
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1.1
>
>
> Since HttpClient 4.3, classes like {{DefaultHttpClient}} [were
> deprecated|https://archive.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.3.x.txt]
> in favor of using builder classes to create immutable {{HttpClient}}
> instances. As a consequence, we should update the code to use the newer APIs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MNG-6638) MavenMetadataSource parses POMs unnecessarily
[ https://issues.apache.org/jira/browse/MNG-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MNG-6638: - Assignee: Sylwester Lachiewicz > MavenMetadataSource parses POMs unnecessarily > - > > Key: MNG-6638 > URL: https://issues.apache.org/jira/browse/MNG-6638 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.0, 3.6.1 >Reporter: Stefan Oehme >Assignee: Sylwester Lachiewicz >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > MavenMetadataSource parses POM files even when an artifact comes from a > project that is part of the current reactor build. This wastes a lot of time > and memory, since the POMs of these projects are already in memory. It should > instead try to find an existing project model in the reactor before falling > back to POM parsing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6639) Child inherit.append.path attributes not defined in Maven POM XSD
[ https://issues.apache.org/jira/browse/MNG-6639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Echegut updated MNG-6639: - Attachment: (was: test-parent-pom.xml) > Child inherit.append.path attributes not defined in Maven POM XSD > - > > Key: MNG-6639 > URL: https://issues.apache.org/jira/browse/MNG-6639 > Project: Maven > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 3.6.0, 3.6.1 >Reporter: Nicolas Echegut >Priority: Major > Attachments: test-parent-pom.xml > > > The child inherit.append.path attributes, introduced in Maven 3.6.0, are not > defined in the Maven POM XML Schema Definition: > [http://maven.apache.org/xsd/maven-4.0.0.xsd] > This is causing XML Validators to report the following error: > _cvc-complex-type.3.2.2: Attribute 'child.site.url.inherit.append.path' is > not allowed to appear in element 'site'._ > The error is for instance visible in Eclipse POM editor or while attempting > to deploy artifacts to Maven Central, as they validate project POMs against > [maven-4.0.0.xsd|http://maven.apache.org/xsd/maven-4.0.0.xsd]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6639) Child inherit.append.path attributes not defined in Maven POM XSD
[ https://issues.apache.org/jira/browse/MNG-6639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Echegut updated MNG-6639: - Attachment: test-parent-pom.xml > Child inherit.append.path attributes not defined in Maven POM XSD > - > > Key: MNG-6639 > URL: https://issues.apache.org/jira/browse/MNG-6639 > Project: Maven > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 3.6.0, 3.6.1 >Reporter: Nicolas Echegut >Priority: Major > Attachments: test-parent-pom.xml > > > The child inherit.append.path attributes, introduced in Maven 3.6.0, are not > defined in the Maven POM XML Schema Definition: > [http://maven.apache.org/xsd/maven-4.0.0.xsd] > This is causing XML Validators to report the following error: > _cvc-complex-type.3.2.2: Attribute 'child.site.url.inherit.append.path' is > not allowed to appear in element 'site'._ > The error is for instance visible in Eclipse POM editor or while attempting > to deploy artifacts to Maven Central, as they validate project POMs against > [maven-4.0.0.xsd|http://maven.apache.org/xsd/maven-4.0.0.xsd]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6639) Child inherit.append.path attributes not defined in Maven POM XSD
[ https://issues.apache.org/jira/browse/MNG-6639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Echegut updated MNG-6639: - Summary: Child inherit.append.path attributes not defined in Maven POM XSD (was: child.(x.y).inherit.append.path attributes not defined in Maven POM XSD) > Child inherit.append.path attributes not defined in Maven POM XSD > - > > Key: MNG-6639 > URL: https://issues.apache.org/jira/browse/MNG-6639 > Project: Maven > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 3.6.0, 3.6.1 >Reporter: Nicolas Echegut >Priority: Major > Attachments: test-parent-pom.xml > > > The child inherit.append.path attributes, introduced in Maven 3.6.0, are not > defined in the Maven POM XML Schema Definition: > [http://maven.apache.org/xsd/maven-4.0.0.xsd] > This is causing XML Validators to report the following error: > _cvc-complex-type.3.2.2: Attribute 'child.site.url.inherit.append.path' is > not allowed to appear in element 'site'._ > The error is for instance visible in Eclipse POM editor or while attempting > to deploy artifacts to Maven Central, as they validate project POMs against > [maven-4.0.0.xsd|http://maven.apache.org/xsd/maven-4.0.0.xsd]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6639) child.(x.y).inherit.append.path attributes not defined in Maven POM XSD
[ https://issues.apache.org/jira/browse/MNG-6639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817367#comment-16817367 ] Nicolas Echegut commented on MNG-6639: -- The issue can be reproduced with a simple online XML validator such as: [https://www.freeformatter.com/xml-validator-xsd.html] Use the attached sample POM as the XML Input. > child.(x.y).inherit.append.path attributes not defined in Maven POM XSD > --- > > Key: MNG-6639 > URL: https://issues.apache.org/jira/browse/MNG-6639 > Project: Maven > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 3.6.0, 3.6.1 >Reporter: Nicolas Echegut >Priority: Major > Attachments: test-parent-pom.xml > > > The child inherit.append.path attributes, introduced in Maven 3.6.0, are not > defined in the Maven POM XML Schema Definition: > [http://maven.apache.org/xsd/maven-4.0.0.xsd] > This is causing XML Validators to report the following error: > _cvc-complex-type.3.2.2: Attribute 'child.site.url.inherit.append.path' is > not allowed to appear in element 'site'._ > The error is for instance visible in Eclipse POM editor or while attempting > to deploy artifacts to Maven Central, as they validate project POMs against > [maven-4.0.0.xsd|http://maven.apache.org/xsd/maven-4.0.0.xsd]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6639) child.(x.y).inherit.append.path attributes not defined in Maven POM XSD
[ https://issues.apache.org/jira/browse/MNG-6639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Echegut updated MNG-6639: - Attachment: test-parent-pom.xml > child.(x.y).inherit.append.path attributes not defined in Maven POM XSD > --- > > Key: MNG-6639 > URL: https://issues.apache.org/jira/browse/MNG-6639 > Project: Maven > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 3.6.0, 3.6.1 >Reporter: Nicolas Echegut >Priority: Major > Attachments: test-parent-pom.xml > > > The child inherit.append.path attributes, introduced in Maven 3.6.0, are not > defined in the Maven POM XML Schema Definition: > [http://maven.apache.org/xsd/maven-4.0.0.xsd] > This is causing XML Validators to report the following error: > _cvc-complex-type.3.2.2: Attribute 'child.site.url.inherit.append.path' is > not allowed to appear in element 'site'._ > The error is for instance visible in Eclipse POM editor or while attempting > to deploy artifacts to Maven Central, as they validate project POMs against > [maven-4.0.0.xsd|http://maven.apache.org/xsd/maven-4.0.0.xsd]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6639) child.(x.y).inherit.append.path attributes not defined in Maven POM XSD
Nicolas Echegut created MNG-6639: Summary: child.(x.y).inherit.append.path attributes not defined in Maven POM XSD Key: MNG-6639 URL: https://issues.apache.org/jira/browse/MNG-6639 Project: Maven Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 3.6.1, 3.6.0 Reporter: Nicolas Echegut The child inherit.append.path attributes, introduced in Maven 3.6.0, are not defined in the Maven POM XML Schema Definition: [http://maven.apache.org/xsd/maven-4.0.0.xsd] This is causing XML Validators to report the following error: _cvc-complex-type.3.2.2: Attribute 'child.site.url.inherit.append.path' is not allowed to appear in element 'site'._ The error is for instance visible in Eclipse POM editor or while attempting to deploy artifacts to Maven Central, as they validate project POMs against [maven-4.0.0.xsd|http://maven.apache.org/xsd/maven-4.0.0.xsd]. -- 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=16817361#comment-16817361
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/14/19 5:15 PM:
-
[~Srdo]
Don't talk about Surefire because latest version does not understand
DisplayName.
What is obious from your code and listener console is the fact that DisplayName
annotation has *bar(\{0\})* but the console has *displayName: a parameterized
test (bar(int)), type: TEST, source: MethodSource*.
Now me as developer of Surefire should be interested in the following call:
{code:java}
Optional testSource = testIdentifier.getSource();
String display = testIdentifier.getDisplayName(); // <<<
MethodSource methodSource = testSource.map( MethodSource.class::cast ).get();
// we are in the test method "bar"
String methodName = methodSource.getMethodName(); // returns "bar"
{code}
and I expect that {{display}} would have the string from the DisplayName
annotation, i.e. {{bar(15)}} etc.
I guess the user would expect the same. And if it is not like that then it is a
problem, and even more problematic if another "display name" is in the second
annotation {{ParameterizedTest}}.
How should I as Surefire developer cope with the JUnit API in this case of
parameterized tests?
was (Author: tibor17):
[~Srdo]
Don't talk about Surefire because latest version does not understand
DisplayName.
What is obious from your code and listener console is the fact that DisplayName
annotation has *bar(\{0\})* but the console has *displayName: a parameterized
test (bar(int)), type: TEST, source: MethodSource*.
Now me as developer of Surefire should must be interested in the following call:
{code:java}
Optional testSource = testIdentifier.getSource();
String display = testIdentifier.getDisplayName(); // <<<
MethodSource methodSource = testSource.map( MethodSource.class::cast ).get();
// we are in the test method "bar"
String methodName = methodSource.getMethodName(); // returns "bar"
{code}
and I expect that {{display}} would have the string from the DisplayName
annotation, i.e. {{bar(15)}} etc.
I guess the user would expect the same. And if it is not like that then it is a
problem, and even more problematic if another "display name" is in the second
annotation {{ParameterizedTest}}.
How should I as Surefire developer cope with the JUnit API in this case of
parameterized tests?
> 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=16817361#comment-16817361
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/14/19 5:07 PM:
-
[~Srdo]
Don't talk about Surefire because latest version does not understand
DisplayName.
What is obious from your code and listener console is the fact that DisplayName
annotation has *bar(\{0\})* but the console has *displayName: a parameterized
test (bar(int)), type: TEST, source: MethodSource*.
Now me as developer of Surefire should must be interested in the following call:
{code:java}
Optional testSource = testIdentifier.getSource();
String display = testIdentifier.getDisplayName(); // <<<
MethodSource methodSource = testSource.map( MethodSource.class::cast ).get();
// we are in the test method "bar"
String methodName = methodSource.getMethodName(); // returns "bar"
{code}
and I expect that {{display}} would have the string from the DisplayName
annotation, i.e. {{bar(15)}} etc.
I guess the user would expect the same. And if it is not like that then it is a
problem, and even more problematic if another "display name" is in the second
annotation {{ParameterizedTest}}.
How should I as Surefire developer cope with the JUnit API in this case of
parameterized tests?
was (Author: tibor17):
[~Srdo]
Don't talk about Surefire because latest version does not understand
DisplayName.
What is obious from your code and listener console is the fact that DisplayName
annotation has *bar({0})* but the console has *displayName: a parameterized
test (bar(int)), type: TEST, source: MethodSource*.
Now me as developer of Surefire should must be interested in the following call:
{code:java}
Optional testSource = testIdentifier.getSource();
String display = testIdentifier.getDisplayName(); // <<<
MethodSource methodSource = testSource.map( MethodSource.class::cast ).get();
// we are in the test method "bar"
String methodName = methodSource.getMethodName(); // returns "bar"
{code}
and I expect that {{display}} would have the string from the DisplayName
annotation, i.e. {{bar(15)}} etc.
I guess the user would expect the same. And if it is not like that then it is a
problem, and even more problematic if another "display name" is in the second
annotation {{ParameterizedTest}}.
How should I as Surefire developer cope with the JUnit API in this case of
parameterized tests?
> 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=16817361#comment-16817361
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/14/19 5:06 PM:
-
[~Srdo]
Don't talk about Surefire because latest version does not understand
DisplayName.
What is obious from your code and listener console is the fact that DisplayName
annotation has *bar({0})* but the console has *displayName: a parameterized
test (bar(int)), type: TEST, source: MethodSource*.
Now me as developer of Surefire should must be interested in the following call:
{code:java}
Optional testSource = testIdentifier.getSource();
String display = testIdentifier.getDisplayName(); // <<<
MethodSource methodSource = testSource.map( MethodSource.class::cast ).get();
// we are in the test method "bar"
String methodName = methodSource.getMethodName(); // returns "bar"
{code}
and I expect that {{display}} would have the string from the DisplayName
annotation, i.e. {{bar(15)}} etc.
I guess the user would expect the same. And if it is not like that then it is a
problem, and even more problematic if another "display name" is in the second
annotation {{ParameterizedTest}}.
How should I as Surefire developer cope with the JUnit API in this case of
parameterized tests?
was (Author: tibor17):
[~Srdo]
Don't talk about Surefire because latest version does not understand
DisplayName.
What is obious from your code and listener console is the fact that DisplayName
annotation has {{bar({0})}} but the console has {{displayName: a parameterized
test (bar(int)), type: TEST, source: MethodSource}}.
Now me as developer of Surefire should must be interested in the following call:
{code:java}
Optional testSource = testIdentifier.getSource();
String display = testIdentifier.getDisplayName(); // <<<
MethodSource methodSource = testSource.map( MethodSource.class::cast ).get();
// we are in the test method "bar"
String methodName = methodSource.getMethodName(); // returns "bar"
{code}
and I expect that {{display}} would have the string from the DisplayName
annotation, i.e. {{bar(15)}} etc.
I guess the user would expect the same. And if it is not like that then it is a
problem, and even more problematic if another "display name" is in the second
annotation {{ParameterizedTest}}.
How should I as Surefire developer cope with the JUnit API in this case of
parameterized tests?
> 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=16817361#comment-16817361
]
Tibor Digana commented on SUREFIRE-1546:
[~Srdo]
Don't talk about Surefire because latest version does not understand
DisplayName.
What is obious from your code and listener console is the fact that DisplayName
annotation has {{bar({0})}} but the console has {{displayName: a parameterized
test (bar(int)), type: TEST, source: MethodSource}}.
Now me as developer of Surefire should must be interested in the following call:
{code:java}
Optional testSource = testIdentifier.getSource();
String display = testIdentifier.getDisplayName(); // <<<
MethodSource methodSource = testSource.map( MethodSource.class::cast ).get();
// we are in the test method "bar"
String methodName = methodSource.getMethodName(); // returns "bar"
{code}
and I expect that {{display}} would have the string from the DisplayName
annotation, i.e. {{bar(15)}} etc.
I guess the user would expect the same. And if it is not like that then it is a
problem, and even more problematic if another "display name" is in the second
annotation {{ParameterizedTest}}.
How should I as Surefire developer cope with the JUnit API in this case of
parameterized tests?
> 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] [Closed] (MJAVADOC-516) Replace usage of deprecated HttpClient code
[
https://issues.apache.org/jira/browse/MJAVADOC-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MJAVADOC-516.
---
Resolution: Fixed
Assignee: Robert Scholte (was: Guillaume Boué)
Fix Version/s: 3.1.1
Fixed in
[d80cb08678a91a5da15b8b8ed5ce781e4d559d9b|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=d80cb08678a91a5da15b8b8ed5ce781e4d559d9b]
> Replace usage of deprecated HttpClient code
> ---
>
> Key: MJAVADOC-516
> URL: https://issues.apache.org/jira/browse/MJAVADOC-516
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Guillaume Boué
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1.1
>
>
> Since HttpClient 4.3, classes like {{DefaultHttpClient}} [were
> deprecated|https://archive.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.3.x.txt]
> in favor of using builder classes to create immutable {{HttpClient}}
> instances. As a consequence, we should update the code to use the newer APIs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-516) Replace usage of deprecated HttpClient code
[
https://issues.apache.org/jira/browse/MJAVADOC-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817359#comment-16817359
]
Hudson commented on MJAVADOC-516:
-
Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » master #20
See
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/20/
> Replace usage of deprecated HttpClient code
> ---
>
> Key: MJAVADOC-516
> URL: https://issues.apache.org/jira/browse/MJAVADOC-516
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Minor
>
> Since HttpClient 4.3, classes like {{DefaultHttpClient}} [were
> deprecated|https://archive.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.3.x.txt]
> in favor of using builder classes to create immutable {{HttpClient}}
> instances. As a consequence, we should update the code to use the newer APIs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-shade-plugin] rfscholte commented on issue #19: [MSHADE-316] - Configuration option
rfscholte commented on issue #19: [MSHADE-316] - Configuration option URL: https://github.com/apache/maven-shade-plugin/pull/19#issuecomment-483002705 docs look good enough to me 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 a change in pull request #19: [MSHADE-316] - Configuration option
rfscholte commented on a change in pull request #19: [MSHADE-316] -
Configuration option
URL: https://github.com/apache/maven-shade-plugin/pull/19#discussion_r275162538
##
File path:
src/main/java/org/apache/maven/plugins/shade/filter/SimpleFilter.java
##
@@ -42,16 +42,19 @@
private Set excludes;
+private boolean excludeDefaults = true;
+
/**
* @param jars set of {@link File}s.
* @param includes set of includes.
* @param excludes set of excludes
*/
-public SimpleFilter( Set jars, Set includes, Set
excludes )
+public SimpleFilter( Set jars, Set includes, Set
excludes, boolean excludeDefaults )
Review comment:
IMHO this is more an improvement than a bugfix. And I'm not sure if others
use this SimpleFilter as superclass, so better to keep the original constructor
anyway. I don't like the idea that every new field for ArchiveFilter would
translate to an extra constructor, just pass the original instead.
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] carlspring commented on issue #25: [MINDEXER-114] Extend JarFileContentsIndexCreator to support zip files
carlspring commented on issue #25: [MINDEXER-114] Extend JarFileContentsIndexCreator to support zip files URL: https://github.com/apache/maven-indexer/pull/25#issuecomment-482993538 Thanks for clarifying! :) 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] mkarg commented on issue #19: [MSHADE-316] - Configuration option
mkarg commented on issue #19: [MSHADE-316] - Configuration option URL: https://github.com/apache/maven-shade-plugin/pull/19#issuecomment-482991030 @rfscholte Added documentation for `excludeDefaults` as part of the filter example. Is that sufficient? 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] mkarg commented on a change in pull request #19: [MSHADE-316] - Configuration option
mkarg commented on a change in pull request #19: [MSHADE-316] - Configuration
option
URL: https://github.com/apache/maven-shade-plugin/pull/19#discussion_r275159113
##
File path:
src/main/java/org/apache/maven/plugins/shade/filter/SimpleFilter.java
##
@@ -42,16 +42,19 @@
private Set excludes;
+private boolean excludeDefaults = true;
+
/**
* @param jars set of {@link File}s.
* @param includes set of includes.
* @param excludes set of excludes
*/
-public SimpleFilter( Set jars, Set includes, Set
excludes )
+public SimpleFilter( Set jars, Set includes, Set
excludes, boolean excludeDefaults )
Review comment:
That would be a refactoring, not just a bug fix. Are you sure you want to me
to do that in the same PR?
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 #19: [MSHADE-316] - Configuration option
rfscholte commented on issue #19: [MSHADE-316] - Configuration option URL: https://github.com/apache/maven-shade-plugin/pull/19#issuecomment-482981058 We should update dthe documentation as part of this PR as well 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 a change in pull request #19: [MSHADE-316] - Configuration option
rfscholte commented on a change in pull request #19: [MSHADE-316] -
Configuration option
URL: https://github.com/apache/maven-shade-plugin/pull/19#discussion_r275157984
##
File path:
src/main/java/org/apache/maven/plugins/shade/filter/SimpleFilter.java
##
@@ -42,16 +42,19 @@
private Set excludes;
+private boolean excludeDefaults = true;
+
/**
* @param jars set of {@link File}s.
* @param includes set of includes.
* @param excludes set of excludes
*/
-public SimpleFilter( Set jars, Set includes, Set
excludes )
+public SimpleFilter( Set jars, Set includes, Set
excludes, boolean excludeDefaults )
Review comment:
It looks to me we're at a point where we need a second constructor, using
the `ArchiveFilter` as argument instead of includes/excludes/excludeDefaults.
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-482980298 Added in https://github.com/apache/maven-shade-plugin/commit/8278c9f28d94f8af6d98655b3db7bd295b9785aa 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 closed pull request #17: [MSHADE-313] - Keep Services
rfscholte closed pull request #17: [MSHADE-313] - Keep Services URL: https://github.com/apache/maven-shade-plugin/pull/17 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] oehme edited a comment on issue #244: [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource
oehme edited a comment on issue #244: [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource URL: https://github.com/apache/maven/pull/244#issuecomment-482967311 Here's an allocation profile showing the severe impact this has on plugins like enforcer and assembly (jar-with-dependencies). The POM parsing overhead is marked in pink. https://user-images.githubusercontent.com/1191797/56093000-e085a780-5ec3-11e9-8d47-6e35f4b305ca.png;> 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] oehme commented on issue #244: [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource
oehme commented on issue #244: [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource URL: https://github.com/apache/maven/pull/244#issuecomment-482967311 Here's an allocation profile showing the severe impact this has on plugins like enforcer and assembly (jar-with-dependencies). The POM parsing overhead is marked in pink. https://user-images.githubusercontent.com/1191797/56092980-ab795500-5ec3-11e9-939b-fd050c82f9d1.png;> 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-313) Minimize jar should respect implementations under /META-INF/services/
[ https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817296#comment-16817296 ] Hudson commented on MSHADE-313: --- Build succeeded in Jenkins: Maven TLP » maven-shade-plugin » master #4 See https://builds.apache.org/job/maven-box/job/maven-shade-plugin/job/master/4/ > Minimize jar should respect implementations under /META-INF/services/ > - > > Key: MSHADE-313 > URL: https://issues.apache.org/jira/browse/MSHADE-313 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Markus Karg >Assignee: Robert Scholte >Priority: Major > Fix For: 3.2.2 > > Time Spent: 10m > Remaining Estimate: 0h > > The maven shade plugin already does a great job in minimizing JAR size. For > the majority of applications this is exactly what is needed. > On the other hand there are some application areas where the algorithm is too > agressive. One particular and rather frequently found case is the services > API: ServiceLoader will ceise to work for minimized JARs since it is the > prototype of the biggest "minimize-JAR-antipattern": String-to-class > conversion. > To make usable in such scenarios, there should be a set of > options to enable the usual suspetcs (like ServiceLoader) to be detected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven] oehme opened a new pull request #244: [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource
oehme opened a new pull request #244: [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource URL: https://github.com/apache/maven/pull/244 If a dependency on another project is found, don't parse its POM again, but instead use the model we already have in memory. This saves a large amount of time and memory for builds that have lots of subprojects and dependencies between them. The approach was directly copied from DefaultArtifactDescriptorReader, which does the same optimization. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MNG-6638) MavenMetadataSource parses POMs unnecessarily
Stefan Oehme created MNG-6638: - Summary: MavenMetadataSource parses POMs unnecessarily Key: MNG-6638 URL: https://issues.apache.org/jira/browse/MNG-6638 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.1, 3.6.0, 3.5.4 Reporter: Stefan Oehme MavenMetadataSource parses POM files even when an artifact comes from a project that is part of the current reactor build. This wastes a lot of time and memory, since the POMs of these projects are already in memory. It should instead try to find an existing project model in the reactor before falling back to POM parsing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MSHADE-313) Minimize jar should respect implementations under /META-INF/services/
[ https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSHADE-313. - Resolution: Fixed Assignee: Robert Scholte Fix Version/s: 3.2.2 Fixed in [8278c9f28d94f8af6d98655b3db7bd295b9785aa|https://gitbox.apache.org/repos/asf?p=maven-shade-plugin.git;a=commit;h=8278c9f28d94f8af6d98655b3db7bd295b9785aa] Thanks for the patch! > Minimize jar should respect implementations under /META-INF/services/ > - > > Key: MSHADE-313 > URL: https://issues.apache.org/jira/browse/MSHADE-313 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Markus Karg >Assignee: Robert Scholte >Priority: Major > Fix For: 3.2.2 > > Time Spent: 10m > Remaining Estimate: 0h > > The maven shade plugin already does a great job in minimizing JAR size. For > the majority of applications this is exactly what is needed. > On the other hand there are some application areas where the algorithm is too > agressive. One particular and rather frequently found case is the services > API: ServiceLoader will ceise to work for minimized JARs since it is the > prototype of the biggest "minimize-JAR-antipattern": String-to-class > conversion. > To make usable in such scenarios, there should be a set of > options to enable the usual suspetcs (like ServiceLoader) to be detected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHADE-313) Minimize jar should respect implementations under /META-INF/services/
[ https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MSHADE-313: -- Summary: Minimize jar should respect implementations under /META-INF/services/ (was: Less agressive ) > Minimize jar should respect implementations under /META-INF/services/ > - > > Key: MSHADE-313 > URL: https://issues.apache.org/jira/browse/MSHADE-313 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Markus Karg >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The maven shade plugin already does a great job in minimizing JAR size. For > the majority of applications this is exactly what is needed. > On the other hand there are some application areas where the algorithm is too > agressive. One particular and rather frequently found case is the services > API: ServiceLoader will ceise to work for minimized JARs since it is the > prototype of the biggest "minimize-JAR-antipattern": String-to-class > conversion. > To make usable in such scenarios, there should be a set of > options to enable the usual suspetcs (like ServiceLoader) to be detected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-516) Replace usage of deprecated HttpClient code
[
https://issues.apache.org/jira/browse/MJAVADOC-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817287#comment-16817287
]
Robert Scholte commented on MJAVADOC-516:
-
[~michael-o] just gave it a try, but it seems like when httpClient tries to
resolve a redirect, it "forgets" the protocols as set via the
setSSLSocketFactory. Does this ring a bell?
> Replace usage of deprecated HttpClient code
> ---
>
> Key: MJAVADOC-516
> URL: https://issues.apache.org/jira/browse/MJAVADOC-516
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Minor
>
> Since HttpClient 4.3, classes like {{DefaultHttpClient}} [were
> deprecated|https://archive.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.3.x.txt]
> in favor of using builder classes to create immutable {{HttpClient}}
> instances. As a consequence, we should update the code to use the newer APIs.
--
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=16817279#comment-16817279
]
Stig Rohde Døssing commented on SUREFIRE-1546:
--
[~tibor17] I would like the HTML report/console output to contain (at least)
the classname, method name and parameters of the test.
I'm talking about the container and its display name, because in JUnit 5,
writing a ParameterizedTest with e.g. 2 runs produces a container with a
display name (e.g. "bar(int)"), containing two tests each with their own
display names (e.g "[1] 15" and "[2] 54"). Surefire's test listener currently
only cares about the display name of the two tests, and not the name of the
container. This means we lose the test method name when using
ParameterizedTests, because we only print e.g. "[1] 15", and not "bar(int) >
[1] 15".
{quote}
IMHO what you guys have showed me is a technical problem in JUnit where the
annotation DisplayName does not show x = bar(15) and x = bar(54) which I would
expect (according the experiences with JUnit4) as a user.
{quote}
I agree that DisplayName for ParameterizedTests is slightly confusing, but the
DisplayName set for the test is for the entire set of ParameterizedTest
invocations. The DisplayName for the individual invocations is set via
ParameterizedTest(name = "invocation display name"). Does it matter whether you
need to write
{code}
@DisplayName(container = "a parameterized test (bar(int))", value = "bar({0})")
@ParameterizedTest
{code}
or
{code}
@DisplayName("a parameterized test (bar(int))")
@ParameterizedTest("bar({0})")
{code}
They express the same thing IMO.
I think the issue here is that Surefire's test listener needs to be aware that
it needs to get both the DisplayName of the invoked test method, and
potentially also the DisplayName of the containers of that test method.
{quote}
The next problem is that DisplayName talks about string constant, but JUnit5
adds something to the end: (bar(int)) which I as user would not like to see
because the framework is adding it unexpectedly and I do not have the string
under control
{quote}
JUnit 5 doesn't add anything to the DisplayName as far as I can tell? Are you
talking about the legacy reporting name?
> 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] (MSHARED-815) Maven Archiver: MavenArchiver.addManifestAttribute does not escape empty lines in value
[
https://issues.apache.org/jira/browse/MSHARED-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817269#comment-16817269
]
Konrad Windszus edited comment on MSHARED-815 at 4/14/19 11:08 AM:
---
To me it seems that the right thing to escape e.g. key "test" with value
{code}
This is a paragraph
This is another paragraph
{code}
is
{code}
test: This is a paragraph
This is another paragraph
{code}
There is a space in line 2!
was (Author: kwin):
To me it seems that the right thing to e.g. escape key "test" with value
{code}
This is a paragraph
This is another paragraph
{code}
is
{code}
test: This is a paragraph
This is another paragraph
{code}
There is a space in line 2!
> Maven Archiver: MavenArchiver.addManifestAttribute does not escape empty
> lines in value
> ---
>
> Key: MSHARED-815
> URL: https://issues.apache.org/jira/browse/MSHARED-815
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Konrad Windszus
>Priority: Major
>
> According to
> https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#name-value-pairs-and-sections
> {quote}
> Groups of name-value pairs are known as a "section". Sections are separated
> from other sections by empty lines.
> {quote}
> Therefore empty lines in attribute values lead to invalid manifests and must
> somehow be escaped.
> As this is not done by default in {{java.util.jar.Attributes.writeMain(...)}}
> the method {{MavenArchiver.addManifestAttribute(...)}} should either throw an
> exception in case of empty lines given to parameter {{value}} or escape those
> empty lines somehow
> (https://github.com/apache/maven-archiver/blob/d454ab3fcd147c0201a14f298cc8f9e1a25ba03e/src/main/java/org/apache/maven/archiver/MavenArchiver.java#L221).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-516) Replace usage of deprecated HttpClient code
[
https://issues.apache.org/jira/browse/MJAVADOC-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817277#comment-16817277
]
Robert Scholte commented on MJAVADOC-516:
-
This one needs more priority
( Integration test for MJAVADOC-325 fails with {{[DEBUG] Could not follow
[https://docs.oracle.com/javase/1,5,0/docs/api/]. Reason: Received fatal alert:
protocol_version}} )
> Replace usage of deprecated HttpClient code
> ---
>
> Key: MJAVADOC-516
> URL: https://issues.apache.org/jira/browse/MJAVADOC-516
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Minor
>
> Since HttpClient 4.3, classes like {{DefaultHttpClient}} [were
> deprecated|https://archive.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.3.x.txt]
> in favor of using builder classes to create immutable {{HttpClient}}
> instances. As a consequence, we should update the code to use the newer APIs.
--
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=16817267#comment-16817267
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/14/19 10:54 AM:
--
[~Srdo]
[~marcphilipp]
It's clear what I said. You had a problem and I showed you my opinion with
another annotations which make sense to me.
In my opinion users want to see test methods and classes in HTML, so why we are
talking about container and its display name.
It is better to list all attributes which want to be shown on HTML and then we
will see if JUnit5 can currently cover those, and not to talk about "how to do
this and that technically" instead of writing a manifesto with this list of
attributes.
IMHO what you guys have showed me is a technical problem in JUnit where the
annotation {{DisplayName}} does not show {{x = bar(15)}} and {{x = bar(54)}}
which I would expect (according the experiences with JUnit4) as a user. The
next problem is that DisplayName talks about string constant, but JUnit5 adds
something to the end: {{(bar(int))}} which I as user would not like to see
because the framework is adding it unexpectedly and I do not have the string
under control => therefore my sample code. Are we talking about bug in JUnit5
or HTML report?
was (Author: tibor17):
[~Srdo]
[~marcphilipp]
It's clear what I said. You had a problem and I showed you my opinion with
another annotations which make sense to me.
In my opinion users want to see test methods and classes in HTML, so why we are
talking about container and its display name.
It is better to list all attributes which want to be shown on HTML and then we
will see if JUnit5 can currently cover those, and not to talk about "how to do
this and that technically" instead of writing a manifesto with this list of
attributes.
IMHO what you guys have showed me is a technical problem in JUnit where the
annotation {{DisplayName}} does not show {{x = bar(15)}} and {{x = bar(54)}}
which I would expect (according the experiences with JUnit4) as a user. The
next problem is that DisplayName talks about string constant, but JUnit5 adds
something to the end: {{(bar(int))}} which I as user would not like to see
because the framework is adding it unexpectedly and I do not have the string
under control => therefore my sample code. Are we about a bug in JUnit5 or HTML
report?
> 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-318) Specifically included class's dependencies are missing
[ https://issues.apache.org/jira/browse/MSHADE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817275#comment-16817275 ] Markus Karg commented on MSHADE-318: I withhold a fix in the draft state ([https://github.com/apache/maven-shade-plugin/pull/20]) until [https://github.com/apache/maven-shade-plugin/pull/19] is merged, as my solution builds ontop of that. > Specifically included class's dependencies are missing > -- > > Key: MSHADE-318 > URL: https://issues.apache.org/jira/browse/MSHADE-318 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.2.1 >Reporter: Markus Karg >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Using `` one can specifically defined classes to exempt from > minijar's filtering. This is useful when a class is referenced by `String` > name instead of `Class` object reference, like e. g. reflection. > Unfortunately *just* the explicitly included class is exempted from removal, > while all its transitive references (i. e. all the classes it uses it turn) > are still removed when shading. This effectively breaks the result's > functionality. This is hard to work around, as *all* such dependencies have > to be explicitly given in the pom to prevent it. That is really nasty. > As a solution, a specific include shall always automatically include all > *transitive dependencies* of the explicitly exempted class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-shade-plugin] mkarg commented on issue #20: [MSHADE-318] - Include transitive dependencies
mkarg commented on issue #20: [MSHADE-318] - Include transitive dependencies URL: https://github.com/apache/maven-shade-plugin/pull/20#issuecomment-482945510 I withhold this fix in the draft state until #19 is merged, as my solution builds ontop of that. 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=16817267#comment-16817267
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/14/19 10:20 AM:
--
[~Srdo]
[~marcphilipp]
It's clear what I said. You had a problem and I showed you my opinion with
another annotations which make sense to me.
In my opinion users want to see test methods and classes in HTML, so why we are
talking about container and its display name.
It is better to list all attributes which want to be shown on HTML and then we
will see if JUnit5 can currently cover those, and not to talk about "how to do
this and that technically" instead of writing a manifesto with this list of
attributes.
IMHO what you guys have showed me is a technical problem in JUnit where the
annotation {{DisplayName}} does not show {{x = bar(15)}} and {{x = bar(54)}}
which I would expect (according the experiences with JUnit4) as a user. The
next problem is that DisplayName talks about string constant, but JUnit5 adds
something to the end: {{(bar(int))}} which I as user would not like to see
because the framework is adding it unexpectedly and I do not have the string
under control => therefore my sample code. Are we about a bug in JUnit5 or HTML
report?
was (Author: tibor17):
[~Srdo]
[~marcphilipp]
It's clear what I said. You had a problem and I showed you my opinion with
another annotations which make sense to me.
In my opinion users want to see test methods and classes in HTML, so why we are
talking about container and its display name.
It is better to list all attributes which want to be shown on HTML and then we
will see if JUnit5 can currently cover those, and not to talk about "how to do
this and that technically" instead of writing a manifesto with this list of
attributes.
IMHO what you guys have showed me is a technical problem in JUnit where the
annotation {{DisplayName}} does not show {{x = bar(15)}} and {{x = bar(54)}}
which I would expect (according the experiences with JUnit4) as a user. The
next problem is that DisplayName talks about string constant, but JUnit5 adds
something to the end: {{ (bar(int))}} which I as user would not like to see
because the framework is adding it unexpectedly and I do not have the string
under control => therefore my sample code. Are we about a bug in JUnit5 or HTML
report?
> 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=16817267#comment-16817267
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/14/19 10:19 AM:
--
[~Srdo]
[~marcphilipp]
It's clear what I said. You had a problem and I showed you my opinion with
another annotations which make sense to me.
In my opinion users want to see test methods and classes in HTML, so why we are
talking about container and its display name.
It is better to list all attributes which want to be shown on HTML and then we
will see if JUnit5 can currently cover those, and not to talk about "how to do
this and that technically" instead of writing a manifesto with this list of
attributes.
IMHO what you guys have showed me is a technical problem in JUnit where the
annotation {{DisplayName}} does not show {{x = bar(15)}} and {{x = bar(54)}}
which I would expect (according the experiences with JUnit4) as a user. The
next problem is that DisplayName talks about string constant, but JUnit5 adds
something to the end: {{ (bar(int))}} which I as user would not like to see
because the framework is adding it unexpectedly and I do not have the string
under control => therefore my sample code. Are we about a bug in JUnit5 or HTML
report?
was (Author: tibor17):
[~Srdo]
[~marcphilipp]
It's clear what I said. You had a problem and I showed you my opinion with
another annotations which make sense to me.
In my opinion users want to see test methods and classes in HTML, so why we are
talking about container and its display name.
It is better to list all attributes which want to be shown on HTML and then we
will see if JUnit5 can currently cover those, and not to talk about "how to do
this and that technically" instead of writing a manifesto with this list of
attributes.
IMHO what you guys have showed me is a technical problem in JUnit where the
annotation {{DisplayName}} does not show {{bar(15)}} and {{bar(54)}} which I
would expect as a user. Are we about a bug in JUnit5 or HTML report?
> 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=16817267#comment-16817267
]
Tibor Digana edited comment on SUREFIRE-1546 at 4/14/19 10:16 AM:
--
[~Srdo]
[~marcphilipp]
It's clear what I said. You had a problem and I showed you my opinion with
another annotations which make sense to me.
In my opinion users want to see test methods and classes in HTML, so why we are
talking about container and its display name.
It is better to list all attributes which want to be shown on HTML and then we
will see if JUnit5 can currently cover those, and not to talk about "how to do
this and that technically" instead of writing a manifesto with this list of
attributes.
IMHO what you guys have showed me is a technical problem in JUnit where the
annotation {{DisplayName}} does not show {{bar(15)}} and {{bar(54)}} which I
would expect as a user. Are we about a bug in JUnit5 or HTML report?
was (Author: tibor17):
[~Srdo]
[~marcphilipp]
It's clear what I said. You had a problem and I showed you my opinion with
another annotations which make sense to me.
In my opinion users want to see test methods and classes in HTML, so why we are
talking about container and its display name.
It is better to list all attributes which want to be shown on HTML and then we
will see if JUnit5 can currently cover those, and not to talk about "how to do
this and that technically" instead of writing a manifesto with this list of
attributes.
> 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] (MSHARED-815) Maven Archiver: MavenArchiver.addManifestAttribute does not escape empty lines in value
[
https://issues.apache.org/jira/browse/MSHARED-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817269#comment-16817269
]
Konrad Windszus commented on MSHARED-815:
-
To me it seems that the right thing to e.g. escape key "test" with value
{code}
This is a paragraph
This is another paragraph
{code}
is
{code}
test: This is a paragraph
This is another paragraph
{code}
There is a space in line 2!
> Maven Archiver: MavenArchiver.addManifestAttribute does not escape empty
> lines in value
> ---
>
> Key: MSHARED-815
> URL: https://issues.apache.org/jira/browse/MSHARED-815
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Konrad Windszus
>Priority: Major
>
> According to
> https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#name-value-pairs-and-sections
> {quote}
> Groups of name-value pairs are known as a "section". Sections are separated
> from other sections by empty lines.
> {quote}
> Therefore empty lines in attribute values lead to invalid manifests and must
> somehow be escaped.
> As this is not done by default in {{java.util.jar.Attributes.writeMain(...)}}
> the method {{MavenArchiver.addManifestAttribute(...)}} should either throw an
> exception in case of empty lines given to parameter {{value}} or escape those
> empty lines somehow
> (https://github.com/apache/maven-archiver/blob/d454ab3fcd147c0201a14f298cc8f9e1a25ba03e/src/main/java/org/apache/maven/archiver/MavenArchiver.java#L221).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-shade-plugin] mkarg opened a new pull request #20: [MSHADE-318] - Include transitive dependencies
mkarg opened a new pull request #20: [MSHADE-318] - Include transitive dependencies URL: https://github.com/apache/maven-shade-plugin/pull/20 Fixes [MSHADE-318](https://issues.apache.org/jira/projects/MSHADE/issues/MSHADE-318) - Specifically included class's dependencies are missing. Solution: Include transitive dependencies of specifically included classes. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) 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=16817267#comment-16817267 ] Tibor Digana edited comment on SUREFIRE-1546 at 4/14/19 10:01 AM: -- [~Srdo] [~marcphilipp] It's clear what I said. You had a problem and I showed you my opinion with another annotations which make sense to me. In my opinion users want to see test methods and classes in HTML, so why we are talking about container and its display name. It is better to list all attributes which want to be shown on HTML and then we will see if JUnit5 can currently cover those, and not to talk about "how to do this and that technically" instead of writing a manifesto with this list of attributes. was (Author: tibor17): [~Srdo] [~marcphilipp] It's clear what I said. You had a problem and I showed you my opinion with another annotations which make sense to me. In my opinion users want to see test methods and classes in HTML, so why we are talking about container and its display name. It is better to list all attributes which want to be shown on HTML and then we will see if JUnit5 can currently cover those, and not to talk about "how to do this and that technically" instead of writing a manifesto with these list of attributes. > 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=16817267#comment-16817267 ] Tibor Digana commented on SUREFIRE-1546: [~Srdo] [~marcphilipp] It's clear what I said. You had a problem and I showed you my opinion with another annotations which make sense to me. In my opinion users want to see test methods and classes in HTML, so why we are talking about container and its display name. It is better to list all attributes which want to be shown on HTML and then we will see if JUnit5 can currently cover those, and not to talk about "how to do this and that technically" instead of writing a manifesto with these list of attributes. > 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] [Created] (MSHADE-318) Specifically included class's dependencies are missing
Markus Karg created MSHADE-318: -- Summary: Specifically included class's dependencies are missing Key: MSHADE-318 URL: https://issues.apache.org/jira/browse/MSHADE-318 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 3.2.1 Reporter: Markus Karg Using `` one can specifically defined classes to exempt from minijar's filtering. This is useful when a class is referenced by `String` name instead of `Class` object reference, like e. g. reflection. Unfortunately *just* the explicitly included class is exempted from removal, while all its transitive references (i. e. all the classes it uses it turn) are still removed when shading. This effectively breaks the result's functionality. This is hard to work around, as *all* such dependencies have to be explicitly given in the pom to prevent it. That is really nasty. As a solution, a specific include shall always automatically include all *transitive dependencies* of the explicitly exempted class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHARED-815) Maven Archiver: MavenArchiver.addManifestAttribute does not escape empty lines in value
[
https://issues.apache.org/jira/browse/MSHARED-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MSHARED-815:
Description:
According to
https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#name-value-pairs-and-sections
{quote}
Groups of name-value pairs are known as a "section". Sections are separated
from other sections by empty lines.
{quote}
Therefore empty lines in attribute values lead to invalid manifests and must
somehow be escaped.
As this is not done by default in {{java.util.jar.Attributes.writeMain(...)}}
the method {{MavenArchiver.addManifestAttribute(...)}} should either throw an
exception in case of empty lines given to parameter {{value}} or escape those
empty lines somehow
(https://github.com/apache/maven-archiver/blob/d454ab3fcd147c0201a14f298cc8f9e1a25ba03e/src/main/java/org/apache/maven/archiver/MavenArchiver.java#L221).
was:
According to
https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#name-value-pairs-and-sections
{quote}
Groups of name-value pairs are known as a "section". Sections are separated
from other sections by empty lines.
{quote}
Therefore empty lines in attribute values lead to invalid manifests and must
somehow be escaped.
As this is not done by default in {{java.util.jar.Attributes.writeMain(...)}}
the method {{MavenArchiver.addManifestAttribute(...}} should either throw an
exception in case of empty lines given to parameter {{value}} or escape those
empty lines somehow
(https://github.com/apache/maven-archiver/blob/d454ab3fcd147c0201a14f298cc8f9e1a25ba03e/src/main/java/org/apache/maven/archiver/MavenArchiver.java#L221)
> Maven Archiver: MavenArchiver.addManifestAttribute does not escape empty
> lines in value
> ---
>
> Key: MSHARED-815
> URL: https://issues.apache.org/jira/browse/MSHARED-815
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Konrad Windszus
>Priority: Major
>
> According to
> https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#name-value-pairs-and-sections
> {quote}
> Groups of name-value pairs are known as a "section". Sections are separated
> from other sections by empty lines.
> {quote}
> Therefore empty lines in attribute values lead to invalid manifests and must
> somehow be escaped.
> As this is not done by default in {{java.util.jar.Attributes.writeMain(...)}}
> the method {{MavenArchiver.addManifestAttribute(...)}} should either throw an
> exception in case of empty lines given to parameter {{value}} or escape those
> empty lines somehow
> (https://github.com/apache/maven-archiver/blob/d454ab3fcd147c0201a14f298cc8f9e1a25ba03e/src/main/java/org/apache/maven/archiver/MavenArchiver.java#L221).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MSHARED-815) Maven Archiver: MavenArchiver.addManifestAttribute does not escape empty lines in value
Konrad Windszus created MSHARED-815:
---
Summary: Maven Archiver: MavenArchiver.addManifestAttribute does
not escape empty lines in value
Key: MSHARED-815
URL: https://issues.apache.org/jira/browse/MSHARED-815
Project: Maven Shared Components
Issue Type: Bug
Components: maven-archiver
Affects Versions: maven-archiver-3.4.0
Reporter: Konrad Windszus
According to
https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#name-value-pairs-and-sections
{quote}
Groups of name-value pairs are known as a "section". Sections are separated
from other sections by empty lines.
{quote}
Therefore empty lines in attribute values lead to invalid manifests and must
somehow be escaped.
As this is not done by default in {{java.util.jar.Attributes.writeMain(...)}}
the method {{MavenArchiver.addManifestAttribute(...}} should either throw an
exception in case of empty lines given to parameter {{value}} or escape those
empty lines somehow
(https://github.com/apache/maven-archiver/blob/d454ab3fcd147c0201a14f298cc8f9e1a25ba03e/src/main/java/org/apache/maven/archiver/MavenArchiver.java#L221)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MSKINS-137) Enable "Hamburger menu" with top-nav only
[ https://issues.apache.org/jira/browse/MSKINS-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSKINS-137: --- Assignee: Sylwester Lachiewicz > Enable "Hamburger menu" with top-nav only > - > > Key: MSKINS-137 > URL: https://issues.apache.org/jira/browse/MSKINS-137 > Project: Maven Skins > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Sylwester Lachiewicz >Priority: Major > > Revitalizing this old PR https://github.com/apache/maven-skins/pull/4 > Still an issue for us down in HBase. Changes seem to apply and have worked in > local testing on the HBase site. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [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=16817248#comment-16817248
]
Stig Rohde Døssing commented on SUREFIRE-1546:
--
[~tibor17] I think JUnit already has the syntax needed for configuring the
container name.
With the current JUnit syntax, you example would be written as
{code}
class DemoTest {
@ParameterizedTest(name = "a parameterized test (bar(int))") <-- This is the
individual invocation name, where param index and value is available
@DisplayName(value = "bar({0})") <-- This is the name for the whole
ParameterizedTest container
void bar(@ValueSource(intValue = {15, 54}) int x) {
...
}
}
{code}
When JUnit calls the RunListenerAdapter, the sequence of calls will be
{code}
executionStarted - { displayName: JUnit Jupiter, type: CONTAINER, source: null }
executionStarted - { displayName: DemoTest, type: CONTAINER, source:
ClassSource [className = 'org.apache.surefire.stdout.corrupt.DemoTest'] }
executionStarted - { displayName: bar{{0}}, type: CONTAINER, source:
MethodSource [className = 'org.apache.surefire.stdout.corrupt.DemoTest',
methodName = 'bar'] } <-- ParameterizedTest container
executionStarted - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- First parameter invocation,
executionFinished - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- First parameter invocation
executionStarted - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- Second parameter invocation
executionFinished - { displayName: a parameterized test (bar(int)), type: TEST,
source: MethodSource [...] } <-- Second parameter invocation
executionFinished - { displayName: bar{{0}}, type: CONTAINER, source:
MethodSource [...] } <-- ParameterizedTest container
executionFinished - { displayName: DemoTest, type: CONTAINER, source:
ClassSource [...] }
executionFinished - { displayName: JUnit Jupiter, type: CONTAINER, source: null
}
{code}
I think the RunListenerAdapter could build a stack of displayNames, where you
add a name to the stack when executionStarted is called, and remove it when
executionFinished is called. We should be able to build a tree like
{code}
JUnit Jupiter
└── DemoTest
└── a parameterized test (bar(int))
├── bar(0)
└── bar(1)
{code}
that way.
The default DisplayName of the ParameterizedTest container is the method name
and parameter types (so "bar(int)"), and the default DisplayName of the
individual invocations is
{code}
"[{index}] {arguments}"
{code}
So with no custom DisplayName or name parameter on ParameterizedTest, we get a
DisplayName hierarchy of
{code}
JUnit Jupiter
└── DemoTest
└── bar(int)
├── [1] 15
└── [2] 54
{code}
I put a little example here if you want to play around with how JUnit calls the
TestExecutionListener https://github.com/srdo/junit-5-test-listener. The
sequence of calls is logged to test-out.log (stdout gets broken due to
https://issues.apache.org/jira/browse/SUREFIRE-1659)
> 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] [Updated] (MSKINS-109) Support HiDPI displays
[ https://issues.apache.org/jira/browse/MSKINS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MSKINS-109: Labels: up-for-grabs (was: close-pending) > Support HiDPI displays > -- > > Key: MSKINS-109 > URL: https://issues.apache.org/jira/browse/MSKINS-109 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.3.1 > Environment: HiDPI/Retina display >Reporter: Hendrik Schreiber >Priority: Major > Labels: up-for-grabs > > Graphics provided in the skin (github ribbon, "Built by Maven", link icons, > ...) are only provided in standard resolution. By now, this looks amateurish > on screens with HiDPI (i.e. Retina displays). > Please provide hi res images that are scaled with width/height parameters so > that they look good on hi res displays. > Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MSKINS-109) Support HiDPI displays
[ https://issues.apache.org/jira/browse/MSKINS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817243#comment-16817243 ] Sylwester Lachiewicz edited comment on MSKINS-109 at 4/14/19 8:58 AM: -- I found an interesting CSS version - as an alternative to PNG versions here: [https://www.unindented.org/blog/github-ribbon-using-css-transforms/] And still, we can try to find better icon images [https://github.com/apache/maven-fluido-skin/tree/master/src/main/resources/images] was (Author: slachiewicz): I found an interesting CSS version - as an alternative to PNG versions here: [https://www.unindented.org/blog/github-ribbon-using-css-transforms/] And still, we can try to find better icons images. > Support HiDPI displays > -- > > Key: MSKINS-109 > URL: https://issues.apache.org/jira/browse/MSKINS-109 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.3.1 > Environment: HiDPI/Retina display >Reporter: Hendrik Schreiber >Priority: Major > Labels: close-pending > > Graphics provided in the skin (github ribbon, "Built by Maven", link icons, > ...) are only provided in standard resolution. By now, this looks amateurish > on screens with HiDPI (i.e. Retina displays). > Please provide hi res images that are scaled with width/height parameters so > that they look good on hi res displays. > Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSKINS-109) Support HiDPI displays
[ https://issues.apache.org/jira/browse/MSKINS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817243#comment-16817243 ] Sylwester Lachiewicz commented on MSKINS-109: - I found an interesting CSS version - as an alternative to PNG versions here: [https://www.unindented.org/blog/github-ribbon-using-css-transforms/] And still, we can try to find better icons images. > Support HiDPI displays > -- > > Key: MSKINS-109 > URL: https://issues.apache.org/jira/browse/MSKINS-109 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.3.1 > Environment: HiDPI/Retina display >Reporter: Hendrik Schreiber >Priority: Major > Labels: close-pending > > Graphics provided in the skin (github ribbon, "Built by Maven", link icons, > ...) are only provided in standard resolution. By now, this looks amateurish > on screens with HiDPI (i.e. Retina displays). > Please provide hi res images that are scaled with width/height parameters so > that they look good on hi res displays. > Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSKINS-145) Google+ Shutdown - remove code from skins
[ https://issues.apache.org/jira/browse/MSKINS-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MSKINS-145: Labels: up-for-grabs (was: ) > Google+ Shutdown - remove code from skins > - > > Key: MSKINS-145 > URL: https://issues.apache.org/jira/browse/MSKINS-145 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Reporter: Sylwester Lachiewicz >Priority: Minor > Labels: up-for-grabs > > Due to Google shutdown of all APIs related to Google+ we should remove our > code generation logic to display GooglePlus buttons. > https://developers.google.com/+/integrations-shutdown -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSKINS-145) Google+ Shutdown - remove code from skins
[ https://issues.apache.org/jira/browse/MSKINS-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817238#comment-16817238 ] Sylwester Lachiewicz commented on MSKINS-145: - Start from: [https://github.com/apache/maven-fluido-skin/blob/master/src/main/resources/META-INF/maven/site-macros.vm#L691] also correct and verify IT test results > Google+ Shutdown - remove code from skins > - > > Key: MSKINS-145 > URL: https://issues.apache.org/jira/browse/MSKINS-145 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Reporter: Sylwester Lachiewicz >Priority: Minor > > Due to Google shutdown of all APIs related to Google+ we should remove our > code generation logic to display GooglePlus buttons. > https://developers.google.com/+/integrations-shutdown -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSKINS-145) Google+ Shutdown - remove code from skins
Sylwester Lachiewicz created MSKINS-145: --- Summary: Google+ Shutdown - remove code from skins Key: MSKINS-145 URL: https://issues.apache.org/jira/browse/MSKINS-145 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Reporter: Sylwester Lachiewicz Due to Google shutdown of all APIs related to Google+ we should remove our code generation logic to display GooglePlus buttons. https://developers.google.com/+/integrations-shutdown -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (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=16817219#comment-16817219 ] Marc Philipp commented on SUREFIRE-1546: [~tibor17] I don't understand where you're going with this. Are you proposing a new way to write parameterized tests for JUnit Jupiter? Could you please elaborate? > 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=16816884#comment-16816884
]
Marc Philipp edited comment on SUREFIRE-1546 at 4/14/19 7:47 AM:
-
{code:java}
@DisplayName("Some tests"
class SomeTests {
@ParameterizedTest(name = "x = {0}")
@DisplayName("a parameterized test")
@ValueSource(intValue = {15, 54})
void bar(int x) {}
}
{code}
Given the code above, the test tree would look like the following:
{code:java}
JUnit Jupiter
└── Some tests (com.acme.SomeTests)
└── a parameterized test (bar(int))
├── x = 15 (bar(int)[0])
└── x = 54 (bar(int)[1])
{code}
I put the "legacy reporting name" that JUnit provides in parentheses.
In the long run, I think Surefire should move beyond the strict class-method
tuple requirement. As [~sor] mentioned above, that will require a new reporting
format which we plan to work on for JUnit 5.6. For now, Surefire could combine
the display name of the method ("a parameterized test") with the one for the
invocation ("x = ...").
was (Author: marcphilipp):
{code:java}
@DisplayName("Some tests"
class SomeTests {
@ParameterizedTest(name = "x = {0}")
@DisplayName("a parameterized test")
@ValueSource(intValue = {15, 54})
void bar(int x) {}
}
{code}
Given the code above, the test tree would look like the following:
{code}
JUnit Jupiter
└── Some tests (com.acme.SomeTests)
└── a parameterized test (bar(int))
├── x = 15 (bar(int)[0])
└── x = 54 (bar(int)[1])
{code}
In put the "legacy reporting name" that JUnit provides in parentheses.
In the long run, I think Surefire should move beyond the strict class-method
tuple requirement. As [~sor] mentioned above, that will require a new reporting
format which we plan to work on for JUnit 5.6. For now, Surefire could combine
the display name of the method ("a parameterized test") with the one for the
invocation ("x = ...").
> 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] 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-482925994 It's in the `master` branch https://github.com/apache/maven-indexer/commits/master, @carlspring 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
