[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682775#comment-16682775
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232477337
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -243,7 +243,7 @@ private StackTraceWriter getStackTraceWriter(
TestIdentifier testIdentifier, Thr
{
String className = getClassName( testIdentifier );
String methodName = getMethodName( testIdentifier ).orElse( "" );
-return new PojoStackTraceWriter( className, methodName, throwable );
+return new LegacyPojoStackTraceWriter( className, methodName,
throwable );
Review comment:
Yes to restore please. We should use the previous `PojoStackTraceWriter`.
The old `LegacyPojoStackTraceWriter` has bad user experience on the console.
Now it has only one purpose within plugin's process. Maybe it could be moved to
`surefire-common`. We will have a chance to break backwards compatibility in
3.0.0.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232477337
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -243,7 +243,7 @@ private StackTraceWriter getStackTraceWriter(
TestIdentifier testIdentifier, Thr
{
String className = getClassName( testIdentifier );
String methodName = getMethodName( testIdentifier ).orElse( "" );
-return new PojoStackTraceWriter( className, methodName, throwable );
+return new LegacyPojoStackTraceWriter( className, methodName,
throwable );
Review comment:
Yes to restore please. We should use the previous `PojoStackTraceWriter`.
The old `LegacyPojoStackTraceWriter` has bad user experience on the console.
Now it has only one purpose within plugin's process. Maybe it could be moved to
`surefire-common`. We will have a chance to break backwards compatibility in
3.0.0.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[ https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682766#comment-16682766 ] ASF GitHub Bot commented on SUREFIRE-1585: -- Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232477165 ## File path: surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformEnginesIT.java ## @@ -93,12 +93,10 @@ public void platform() throws VerificationException String testClasspath = "[DEBUG] test(compact) classpath:" + " test-classes" + " classes" -+ " junit-jupiter-engine-" + jupiter + ".jar" ++ " junit-jupiter-api-" + jupiter + ".jar" Review comment: Excellent, we should document a new user experience with examples: 1. with engine dependency 2. with API dependency (since of `3.0.0-M2`) Do we have third option we can document with this fix? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Auto-resolve "missing" JUnit 5 artifacts > > > Key: SUREFIRE-1585 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1585 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support >Affects Versions: 2.22.1 >Reporter: Christian Stein >Assignee: Christian Stein >Priority: Minor > Labels: features > > Providers should be able to enhance the test runtime by injecting "missing" > artifacts before executing tests. > > For example, the JUnit Platform Provider should add "missing" Test Engine > artifacts for when users only depend on the API of a test framework. > * User test depends on *`junit-jupiter-api`* only? Provide > *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps. > * User test depends on *`junit-jupiter-params`* only? That pulls in > *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test > runtime -- automatically or via plugin deps. > * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform > Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- > automatically or via plugin deps. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232477165 ## File path: surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformEnginesIT.java ## @@ -93,12 +93,10 @@ public void platform() throws VerificationException String testClasspath = "[DEBUG] test(compact) classpath:" + " test-classes" + " classes" -+ " junit-jupiter-engine-" + jupiter + ".jar" ++ " junit-jupiter-api-" + jupiter + ".jar" Review comment: Excellent, we should document a new user experience with examples: 1. with engine dependency 2. with API dependency (since of `3.0.0-M2`) Do we have third option we can document with this fix? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682765#comment-16682765
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232476986
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
Review comment:
I only wanted to say that it is a Clean Code to write expressive code for
places where were previous comments.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682764#comment-16682764
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232476986
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
Review comment:
I only wanted to say that it is a Clean Code to write expressive code for
places where were previus comments.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232476986
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
Review comment:
I only wanted to say that it is a Clean Code to write expressive code for
places where were previous comments.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232476986
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
Review comment:
I only wanted to say that it is a Clean Code to write expressive code for
places where were previus comments.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] Tibor17 commented on a change in pull request #199: Surefire 1593
Tibor17 commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r232476665
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
##
@@ -116,10 +116,10 @@ private File createJar( @Nonnull List classPath,
@Nonnull String startCl
StringBuilder cp = new StringBuilder();
for ( Iterator it = classPath.iterator(); it.hasNext(); )
{
-File classPathElement = new File( it.next() );
+String classPathElement = it.next();
String uri = toClasspathElementUri( parent, classPathElement,
dumpLogDirectory );
cp.append( uri );
-if ( classPathElement.isDirectory() && !uri.endsWith( "/" ) )
+if ( new File( classPathElement ).isDirectory() &&
!uri.endsWith( "/" ) )
Review comment:
I am totally with you. Let's wait for @jglick until he makes all changes.
off-topic: We have one JUnit5 issue and some easy issues to fix. I guess we
can release a new release candidate next week,
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] eolivelli commented on a change in pull request #199: Surefire 1593
eolivelli commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r232475842
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
##
@@ -116,10 +116,10 @@ private File createJar( @Nonnull List classPath,
@Nonnull String startCl
StringBuilder cp = new StringBuilder();
for ( Iterator it = classPath.iterator(); it.hasNext(); )
{
-File classPathElement = new File( it.next() );
+String classPathElement = it.next();
String uri = toClasspathElementUri( parent, classPathElement,
dumpLogDirectory );
cp.append( uri );
-if ( classPathElement.isDirectory() && !uri.endsWith( "/" ) )
+if ( new File( classPathElement ).isDirectory() &&
!uri.endsWith( "/" ) )
Review comment:
In the scope of this change which is about using Paths it seemed to me
strange to add a line which is using the legacy API.
Btw the result will be correct
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682745#comment-16682745 ] Dan Tran commented on WAGON-537: This is Xmas present ... early. Many thanks > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.2.1 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINVOKER-243) invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)
[ https://issues.apache.org/jira/browse/MINVOKER-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682680#comment-16682680 ] Bryan Turner commented on MINVOKER-243: --- (Note: I'm not sure why _both_ 3.0.1 and 3.1.0 appear to copy the POMs twice; seems like that might be a different issue. Not filtering duplicates, perhaps?) > invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0) > -- > > Key: MINVOKER-243 > URL: https://issues.apache.org/jira/browse/MINVOKER-243 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: Christopher Tubbs >Priority: Blocker > > Something seems to have broken between 3.0.1 and 3.1.0, as the install goal > no longer copies transitive dependencies to the localRepositoryPath as it did > in version 3.0.1. > This is very problematic, because if the artifacts are not in the > localRepositoryPath, the invoked project will try to download them from a > remote repository, which isn't possible for SNAPSHOT versions (such as those > in a sibling module in a multi-module project). This can make it difficult to > even build a multi-module project, unless the invoked task is skipped and the > sibling module can be published to a remote snapshot repository temporarily, > and then the build re-executed normally. (Saw this happen in Apache Accumulo > after upgrading to apache-21.pom) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINVOKER-243) invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)
[
https://issues.apache.org/jira/browse/MINVOKER-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682679#comment-16682679
]
Bryan Turner commented on MINVOKER-243:
---
This just caused some CI failures for me. We've got branch builds for our Maven
plugins, and artifacts from different branches can be incompatible in various
ways depending on the in-flight changes. Since the artifacts from different
branches aren't compatible, transitive _in-reactor_ dependencies not being
copied can result in mismatches between any current-build artifacts that _do_
get copied and other _in-reactor_ artifacts from previous builds that aren't
overwritten. Under 3.0.1, that's not an issue as all _in-reactor_ artifacts are
copied, whether they're explicit dependencies or transitive.
{{install}} output from 3.0.1:
{noformat}
[INFO] --- maven-invoker-plugin:3.0.1:install (integration-test) @
bitbucket-maven-plugin ---
[INFO] Installing /Users/bturner/Development/atlassian/amps/pom.xml to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/atlassian-amps-parent/8.0.0-SNAPSHOT/atlassian-amps-parent-8.0.0-SNAPSHOT.pom
[INFO] Installing
/Users/bturner/Development/atlassian/amps/plugin-module-codegen-api/pom.xml to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/plugin-module-codegen-api/8.0.0-SNAPSHOT/plugin-module-codegen-api-8.0.0-SNAPSHOT.pom
[INFO] Installing
/Users/bturner/Development/atlassian/amps/plugin-module-codegen-api/target/plugin-module-codegen-api-8.0.0-SNAPSHOT.jar
to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/plugin-module-codegen-api/8.0.0-SNAPSHOT/plugin-module-codegen-api-8.0.0-SNAPSHOT.jar
[INFO] Installing
/Users/bturner/Development/atlassian/amps/plugin-module-codegen-api/pom.xml to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/plugin-module-codegen-api/8.0.0-SNAPSHOT/plugin-module-codegen-api-8.0.0-SNAPSHOT.pom
[INFO] Installing
/Users/bturner/Development/atlassian/amps/test-codegen-jar-classes/pom.xml to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/test-codegen-jar-classes/8.0.0-SNAPSHOT/test-codegen-jar-classes-8.0.0-SNAPSHOT.pom
[INFO] Installing
/Users/bturner/Development/atlassian/amps/test-codegen-jar-classes/target/test-codegen-jar-classes-8.0.0-SNAPSHOT.jar
to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/test-codegen-jar-classes/8.0.0-SNAPSHOT/test-codegen-jar-classes-8.0.0-SNAPSHOT.jar
[INFO] Installing
/Users/bturner/Development/atlassian/amps/test-codegen-jar-classes/pom.xml to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/test-codegen-jar-classes/8.0.0-SNAPSHOT/test-codegen-jar-classes-8.0.0-SNAPSHOT.pom
[INFO] Installing
/Users/bturner/Development/atlassian/amps/plugin-module-codegen-engine/pom.xml
to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/plugin-module-codegen-engine/8.0.0-SNAPSHOT/plugin-module-codegen-engine-8.0.0-SNAPSHOT.pom
[INFO] Installing
/Users/bturner/Development/atlassian/amps/plugin-module-codegen-engine/target/plugin-module-codegen-engine-8.0.0-SNAPSHOT.jar
to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/plugin-module-codegen-engine/8.0.0-SNAPSHOT/plugin-module-codegen-engine-8.0.0-SNAPSHOT.jar
[INFO] Installing
/Users/bturner/Development/atlassian/amps/plugin-module-codegen-engine/pom.xml
to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/plugin-module-codegen-engine/8.0.0-SNAPSHOT/plugin-module-codegen-engine-8.0.0-SNAPSHOT.pom
[INFO] Installing
/Users/bturner/Development/atlassian/amps/plugin-module-codegen-maven-client/pom.xml
to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/plugin-module-codegen-maven-client/8.0.0-SNAPSHOT/plugin-module-codegen-maven-client-8.0.0-SNAPSHOT.pom
[INFO] Installing
/Users/bturner/Development/atlassian/amps/plugin-module-codegen-maven-client/target/plugin-module-codegen-maven-client-8.0.0-SNAPSHOT.jar
to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/plugin-module-codegen-maven-client/8.0.0-SNAPSHOT/plugin-module-codegen-maven-client-8.0.0-SNAPSHOT.jar
[INFO] Installing
/Users/bturner/Development/atlassian/amps/plugin-module-codegen-maven-client/pom.xml
to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/plugin-module-codegen-maven-client/8.0.0-SNAPSHOT/plugin-module-codegen-maven-client-8.0.0-SNAPSHOT.pom
[INFO] Installing /Users/bturner/Development/atlassian/amps/standalone/pom.xml
to
/Users/bturner/Development/atlassian/amps/invoker-repo/com/atlassian/amps/standalone/8.0.0-SNAPSHOT/standalone-8.0.0-SNAPSHOT.pom
[INFO] Installing
/Users/bturner/Development/atlassian/amps/amps-product-archetypes/pom.xml to
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682667#comment-16682667
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469829
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get(
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
+String junitVintageVersion = "5" +
junitPlatformArtifact.getBaseVersion().substring( 1 );
+resolve( providerArtifacts, "org.junit.vintage",
"junit-vintage-engine", junitVintageVersion );
+}
+
+private void alignJUnitPlatformVersion( Set
providerArtifacts )
+{
+Map providerArtifactMap = new HashMap();
+for ( Artifact artifact : providerArtifacts )
+{
+String key = artifact.getGroupId() + ":" +
artifact.getArtifactId();
+providerArtifactMap.put( key, artifact );
+}
+Artifact defaultLauncher = providerArtifactMap.get(
"org.junit.platform:junit-platform-launcher" );
+logDebugOrCliShowErrors( "JUnit Platform Artifact: " +
junitPlatformArtifact );
+logDebugOrCliShowErrors( "JUnit Platform Launcher: " +
defaultLauncher );
+if ( junitPlatformArtifact.getVersion().equals(
defaultLauncher.getVersion() ) )
+{
+logDebugOrCliShowErrors( "JUnit Platform versions are equal -
proceeding anyway... " );
Review comment:
Here should be a `return;` statement -- but then resulting classpath order
is not matching in the integration tests.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts
[GitHub] sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469829
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
+{
+return;
+}
+Artifact junitVintageEngine = getProjectArtifactMap().get(
"org.junit.vintage:junit-vintage-engine" );
+if ( junitVintageEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-vintage-engine" and its transitive dependencies
+// heuristic: from Platform "x.y.z" to Vintage "5" + ".y.z"
+String junitVintageVersion = "5" +
junitPlatformArtifact.getBaseVersion().substring( 1 );
+resolve( providerArtifacts, "org.junit.vintage",
"junit-vintage-engine", junitVintageVersion );
+}
+
+private void alignJUnitPlatformVersion( Set
providerArtifacts )
+{
+Map providerArtifactMap = new HashMap();
+for ( Artifact artifact : providerArtifacts )
+{
+String key = artifact.getGroupId() + ":" +
artifact.getArtifactId();
+providerArtifactMap.put( key, artifact );
+}
+Artifact defaultLauncher = providerArtifactMap.get(
"org.junit.platform:junit-platform-launcher" );
+logDebugOrCliShowErrors( "JUnit Platform Artifact: " +
junitPlatformArtifact );
+logDebugOrCliShowErrors( "JUnit Platform Launcher: " +
defaultLauncher );
+if ( junitPlatformArtifact.getVersion().equals(
defaultLauncher.getVersion() ) )
+{
+logDebugOrCliShowErrors( "JUnit Platform versions are equal -
proceeding anyway... " );
Review comment:
Here should be a `return;` statement -- but then resulting classpath order
is not matching in the integration tests.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682664#comment-16682664
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469789
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
Review comment:
It's not about speed. It's about handling trivial cases ...
> [...] using return in the middle
... at the beginning of the method. And leave it early, when there's nothing
to do.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469789
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
Review comment:
It's not about speed. It's about handling trivial cases ...
> [...] using return in the middle
... at the beginning of the method. And leave it early, when there's nothing
to do.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682663#comment-16682663
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469724
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
Review comment:
Even with the longer variable name I still see value in the comment. I even
tend to split the `if`-clause into two distinct ones.
```java
if ( junit == null) { return; } // No JUnit at all? No vintage engine.
if ( !junit.getBaseVersion().equals( "4.12" ) ) { return; } // Not exactly
JUnit 4.12? No vintage engine.
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469724
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
Review comment:
Even with the longer variable name I still see value in the comment. I even
tend to split the `if`-clause into two distinct ones.
```java
if ( junit == null) { return; } // No JUnit at all? No vintage engine.
if ( !junit.getBaseVersion().equals( "4.12" ) ) { return; } // Not exactly
JUnit 4.12? No vintage engine.
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682662#comment-16682662
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469652
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
Review comment:
?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469652
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
Review comment:
?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[ https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682661#comment-16682661 ] ASF GitHub Bot commented on SUREFIRE-1585: -- sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469617 ## File path: surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformEnginesIT.java ## @@ -93,12 +93,10 @@ public void platform() throws VerificationException String testClasspath = "[DEBUG] test(compact) classpath:" + " test-classes" + " classes" -+ " junit-jupiter-engine-" + jupiter + ".jar" ++ " junit-jupiter-api-" + jupiter + ".jar" Review comment: At least _IntelliJ IDEA 2018.3 EAP (Community Edition)_ is able to add the matching engines at runtime. Not sure about Eclipse, though. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Auto-resolve "missing" JUnit 5 artifacts > > > Key: SUREFIRE-1585 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1585 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support >Affects Versions: 2.22.1 >Reporter: Christian Stein >Assignee: Christian Stein >Priority: Minor > Labels: features > > Providers should be able to enhance the test runtime by injecting "missing" > artifacts before executing tests. > > For example, the JUnit Platform Provider should add "missing" Test Engine > artifacts for when users only depend on the API of a test framework. > * User test depends on *`junit-jupiter-api`* only? Provide > *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps. > * User test depends on *`junit-jupiter-params`* only? That pulls in > *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test > runtime -- automatically or via plugin deps. > * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform > Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- > automatically or via plugin deps. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469617 ## File path: surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformEnginesIT.java ## @@ -93,12 +93,10 @@ public void platform() throws VerificationException String testClasspath = "[DEBUG] test(compact) classpath:" + " test-classes" + " classes" -+ " junit-jupiter-engine-" + jupiter + ".jar" ++ " junit-jupiter-api-" + jupiter + ".jar" Review comment: At least _IntelliJ IDEA 2018.3 EAP (Community Edition)_ is able to add the matching engines at runtime. Not sure about Eclipse, though. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469556
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -243,7 +243,7 @@ private StackTraceWriter getStackTraceWriter(
TestIdentifier testIdentifier, Thr
{
String className = getClassName( testIdentifier );
String methodName = getMethodName( testIdentifier ).orElse( "" );
-return new PojoStackTraceWriter( className, methodName, throwable );
+return new LegacyPojoStackTraceWriter( className, methodName,
throwable );
Review comment:
What was the solution?
- restore `PojoStackTraceWriter` and use `common-java5` artifact or
- copy `PojoStackTraceWriter` to a local `StackTraceWriter`?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682659#comment-16682659
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469556
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -243,7 +243,7 @@ private StackTraceWriter getStackTraceWriter(
TestIdentifier testIdentifier, Thr
{
String className = getClassName( testIdentifier );
String methodName = getMethodName( testIdentifier ).orElse( "" );
-return new PojoStackTraceWriter( className, methodName, throwable );
+return new LegacyPojoStackTraceWriter( className, methodName,
throwable );
Review comment:
What was the solution?
- restore `PojoStackTraceWriter` and use `common-java5` artifact or
- copy `PojoStackTraceWriter` to a local `StackTraceWriter`?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682657#comment-16682657
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469490
##
File path: surefire-its/src/test/resources/junit-platform/pom.xml
##
@@ -70,4 +64,17 @@
+
+
Review comment:
In `JUnitPlatformEnginesIT` there's the line 66 with `args.add( new Object[]
{ "1.4.0-SNAPSHOT", "5.4.0-SNAPSHOT", "1.1.1", "1.0.0" } );` being passed to
`unpack( "junit-platform",...` within the `@Test platform()` method.
iirc, the auto-resolve feature didn't work when only a user-defined snapshot
repo was added to the project.
Just double-checked and now it works. Removing the ``
element.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232469490
##
File path: surefire-its/src/test/resources/junit-platform/pom.xml
##
@@ -70,4 +64,17 @@
+
+
Review comment:
In `JUnitPlatformEnginesIT` there's the line 66 with `args.add( new Object[]
{ "1.4.0-SNAPSHOT", "5.4.0-SNAPSHOT", "1.1.1", "1.0.0" } );` being passed to
`unpack( "junit-platform",...` within the `@Test platform()` method.
iirc, the auto-resolve feature didn't work when only a user-defined snapshot
repo was added to the project.
Just double-checked and now it works. Removing the ``
element.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Comment Edited] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[
https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682640#comment-16682640
]
Michael Osipov edited comment on WAGON-537 at 11/10/18 10:38 PM:
-
What a great improvement! I made some simple tests form my Windows box to my
Nexus instance in my LAN with a gigabit link:
{noformat}
Before:
Uploaded to nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.220953-5-big.bin
(5.0 GB at 5.7 MB/s)
Downloaded from nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.220953-5-big.bin
(5.0 GB at 11 MB/s)
After:
Uploaded to nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.215857-3-big.bin
(5.0 GB at 20 MB/s)
Downloaded from nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.214908-2-big.bin
(5.0 GB at 83 MB/s)
{noformat}
The difference is insane! I have pushed a slighly modified branch. Any idea why
upload is way slower than download?
was (Author: michael-o):
What a great improvement! I made some simple tests form my Windows box to my
NExus instance in my LAN with a gigabit link:
{noformat}
Before:
Uploaded to nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.220953-5-big.bin
(5.0 GB at 5.7 MB/s)
Downloaded from nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.220953-5-big.bin
(5.0 GB at 11 MB/s)
After:
Uploaded to nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.215857-3-big.bin
(5.0 GB at 20 MB/s)
Downloaded from nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.214908-2-big.bin
(5.0 GB at 83 MB/s)
{noformat}
The difference is insane! I have pushed a slighly modified branch. Any idea why
upload is way slower than download?
> Maven transfer speed of large artifacts is slow due to unsuitable buffer
> strategy
> -
>
> Key: WAGON-537
> URL: https://issues.apache.org/jira/browse/WAGON-537
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http, wagon-provider-api
>Affects Versions: 3.2.0
> Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s
> network connection.
>Reporter: Olaf Otto
>Assignee: Michael Osipov
>Priority: Major
> Labels: perfomance
> Fix For: 3.2.1
>
> Attachments: wagon-issue.png
>
>
> We are using maven for build process automation with docker. This sometimes
> involves uploading and downloading artifacts with a few gigabytes in size.
> Here, maven's transfer speed is consistently and reproducibly slow. For
> instance, an artifact with 7,5 GB in size took almost two hours to transfer
> in spite of a 100 MB/s connection with respective reproducible download speed
> from the remote nexus artifact repository when using a browser to download.
> The same is true when uploding such an artifact.
> I have investigated the issue using JProfiler. The result shows an issue in
> AbstractWagon's transfer( Resource resource, InputStream input, OutputStream
> output, int requestType, long maxSize ) method used for remote artifacts and
> the same issue in AbstractHttpClientWagon#writeTo(OutputStream).
> Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data
> is received, the received data is pushed to downstream listeners via
> fireTransferProgress. These listeners (or rather consumers) perform expensive
> tasks.
> Now, the underlying InputStream implementation used in transfer will return
> calls to read(buffer, offset, length) as soon as *some* data is available.
> That is, fireTransferProgress may well be invoked with an average number of
> bytes less than half the buffer capacity (this varies with the underlying
> network and hardware architecture). Consequently, fireTransferProgress is
> invoked *millions of times* for large files. As this is a blocking operation,
> the time spent in fireTransferProgress dominates and drastically slows down
> the transfers by at least one order of magnitude.
> !wagon-issue.png!
> In our case, we found download speed reduced from a theoretical optimum of
> ~80 seconds to to more than 3200 seconds.
> From an architectural perspective, I would not want to make the consumers /
> listeners invoked via fireTransferProgress aware of their potential impact
[jira] [Updated] (MNG-6513) Replace depreated Plexus javadoc tags with annotations in ITs
[ https://issues.apache.org/jira/browse/MNG-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6513: -- Component/s: Integration Tests > Replace depreated Plexus javadoc tags with annotations in ITs > -- > > Key: MNG-6513 > URL: https://issues.apache.org/jira/browse/MNG-6513 > Project: Maven > Issue Type: Improvement > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Priority: Trivial > > Remove Javadoc Plexus tags @plexus.component and replace with standard Java > annotations from plexus-component-annotations in Integration Tests > Guide: > [https://maven.apache.org/plugin-developers/cookbook/plexus-plugin-upgrade.html] > As effect - remove Javadoc generation warning about Taglets -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[
https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682640#comment-16682640
]
Michael Osipov commented on WAGON-537:
--
What a great improvement! I made some simple tests form my Windows box to my
NExus instance in my LAN with a gigabit link:
{noformat}
Before:
Uploaded to nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.220953-5-big.bin
(5.0 GB at 5.7 MB/s)
Downloaded from nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.220953-5-big.bin
(5.0 GB at 11 MB/s)
After:
Uploaded to nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.215857-3-big.bin
(5.0 GB at 20 MB/s)
Downloaded from nexus-mika:
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/test-big-0.0.1-20181110.214908-2-big.bin
(5.0 GB at 83 MB/s)
{noformat}
The difference is insane! I have pushed a slighly modified branch. Any idea why
upload is way slower than download?
> Maven transfer speed of large artifacts is slow due to unsuitable buffer
> strategy
> -
>
> Key: WAGON-537
> URL: https://issues.apache.org/jira/browse/WAGON-537
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http, wagon-provider-api
>Affects Versions: 3.2.0
> Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s
> network connection.
>Reporter: Olaf Otto
>Assignee: Michael Osipov
>Priority: Major
> Labels: perfomance
> Fix For: 3.2.1
>
> Attachments: wagon-issue.png
>
>
> We are using maven for build process automation with docker. This sometimes
> involves uploading and downloading artifacts with a few gigabytes in size.
> Here, maven's transfer speed is consistently and reproducibly slow. For
> instance, an artifact with 7,5 GB in size took almost two hours to transfer
> in spite of a 100 MB/s connection with respective reproducible download speed
> from the remote nexus artifact repository when using a browser to download.
> The same is true when uploding such an artifact.
> I have investigated the issue using JProfiler. The result shows an issue in
> AbstractWagon's transfer( Resource resource, InputStream input, OutputStream
> output, int requestType, long maxSize ) method used for remote artifacts and
> the same issue in AbstractHttpClientWagon#writeTo(OutputStream).
> Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data
> is received, the received data is pushed to downstream listeners via
> fireTransferProgress. These listeners (or rather consumers) perform expensive
> tasks.
> Now, the underlying InputStream implementation used in transfer will return
> calls to read(buffer, offset, length) as soon as *some* data is available.
> That is, fireTransferProgress may well be invoked with an average number of
> bytes less than half the buffer capacity (this varies with the underlying
> network and hardware architecture). Consequently, fireTransferProgress is
> invoked *millions of times* for large files. As this is a blocking operation,
> the time spent in fireTransferProgress dominates and drastically slows down
> the transfers by at least one order of magnitude.
> !wagon-issue.png!
> In our case, we found download speed reduced from a theoretical optimum of
> ~80 seconds to to more than 3200 seconds.
> From an architectural perspective, I would not want to make the consumers /
> listeners invoked via fireTransferProgress aware of their potential impact on
> download speed, but rather refactor the transfer method such that it uses a
> buffer strategy reducing the the number of fireTransferProgress invocations.
> This should be done with regard to the expected file size of the transfer,
> such that fireTransferProgress is invoked often enough but not to frequent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682630#comment-16682630
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467808
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
Review comment:
I think `get()` in hashMap is fast enough which value can be used to
evaluate it within IF argument and then continue with the main stuff. It makes
sense to me to warp the algorithm around IF-ELSE without using `return` in the
middle within the algorithm.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467808
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
Review comment:
I think `get()` in hashMap is fast enough which value can be used to
evaluate it within IF argument and then continue with the main stuff. It makes
sense to me to warp the algorithm around IF-ELSE without using `return` in the
middle within the algorithm.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682629#comment-16682629
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467808
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
Review comment:
I think `get()` in hashMap is fast enough which value can be used to
evaluate it within IF argument and then cntinue with the main stuff. It makes
sense to me to warp the algorithm around IF-ELSE without using `return` in the
middle within the algorithm.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467808
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
Review comment:
I think `get()` in hashMap is fast enough which value can be used to
evaluate it within IF argument and then cntinue with the main stuff. It makes
sense to me to warp the algorithm around IF-ELSE without using `return` in the
middle within the algorithm.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682626#comment-16682626
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467703
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
Review comment:
The comments like this can be substituted with good name of `boolean`
variable which expressed the purpose.
For instance, `boolean hasApplicableJUnit4ArtifactInProject`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467703
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
Review comment:
The comments like this can be substituted with good name of `boolean`
variable which expressed the purpose.
For instance, `boolean hasApplicableJUnit4ArtifactInProject`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682625#comment-16682625
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467703
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
Review comment:
The comments like this can be substituted with good name of `boolean`
variable which expressed the purpose.
For instance, `boolean hasApplicableJUnit4InProject`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467703
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
+resolveJUnitJupiterEngine( providerArtifacts );
+resolveJUnitVintageEngine( providerArtifacts );
+return providerArtifacts;
+}
+
+private void resolveJUnitJupiterEngine( Set
providerArtifacts )
+{
+Artifact junitJupiterApi = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-api" );
+if ( junitJupiterApi == null ) // no api, no engine
+{
+return;
+}
+Artifact junitJupiterEngine = getProjectArtifactMap().get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterEngine != null ) // engine already resolved by
project
+{
+return;
+}
+// resolve "junit-jupiter-engine" and its transitive dependencies
+String version = junitJupiterApi.getBaseVersion();
+resolve( providerArtifacts, "org.junit.jupiter",
"junit-jupiter-engine", version );
+}
+
+private void resolveJUnitVintageEngine( Set
providerArtifacts )
+{
+Artifact junit = getProjectArtifactMap().get( "junit:junit" );
+if ( junit == null || !junit.getBaseVersion().equals( "4.12" ) )
// no or wrong "junit", no engine
Review comment:
The comments like this can be substituted with good name of `boolean`
variable which expressed the purpose.
For instance, `boolean hasApplicableJUnit4InProject`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682624#comment-16682624
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467602
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
Review comment:
LGTM
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467602
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2846,8 +2849,92 @@ public void addProviderProperties()
@Nonnull
public Set getProviderClasspath()
{
+String provider = "surefire-junit-platform";
String version = surefireBooterArtifact.getBaseVersion();
-return dependencyResolver.getProviderClasspath(
"surefire-junit-platform", version );
+Set providerArtifacts =
dependencyResolver.getProviderClasspath( provider, version );
+alignJUnitPlatformVersion( providerArtifacts );
Review comment:
LGTM
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[ https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682622#comment-16682622 ] ASF GitHub Bot commented on SUREFIRE-1585: -- Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467428 ## File path: surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformEnginesIT.java ## @@ -93,12 +93,10 @@ public void platform() throws VerificationException String testClasspath = "[DEBUG] test(compact) classpath:" + " test-classes" + " classes" -+ " junit-jupiter-engine-" + jupiter + ".jar" ++ " junit-jupiter-api-" + jupiter + ".jar" Review comment: Perfect! This makes sense for users. They will see only API. But this reminds me to think about IDE which is not able to run the tests without implementation of engines. Did you try the same test in Eclipse or IntelliJ IDEA? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Auto-resolve "missing" JUnit 5 artifacts > > > Key: SUREFIRE-1585 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1585 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support >Affects Versions: 2.22.1 >Reporter: Christian Stein >Assignee: Christian Stein >Priority: Minor > Labels: features > > Providers should be able to enhance the test runtime by injecting "missing" > artifacts before executing tests. > > For example, the JUnit Platform Provider should add "missing" Test Engine > artifacts for when users only depend on the API of a test framework. > * User test depends on *`junit-jupiter-api`* only? Provide > *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps. > * User test depends on *`junit-jupiter-params`* only? That pulls in > *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test > runtime -- automatically or via plugin deps. > * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform > Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- > automatically or via plugin deps. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467428 ## File path: surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformEnginesIT.java ## @@ -93,12 +93,10 @@ public void platform() throws VerificationException String testClasspath = "[DEBUG] test(compact) classpath:" + " test-classes" + " classes" -+ " junit-jupiter-engine-" + jupiter + ".jar" ++ " junit-jupiter-api-" + jupiter + ".jar" Review comment: Perfect! This makes sense for users. They will see only API. But this reminds me to think about IDE which is not able to run the tests without implementation of engines. Did you try the same test in Eclipse or IntelliJ IDEA? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682620#comment-16682620
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467317
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -243,7 +243,7 @@ private StackTraceWriter getStackTraceWriter(
TestIdentifier testIdentifier, Thr
{
String className = getClassName( testIdentifier );
String methodName = getMethodName( testIdentifier ).orElse( "" );
-return new PojoStackTraceWriter( className, methodName, throwable );
+return new LegacyPojoStackTraceWriter( className, methodName,
throwable );
Review comment:
Do you have time for this? We talked about it on Slack.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Auto-resolve "missing" JUnit 5 artifacts
>
>
> Key: SUREFIRE-1585
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1585
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1
>Reporter: Christian Stein
>Assignee: Christian Stein
>Priority: Minor
> Labels: features
>
> Providers should be able to enhance the test runtime by injecting "missing"
> artifacts before executing tests.
>
> For example, the JUnit Platform Provider should add "missing" Test Engine
> artifacts for when users only depend on the API of a test framework.
> * User test depends on *`junit-jupiter-api`* only? Provide
> *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps.
> * User test depends on *`junit-jupiter-params`* only? That pulls in
> *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test
> runtime -- automatically or via plugin deps.
> * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform
> Provider is forced? Provide *`junit-vintage-engine`* at test runtime --
> automatically or via plugin deps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing and align "JUnit 5" artifacts
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467317
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -243,7 +243,7 @@ private StackTraceWriter getStackTraceWriter(
TestIdentifier testIdentifier, Thr
{
String className = getClassName( testIdentifier );
String methodName = getMethodName( testIdentifier ).orElse( "" );
-return new PojoStackTraceWriter( className, methodName, throwable );
+return new LegacyPojoStackTraceWriter( className, methodName,
throwable );
Review comment:
Do you have time for this? We talked about it on Slack.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" JUnit 5 artifacts
[ https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682619#comment-16682619 ] ASF GitHub Bot commented on SUREFIRE-1585: -- Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467299 ## File path: surefire-its/src/test/resources/junit-platform/pom.xml ## @@ -70,4 +64,17 @@ + + Review comment: There are no snapshot plugins. Why you added this section? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Auto-resolve "missing" JUnit 5 artifacts > > > Key: SUREFIRE-1585 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1585 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support >Affects Versions: 2.22.1 >Reporter: Christian Stein >Assignee: Christian Stein >Priority: Minor > Labels: features > > Providers should be able to enhance the test runtime by injecting "missing" > artifacts before executing tests. > > For example, the JUnit Platform Provider should add "missing" Test Engine > artifacts for when users only depend on the API of a test framework. > * User test depends on *`junit-jupiter-api`* only? Provide > *`junit-jupiter-engine`* at test runtime -- automatically or via plugin deps. > * User test depends on *`junit-jupiter-params`* only? That pulls in > *`junit-jupiter-api`* transitively. Provide *`junit-jupiter-engine`* at test > runtime -- automatically or via plugin deps. > * User test depends on *`junit:junit:4.12`* only *AND* the JUnit Platform > Provider is forced? Provide *`junit-vintage-engine`* at test runtime -- > automatically or via plugin deps. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP] Resolve missing and align "JUnit 5" artifacts URL: https://github.com/apache/maven-surefire/pull/196#discussion_r232467299 ## File path: surefire-its/src/test/resources/junit-platform/pom.xml ## @@ -70,4 +64,17 @@ + + Review comment: There are no snapshot plugins. Why you added this section? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files
[
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682616#comment-16682616
]
Fabiano Cipriano de Oliveira commented on MSHADE-291:
-
Done
> shadedPattern applied multiples times when relocating the contents of
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Jan Luehe
>Priority: Major
> Labels: up-for-grabs
>
> Steps to reproduce:
> 1. Modified the test case for
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>
> org.apache.maven.plugins
> maven-shade-plugin
> -2.4
> +3.1.1
>
>
>
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>
>
>
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows:
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0
[
https://issues.apache.org/jira/browse/SUREFIRE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682605#comment-16682605
]
James Pether Sörling commented on SUREFIRE-1539:
Created a test case that have the same issue which do not use classifier=tests.
[https://github.com/pethers/SUREFIRE1539] ,using toolchains.xml with dual
compile jdk8 and jdk11 to compile module-info.java. Same issue with jdk9/10 as
well.
Also thanks to all people contributing.
> Surefire causes Jigwaw runtime errors when forkCount > 0
>
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: foo bar
>Priority: Major
> Attachments: mvn-X-clean-install--forkCount0-OK.txt,
> mvn-X-clean-install--noforkCount0-KO.txt
>
>
> h1. The problem
> I'm migrating my toy project to Jigsaw modules.
> Now I managed to make it work ({{maven clean install}} OK), but I had to
> pass an additional flag to Surefire ({{forkCount=0}}) that I think I
> shouldn't have to and feels very "magical" (in a bad way).
> To reproduce:
> 1. {{git clone [https://github.com/vandekeiser/wires.git]}}
> 2. {{git checkout REPORT_SUREFIRE}}
> 3.1 {{mvn clean install}}
> -->passes
> 3.2 remove {{0}} in {{/pom.xml}}
> -->fails
> h1. Analysis
> If I remove {{0}} or set it to 1 in {{/pom.xml}} I get:
> {code:java}
> [ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678
> s <<< FAILURE! - in
> fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
> [ERROR]
> should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
> Time elapsed: 0.219 s <<< ERROR!
> com.pholser.junit.quickcheck.internal.ReflectionException:
> java.lang.IllegalAccessException: class
> com.pholser.junit.quickcheck.internal.Reflection cannot access class
> fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module
> fr.cla.wires.core) because module fr.cla.wires.core does not export
> fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
> {code}
> Looks like --add-opens is no longer added? Or is it just appended to the
> command line, not added to the tmp java @arg file?
> Or is it that with forkCount=0 the test is ran on the classpath and with
> forkCount=1 the test is ran on the modulepath?
>
> If i set it to 2, I get instead:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on
> project wires-support: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test failed:
> java.lang.ClassNotFoundException:
> org.apache.maven.plugin.surefire.StartupReportConfiguration -> [Help 1]{code}
> Which is even more mysterious.
> Environment:
> {code:java}
> $ mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T20:33:14+02:00)
> Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
> Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk-10.0.2
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1593) 3.0.0-M1 produces invalid code sources on Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682603#comment-16682603
]
ASF GitHub Bot commented on SUREFIRE-1593:
--
Tibor17 commented on issue #198: [SUREFIRE-1593] Correcting relativization
logic to produce valid URIs on Windows
URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-437622572
linked with discussion https://github.com/apache/maven-surefire/pull/199
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 3.0.0-M1 produces invalid code sources on Windows
> -
>
> Key: SUREFIRE-1593
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1593
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, process forking
>Affects Versions: 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Major
>
> The fix for SUREFIRE-1588 did not work correctly on Windows. (When
> active—i.e., when the drive letters of the system temporary directory, per
> SUREFIRE-1400, and the project basedir were the same.) It would produce
> relative URIs containing {{%5C}} where {{/}} was intended.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on issue #198: [SUREFIRE-1593] Correcting relativization logic to produce valid URIs on Windows
Tibor17 commented on issue #198: [SUREFIRE-1593] Correcting relativization logic to produce valid URIs on Windows URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-437622572 linked with discussion https://github.com/apache/maven-surefire/pull/199 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682596#comment-16682596
]
Falko Modler edited comment on MNG-6511 at 11/10/18 9:20 PM:
-
{quote}
In general that means strict is better to match the expected result.
{quote}
I'd still say that a user first and foremost just expects the given module not
to be built.
Anyhow, we have different opinons and it's of course up to you to decide
(otherwise).
{quote}
Since it seems you're already using scripts, maybe mavenrc is an option or the
Maven Project options introduced with MNG-5767 which seems to be porely
documented.
{quote}
You can't put {{-pl ! ...}} in {{.mvn/maven.config}} because it kicks in
regardless of which level you are operating on in your multi module project.
{{mvn}} will thus fail if you change the working directory or use {{-f}} in
such a way that one of the negated modules is not part of the reactor anymore.
I guess the same happens with mavenrc.
Anyway, I would _not_ put {{-pl ! ...}} in either of these files because that
would be like a permanent filter for the entire project causing those modules
never to be built.
Instead, I would put {{-pl ! ...}} into my "quick build" script (and maybe
other variants of that script) which lives happily next to my "pre push" script
which doesn't exclude anything (or just use {{mvn clean install}} or whatever).
For me the bottom line of this discussion is that the current behaviour won't
be changed, unfortunately.
I see one possible extension of {{-pl}}, though:
What if you could define something like {{-pl !?foo}}, meaning "exclude foo, if
exists"? And Wildcard or even Regex support would be even more flexible...
WDYT?
was (Author: famod):
{quote}
In general that means strict is better to match the expected result.
{quote}
I'd still say that a user first and foremost just expects the given module not
to be built.
Anyhow, we have different opinons and it's of course up to you to decide
(otherwise).
{quote}
Since it seems you're already using scripts, maybe mavenrc is an option or the
Maven Project options introduced with MNG-5767 which seems to be porely
documented.
{quote}
You can't put {{-pl ! ...}} in {{.mvn/maven.config}} because it kicks in
regardless of which level you are operating on in your multi module project.
{{mvn}} will thus fail if you change the working directory or use {{-f}} in
such a way that one of the negated modules is not part of the reactor anymore.
I guess the same happens with mavenrc.
Anyway, I would _not_ put {{-pl ! ...}} in either of these files because that
would be like a permanent filter for the entire project causing those modules
never to be built.
Instead, I would put {{-pl ! ...}} into my "quick build" script (and maybe
other variants of that script) which lives happily next to my "pre push" script
which doesn't exclude anything (or just use {{mvn clean install}} or whatever).
For me the bottom line of this discussion is that the current behaviour won't
be changed, unfortunalety.
I see one possible extension of {{-pl}}, though:
What if you could define something like {{-pl !?foo}}, meaning "exclude foo, if
exists"? And Wildcard or even Regex support would be even more flexible...
WDYT?
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682596#comment-16682596
]
Falko Modler commented on MNG-6511:
---
{quote}
In general that means strict is better to match the expected result.
{quote}
I'd still say that a user first and foremost just expects the given module not
to be built.
Anyhow, we have different opinons and it's of course up to you to decide
(otherwise).
{quote}
Since it seems you're already using scripts, maybe mavenrc is an option or the
Maven Project options introduced with MNG-5767 which seems to be porely
documented.
{quote}
You can't put {{-pl ! ...}} in {{.mvn/maven.config}} because it kicks in
regardless of which level you are operating on in your multi module project.
{{mvn}} will thus fail if you change the working directory or use {{-f}} in
such a way that one of the negated modules is not part of the reactor anymore.
I guess the same happens with mavenrc.
Anyway, I would _not_ put {{-pl ! ...}} in either of these files because that
would be like a permanent filter for the entire project causing those modules
never to be built.
Instead, I would put {{-pl ! ...}} into my "quick build" script (and maybe
other variants of that script) which lives happily next to my "pre push" script
which doesn't exclude anything (or just use {{mvn clean install}} or whatever).
For me the bottom line of this discussion is that the current behaviour won't
be changed, unfortunalety.
I see one possible extension of {{-pl}}, though:
What if you could define something like {{-pl !?foo}}, meaning "exclude foo, if
exists"? And Wildcard or even Regex support would be even more flexible...
WDYT?
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #199: Surefire 1593
Tibor17 commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r232466200
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
##
@@ -116,10 +116,10 @@ private File createJar( @Nonnull List classPath,
@Nonnull String startCl
StringBuilder cp = new StringBuilder();
for ( Iterator it = classPath.iterator(); it.hasNext(); )
{
-File classPathElement = new File( it.next() );
+String classPathElement = it.next();
String uri = toClasspathElementUri( parent, classPathElement,
dumpLogDirectory );
cp.append( uri );
-if ( classPathElement.isDirectory() && !uri.endsWith( "/" ) )
+if ( new File( classPathElement ).isDirectory() &&
!uri.endsWith( "/" ) )
Review comment:
It would be nice to have `Path parent` created once before the loop.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] Tibor17 commented on a change in pull request #199: Surefire 1593
Tibor17 commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r232466133
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
##
@@ -116,10 +116,10 @@ private File createJar( @Nonnull List classPath,
@Nonnull String startCl
StringBuilder cp = new StringBuilder();
for ( Iterator it = classPath.iterator(); it.hasNext(); )
{
-File classPathElement = new File( it.next() );
+String classPathElement = it.next();
String uri = toClasspathElementUri( parent, classPathElement,
dumpLogDirectory );
cp.append( uri );
-if ( classPathElement.isDirectory() && !uri.endsWith( "/" ) )
+if ( new File( classPathElement ).isDirectory() &&
!uri.endsWith( "/" ) )
Review comment:
@eolivelli
yes, and moreover we should change the method signature from this:
`toClasspathElementUri( String parent, String classPathElement, File
dumpLogDirectory )`
to this:
`toClasspathElementUri( Path parent, Path classPathElement, Path
dumpLogDirectory )`
Which requires calling `dumpLogDir.toPath()` in `ForkStarter` (Line 580) but
pls do not go deeper changing File to Path in all project since it is not a
matter of this PR.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] Tibor17 commented on issue #198: [SUREFIRE-1593] Correcting relativization logic to produce valid URIs on Windows
Tibor17 commented on issue #198: [SUREFIRE-1593] Correcting relativization logic to produce valid URIs on Windows URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-437620227 @cstamas @jglick I could not find in Java specification that element in `Class-Path` should be URI `file:///path/to/jar`. Oracle used examples with relative paths only. In case of absolute paths we use URI. Is this expected? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1593) 3.0.0-M1 produces invalid code sources on Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682586#comment-16682586
]
ASF GitHub Bot commented on SUREFIRE-1593:
--
Tibor17 commented on issue #198: [SUREFIRE-1593] Correcting relativization
logic to produce valid URIs on Windows
URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-437620227
@cstamas
@jglick
I could not find in Java specification that element in `Class-Path` should
be URI `file:///path/to/jar`. Oracle used examples with relative paths only. In
case of absolute paths we use URI. Is this expected?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 3.0.0-M1 produces invalid code sources on Windows
> -
>
> Key: SUREFIRE-1593
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1593
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, process forking
>Affects Versions: 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Major
>
> The fix for SUREFIRE-1588 did not work correctly on Windows. (When
> active—i.e., when the drive letters of the system temporary directory, per
> SUREFIRE-1400, and the project basedir were the same.) It would produce
> relative URIs containing {{%5C}} where {{/}} was intended.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] eolivelli commented on a change in pull request #199: Surefire 1593
eolivelli commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r232465027
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
##
@@ -116,10 +116,10 @@ private File createJar( @Nonnull List classPath,
@Nonnull String startCl
StringBuilder cp = new StringBuilder();
for ( Iterator it = classPath.iterator(); it.hasNext(); )
{
-File classPathElement = new File( it.next() );
+String classPathElement = it.next();
String uri = toClasspathElementUri( parent, classPathElement,
dumpLogDirectory );
cp.append( uri );
-if ( classPathElement.isDirectory() && !uri.endsWith( "/" ) )
+if ( new File( classPathElement ).isDirectory() &&
!uri.endsWith( "/" ) )
Review comment:
Files.isDirectory will be more consistent with the new use of Paths.
What do you think?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] Tibor17 opened a new pull request #199: Surefire 1593
Tibor17 opened a new pull request #199: Surefire 1593 URL: https://github.com/apache/maven-surefire/pull/199 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1593) 3.0.0-M1 produces invalid code sources on Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682580#comment-16682580
]
ASF GitHub Bot commented on SUREFIRE-1593:
--
Tibor17 commented on issue #198: [SUREFIRE-1593] Correcting relativization
logic to produce valid URIs on Windows
URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-437618365
@jglick
Pls update your PR with https://github.com/jglick/maven-surefire/pull/1
there are more unit tests and fixes in codestyle in the test class.
Thx
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 3.0.0-M1 produces invalid code sources on Windows
> -
>
> Key: SUREFIRE-1593
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1593
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, process forking
>Affects Versions: 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Major
>
> The fix for SUREFIRE-1588 did not work correctly on Windows. (When
> active—i.e., when the drive letters of the system temporary directory, per
> SUREFIRE-1400, and the project basedir were the same.) It would produce
> relative URIs containing {{%5C}} where {{/}} was intended.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on issue #198: [SUREFIRE-1593] Correcting relativization logic to produce valid URIs on Windows
Tibor17 commented on issue #198: [SUREFIRE-1593] Correcting relativization logic to produce valid URIs on Windows URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-437618365 @jglick Pls update your PR with https://github.com/jglick/maven-surefire/pull/1 there are more unit tests and fixes in codestyle in the test class. Thx This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-537: - Fix Version/s: 3.3.0 > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.3.0 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6513) Replace depreated Plexus javadoc tags with annotations in ITs
Sylwester Lachiewicz created MNG-6513: - Summary: Replace depreated Plexus javadoc tags with annotations in ITs Key: MNG-6513 URL: https://issues.apache.org/jira/browse/MNG-6513 Project: Maven Issue Type: Improvement Reporter: Sylwester Lachiewicz Remove Javadoc Plexus tags @plexus.component and replace with standard Java annotations from plexus-component-annotations in Integration Tests Guide: [https://maven.apache.org/plugin-developers/cookbook/plexus-plugin-upgrade.html] As effect - remove Javadoc generation warning about Taglets -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0
[
https://issues.apache.org/jira/browse/SUREFIRE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682549#comment-16682549
]
Tibor Digana commented on SUREFIRE-1539:
Yes, we have exactly these problems with users who provide bad workarounds or
information and stackoverflow just follows this.
The Surefire has to follow the Maven dependencies and Jigsaw modularity because
they are both relevant the same as they are relevant for application runtime
and Java compiler. So. I do not see any reason why we should not respect it
since the developer=architect of the project created it with a purpose.
Regarding the cross-directory dependency with {{classifier=tests}} is bad habit
the same bad habit using {{scope=system}}. If any framework has some technical
possibility to use it, it does not mean it should be used with the only
argument "because it is possible". Yes, bad design is technically always
possible but the thing is that every feature of every framework must be
considered very carefully and one should understand the context behind it why
it was introduced in the world. Here test classes have a bounded context within
contained Maven module and thus another module has to have its own
{{src/test/java}}, and they do not want to be shared all over the multi module
project.
> Surefire causes Jigwaw runtime errors when forkCount > 0
>
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: foo bar
>Priority: Major
> Attachments: mvn-X-clean-install--forkCount0-OK.txt,
> mvn-X-clean-install--noforkCount0-KO.txt
>
>
> h1. The problem
> I'm migrating my toy project to Jigsaw modules.
> Now I managed to make it work ({{maven clean install}} OK), but I had to
> pass an additional flag to Surefire ({{forkCount=0}}) that I think I
> shouldn't have to and feels very "magical" (in a bad way).
> To reproduce:
> 1. {{git clone [https://github.com/vandekeiser/wires.git]}}
> 2. {{git checkout REPORT_SUREFIRE}}
> 3.1 {{mvn clean install}}
> -->passes
> 3.2 remove {{0}} in {{/pom.xml}}
> -->fails
> h1. Analysis
> If I remove {{0}} or set it to 1 in {{/pom.xml}} I get:
> {code:java}
> [ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678
> s <<< FAILURE! - in
> fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
> [ERROR]
> should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
> Time elapsed: 0.219 s <<< ERROR!
> com.pholser.junit.quickcheck.internal.ReflectionException:
> java.lang.IllegalAccessException: class
> com.pholser.junit.quickcheck.internal.Reflection cannot access class
> fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module
> fr.cla.wires.core) because module fr.cla.wires.core does not export
> fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
> {code}
> Looks like --add-opens is no longer added? Or is it just appended to the
> command line, not added to the tmp java @arg file?
> Or is it that with forkCount=0 the test is ran on the classpath and with
> forkCount=1 the test is ran on the modulepath?
>
> If i set it to 2, I get instead:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on
> project wires-support: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test failed:
> java.lang.ClassNotFoundException:
> org.apache.maven.plugin.surefire.StartupReportConfiguration -> [Help 1]{code}
> Which is even more mysterious.
> Environment:
> {code:java}
> $ mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T20:33:14+02:00)
> Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
> Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk-10.0.2
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682526#comment-16682526
]
Robert Scholte commented on MNG-6511:
-
It is likely we have to disappoint somebody with any decision. In general that
means strict is better to match the expected result.
However, I think there are already some options available that can help.
Since it seems you're already using scripts, maybe mavenrc is an option or the
Maven Project options introduced with
[MNG-5767|https://issues.apache.org/jira/browse/MNG-5767] which seems to be
porely documented.
Maybe there are other options. If your wish is like "If only I could make the
project-list argument less strict", I would actually think of Maven Extensions.
It will be a customized solution that needs to be implemented, but so should
any other solution.
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6427) IT for MNG-1957 fails on Java 9+
[
https://issues.apache.org/jira/browse/MNG-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682489#comment-16682489
]
Hudson commented on MNG-6427:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6059 #3
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6059/3/
> IT for MNG-1957 fails on Java 9+
>
>
> Key: MNG-6427
> URL: https://issues.apache.org/jira/browse/MNG-6427
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The execution fails with:
> {noformat}
> junit.framework.ComparisonFailure: expected: but was:
> at
> org.apache.maven.it.MavenITmng1957JdkActivationWithVersionRangeTest.testitMNG1957(MavenITmng1957JdkActivationWithVersionRangeTest.java:64)
> {noformat}
> This is caused by incorrect JDK ranges in the {{pom.xml}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6059) Important use cases not covered, as child.inherit.append.path affects all children
[
https://issues.apache.org/jira/browse/MNG-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682488#comment-16682488
]
Hudson commented on MNG-6059:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6059 #3
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6059/3/
> Important use cases not covered, as child.inherit.append.path affects all
> children
> --
>
> Key: MNG-6059
> URL: https://issues.apache.org/jira/browse/MNG-6059
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.6.0
> Environment: Apache Maven 3.4.0-SNAPSHOT
> (227085283b6379038ec16f4cf9ad2e8869cef694; 2016-07-06T21:29:12+02:00)
>Reporter: Andreas Sewe
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.6.1
>
>
> The {{child.inherit.append.path}} attribute introduced with MNG-5951
> unfortunately does not support the use case where the children of the element
> with the attribute should follow different inheritance rules. Take a typical
> configuration for Github, for example (taken from
> <[http://central.sonatype.org/pages/requirements.html]>):
> {noformat}
>
>
> scm:git:git://github.com/simpligility/ossrh-demo.git
>
> scm:git:ssh://github.com:simpligility/ossrh-demo.git
> http://github.com/simpligility/ossrh-demo/tree/master
>
> {noformat}
> If the {{ossrh-demo.git}} repository contains a child module called
> {{some-module}}, then that child’s {{scm/url}} should become
> {{[http://github.com/simpligility/ossrh-demo/tree/master/some-module]}} as
> per the normal inheritance rules, but both the {{scm/connection}} and
> {{scm/developerConnection}} URLs should remain unchanged.
> Unfortunately, this is not possible with {{*child*.inherit.append.path}},
> which acts on all children simultaneously.
> IMHO, this is a conceptual problem. In particular, setting
> {{child.inherit.append.path}} on the *root* element to just control a single
> child ({{project/url}}) feels wrong, as the attribute is in all likelihood
> not even located close to the {{}} element it controls.
> h1. Implemented Solution
> {code:xml}
> ...
> child.scm.developerConnection.inherit.append.path="false"
>child.scm.url.inherit.append.path="false">
> ...
> ...
> ...
>
>
>
> ...
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6509) Upgrade maven-dependency-plugin to 3.1.1
[ https://issues.apache.org/jira/browse/MNG-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682492#comment-16682492 ] Hudson commented on MNG-6509: - Build succeeded in Jenkins: Maven TLP » maven » MNG-6059 #3 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6059/3/ > Upgrade maven-dependency-plugin to 3.1.1 > > > Key: MNG-6509 > URL: https://issues.apache.org/jira/browse/MNG-6509 > Project: Maven > Issue Type: Dependency upgrade > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > > Upgrade plugin to version compatible with Java 9+ for dependency:resolve goal > in Bootstrap ITs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-1957) clause in the activation section has to provide more complex expressions.
[ https://issues.apache.org/jira/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682490#comment-16682490 ] Hudson commented on MNG-1957: - Build succeeded in Jenkins: Maven TLP » maven » MNG-6059 #3 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6059/3/ > clause in the activation section has to provide more complex > expressions. > - > > Key: MNG-1957 > URL: https://issues.apache.org/jira/browse/MNG-1957 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 2.0, 2.0.1 >Reporter: Trustin Lee >Assignee: Brett Porter >Priority: Major > Fix For: 2.1.0 > > Attachments: MNG-1957-maven-project.patch > > > For now, provides only one operator '!' which means negation, but > it would be great if i can use '+' and ~ operator: > 1.5+ > 1.1 ~ 1.4 > ~ 1.3 > 1.4 ~ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682491#comment-16682491 ] Hudson commented on MNG-6481: - Build succeeded in Jenkins: Maven TLP » maven » MNG-6059 #3 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6059/3/ > Allow to compile and test Maven with Java 11 > > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.x-candidate > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682455#comment-16682455
]
Falko Modler commented on MNG-6511:
---
Improving help output is a good idea!
{quote}
why do you want these modules to be excluded? Can it be solved with profiles?
{quote}
Me and my developer colleagues have our own scripts to quickly build a 90+
modules project. These scripts contain options that _could_ be defined by
profiles like {{-Dcheckstyle.skip=true}} and {{-Denforcer.skip=true}} but also
options like {{-T4}} which cannot be defined by profiles.
That project has a couple of modules that you don't want to and also don't need
rebuild all the time, like a final big assembly of everything. I admit that the
project structure might not be ideal but with a more flexible {{-pl}}, people
could just use for (instance) {{-pl ! final-assembly}} in their "quick build"
script and wouldn't need to worry on which level their are invoking that script.
Excluding modules with profiles is pretty verbose, especially since you cannot
say in root pom that you want to exclude one or more modules two or more levels
deeper. You would end up with "module exclusion profiles" scattered all over
the project and that's not something I want to do.
In the end I am just asking for a litte more flexibility of {{-pl ! ...}}. I
mean when I say {{-pl ! foo}} I just don't want that module to be built. At
that point I don't care if it exists or not.
{quote}
However, there's an issue that wants make this more strict, just to ensure you
haven't made a typo or that you accidentally excluded one. For that reason I
tend to say -1 for this proposal.
{quote}
For me this is not the same. When you specify a non-existing profile (which
just issues a warning) you _don't get_ what you wanted (which might be pretty
bad) but when I _don't want_ something then IMHO it is irrelevant whether this
is "achieved" by non-existence or due to being disabled/excluded.
Am I making sense?
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JXR-142) Switch to CDI
Robert Scholte created JXR-142: -- Summary: Switch to CDI Key: JXR-142 URL: https://issues.apache.org/jira/browse/JXR-142 Project: Maven JXR Issue Type: Improvement Components: jxr Reporter: Robert Scholte In order to support more JVM languages the code should be rewritten with the usage of CDI, either as Plexus Components or JSR 330. See https://maven.apache.org/maven-jsr330.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files
[
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682407#comment-16682407
]
ASF GitHub Bot commented on MSHADE-291:
---
rfscholte commented on issue #9: [MSHADE-291] - Fixes bug in SimpleRelocator
URL: https://github.com/apache/maven-shade-plugin/pull/9#issuecomment-437584613
This PR looks good, see
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-shade-plugin/job/MSHADE-291/
If you add yourself as contributor in the pom and squash the commits, I'll
merge them into master.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> shadedPattern applied multiples times when relocating the contents of
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Jan Luehe
>Priority: Major
> Labels: up-for-grabs
>
> Steps to reproduce:
> 1. Modified the test case for
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>
> org.apache.maven.plugins
> maven-shade-plugin
> -2.4
> +3.1.1
>
>
>
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>
>
>
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows:
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] rfscholte commented on issue #9: [MSHADE-291] - Fixes bug in SimpleRelocator
rfscholte commented on issue #9: [MSHADE-291] - Fixes bug in SimpleRelocator URL: https://github.com/apache/maven-shade-plugin/pull/9#issuecomment-437584613 This PR looks good, see https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-shade-plugin/job/MSHADE-291/ If you add yourself as contributor in the pom and squash the commits, I'll merge them into master. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files
[
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682406#comment-16682406
]
Hudson commented on MSHADE-291:
---
Build succeeded in Jenkins: Maven TLP » maven-shade-plugin » MSHADE-291 #2
See
https://builds.apache.org/job/maven-box/job/maven-shade-plugin/job/MSHADE-291/2/
> shadedPattern applied multiples times when relocating the contents of
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Jan Luehe
>Priority: Major
> Labels: up-for-grabs
>
> Steps to reproduce:
> 1. Modified the test case for
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>
> org.apache.maven.plugins
> maven-shade-plugin
> -2.4
> +3.1.1
>
>
>
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>
>
>
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows:
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6512) Checking possibility to require Java 11 to run Maven
[ https://issues.apache.org/jira/browse/MNG-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682405#comment-16682405 ] Michael Osipov commented on MNG-6512: - We have a busload of issues when Javadoc is generated. I most cases it fails due to bad syntax and strict checking beginning with Java 8. For all possible projects I have set Java 7 to perform releases. > Checking possibility to require Java 11 to run Maven > > > Key: MNG-6512 > URL: https://issues.apache.org/jira/browse/MNG-6512 > Project: Maven > Issue Type: Wish >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.x-candidate > > > Based on Maven Core - verify code and plugins how they work with classes > compiled for only Java 11+. > MNG-3699 Require Java 8 - now works fine and pass all tests, also in MNG-6481 > we verified that Maven can be compiled and pass ITs with Java 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6512) Checking possibility to require Java 11 to run Maven
Sylwester Lachiewicz created MNG-6512: - Summary: Checking possibility to require Java 11 to run Maven Key: MNG-6512 URL: https://issues.apache.org/jira/browse/MNG-6512 Project: Maven Issue Type: Wish Reporter: Sylwester Lachiewicz Fix For: 3.6.x-candidate Based on Maven Core - verify code and plugins how they work with classes compiled for only Java 11+. MNG-3699 Require Java 8 - now works fine and pass all tests, also in MNG-6481 we verified that Maven can be compiled and pass ITs with Java 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSITE-828) Jdk 1.8 required / Upgrade Jetty Version 9.4.12
[ https://issues.apache.org/jira/browse/MSITE-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682363#comment-16682363 ] ASF GitHub Bot commented on MSITE-828: -- michael-o commented on issue #3: [MSITE-828] Upgrade jetty to recent version. Update to java 1.8 (required for jetty) URL: https://github.com/apache/maven-site-plugin/pull/3#issuecomment-437579945 @olamy @oflebbe I definitvely see your point, but Jetty 9.2 does its job for testing. As for bumping a Java version: I see this as valid as soon as someone provides good code using those features. When I see how slow we are changing stuff, I don't see this happening beyond 2019. Just for the sake of upgrading, I wouldn't do this. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Jdk 1.8 required / Upgrade Jetty Version 9.4.12 > --- > > Key: MSITE-828 > URL: https://issues.apache.org/jira/browse/MSITE-828 > Project: Maven Site Plugin > Issue Type: Task >Reporter: Olivier Lamy (*$^¨%`£) >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files
[
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682353#comment-16682353
]
Fabiano Cipriano de Oliveira commented on MSHADE-291:
-
If I undertand right {{ServicesResourceTransformer}} was applying source
content 2 times. I made a fix and revert SimpleRelocator modifications.
> shadedPattern applied multiples times when relocating the contents of
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Jan Luehe
>Priority: Major
> Labels: up-for-grabs
>
> Steps to reproduce:
> 1. Modified the test case for
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>
> org.apache.maven.plugins
> maven-shade-plugin
> -2.4
> +3.1.1
>
>
>
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>
>
>
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows:
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682333#comment-16682333 ] Hudson commented on MNG-6481: - Build succeeded in Jenkins: Maven TLP » maven » MNG-6481 #8 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6481/8/ > Allow to compile and test Maven with Java 11 > > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.x-candidate > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 10/11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682317#comment-16682317 ] Sylwester Lachiewicz commented on MNG-6481: --- No issues with rat and checkstyle - just try to decrease test time, but no significant improvement. I'll remove that part. > Allow to compile and test Maven with Java 10/11 > --- > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.x-candidate > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6481) Allow to compile and test Maven with Java 11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6481: -- Summary: Allow to compile and test Maven with Java 11 (was: Allow to compile and test Maven with Java 10/11) > Allow to compile and test Maven with Java 11 > > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.x-candidate > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MNG-6481) Allow to compile and test Maven with Java 10/11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MNG-6481: - Assignee: Sylwester Lachiewicz > Allow to compile and test Maven with Java 10/11 > --- > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.x-candidate > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] cstamas commented on issue #198: [SUREFIRE-1593] Correcting relativization logic to produce valid URIs on Windows
cstamas commented on issue #198: [SUREFIRE-1593] Correcting relativization logic to produce valid URIs on Windows URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-437573037 +1 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1593) 3.0.0-M1 produces invalid code sources on Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682319#comment-16682319
]
ASF GitHub Bot commented on SUREFIRE-1593:
--
cstamas commented on issue #198: [SUREFIRE-1593] Correcting relativization
logic to produce valid URIs on Windows
URL: https://github.com/apache/maven-surefire/pull/198#issuecomment-437573037
+1
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 3.0.0-M1 produces invalid code sources on Windows
> -
>
> Key: SUREFIRE-1593
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1593
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, process forking
>Affects Versions: 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Major
>
> The fix for SUREFIRE-1588 did not work correctly on Windows. (When
> active—i.e., when the drive letters of the system temporary directory, per
> SUREFIRE-1400, and the project basedir were the same.) It would produce
> relative URIs containing {{%5C}} where {{/}} was intended.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682314#comment-16682314
]
Karl Heinz Marbaise commented on MNG-6511:
--
[~rfscholte] Ah read the release notes. So this means one thing: We have to
enhance the help output.
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files
[
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682310#comment-16682310
]
Fabiano Cipriano de Oliveira commented on MSHADE-291:
-
I see I will look at it. Thanks
> shadedPattern applied multiples times when relocating the contents of
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Jan Luehe
>Priority: Major
> Labels: up-for-grabs
>
> Steps to reproduce:
> 1. Modified the test case for
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>
> org.apache.maven.plugins
> maven-shade-plugin
> -2.4
> +3.1.1
>
>
>
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>
>
>
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows:
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 10/11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682303#comment-16682303 ] Robert Scholte commented on MNG-6481: - So the build server is green. I would love to see at least the ITs to run with Java 11. https://github.com/apache/maven/commit/5844c6e5b501dfe8befb0674fb84256ddb36eb21 shows a bit more changes: skipping rat and checkstyle. Can these be fixed as well? Would be nice if I could demo this Tuesday at Devoxx that Java 11 is validated at the buildserver too. > Allow to compile and test Maven with Java 10/11 > --- > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.x-candidate > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 10/11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682292#comment-16682292 ] Hudson commented on MNG-6481: - Build succeeded in Jenkins: Maven TLP » maven » MNG-6481 #7 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6481/7/ > Allow to compile and test Maven with Java 10/11 > --- > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.x-candidate > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files
[
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682279#comment-16682279
]
Robert Scholte commented on MSHADE-291:
---
I would expect the issue to be in the {{ServicesResourceTransformer}}, the
{{canRelocatePath()}}-method should not take the shadedPattern into account.
> shadedPattern applied multiples times when relocating the contents of
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Jan Luehe
>Priority: Major
> Labels: up-for-grabs
>
> Steps to reproduce:
> 1. Modified the test case for
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>
> org.apache.maven.plugins
> maven-shade-plugin
> -2.4
> +3.1.1
>
>
>
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>
>
>
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows:
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682276#comment-16682276
]
Robert Scholte commented on MNG-6511:
-
The negation option is introduced in MNG-5230.
Profiles are comparable, but that one gives warnings when you specify
non-existing profiles. However, there's an issue that wants make this more
strict, just to ensure you haven't made a typo or that you accidentally
excluded one. For that reason I tend to say -1 for this proposal.
I would like to understand the usecase better and to see if there are better
options to solve this. For example: why do you want _these_ modules to be
excluded? Can it be solved with profiles?
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
