[jira] [Updated] (MDEP-613) Analyze failed: Unsupported class file major version 55 (Java 11)
[
https://issues.apache.org/jira/browse/MDEP-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MDEP-613:
---
Summary: Analyze failed: Unsupported class file major version 55 (Java 11)
(was: Analyze failed: Unsupported class file major version 55)
> Analyze failed: Unsupported class file major version 55 (Java 11)
> -
>
> Key: MDEP-613
> URL: https://issues.apache.org/jira/browse/MDEP-613
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.1.0
>Reporter: Mincong Huang
>Priority: Major
> Labels: up-for-grabs
> Fix For: next-release
>
> Attachments: log.txt
>
>
> Class file of major version 55 (Java 11) is not yet supported by Maven
> Dependency Plugin. So when running command {{mvn dependency:analysis}} on
> classes created by Java 11, il failed. See {{log.txt}} for the full log trace.
> This is caused by ASM, which does not support major version 55 (Java 11) yet.
> However, their HEAD contains already the solution, so using the SNAPSHOT
> version will work. This support will be included in the next release 6.2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MDEP-613) Analyze failed: Unsupported class file major version 55
[
https://issues.apache.org/jira/browse/MDEP-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MDEP-613:
---
Labels: up-for-grabs (was: )
> Analyze failed: Unsupported class file major version 55
> ---
>
> Key: MDEP-613
> URL: https://issues.apache.org/jira/browse/MDEP-613
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.1.0
>Reporter: Mincong Huang
>Priority: Major
> Labels: up-for-grabs
> Fix For: next-release
>
> Attachments: log.txt
>
>
> Class file of major version 55 (Java 11) is not yet supported by Maven
> Dependency Plugin. So when running command {{mvn dependency:analysis}} on
> classes created by Java 11, il failed. See {{log.txt}} for the full log trace.
> This is caused by ASM, which does not support major version 55 (Java 11) yet.
> However, their HEAD contains already the solution, so using the SNAPSHOT
> version will work. This support will be included in the next release 6.2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MPLUGIN-323) create @Requirement annotation to replace @Component (should be deprecated)
[
https://issues.apache.org/jira/browse/MPLUGIN-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MPLUGIN-323:
--
Fix Version/s: (was: 3.6.1)
3.7.0
> create @Requirement annotation to replace @Component (should be deprecated)
> ---
>
> Key: MPLUGIN-323
> URL: https://issues.apache.org/jira/browse/MPLUGIN-323
> Project: Maven Plugin Tools
> Issue Type: Wish
> Components: maven-plugin-annotations, maven-plugin-tools-javadoc
>Affects Versions: 3.5
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: 3.7.0
>
>
> injecting a Plexus component into a mojo is currently marked through
> {{@Component}} annotation (or {{@component}} javadoc tag)
> This "component" term is misleading for 2 reasons:
> 1. in plugin descriptor, it creates a {{}} XML element:
> http://maven.apache.org/ref/3-LATEST/maven-plugin-api/plugin.html#class_requirement
> 2. in Plexus, injecting is marked with {{@Requirement}} annotation, when
> {{@Component}} is used to define a component:
> http://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/
> This annotation creates great confusion for years, then even if Plexus is
> being dropped for javax.inject, fixing this misleading terms would be
> beneficial IMHO
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6499) Introducing source dependencies
netroby created MNG-6499: Summary: Introducing source dependencies Key: MNG-6499 URL: https://issues.apache.org/jira/browse/MNG-6499 Project: Maven Issue Type: New Feature Reporter: netroby The gradle build tool now provided us a new dependencies management tools. Refer: [https://blog.gradle.org/introducing-source-dependencies] Hope maven can do same work for us. Maven is good. but the mvn repository management ugly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MENFORCER-306) [REGRESSION] RequirePluginVersions fails
[
https://issues.apache.org/jira/browse/MENFORCER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664391#comment-16664391
]
Geoffrey De Smet commented on MENFORCER-306:
We also see this regression. It fails our build when upgrading from M1 to M2.
> [REGRESSION] RequirePluginVersions fails
>
>
> Key: MENFORCER-306
> URL: https://issues.apache.org/jira/browse/MENFORCER-306
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: MENFORCER-306.zip, pom.xml
>
>
> I have found that running the {{RequirePluginVersions}} rule on a project
> with version {{3.0.0-M1}} works fine whereas it fails with version
> {{3.0.0-M2}}.
> {code}
> [DEBUG] Executing rule:
> org.apache.maven.plugins.enforcer.RequirePluginVersions
> [DEBUG] RequirePluginVersions.getAllPlugins:
> [DEBUG] lifecycleMapping = clean
> [DEBUG] plugins = org.apache.maven.plugins:maven-clean-plugin:2.5:clean
> [DEBUG] plugin = org.apache.maven.plugins:maven-clean-plugin:2.5:clean
> [DEBUG] GAV = [org.apache.maven.plugins, maven-clean-plugin, 2.5, clean]
> [DEBUG] RequirePluginVersions.getAllPlugins:
> [DEBUG] lifecycleMapping = install
> [DEBUG] plugins = org.apache.maven.plugins:maven-install-plugin:2.4:install
> [DEBUG] plugin = org.apache.maven.plugins:maven-install-plugin:2.4:install
> [DEBUG] GAV = [org.apache.maven.plugins, maven-install-plugin, 2.4,
> install]
> [DEBUG] lifecycleMapping = deploy
> [DEBUG] plugins = org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
> [DEBUG] plugin = org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
> [DEBUG] GAV = [org.apache.maven.plugins, maven-deploy-plugin, 2.7, deploy]
> [DEBUG] RequirePluginVersions.getAllPlugins:
> [DEBUG] lifecycleMapping = site
> [DEBUG] plugins = org.apache.maven.plugins:maven-site-plugin:3.3:site
> [DEBUG] plugin = org.apache.maven.plugins:maven-site-plugin:3.3:site
> [DEBUG] GAV = [org.apache.maven.plugins, maven-site-plugin, 3.3, site]
> [DEBUG] lifecycleMapping = site-deploy
> [DEBUG] plugins = org.apache.maven.plugins:maven-site-plugin:3.3:deploy
> [DEBUG] plugin = org.apache.maven.plugins:maven-site-plugin:3.3:deploy
> [DEBUG] GAV = [org.apache.maven.plugins, maven-site-plugin, 3.3, deploy]
> [DEBUG] All Plugins in use: [Plugin [org.tinyjee.dim:doxia-include-macro],
> Plugin [org.apache.maven.plugins:maven-clean-plugin], Plugin
> [org.apache.maven.plugins:maven-install-plugin], Plugin
> [org.apache.maven.plugins:maven-site-plugin], Plugin
> [org.apache.maven.plugins:maven-deploy-plugin], Plugin
> [org.jacoco:jacoco-maven-plugin], Plugin
> [org.apache.maven.plugins:maven-enforcer-plugin]]
> [DEBUG] plugin org.tinyjee.dim:doxia-include-macro not found
> [DEBUG] plugin org.apache.maven.plugins:maven-clean-plugin not found
> [DEBUG] plugin org.apache.maven.plugins:maven-install-plugin not found
> [DEBUG] plugin org.apache.maven.plugins:maven-site-plugin not found
> [DEBUG] plugin org.apache.maven.plugins:maven-deploy-plugin not found
> [DEBUG] plugin org.jacoco:jacoco-maven-plugin not found
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Some plugins are
> missing valid versions:(LATEST RELEASE SNAPSHOT are not allowed )
> org.tinyjee.dim:doxia-include-macro. The version currently in use is 1.1
> org.apache.maven.plugins:maven-clean-plugin. The version currently in use is
> 3.0.0
> org.apache.maven.plugins:maven-install-plugin.The version currently
> in use is 2.5.2
> org.apache.maven.plugins:maven-site-plugin. The version currently in use is
> 3.6
> org.apache.maven.plugins:maven-deploy-plugin. The version currently
> in use is 2.8.2
> org.jacoco:jacoco-maven-plugin. The version currently in use is 0.8.0
> Always define plugin versions! Never use LATEST or RELEASE.
> at org.apache.maven.plugins.enforcer.RequirePluginVersions.execute
> (RequirePluginVersions.java:320)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:194)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {code}
--
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&focusedCommentId=16664388#comment-16664388 ] ASF GitHub Bot commented on WAGON-537: -- olaf-otto commented on issue #51: WAGON-537 Maven transfer speed of large artifacts is slow URL: https://github.com/apache/maven-wagon/pull/51#issuecomment-433232059 This change increases download and upload speed of large artifacts by more than a factor of 10 when applied to maven 3.5.4 on Windows 10 64 bit on recent hardware. 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 > 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-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 > 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)
[GitHub] olaf-otto commented on issue #51: WAGON-537 Maven transfer speed of large artifacts is slow
olaf-otto commented on issue #51: WAGON-537 Maven transfer speed of large artifacts is slow URL: https://github.com/apache/maven-wagon/pull/51#issuecomment-433232059 This change increases download and upload speed of large artifacts by more than a factor of 10 when applied to maven 3.5.4 on Windows 10 64 bit on recent hardware. 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&focusedCommentId=16664329#comment-16664329 ] ASF GitHub Bot commented on WAGON-537: -- olaf-otto opened a new pull request #51: WAGON-537 Maven transfer speed of large artifacts is slow URL: https://github.com/apache/maven-wagon/pull/51 Implemented a buffer strategy such that filling the buffer to at least 50% has priority over frequent writes. Added dynamic buffer capacity allocation based on the expected number of bytes to transfer. Used NIO buffers to simplify buffer management. 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 > 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-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 > 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)
[GitHub] olaf-otto opened a new pull request #51: WAGON-537 Maven transfer speed of large artifacts is slow
olaf-otto opened a new pull request #51: WAGON-537 Maven transfer speed of large artifacts is slow URL: https://github.com/apache/maven-wagon/pull/51 Implemented a buffer strategy such that filling the buffer to at least 50% has priority over frequent writes. Added dynamic buffer capacity allocation based on the expected number of bytes to transfer. Used NIO buffers to simplify buffer management. 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 ] Olaf Otto updated WAGON-537: Description: 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. was: We are using maven for build process automation with docker. This sometimes involves downloading images with a few gigabytes in size. Here, maven's download 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. I have investigated the issue using JProfiler. The result clearly shows a significant issue in AbstractWagon's transfer( Resource resource, InputStream input, OutputStream output, int requestType, long maxSize ) method used for remote artifacts. 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 such as checksumming or printing to console. Now, the underlying InputStream implementation used in transfer will return calls to read(bugger, offset, length) as soon as *some* data is available. That is, fireTransferProgress is 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 transfer 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. I have implemented a solution and transfer speed went up more than one order of magnitude. I will provide a pull request asap. Summary: Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy (was: Maven download speed of large artifacts is slow due to unsuitable buffer strategy for remote Artifacts in AbstractWagon) > Maven transfer speed of larg
[jira] [Commented] (SUREFIRE-1532) MIME type for javascript is now officially application/javascript
[ https://issues.apache.org/jira/browse/SUREFIRE-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664248#comment-16664248 ] ASF GitHub Bot commented on SUREFIRE-1532: -- Tibor17 edited a comment on issue #188: [SUREFIRE-1532] MIME type for javascript is now officially application/javascript URL: https://github.com/apache/maven-surefire/pull/188#issuecomment-433193204 @based2 This feature with `application/javascript` was released in version 2.22.1. Do you know that? Close this ticket. 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 > MIME type for javascript is now officially application/javascript > - > > Key: SUREFIRE-1532 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1532 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Basile Chandesris >Assignee: Tibor Digana >Priority: Minor > Labels: easyfix > Fix For: 2.22.1 > > > > ref [http://www.rfc-editor.org/rfc/rfc4329.txt > |http://www.rfc-editor.org/rfc/rfc4329.txt]Scripting Media Types > src > [https://stackoverflow.com/questions/189850/what-is-the-javascript-mime-type-for-the-type-attribute-of-a-script-tag] > "This is a common mistake. The MIME type for javascript wasn't standardized > for years. It's now officially: "application/javascript"." > github > https://github.com/apache/maven-surefire/pull/188#issuecomment-401559853 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-537) Maven download speed of large artifacts is slow due to unsuitable buffer strategy for remote Artifacts in AbstractWagon
[
https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664245#comment-16664245
]
ASF GitHub Bot commented on WAGON-537:
--
olaf-otto commented on a change in pull request #50: WAGON-537 Maven download
speed of large artifacts is slow
URL: https://github.com/apache/maven-wagon/pull/50#discussion_r228322159
##
File path:
wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
##
@@ -560,31 +564,78 @@ protected void transfer( Resource resource, InputStream
input, OutputStream outp
protected void transfer( Resource resource, InputStream input,
OutputStream output, int requestType, long maxSize )
throws IOException
{
-byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
+byte[] buffer = bufferForTransferring( resource );
TransferEvent transferEvent = new TransferEvent( this, resource,
TransferEvent.TRANSFER_PROGRESS, requestType );
transferEvent.setTimestamp( System.currentTimeMillis() );
long remaining = maxSize;
while ( remaining > 0 )
{
-// let's safely cast to int because the min value will be lower
than the buffer size.
-int n = input.read( buffer, 0, (int) Math.min( buffer.length,
remaining ) );
+// Read from the stream, block if necessary until either EOF or
buffer is filled.
+// Filling the buffer has priority since downstream processors
will significantly degrade i/o
+// performance if called to frequently (large data streams) as
they perform expensive tasks such as
+// console output or data integrity checks.
+int nextByte = input.read();
-if ( n == -1 )
+if ( nextByte == -1 )
{
break;
}
-fireTransferProgress( transferEvent, buffer, n );
+buffer[0] = ( byte ) nextByte;
+
+// let's safely cast to int because the min value will be lower
than the buffer size.
+int length = (int) min( buffer.length, remaining ),
+read = 1;
+
+for ( ; read < length ; ++read )
+{
+nextByte = input.read();
+if ( nextByte == -1 )
+{
+break;
+}
+buffer[read] = ( byte ) nextByte;
+}
+
+fireTransferProgress( transferEvent, buffer, read );
Review comment:
Hi @michael-o
I am going to retract htis pull request to change as I am not satisfied with
the solution yet. As it happens, the same issue exist when uploading large
files (100+ MB) using maven. Thee, however, buffering has a different effect as
the underlying stream usually stems from a file.
I have decided that I will address both issues. The best course of action is
thus to change the scope of WAGON-537 and adopt a more generic solution (using
nio) that will fix the issue for both cases. I will open up a ne wpoull request
asap.
Thanks again for your review!
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
> Maven download speed of large artifacts is slow due to unsuitable buffer
> strategy for remote Artifacts in AbstractWagon
> ---
>
> Key: WAGON-537
> URL: https://issues.apache.org/jira/browse/WAGON-537
> Project: Maven Wagon
> Issue Type: Improvement
> Components: 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
> Attachments: wagon-issue.png
>
>
> We are using maven for build process automation with docker. This sometimes
> involves downloading images with a few gigabytes in size. Here, maven's
> download 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.
> I have investigated the issue using JProfiler. The result clearly shows a
> significant issue in AbstractWagon's transfer( Resource resource, InputStream
> input, OutputStream output, int requestType, long maxSize ) method used for
> remote artifacts.
[jira] [Commented] (SUREFIRE-1532) MIME type for javascript is now officially application/javascript
[ https://issues.apache.org/jira/browse/SUREFIRE-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664244#comment-16664244 ] ASF GitHub Bot commented on SUREFIRE-1532: -- Tibor17 commented on issue #188: [SUREFIRE-1532] MIME type for javascript is now officially application/javascript URL: https://github.com/apache/maven-surefire/pull/188#issuecomment-433193204 @based2 This feature with `application/javascript` was released in version 2.22.1. Do you know that? Close this ticket. 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 > MIME type for javascript is now officially application/javascript > - > > Key: SUREFIRE-1532 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1532 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Basile Chandesris >Assignee: Tibor Digana >Priority: Minor > Labels: easyfix > Fix For: 2.22.1 > > > > ref [http://www.rfc-editor.org/rfc/rfc4329.txt > |http://www.rfc-editor.org/rfc/rfc4329.txt]Scripting Media Types > src > [https://stackoverflow.com/questions/189850/what-is-the-javascript-mime-type-for-the-type-attribute-of-a-script-tag] > "This is a common mistake. The MIME type for javascript wasn't standardized > for years. It's now officially: "application/javascript"." > github > https://github.com/apache/maven-surefire/pull/188#issuecomment-401559853 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-537) Maven download speed of large artifacts is slow due to unsuitable buffer strategy for remote Artifacts in AbstractWagon
[
https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664246#comment-16664246
]
ASF GitHub Bot commented on WAGON-537:
--
olaf-otto closed pull request #50: WAGON-537 Maven download speed of large
artifacts is slow
URL: https://github.com/apache/maven-wagon/pull/50
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
b/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
index 4cbf37d7..d420ee80 100644
--- a/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
+++ b/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
@@ -44,6 +44,9 @@
import java.io.OutputStream;
import java.util.List;
+import static java.lang.Math.max;
+import static java.lang.Math.min;
+
/**
* Implementation of common facilities for Wagon providers.
*
@@ -53,6 +56,24 @@
implements Wagon
{
protected static final int DEFAULT_BUFFER_SIZE = 1024 * 4;
+protected static final int MAXIMUM_BUFFER_SIZE = 1024 * 512;
+
+/**
+ * To efficiently buffer data, use a multiple of 4k
+ * as this is likely to match the hardware buffer size of certain
+ * storage devices.
+ */
+protected static final int BUFFER_SEGMENT_SIZE = 4 * 1024;
+
+/**
+ * The desired minimum amount of chunks in which a {@link Resource} shall
be
+ * {@link #transfer(Resource, InputStream, OutputStream, int, long)
transferred}.
+ * This corresponds to the minimum times {@link
#fireTransferProgress(TransferEvent, byte[], int)}.
+ * 100 notifications is a conservative value that will lead to small
chunks for
+ * any artifact less that {@link #BUFFER_SEGMENT_SIZE} * {@link
#MINIMUM_AMOUNT_OF_TRANSFER_CHUNKS}
+ * in size.
+ */
+protected static final int MINIMUM_AMOUNT_OF_TRANSFER_CHUNKS = 100;
protected Repository repository;
@@ -560,7 +581,7 @@ protected void transfer( Resource resource, InputStream
input, OutputStream outp
protected void transfer( Resource resource, InputStream input,
OutputStream output, int requestType, long maxSize )
throws IOException
{
-byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
+byte[] buffer = bufferForTransferring( resource );
TransferEvent transferEvent = new TransferEvent( this, resource,
TransferEvent.TRANSFER_PROGRESS, requestType );
transferEvent.setTimestamp( System.currentTimeMillis() );
@@ -568,23 +589,72 @@ protected void transfer( Resource resource, InputStream
input, OutputStream outp
long remaining = maxSize;
while ( remaining > 0 )
{
-// let's safely cast to int because the min value will be lower
than the buffer size.
-int n = input.read( buffer, 0, (int) Math.min( buffer.length,
remaining ) );
+// Read from the stream, block if necessary until either EOF or
buffer is filled.
+// Filling the buffer has priority since downstream processors
will significantly degrade i/o
+// performance if called to frequently (large data streams) as
they perform expensive tasks such as
+// console output or data integrity checks.
+int nextByte = input.read();
-if ( n == -1 )
+if ( nextByte == -1 )
{
break;
}
-fireTransferProgress( transferEvent, buffer, n );
+buffer[0] = ( byte ) nextByte;
-output.write( buffer, 0, n );
+// let's safely cast to int because the min value will be lower
than the buffer size.
+int length = (int) min( buffer.length, remaining ),
+read = 1;
-remaining -= n;
+for ( ; read < length ; ++read )
+{
+nextByte = input.read();
+if ( nextByte == -1 )
+{
+break;
+}
+buffer[read] = ( byte ) nextByte;
+}
+
+fireTransferProgress( transferEvent, buffer, read );
+
+output.write( buffer, 0, read );
+
+remaining -= read;
}
output.flush();
}
+/**
+ * Provide a buffer suitably sized for efficiently
+ * {@link #transfer(Resource, InputStream, OutputStream, int, long)
transferring}
+ * the given {@link Resource}. For larger files, larger buffers are
provided such that downstream
+ * {@link #fireTransferProgress(TransferEvent, byte[], int) listeners} are
not notified overly frequently.
+ * For instance,
[GitHub] Tibor17 commented on issue #188: [SUREFIRE-1532] MIME type for javascript is now officially application/javascript
Tibor17 commented on issue #188: [SUREFIRE-1532] MIME type for javascript is now officially application/javascript URL: https://github.com/apache/maven-surefire/pull/188#issuecomment-433193204 @based2 This feature with `application/javascript` was released in version 2.22.1. Do you know that? Close this ticket. 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] olaf-otto commented on a change in pull request #50: WAGON-537 Maven download speed of large artifacts is slow
olaf-otto commented on a change in pull request #50: WAGON-537 Maven download
speed of large artifacts is slow
URL: https://github.com/apache/maven-wagon/pull/50#discussion_r228322159
##
File path:
wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
##
@@ -560,31 +564,78 @@ protected void transfer( Resource resource, InputStream
input, OutputStream outp
protected void transfer( Resource resource, InputStream input,
OutputStream output, int requestType, long maxSize )
throws IOException
{
-byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
+byte[] buffer = bufferForTransferring( resource );
TransferEvent transferEvent = new TransferEvent( this, resource,
TransferEvent.TRANSFER_PROGRESS, requestType );
transferEvent.setTimestamp( System.currentTimeMillis() );
long remaining = maxSize;
while ( remaining > 0 )
{
-// let's safely cast to int because the min value will be lower
than the buffer size.
-int n = input.read( buffer, 0, (int) Math.min( buffer.length,
remaining ) );
+// Read from the stream, block if necessary until either EOF or
buffer is filled.
+// Filling the buffer has priority since downstream processors
will significantly degrade i/o
+// performance if called to frequently (large data streams) as
they perform expensive tasks such as
+// console output or data integrity checks.
+int nextByte = input.read();
-if ( n == -1 )
+if ( nextByte == -1 )
{
break;
}
-fireTransferProgress( transferEvent, buffer, n );
+buffer[0] = ( byte ) nextByte;
+
+// let's safely cast to int because the min value will be lower
than the buffer size.
+int length = (int) min( buffer.length, remaining ),
+read = 1;
+
+for ( ; read < length ; ++read )
+{
+nextByte = input.read();
+if ( nextByte == -1 )
+{
+break;
+}
+buffer[read] = ( byte ) nextByte;
+}
+
+fireTransferProgress( transferEvent, buffer, read );
Review comment:
Hi @michael-o
I am going to retract htis pull request to change as I am not satisfied with
the solution yet. As it happens, the same issue exist when uploading large
files (100+ MB) using maven. Thee, however, buffering has a different effect as
the underlying stream usually stems from a file.
I have decided that I will address both issues. The best course of action is
thus to change the scope of WAGON-537 and adopt a more generic solution (using
nio) that will fix the issue for both cases. I will open up a ne wpoull request
asap.
Thanks again for your review!
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] olaf-otto closed pull request #50: WAGON-537 Maven download speed of large artifacts is slow
olaf-otto closed pull request #50: WAGON-537 Maven download speed of large
artifacts is slow
URL: https://github.com/apache/maven-wagon/pull/50
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
b/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
index 4cbf37d7..d420ee80 100644
--- a/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
+++ b/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
@@ -44,6 +44,9 @@
import java.io.OutputStream;
import java.util.List;
+import static java.lang.Math.max;
+import static java.lang.Math.min;
+
/**
* Implementation of common facilities for Wagon providers.
*
@@ -53,6 +56,24 @@
implements Wagon
{
protected static final int DEFAULT_BUFFER_SIZE = 1024 * 4;
+protected static final int MAXIMUM_BUFFER_SIZE = 1024 * 512;
+
+/**
+ * To efficiently buffer data, use a multiple of 4k
+ * as this is likely to match the hardware buffer size of certain
+ * storage devices.
+ */
+protected static final int BUFFER_SEGMENT_SIZE = 4 * 1024;
+
+/**
+ * The desired minimum amount of chunks in which a {@link Resource} shall
be
+ * {@link #transfer(Resource, InputStream, OutputStream, int, long)
transferred}.
+ * This corresponds to the minimum times {@link
#fireTransferProgress(TransferEvent, byte[], int)}.
+ * 100 notifications is a conservative value that will lead to small
chunks for
+ * any artifact less that {@link #BUFFER_SEGMENT_SIZE} * {@link
#MINIMUM_AMOUNT_OF_TRANSFER_CHUNKS}
+ * in size.
+ */
+protected static final int MINIMUM_AMOUNT_OF_TRANSFER_CHUNKS = 100;
protected Repository repository;
@@ -560,7 +581,7 @@ protected void transfer( Resource resource, InputStream
input, OutputStream outp
protected void transfer( Resource resource, InputStream input,
OutputStream output, int requestType, long maxSize )
throws IOException
{
-byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
+byte[] buffer = bufferForTransferring( resource );
TransferEvent transferEvent = new TransferEvent( this, resource,
TransferEvent.TRANSFER_PROGRESS, requestType );
transferEvent.setTimestamp( System.currentTimeMillis() );
@@ -568,23 +589,72 @@ protected void transfer( Resource resource, InputStream
input, OutputStream outp
long remaining = maxSize;
while ( remaining > 0 )
{
-// let's safely cast to int because the min value will be lower
than the buffer size.
-int n = input.read( buffer, 0, (int) Math.min( buffer.length,
remaining ) );
+// Read from the stream, block if necessary until either EOF or
buffer is filled.
+// Filling the buffer has priority since downstream processors
will significantly degrade i/o
+// performance if called to frequently (large data streams) as
they perform expensive tasks such as
+// console output or data integrity checks.
+int nextByte = input.read();
-if ( n == -1 )
+if ( nextByte == -1 )
{
break;
}
-fireTransferProgress( transferEvent, buffer, n );
+buffer[0] = ( byte ) nextByte;
-output.write( buffer, 0, n );
+// let's safely cast to int because the min value will be lower
than the buffer size.
+int length = (int) min( buffer.length, remaining ),
+read = 1;
-remaining -= n;
+for ( ; read < length ; ++read )
+{
+nextByte = input.read();
+if ( nextByte == -1 )
+{
+break;
+}
+buffer[read] = ( byte ) nextByte;
+}
+
+fireTransferProgress( transferEvent, buffer, read );
+
+output.write( buffer, 0, read );
+
+remaining -= read;
}
output.flush();
}
+/**
+ * Provide a buffer suitably sized for efficiently
+ * {@link #transfer(Resource, InputStream, OutputStream, int, long)
transferring}
+ * the given {@link Resource}. For larger files, larger buffers are
provided such that downstream
+ * {@link #fireTransferProgress(TransferEvent, byte[], int) listeners} are
not notified overly frequently.
+ * For instance, transferring gigabyte-sized resources would result in
millions of notifications when using
+ * only a few kilobytes of buffer, drastically slowing transfer since
transfer progress listeners and
+ * notifications are synchronous and may block,
[GitHub] Tibor17 edited a comment on issue #188: [SUREFIRE-1532] MIME type for javascript is now officially application/javascript
Tibor17 edited a comment on issue #188: [SUREFIRE-1532] MIME type for javascript is now officially application/javascript URL: https://github.com/apache/maven-surefire/pull/188#issuecomment-433193204 @based2 This feature with `application/javascript` was released in version 2.22.1. Do you know that? Close this ticket. 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] [Moved] (MNGSITE-355) super pom for Maven 3
[ https://issues.apache.org/jira/browse/MNGSITE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise moved MNG-6493 to MNGSITE-355: -- Affects Version/s: (was: 3.5.4) Component/s: (was: Documentation: General) Key: MNGSITE-355 (was: MNG-6493) Project: Maven Project Web Site (was: Maven) > super pom for Maven 3 > - > > Key: MNGSITE-355 > URL: https://issues.apache.org/jira/browse/MNGSITE-355 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > https://maven.apache.org/guides/introduction/introduction-to-the-pom.html > contains the super POM for Maven 2.0.x and 2.1.x but not anything later. This > should be upgraded to whatever we're using in 3.5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663886#comment-16663886
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing artifact
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r228219234
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2995,6 +2996,36 @@ private void resolveJUnitVintageEngine( Set
providerArtifacts )
Set resolvedArtifacts = resolveArtifact( null,
junitVintageEngine ).getArtifacts();
providerArtifacts.addAll( resolvedArtifacts );
}
+
+private void alignJUnitPlatformLauncher( 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" );
+Artifact junitPlatformCommons = getProjectArtifactMap().get(
"org.junit.platform:junit-platform-commons" );
+
+if ( junitPlatformCommons.getVersion().equals(
defaultLauncher.getVersion() ) )
+{
+return;
Review comment:
Why not negation and then pass the code into IF body. Why return. The `new
DefaultArtifact(` is afterwards.
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" 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 artifact
Tibor17 commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing artifact
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r228219234
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2995,6 +2996,36 @@ private void resolveJUnitVintageEngine( Set
providerArtifacts )
Set resolvedArtifacts = resolveArtifact( null,
junitVintageEngine ).getArtifacts();
providerArtifacts.addAll( resolvedArtifacts );
}
+
+private void alignJUnitPlatformLauncher( 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" );
+Artifact junitPlatformCommons = getProjectArtifactMap().get(
"org.junit.platform:junit-platform-commons" );
+
+if ( junitPlatformCommons.getVersion().equals(
defaultLauncher.getVersion() ) )
+{
+return;
Review comment:
Why not negation and then pass the code into IF body. Why return. The `new
DefaultArtifact(` is afterwards.
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] khmarbaise commented on issue #186: better performant for some Collection operations
khmarbaise commented on issue #186: better performant for some Collection operations URL: https://github.com/apache/maven/pull/186#issuecomment-433086416 has been merged to 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
[GitHub] khmarbaise closed pull request #186: better performant for some Collection operations
khmarbaise closed pull request #186: better performant for some Collection
operations
URL: https://github.com/apache/maven/pull/186
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/maven-compat/src/main/java/org/apache/maven/project/ModelUtils.java
b/maven-compat/src/main/java/org/apache/maven/project/ModelUtils.java
index fb99593c90..9bcc384234 100644
--- a/maven-compat/src/main/java/org/apache/maven/project/ModelUtils.java
+++ b/maven-compat/src/main/java/org/apache/maven/project/ModelUtils.java
@@ -313,12 +313,8 @@ private static void mergePluginExecutionDefinitions(
PluginExecution child, Plug
public static List mergeRepositoryLists( List
dominant, List recessive )
{
-List repositories = new ArrayList<>();
-for ( Repository repository : dominant )
-{
-repositories.add( repository );
-}
+List repositories = new ArrayList<>( dominant );
for ( Repository repository : recessive )
{
diff --git
a/maven-compat/src/main/java/org/apache/maven/repository/metadata/DefaultClasspathTransformation.java
b/maven-compat/src/main/java/org/apache/maven/repository/metadata/DefaultClasspathTransformation.java
index b6e3c0c96e..f980f5ab47 100644
---
a/maven-compat/src/main/java/org/apache/maven/repository/metadata/DefaultClasspathTransformation.java
+++
b/maven-compat/src/main/java/org/apache/maven/repository/metadata/DefaultClasspathTransformation.java
@@ -139,7 +139,7 @@ protected void visit( MetadataGraphVertex node ) // ,
String version, String art
if ( exits != null && exits.size() > 0 )
{
-MetadataGraphEdge[] sortedExits = exits.toArray( new
MetadataGraphEdge[exits.size()] );
+MetadataGraphEdge[] sortedExits = exits.toArray( new
MetadataGraphEdge[0] );
Arrays.sort( sortedExits
,
new Comparator()
diff --git
a/maven-core/src/main/java/org/apache/maven/project/ProjectModelResolver.java
b/maven-core/src/main/java/org/apache/maven/project/ProjectModelResolver.java
index 2b3108a47f..24b36dda31 100644
---
a/maven-core/src/main/java/org/apache/maven/project/ProjectModelResolver.java
+++
b/maven-core/src/main/java/org/apache/maven/project/ProjectModelResolver.java
@@ -49,6 +49,7 @@
import org.eclipse.aether.resolution.VersionRangeResolutionException;
import org.eclipse.aether.resolution.VersionRangeResult;
+
/**
* A model resolver to assist building of projects. This resolver gives
priority to those repositories that have been
* declared in the POM.
@@ -91,9 +92,7 @@ public ProjectModelResolver( RepositorySystemSession session,
RequestTrace trace
this.resolver = resolver;
this.remoteRepositoryManager = remoteRepositoryManager;
this.pomRepositories = new ArrayList<>();
-List externalRepositories = new ArrayList<>();
-externalRepositories.addAll( repositories );
-this.externalRepositories = Collections.unmodifiableList(
externalRepositories );
+this.externalRepositories = Collections.unmodifiableList( new
ArrayList<>( repositories ) );
this.repositories = new ArrayList<>();
this.repositories.addAll( externalRepositories );
this.repositoryMerging = repositoryMerging;
diff --git
a/maven-core/src/main/java/org/apache/maven/toolchain/DefaultToolchainManagerPrivate.java
b/maven-core/src/main/java/org/apache/maven/toolchain/DefaultToolchainManagerPrivate.java
index 40db38994d..1591573f62 100644
---
a/maven-core/src/main/java/org/apache/maven/toolchain/DefaultToolchainManagerPrivate.java
+++
b/maven-core/src/main/java/org/apache/maven/toolchain/DefaultToolchainManagerPrivate.java
@@ -69,7 +69,7 @@
}
}
-return toRet.toArray( new ToolchainPrivate[toRet.size()] );
+return toRet.toArray( new ToolchainPrivate[0] );
}
@Override
diff --git
a/maven-core/src/test/java/org/apache/maven/lifecycle/internal/stub/MojoExecutorStub.java
b/maven-core/src/test/java/org/apache/maven/lifecycle/internal/stub/MojoExecutorStub.java
index a8572ffc9f..8a6580b699 100644
---
a/maven-core/src/test/java/org/apache/maven/lifecycle/internal/stub/MojoExecutorStub.java
+++
b/maven-core/src/test/java/org/apache/maven/lifecycle/internal/stub/MojoExecutorStub.java
@@ -50,10 +50,7 @@ public void execute( MavenSession session, MojoExecution
mojoExecution, ProjectI
public void execute( MavenSession session, List
mojoExecutions, ProjectIndex projectIndex )
throws LifecycleExecutionException
{
-for ( MojoExecution mojoExecution : mojoExecutions )
-{
-executions.add( mojoExecution );
-}
+execu
[jira] [Commented] (ARCHETYPE-528) Archetype:generate from repos besides central does not work
[
https://issues.apache.org/jira/browse/ARCHETYPE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663693#comment-16663693
]
Amélie Deltour commented on ARCHETYPE-528:
--
FYI, we finally managed to have the {{archetype}} repository work for fetching
the catalog.
We had to activate the profile containing the {{archetype}} repository in the
{{activeProfiles}} list of the {{settings.xml}}.
It does not work if we activate the profile with the {{-P}} option or with
{{true}} (which
still seems quite strange to me)
> Archetype:generate from repos besides central does not work
> ---
>
> Key: ARCHETYPE-528
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-528
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: João Cabrita
>Priority: Critical
> Attachments: settings.xml
>
>
> {noformat}
> mvn -X -P camunda -DarchetypeCatalog=remote
> org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate
> -Dfilter=org.camunda.bpm.archetype:
> {noformat}
> Results in the following:
> {noformat}
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate' with basic
> configurator -->
> [DEBUG] (f) archetypeCatalog = remote
> [DEBUG] (f) basedir = C:\Users\joao.cabrita\projects\bpm
> [DEBUG] (f) filter = org.camunda.bpm.archetype:
> [DEBUG] (f) interactiveMode = true
> [DEBUG] (f) localRepository = id: local
> url: file:///C:/Users/joao.cabrita/.m2/repository/
>layout: default
> snapshots: [enabled => true, update => always]
> releases: [enabled => true, update => always]
> [DEBUG] (f) remoteArtifactRepositories = [ id: central
> url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
> releases: [enabled => true, update => daily]
> , id: archetype
> url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
> releases: [enabled => true, update => daily]
> ]
> [DEBUG] (f) session = org.apache.maven.execution.MavenSession@325f7fa9
> [DEBUG] -- end configuration --
> [INFO] Generating project in Interactive mode
> [DEBUG] Searching for remote catalog:
> https://repo.maven.apache.org/maven2/archetype-catalog.xml
> [WARNING] No archetype found in remote catalog. Defaulting to internal catalog
> [INFO] Your filter doesn't match any archetype, so try again with another
> value.
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> I've attached my settings.xml file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6498) Order plugin execution changes depending on profile activation method
[
https://issues.apache.org/jira/browse/MNG-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6498.
---
Resolution: Not A Problem
Closing per request.
> Order plugin execution changes depending on profile activation method
> -
>
> Key: MNG-6498
> URL: https://issues.apache.org/jira/browse/MNG-6498
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.3.9, 3.5.2
>Reporter: Luca Botti
>Priority: Critical
>
> In a project with parent child relationship (and spring boot maven plugin) I
> can observe that the order of execution of same phase plugins (boot maven
> plugin and spotify docker plugin, both of which activate in the package
> phase) is not preserved if profile is activated with the file exists.
>
> As an example, the spring boot maven plugin left in the default build /
> pluginManagement section will not be activated if I add a profile like the
> following:
>
> {noformat}
>
>
> local-docker-image
>
> false
>
> ${basedir}/src/main/docker/Dockerfile
>
>
>
>
>
>com.spotify
> docker-maven-plugin
> ${docker.maven.plugin.version}
>
>
> build-image
> package
>
> build
> {noformat}
> The docker plugin will file trying to find the artifact jar (which gets
> renamed from the boot maven plugin, because the execution order is
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6498) Order plugin execution changes depending on profile activation method
[
https://issues.apache.org/jira/browse/MNG-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6498:
Fix Version/s: (was: waiting-for-feedback)
> Order plugin execution changes depending on profile activation method
> -
>
> Key: MNG-6498
> URL: https://issues.apache.org/jira/browse/MNG-6498
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.3.9, 3.5.2
>Reporter: Luca Botti
>Priority: Critical
>
> In a project with parent child relationship (and spring boot maven plugin) I
> can observe that the order of execution of same phase plugins (boot maven
> plugin and spotify docker plugin, both of which activate in the package
> phase) is not preserved if profile is activated with the file exists.
>
> As an example, the spring boot maven plugin left in the default build /
> pluginManagement section will not be activated if I add a profile like the
> following:
>
> {noformat}
>
>
> local-docker-image
>
> false
>
> ${basedir}/src/main/docker/Dockerfile
>
>
>
>
>
>com.spotify
> docker-maven-plugin
> ${docker.maven.plugin.version}
>
>
> build-image
> package
>
> build
> {noformat}
> The docker plugin will file trying to find the artifact jar (which gets
> renamed from the boot maven plugin, because the execution order is
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1585) Auto-resolve "missing" artifacts
[ https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663604#comment-16663604 ] ASF GitHub Bot commented on SUREFIRE-1585: -- sormuras edited a comment on issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact URL: https://github.com/apache/maven-surefire/pull/196#issuecomment-433008647 I guess, we may also move the remainder of `TestClassPath` into the `ProviderInfo` type... 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" 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 edited a comment on issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact
sormuras edited a comment on issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact URL: https://github.com/apache/maven-surefire/pull/196#issuecomment-433008647 I guess, we may also move the remainder of `TestClassPath` into the `ProviderInfo` type... 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" artifacts
[ https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663592#comment-16663592 ] ASF GitHub Bot commented on SUREFIRE-1585: -- sormuras commented on issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact URL: https://github.com/apache/maven-surefire/pull/196#issuecomment-433008647 I guess, we may also the remainder of `TestClassPath` into the `ProviderInfo` type... 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" 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 issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact
sormuras commented on issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact URL: https://github.com/apache/maven-surefire/pull/196#issuecomment-433008647 I guess, we may also the remainder of `TestClassPath` into the `ProviderInfo` type... 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" artifacts
[ https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663591#comment-16663591 ] ASF GitHub Bot commented on SUREFIRE-1585: -- sormuras commented on issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact URL: https://github.com/apache/maven-surefire/pull/196#issuecomment-433008367 Too late. Already force-pushed to this branch and PR. It's much cleaner now, 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" 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 issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact
sormuras commented on issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact URL: https://github.com/apache/maven-surefire/pull/196#issuecomment-433008367 Too late. Already force-pushed to this branch and PR. It's much cleaner now, 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] Tibor17 commented on issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact
Tibor17 commented on issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact URL: https://github.com/apache/maven-surefire/pull/196#issuecomment-433007064 @sormuras If you are going to move the logic to `ProviderInfo`, please make another branch and PR. We can compare both and use one at last. 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" artifacts
[ https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663583#comment-16663583 ] ASF GitHub Bot commented on SUREFIRE-1585: -- Tibor17 commented on issue #196: [SUREFIRE-1585] [WIP] Resolve missing artifact URL: https://github.com/apache/maven-surefire/pull/196#issuecomment-433007064 @sormuras If you are going to move the logic to `ProviderInfo`, please make another branch and PR. We can compare both and use one at last. 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" 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 artifact
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing artifact
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r228126417
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -490,11 +491,11 @@
/**
* Allows you to specify the name of the JUnit Platform artifact.
- * If not set, {@code org.junit.platform:junit-platform-engine} will be
used.
+ * If not set, {@code org.junit.platform:junit-platform-commons} will be
used.
Review comment:
Projects that only refer to `junit-jupiter-api` no longer have
`junit-platform-engine` in their dependencies. So now, we are using
`junit-platform-commons` as the trigger value to activate the JUnit Platform
Provider.
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" artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663580#comment-16663580
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing artifact
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r228126417
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -490,11 +491,11 @@
/**
* Allows you to specify the name of the JUnit Platform artifact.
- * If not set, {@code org.junit.platform:junit-platform-engine} will be
used.
+ * If not set, {@code org.junit.platform:junit-platform-commons} will be
used.
Review comment:
Projects that only refer to `junit-jupiter-api` no longer have
`junit-platform-engine` in their dependencies. So now, we are using
`junit-platform-commons` as the trigger value to activate the JUnit Platform
Provider.
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" 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] [Updated] (SUREFIRE-1587) Forked execution prevents correct ServerSocket closing
[
https://issues.apache.org/jira/browse/SUREFIRE-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Wienke updated SUREFIRE-1587:
--
Summary: Forked execution prevents correct ServerSocket closing (was:
Forked execution prevents correct ServerSocket closin)
> Forked execution prevents correct ServerSocket closing
> --
>
> Key: SUREFIRE-1587
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1587
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1
> Environment: Linux, problem becomes visible on archlinux and also on
> Travis CI
>Reporter: Johannes Wienke
>Priority: Major
>
> The default mode of forked unit test execution (with JUnit) seems to
> interfere with socket operations. In our case, we see that with a surefire
> execution in forked mode, ServerSocket instances, despite returning from a
> close() call, are sometimes not correctly closed and a subsequent try to
> acquire a server socket on the same port then fails. This does not happen
> outside of surefire or when forkMode is set to none.
> Here is a simple test case to try this. First the maven project pom.xml:
> {code:title=pom.xml|borderStyle=solid}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> testing
> testit
> 1.0-SNAPSHOT
> testit
> A simple testit.
> http://www.example.com
>
> UTF-8
> 1.7
> 1.7
>
>
>
> junit
> junit
> 4.11
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.22.1
>
>
>
>
> {code}
> And here a test file to be placed into the test source tree:
> {code:title=AppTest.java|borderStyle=solid}
> package testing;
> import org.junit.Test;
> import java.net.ServerSocket;
> public class AppTest {
> @Test
> public void testSocketStuff() throws Exception {
> while (true) {
> System.out.println("Iteration");
> final ServerSocket socket = new ServerSocket(55444);
> socket.close();
> }
> }
> }
> {code}
> Executing this with the default options (forking mode enabled) will pretty
> soon end up in the following exception after some iterations:
> {code}
> [ERROR] testSocketStuff(testing.AppTest) Time elapsed: 1.376 s <<< ERROR!
> java.net.BindException: Address already in use (Bind failed)
> at testing.AppTest.testSocketStuff(AppTest.java:17)
> {code}
> Executing the same test with -DforkMode=none does not result in this failure
> and the loop runs endlessly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6498) Order plugin execution changes depending on profile activation method
[
https://issues.apache.org/jira/browse/MNG-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663445#comment-16663445
]
Luca Botti commented on MNG-6498:
-
Closing, since I understand the behaviour is different - all plugins are
subsituted in a profile based activation.
> Order plugin execution changes depending on profile activation method
> -
>
> Key: MNG-6498
> URL: https://issues.apache.org/jira/browse/MNG-6498
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.3.9, 3.5.2
>Reporter: Luca Botti
>Priority: Critical
> Fix For: waiting-for-feedback
>
>
> In a project with parent child relationship (and spring boot maven plugin) I
> can observe that the order of execution of same phase plugins (boot maven
> plugin and spotify docker plugin, both of which activate in the package
> phase) is not preserved if profile is activated with the file exists.
>
> As an example, the spring boot maven plugin left in the default build /
> pluginManagement section will not be activated if I add a profile like the
> following:
>
> {noformat}
>
>
> local-docker-image
>
> false
>
> ${basedir}/src/main/docker/Dockerfile
>
>
>
>
>
>com.spotify
> docker-maven-plugin
> ${docker.maven.plugin.version}
>
>
> build-image
> package
>
> build
> {noformat}
> The docker plugin will file trying to find the artifact jar (which gets
> renamed from the boot maven plugin, because the execution order is
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6498) Order plugin execution changes depending on profile activation method
[
https://issues.apache.org/jira/browse/MNG-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6498:
Fix Version/s: waiting-for-feedback
> Order plugin execution changes depending on profile activation method
> -
>
> Key: MNG-6498
> URL: https://issues.apache.org/jira/browse/MNG-6498
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.3.9, 3.5.2
>Reporter: Luca Botti
>Priority: Critical
> Fix For: waiting-for-feedback
>
>
> In a project with parent child relationship (and spring boot maven plugin) I
> can observe that the order of execution of same phase plugins (boot maven
> plugin and spotify docker plugin, both of which activate in the package
> phase) is not preserved if profile is activated with the file exists.
>
> As an example, the spring boot maven plugin left in the default build /
> pluginManagement section will not be activated if I add a profile like the
> following:
>
> {noformat}
>
>
> local-docker-image
>
> false
>
> ${basedir}/src/main/docker/Dockerfile
>
>
>
>
>
>com.spotify
> docker-maven-plugin
> ${docker.maven.plugin.version}
>
>
> build-image
> package
>
> build
> {noformat}
> The docker plugin will file trying to find the artifact jar (which gets
> renamed from the boot maven plugin, because the execution order is
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6498) Order plugin execution changes depending on profile activation method
[
https://issues.apache.org/jira/browse/MNG-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663419#comment-16663419
]
Michael Osipov commented on MNG-6498:
-
As always: minimal sample project, please!
> Order plugin execution changes depending on profile activation method
> -
>
> Key: MNG-6498
> URL: https://issues.apache.org/jira/browse/MNG-6498
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.3.9, 3.5.2
>Reporter: Luca Botti
>Priority: Critical
>
> In a project with parent child relationship (and spring boot maven plugin) I
> can observe that the order of execution of same phase plugins (boot maven
> plugin and spotify docker plugin, both of which activate in the package
> phase) is not preserved if profile is activated with the file exists.
>
> As an example, the spring boot maven plugin left in the default build /
> pluginManagement section will not be activated if I add a profile like the
> following:
>
> {noformat}
>
>
> local-docker-image
>
> false
>
> ${basedir}/src/main/docker/Dockerfile
>
>
>
>
>
>com.spotify
> docker-maven-plugin
> ${docker.maven.plugin.version}
>
>
> build-image
> package
>
> build
> {noformat}
> The docker plugin will file trying to find the artifact jar (which gets
> renamed from the boot maven plugin, because the execution order is
>
>
--
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 artifact
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing artifact
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r228054718
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java
##
@@ -87,15 +88,40 @@ private void addMissingArtifacts( Set
providerArtifacts )
// TODO Check for actual SurefireProvider -- the following only
applies for when
//
'org.apache.maven.surefire.junitplatform.JUnitPlatformProvider' is active.
-// TODO Add missing 'junit-jupiter-engine' to test runtime
-// Artifact junitJupiterApi = findArtifact(
"org.junit.jupiter:junit-jupiter-api", artifacts );
-// Artifact junitJupiterEngine =
-// findArtifact( "org.junit.jupiter:junit-jupiter-engine",
artifacts, providerArtifacts );
-// if ( junitJupiterApi != null && junitJupiterEngine == null )
-// {
-// [artifacts | providerArtifacts]
-// .add( "org.junit.jupiter:junit-jupiter-engine:" +
junitJupiterApi.getVersion() );
-// }
+if ( mojo == null )
+{
+// mojo.getLog().warn( "Can't resolve missing artifacts when mojo
is not set." );
+return;
+}
+
+// Add missing 'junit-jupiter-engine' to test runtime
+Map artifactMap = mojo.getProjectArtifactMap();
+Artifact junitJupiterApi = artifactMap.get(
"org.junit.jupiter:junit-jupiter-api" );
+Artifact junitJupiterEngine = artifactMap.get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterApi != null && junitJupiterEngine == null )
+{
+junitJupiterEngine = new DefaultArtifact(
+"org.junit.jupiter",
+"junit-jupiter-engine",
+junitJupiterApi.getVersionRange(),
+"test",
+"jar",
+"",
+junitJupiterApi.getArtifactHandler()
+);
+@SuppressWarnings( "unchecked" )
+Set resolvedArtifacts = mojo.resolveArtifact( null,
junitJupiterEngine ).getArtifacts();
+providerArtifacts.addAll( resolvedArtifacts );
Review comment:
Not sure about this one... as the version numbers we do inject are those we
extract from the project test class-path artifacts. Thus, the version will be
aligned by default.
Regarding transitive dependencies... well, yes. No. We shouldn't try to fix
those potential version mismatches here. Too much hidden magic inside a magic
feature. Instead let the users configure the right dependencies in their pom in
the first place.
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" artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663353#comment-16663353
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing artifact
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r228054718
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java
##
@@ -87,15 +88,40 @@ private void addMissingArtifacts( Set
providerArtifacts )
// TODO Check for actual SurefireProvider -- the following only
applies for when
//
'org.apache.maven.surefire.junitplatform.JUnitPlatformProvider' is active.
-// TODO Add missing 'junit-jupiter-engine' to test runtime
-// Artifact junitJupiterApi = findArtifact(
"org.junit.jupiter:junit-jupiter-api", artifacts );
-// Artifact junitJupiterEngine =
-// findArtifact( "org.junit.jupiter:junit-jupiter-engine",
artifacts, providerArtifacts );
-// if ( junitJupiterApi != null && junitJupiterEngine == null )
-// {
-// [artifacts | providerArtifacts]
-// .add( "org.junit.jupiter:junit-jupiter-engine:" +
junitJupiterApi.getVersion() );
-// }
+if ( mojo == null )
+{
+// mojo.getLog().warn( "Can't resolve missing artifacts when mojo
is not set." );
+return;
+}
+
+// Add missing 'junit-jupiter-engine' to test runtime
+Map artifactMap = mojo.getProjectArtifactMap();
+Artifact junitJupiterApi = artifactMap.get(
"org.junit.jupiter:junit-jupiter-api" );
+Artifact junitJupiterEngine = artifactMap.get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterApi != null && junitJupiterEngine == null )
+{
+junitJupiterEngine = new DefaultArtifact(
+"org.junit.jupiter",
+"junit-jupiter-engine",
+junitJupiterApi.getVersionRange(),
+"test",
+"jar",
+"",
+junitJupiterApi.getArtifactHandler()
+);
+@SuppressWarnings( "unchecked" )
+Set resolvedArtifacts = mojo.resolveArtifact( null,
junitJupiterEngine ).getArtifacts();
+providerArtifacts.addAll( resolvedArtifacts );
Review comment:
Not sure about this one... as the version numbers we do inject are those we
extract from the project test class-path artifacts. Thus, the version will be
aligned by default.
Regarding transitive dependencies... well, yes. No. We shouldn't try to fix
those potential version mismatches here. Too much hidden magic inside a magic
feature. Instead let the users configure the right dependencies in their pom in
the first place.
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" 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 artifact
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing artifact
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r228054718
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java
##
@@ -87,15 +88,40 @@ private void addMissingArtifacts( Set
providerArtifacts )
// TODO Check for actual SurefireProvider -- the following only
applies for when
//
'org.apache.maven.surefire.junitplatform.JUnitPlatformProvider' is active.
-// TODO Add missing 'junit-jupiter-engine' to test runtime
-// Artifact junitJupiterApi = findArtifact(
"org.junit.jupiter:junit-jupiter-api", artifacts );
-// Artifact junitJupiterEngine =
-// findArtifact( "org.junit.jupiter:junit-jupiter-engine",
artifacts, providerArtifacts );
-// if ( junitJupiterApi != null && junitJupiterEngine == null )
-// {
-// [artifacts | providerArtifacts]
-// .add( "org.junit.jupiter:junit-jupiter-engine:" +
junitJupiterApi.getVersion() );
-// }
+if ( mojo == null )
+{
+// mojo.getLog().warn( "Can't resolve missing artifacts when mojo
is not set." );
+return;
+}
+
+// Add missing 'junit-jupiter-engine' to test runtime
+Map artifactMap = mojo.getProjectArtifactMap();
+Artifact junitJupiterApi = artifactMap.get(
"org.junit.jupiter:junit-jupiter-api" );
+Artifact junitJupiterEngine = artifactMap.get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterApi != null && junitJupiterEngine == null )
+{
+junitJupiterEngine = new DefaultArtifact(
+"org.junit.jupiter",
+"junit-jupiter-engine",
+junitJupiterApi.getVersionRange(),
+"test",
+"jar",
+"",
+junitJupiterApi.getArtifactHandler()
+);
+@SuppressWarnings( "unchecked" )
+Set resolvedArtifacts = mojo.resolveArtifact( null,
junitJupiterEngine ).getArtifacts();
+providerArtifacts.addAll( resolvedArtifacts );
Review comment:
Not sure about this one... as the versions we to inject are those we extract
from the project test class-path. Thus, the version will be aligned by default.
Regarding transitive dependencies... well, yes. No. We shouldn't try to fix
those potential version mismatches here. Too much hidden magic inside a magic
feature. Instead let the users configure the right dependencies in their pom in
the first place.
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" artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663351#comment-16663351
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing artifact
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r228054718
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java
##
@@ -87,15 +88,40 @@ private void addMissingArtifacts( Set
providerArtifacts )
// TODO Check for actual SurefireProvider -- the following only
applies for when
//
'org.apache.maven.surefire.junitplatform.JUnitPlatformProvider' is active.
-// TODO Add missing 'junit-jupiter-engine' to test runtime
-// Artifact junitJupiterApi = findArtifact(
"org.junit.jupiter:junit-jupiter-api", artifacts );
-// Artifact junitJupiterEngine =
-// findArtifact( "org.junit.jupiter:junit-jupiter-engine",
artifacts, providerArtifacts );
-// if ( junitJupiterApi != null && junitJupiterEngine == null )
-// {
-// [artifacts | providerArtifacts]
-// .add( "org.junit.jupiter:junit-jupiter-engine:" +
junitJupiterApi.getVersion() );
-// }
+if ( mojo == null )
+{
+// mojo.getLog().warn( "Can't resolve missing artifacts when mojo
is not set." );
+return;
+}
+
+// Add missing 'junit-jupiter-engine' to test runtime
+Map artifactMap = mojo.getProjectArtifactMap();
+Artifact junitJupiterApi = artifactMap.get(
"org.junit.jupiter:junit-jupiter-api" );
+Artifact junitJupiterEngine = artifactMap.get(
"org.junit.jupiter:junit-jupiter-engine" );
+if ( junitJupiterApi != null && junitJupiterEngine == null )
+{
+junitJupiterEngine = new DefaultArtifact(
+"org.junit.jupiter",
+"junit-jupiter-engine",
+junitJupiterApi.getVersionRange(),
+"test",
+"jar",
+"",
+junitJupiterApi.getArtifactHandler()
+);
+@SuppressWarnings( "unchecked" )
+Set resolvedArtifacts = mojo.resolveArtifact( null,
junitJupiterEngine ).getArtifacts();
+providerArtifacts.addAll( resolvedArtifacts );
Review comment:
Not sure about this one... as the versions we to inject are those we extract
from the project test class-path. Thus, the version will be aligned by default.
Regarding transitive dependencies... well, yes. No. We shouldn't try to fix
those potential version mismatches here. Too much hidden magic inside a magic
feature. Instead let the users configure the right dependencies in their pom in
the first place.
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" 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" artifacts
[
https://issues.apache.org/jira/browse/SUREFIRE-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663344#comment-16663344
]
ASF GitHub Bot commented on SUREFIRE-1585:
--
sormuras commented on a change in pull request #196: [SUREFIRE-1585] [WIP]
Resolve missing artifact
URL: https://github.com/apache/maven-surefire/pull/196#discussion_r228053571
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java
##
@@ -69,9 +70,9 @@ void avoidArtifactDuplicates( Set
providerArtifacts )
&& ( classifier1 == null ? classifier2 == null :
classifier1.equals( classifier2 ) ) )
{
it.remove();
-if ( logger.isDebugEnabled() )
+if ( mojo != null && mojo.getLog().isDebugEnabled() )
Review comment:
Ad 1 and 2: I'm trying to move the logic into the
`ProviderInfo::getProviderClasspath`. The "null-checks" are needed though.
Ad 3: See the second method named `adoptArtifactVersions`. It will care
about aligning versions.
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" 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)
