[GitHub] Tibor17 commented on a change in pull request #199: Surefire 1593
Tibor17 commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r233728638
##
File path:
maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfigurationTest.java
##
@@ -0,0 +1,216 @@
+package org.apache.maven.plugin.surefire.booterclient;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.io.IOException;
+import java.net.URI;
+import java.net.URISyntaxException;
+import java.nio.file.Path;
+
+import
org.apache.maven.plugin.surefire.booterclient.output.InPluginProcessDumpSingleton;
+
+import static
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.relativize;
+import static
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toAbsoluteUri;
+import static
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toClasspathElementUri;
+import static org.fest.assertions.Assertions.assertThat;
+
+import org.junit.BeforeClass;
+import org.junit.ClassRule;
+import org.junit.Test;
+import org.junit.rules.TemporaryFolder;
+import org.junit.runner.RunWith;
+import static org.mockito.ArgumentMatchers.same;
+import static org.powermock.api.mockito.PowerMockito.mock;
+import static org.powermock.api.mockito.PowerMockito.mockStatic;
+import static org.powermock.api.mockito.PowerMockito.when;
+
+import org.mockito.invocation.InvocationOnMock;
+import org.mockito.stubbing.Answer;
+import org.powermock.core.classloader.annotations.PrepareForTest;
+import org.powermock.modules.junit4.PowerMockRunner;
+
+/**
+ * Unit tests for {@link JarManifestForkConfiguration}.
+ */
+@RunWith( PowerMockRunner.class )
+@PrepareForTest( { JarManifestForkConfiguration.class,
InPluginProcessDumpSingleton.class } )
+public class JarManifestForkConfigurationTest
+{
+@ClassRule
+public static final TemporaryFolder TMP = new TemporaryFolder();
+
+private static File dumpDirectory;
+
+@BeforeClass
+public static void createSystemTemporaryDir()
+throws IOException
+{
+TMP.create();
Review comment:
The problem is that `create` was not called. Now I found the root cause.
Powermock does not implement Rules ,
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] [Created] (MPIR-377) Profiles in POMs do not appear to be evaluated
Jason Faust created MPIR-377:
Summary: Profiles in POMs do not appear to be evaluated
Key: MPIR-377
URL: https://issues.apache.org/jira/browse/MPIR-377
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 3.0.0
Environment: Maven 3.5.4, Win 32_64, Java 10
Reporter: Jason Faust
Attachments: log.txt, pom.xml
First of, I do not know if this is a bug, or if it's a result of OpenJFX being
silly with how they setup their parent pom (
[http://repo.maven.apache.org/maven2/org/openjfx/javafx/11.0.1/javafx-11.0.1.pom]
and
[http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1/javafx-base-11.0.1.pom]
), and the bug should be filed there, but:
The dependencies report reports warnings of the OpenJFX poms (for example)
referring to themselves, as they depend on {{${javafx.profile}}} having a
value, which is derived from the parent POM. Net result is it appears that the
dependencies report is unable to see the full tree, whereas Maven normally is
able to include all of the jars required for a build.
Error triggered by running 'site' against the attached [^pom.xml].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-446) SSH agent authentication is no longer working in wagon-ssh 2.10
[
https://issues.apache.org/jira/browse/WAGON-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687227#comment-16687227
]
Michael Osipov commented on WAGON-446:
--
I really would like to pick this up. I think we can apply the following
reasoning:
* If {{ssh-external}} is used, provide creds (password or private key) if
explicitly set in {{settings.xml}} otherwise {{ssh(1)}} will do its magic
* If {{ssh}} (JSch) is used, check if reads {{~/.ssh/id_*}} by default, if so,
we can apply the same logic as for {{ssh}} if not, don't look for the private
key by yourself, use {{settings.xml}} OR configure with {{OpenSSHConfig}},
i.e., behave as JSch woudl behave by default, no magic traversal suprises.
WDYT?
> SSH agent authentication is no longer working in wagon-ssh 2.10
> ---
>
> Key: WAGON-446
> URL: https://issues.apache.org/jira/browse/WAGON-446
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.10
>Reporter: Per Landberg
>Assignee: Dan Tran
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: wagon-446.patch
>
>
> After upgrading to wagon-2.10, SSH Agent authentication doesn't seems to
> work anymore. I got the following error when trying to publish a site, using
> maven-site-plugin 3.4:
> Using private key:
> : Error uploading site: Cannot connect. Reason: Auth fail -> [Help 1]
> I have no server for this site defined in my settings.xml
> After some investigation, I suspect that the cause is WAGON-413 since the
> logic in AbstractJschWagon was changed to not use the agent if
> ScpHelper.getPrivateKey() returns a File.
> Unfortunate, ScpHelper.getPrivateKey() seems to have a fallback behavior that
> always returns the id_rsa key (if one exists) even when no matching server
> element exists in settings.xml and the effect is that the agent is never
> consulted.
> The authentication will then fail since no server element provides a key
> password.
> My current workaround is to set the wagon.privateKeyDirectory System Property
> to an empty directory. This will prevent the ScpHelper.getPrivateKey()
> fallback to kick in.
> Has anybody else got SSH agent working in combination with existing id_rsa
> files?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-538) Basic authentication fails if the password contains non-ASCII characters
[
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687178#comment-16687178
]
Michael Osipov commented on WAGON-538:
--
[~aleksgj], please see whether branch WAGON-540 works for you.
> Basic authentication fails if the password contains non-ASCII characters
>
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
>Reporter: Aleksander Gjermundsen
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.1
>
>
> If the username and/or password used to authenticate to Nexus contains
> non-ascii characters, the authentication fails with an access denied error.
> After using Wireshark to investigate the headers being sent (in my case "Ø",
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
>
>
> artifactory
> userØ
> userØ
>
>
> ...
>
>
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
>
>
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven
> reads the username and passwords correctly into strings, but Apache
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it
> is not completely clear from the standards how these characters are supposed
> to be handled, but on my system both wget and the Chrome web browser encode
> the characters the same way as after my patch and are able to download files
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in
> contrast to Maven it was not able to decode the username and password
> correctly, however it would be broken without the patch anyway.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (WAGON-540) Switch to modern-day encoding (UTF-8) of auth credentials
Michael Osipov created WAGON-540: Summary: Switch to modern-day encoding (UTF-8) of auth credentials Key: WAGON-540 URL: https://issues.apache.org/jira/browse/WAGON-540 Project: Maven Wagon Issue Type: Improvement Components: wagon-http Affects Versions: 3.2.0 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.2.1 These days people use non-ASCII encodings for usernames and password. While other auth schemes like NTLM or Kerberos use Unicode by default, Basic and Digest were restricted to ASCII or ISO-8859-1 for a long time. Major browsers (Chrome + FF) now have switched to UTF-8. We should do that too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-538) Basic authentication fails if the password contains non-ASCII characters
[
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated WAGON-538:
-
Fix Version/s: 3.2.1
> Basic authentication fails if the password contains non-ASCII characters
>
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
>Reporter: Aleksander Gjermundsen
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.1
>
>
> If the username and/or password used to authenticate to Nexus contains
> non-ascii characters, the authentication fails with an access denied error.
> After using Wireshark to investigate the headers being sent (in my case "Ø",
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
>
>
> artifactory
> userØ
> userØ
>
>
> ...
>
>
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
>
>
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven
> reads the username and passwords correctly into strings, but Apache
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it
> is not completely clear from the standards how these characters are supposed
> to be handled, but on my system both wget and the Chrome web browser encode
> the characters the same way as after my patch and are able to download files
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in
> contrast to Maven it was not able to decode the username and password
> correctly, however it would be broken without the patch anyway.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (WAGON-538) Basic authentication fails if the password contains non-ASCII characters
[
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated WAGON-538:
-
Summary: Basic authentication fails if the password contains non-ASCII
characters (was: Basic authentication fails if the password contains non-ascii
characters)
> Basic authentication fails if the password contains non-ASCII characters
>
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
>Reporter: Aleksander Gjermundsen
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.1
>
>
> If the username and/or password used to authenticate to Nexus contains
> non-ascii characters, the authentication fails with an access denied error.
> After using Wireshark to investigate the headers being sent (in my case "Ø",
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
>
>
> artifactory
> userØ
> userØ
>
>
> ...
>
>
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
>
>
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven
> reads the username and passwords correctly into strings, but Apache
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it
> is not completely clear from the standards how these characters are supposed
> to be handled, but on my system both wget and the Chrome web browser encode
> the characters the same way as after my patch and are able to download files
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in
> contrast to Maven it was not able to decode the username and password
> correctly, however it would be broken without the patch anyway.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (WAGON-539) Explicitly register only supported auth schemes
Michael Osipov created WAGON-539:
Summary: Explicitly register only supported auth schemes
Key: WAGON-539
URL: https://issues.apache.org/jira/browse/WAGON-539
Project: Maven Wagon
Issue Type: Improvement
Components: wagon-http
Affects Versions: 3.2.0
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 3.2.1
We shall only register auth schemes Basic, Digest, NTLM which {{settings.xml}}
supports. Other aren't really supported. More over, the SPNEGO support in
HttpClient is broken and shall not be used: HTTPCLIENT-1625 and HTTPCLIENT-1938.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOLVER-63) FileTransformer#transformData(File) should also throw TransformException
[ https://issues.apache.org/jira/browse/MRESOLVER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687129#comment-16687129 ] ASF GitHub Bot commented on MRESOLVER-63: - mcimbora commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233620013 ## File path: maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformationException.java ## @@ -0,0 +1,79 @@ +package org.eclipse.aether.transform; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import java.io.File; + +import org.eclipse.aether.RepositoryException; + +/** + * Thrown when file transformation failed. + */ +public class FileTransformationException +extends RepositoryException Review comment: Good point, thanks for the explaination and prompt review. The exception now inherits directly from Exception. 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 > FileTransformer#transformData(File) should also throw TransformException > > > Key: MRESOLVER-63 > URL: https://issues.apache.org/jira/browse/MRESOLVER-63 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: 1.3.1 >Reporter: Robert Scholte >Priority: Major > Labels: up-for-grabs > Fix For: 1.3.2 > > > 1.3.1 introduced the FileTransformer to allow on-the-fly transforming of data. > For XML files it makes sense to use XMLFilters and create an XMLReader. This > can throw a SAXException, which is a checked exception, which shouldn't be > rethrown as an IOException. > Better to introduce a new Exception to handle this case properly. > Assuming this class isn't used anywhere yet, it should be good to introduce > it asap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] mcimbora commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException
mcimbora commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233620013 ## File path: maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformationException.java ## @@ -0,0 +1,79 @@ +package org.eclipse.aether.transform; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import java.io.File; + +import org.eclipse.aether.RepositoryException; + +/** + * Thrown when file transformation failed. + */ +public class FileTransformationException +extends RepositoryException Review comment: Good point, thanks for the explaination and prompt review. The exception now inherits directly from Exception. 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] [Assigned] (WAGON-538) Basic authentication fails if the password contains non-ascii characters
[
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned WAGON-538:
Assignee: Michael Osipov
> Basic authentication fails if the password contains non-ascii characters
>
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
>Reporter: Aleksander Gjermundsen
>Assignee: Michael Osipov
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains
> non-ascii characters, the authentication fails with an access denied error.
> After using Wireshark to investigate the headers being sent (in my case "Ø",
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
>
>
> artifactory
> userØ
> userØ
>
>
> ...
>
>
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
>
>
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven
> reads the username and passwords correctly into strings, but Apache
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it
> is not completely clear from the standards how these characters are supposed
> to be handled, but on my system both wget and the Chrome web browser encode
> the characters the same way as after my patch and are able to download files
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in
> contrast to Maven it was not able to decode the username and password
> correctly, however it would be broken without the patch anyway.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOLVER-63) FileTransformer#transformData(File) should also throw TransformException
[ https://issues.apache.org/jira/browse/MRESOLVER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687127#comment-16687127 ] ASF GitHub Bot commented on MRESOLVER-63: - mcimbora commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233619531 ## File path: maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformer.java ## @@ -47,5 +46,5 @@ * @param file the file with the original data * @return the transformed data */ -InputStream transformData( File file ) throws IOException; +InputStream transformData( File file ) throws FileTransformationException; Review comment: Included TransformException in the throws clause. 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 > FileTransformer#transformData(File) should also throw TransformException > > > Key: MRESOLVER-63 > URL: https://issues.apache.org/jira/browse/MRESOLVER-63 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: 1.3.1 >Reporter: Robert Scholte >Priority: Major > Labels: up-for-grabs > Fix For: 1.3.2 > > > 1.3.1 introduced the FileTransformer to allow on-the-fly transforming of data. > For XML files it makes sense to use XMLFilters and create an XMLReader. This > can throw a SAXException, which is a checked exception, which shouldn't be > rethrown as an IOException. > Better to introduce a new Exception to handle this case properly. > Assuming this class isn't used anywhere yet, it should be good to introduce > it asap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] mcimbora commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException
mcimbora commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233619531 ## File path: maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformer.java ## @@ -47,5 +46,5 @@ * @param file the file with the original data * @return the transformed data */ -InputStream transformData( File file ) throws IOException; +InputStream transformData( File file ) throws FileTransformationException; Review comment: Included TransformException in the throws clause. 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] (MRESOLVER-63) FileTransformer#transformData(File) should also throw TransformException
[
https://issues.apache.org/jira/browse/MRESOLVER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687126#comment-16687126
]
ASF GitHub Bot commented on MRESOLVER-63:
-
mcimbora commented on a change in pull request #23: [MRESOLVER-63]
FileTransformer#transformData(File) should also throw TransformException
URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233619327
##
File path:
maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformationException.java
##
@@ -0,0 +1,79 @@
+package org.eclipse.aether.transform;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+
+import org.eclipse.aether.RepositoryException;
+
+/**
+ * Thrown when file transformation failed.
+ */
+public class FileTransformationException
+extends RepositoryException
+{
+
+private final transient File file;
+
+/**
+ * Creates a new exception with the specified file.
+ *
+ * @param file The file which transformation failed, may be {@code null}.
+ */
+public FileTransformationException( File file )
Review comment:
Removed.
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
> FileTransformer#transformData(File) should also throw TransformException
>
>
> Key: MRESOLVER-63
> URL: https://issues.apache.org/jira/browse/MRESOLVER-63
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.3.1
>Reporter: Robert Scholte
>Priority: Major
> Labels: up-for-grabs
> Fix For: 1.3.2
>
>
> 1.3.1 introduced the FileTransformer to allow on-the-fly transforming of data.
> For XML files it makes sense to use XMLFilters and create an XMLReader. This
> can throw a SAXException, which is a checked exception, which shouldn't be
> rethrown as an IOException.
> Better to introduce a new Exception to handle this case properly.
> Assuming this class isn't used anywhere yet, it should be good to introduce
> it asap.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] mcimbora commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException
mcimbora commented on a change in pull request #23: [MRESOLVER-63]
FileTransformer#transformData(File) should also throw TransformException
URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233619327
##
File path:
maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformationException.java
##
@@ -0,0 +1,79 @@
+package org.eclipse.aether.transform;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+
+import org.eclipse.aether.RepositoryException;
+
+/**
+ * Thrown when file transformation failed.
+ */
+public class FileTransformationException
+extends RepositoryException
+{
+
+private final transient File file;
+
+/**
+ * Creates a new exception with the specified file.
+ *
+ * @param file The file which transformation failed, may be {@code null}.
+ */
+public FileTransformationException( File file )
Review comment:
Removed.
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-538) Basic authentication fails if the password contains non-ascii characters
[
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687115#comment-16687115
]
Michael Osipov commented on WAGON-538:
--
I think will go the route you have proposed. We basically support only three
auth schemes via {{settings.xml}}: Basic, Digest, NTLM, everything else is: use
at your own risk. We should split it in two tickets: (1) implicit
{{AuthSchemeRegistry}}, (2) switch to UTF-8 for both Basic and Digest.
> Basic authentication fails if the password contains non-ascii characters
>
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains
> non-ascii characters, the authentication fails with an access denied error.
> After using Wireshark to investigate the headers being sent (in my case "Ø",
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
>
>
> artifactory
> userØ
> userØ
>
>
> ...
>
>
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
>
>
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven
> reads the username and passwords correctly into strings, but Apache
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it
> is not completely clear from the standards how these characters are supposed
> to be handled, but on my system both wget and the Chrome web browser encode
> the characters the same way as after my patch and are able to download files
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in
> contrast to Maven it was not able to decode the username and password
> correctly, however it would be broken without the patch anyway.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (WAGON-538) Basic authentication fails if the password contains non-ascii characters
[
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated WAGON-538:
-
Affects Version/s: 3.2.0
> Basic authentication fails if the password contains non-ascii characters
>
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains
> non-ascii characters, the authentication fails with an access denied error.
> After using Wireshark to investigate the headers being sent (in my case "Ø",
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
>
>
> artifactory
> userØ
> userØ
>
>
> ...
>
>
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
>
>
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven
> reads the username and passwords correctly into strings, but Apache
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it
> is not completely clear from the standards how these characters are supposed
> to be handled, but on my system both wget and the Chrome web browser encode
> the characters the same way as after my patch and are able to download files
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in
> contrast to Maven it was not able to decode the username and password
> correctly, however it would be broken without the patch anyway.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSITE-830) Dependency upgrades related to identified security reports
[ https://issues.apache.org/jira/browse/MSITE-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687112#comment-16687112 ] Olaf Flebbe commented on MSITE-830: --- I looked at some of the dependencies. struts for instance is injected via doxia-site-rendering <-> velocity-tools There was a new release of velocity tools which seems to adress some of the issues we see. But IMHO here is the wrong place to discuss: doxia-site-rendering should be improved, than maven-site can pick this up. > Dependency upgrades related to identified security reports > -- > > Key: MSITE-830 > URL: https://issues.apache.org/jira/browse/MSITE-830 > Project: Maven Site Plugin > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Major > > Fix problems reported by [Snyk.io|https://snyk.io/] > > |H|[Arbitrary File Write via Archive Extraction (Zip > Slip)|https://app.snyk.io/vuln/SNYK-JAVA-ORGCODEHAUSPLEXUS-31680] in > org.codehaus.plexus:plexus-archiver| > |H| [Arbitrary Code > Execution|https://app.snyk.io/vuln/SNYK-JAVA-COMMONSBEANUTILS-30077] in > commons-beanutils:commons-beanutils| > |H| [Arbitrary Code > Execution|https://app.snyk.io/vuln/SNYK-JAVA-COMMONSCOLLECTIONS-30078] in > commons-collections:commons-collections| > |H| [XML External Entity (XXE) > Injection|https://app.snyk.io/vuln/SNYK-JAVA-DOM4J-72444] in dom4j:dom4j| > |H| [Denial of Service > (DoS)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEPDFBOX-32417] in > org.apache.pdfbox:fontbox| > |H| [Arbitrary Code > Injection|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHESTRUTS-30763] in > org.apache.struts:struts-core| > |H| [Arbitrary Command > Execution|https://app.snyk.io/vuln/SNYK-JAVA-ORGMORTBAYJETTY-32091] in > org.mortbay.jetty:jetty| > |M|[Denial of Service > (DoS)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHECOMMONS-32122] in > org.apache.commons:commons-compress| > |M|[Directory > Traversal|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHECOMMONS-72275] in > org.apache.commons:commons-compress| > |M| [Man-in-the-Middle > (MitM)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-30646] in > org.apache.httpcomponents:httpclient| > |M| [Directory > Traversal|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-31517] > in org.apache.httpcomponents:httpclient| > |M| [Improper Input > Validation|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-30645] > in org.apache.httpcomponents:httpclient| > |M| [Information > Exposure|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-30644] in > org.apache.httpcomponents:httpclient| > |M| [Denial of Service > (DoS)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-30647] in > org.apache.httpcomponents:httpclient| > |M| [Denial of Service > (DoS)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEPDFBOX-72426] in > org.apache.pdfbox:pdfbox| > |L|[Denial of Service > (DoS)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHECOMMONS-32473] in > org.apache.commons:commons-compress| -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-538) Basic authentication fails if the password contains non-ascii characters
[
https://issues.apache.org/jira/browse/WAGON-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated WAGON-538:
-
Component/s: wagon-http
> Basic authentication fails if the password contains non-ascii characters
>
>
> Key: WAGON-538
> URL: https://issues.apache.org/jira/browse/WAGON-538
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
>Reporter: Aleksander Gjermundsen
>Priority: Major
>
> If the username and/or password used to authenticate to Nexus contains
> non-ascii characters, the authentication fails with an access denied error.
> After using Wireshark to investigate the headers being sent (in my case "Ø",
> any non-ascii characters are replaced with "?".
> To test, I have used the following configuration:
> {code:java}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
> ...
>
>
> artifactory
> userØ
> userØ
>
>
> ...
>
>
> nexus
> *
> Local Nexus
> http://localhost:8081/repository/maven-public
>
>
> ...
> {code}
> The settings.xml file is saved using UTF-8 encoding and it appears that Maven
> reads the username and passwords correctly into strings, but Apache
> HttpClient do not encode the UTF-8 characters when encoding them into base64.
> I did a quick patch of Wagon to make it work for my use case, where
> HttpClient is configured to encode as UTF-8. As is mentioned in MNG-5917, it
> is not completely clear from the standards how these characters are supposed
> to be handled, but on my system both wget and the Chrome web browser encode
> the characters the same way as after my patch and are able to download files
> from Nexus.
> Since Artifactory was used in MNG-5917, I also tested against that, but in
> contrast to Maven it was not able to decode the username and password
> correctly, however it would be broken without the patch anyway.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed WAGON-537. Resolution: Fixed Fixed with [ff45ca83be7a2c07706a3a8dde420c897c58be1c|https://gitbox.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=ff45ca83be7a2c07706a3a8dde420c897c58be1c]. Thank you for this great contribution! > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.2.1 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (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=16687107#comment-16687107
]
ASF GitHub Bot commented on WAGON-537:
--
asfgit closed pull request #51: WAGON-537 Maven transfer speed of large
artifacts is slow
URL: https://github.com/apache/maven-wagon/pull/51
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..361390a4 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
@@ -42,8 +42,14 @@
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
+import java.nio.ByteBuffer;
+import java.nio.channels.Channels;
+import java.nio.channels.ReadableByteChannel;
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 +59,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,31 +584,74 @@ 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];
+
+ByteBuffer buffer = ByteBuffer.allocate(
getBufferCapacityForTransferring( resource.getContentLength() ) );
+int halfBufferCapacity = buffer.capacity() / 2;
TransferEvent transferEvent = new TransferEvent( this, resource,
TransferEvent.TRANSFER_PROGRESS, requestType );
transferEvent.setTimestamp( System.currentTimeMillis() );
+ReadableByteChannel in = Channels.newChannel( input );
+
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 ) );
+int read = in.read( buffer );
-if ( n == -1 )
+if ( read == -1 )
{
+// EOF, but some data has not been written yet.
+if ( buffer.position() != 0 )
+{
+buffer.flip();
+fireTransferProgress( transferEvent, buffer.array(),
buffer.limit() );
+output.write( buffer.array(), 0, buffer.limit() );
+}
+
break;
}
-fireTransferProgress( transferEvent, buffer, n );
-
-output.write( buffer, 0, n );
+// Prevent minichunking / fragmentation: when less than half the
buffer is utilized,
+// read some more bytes before writing and firing progress.
+if ( buffer.position() < halfBufferCapacity )
+{
+continue;
+}
-remaining -= n;
+buffer.flip();
+fireTransferProgress( transferEvent, buffer.array(),
buffer.limit() );
+output.write( buffer.array(), 0, buffer.limit() );
+remaining -= buffer.limit();
+buffer.clear();
}
output.flush();
}
+/**
+ * Provides a buffer size for efficiently transferring the given amount of
bytes, such that
+ * it is not fragmented into to many chunks. For larger files, larger
buffers are provided such that downstream
+ * {@link #fireTransferProgress(TransferEvent, byte[], int) listeners} are
[GitHub] asfgit closed pull request #51: WAGON-537 Maven transfer speed of large artifacts is slow
asfgit closed pull request #51: WAGON-537 Maven transfer speed of large
artifacts is slow
URL: https://github.com/apache/maven-wagon/pull/51
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..361390a4 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
@@ -42,8 +42,14 @@
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
+import java.nio.ByteBuffer;
+import java.nio.channels.Channels;
+import java.nio.channels.ReadableByteChannel;
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 +59,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,31 +584,74 @@ 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];
+
+ByteBuffer buffer = ByteBuffer.allocate(
getBufferCapacityForTransferring( resource.getContentLength() ) );
+int halfBufferCapacity = buffer.capacity() / 2;
TransferEvent transferEvent = new TransferEvent( this, resource,
TransferEvent.TRANSFER_PROGRESS, requestType );
transferEvent.setTimestamp( System.currentTimeMillis() );
+ReadableByteChannel in = Channels.newChannel( input );
+
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 ) );
+int read = in.read( buffer );
-if ( n == -1 )
+if ( read == -1 )
{
+// EOF, but some data has not been written yet.
+if ( buffer.position() != 0 )
+{
+buffer.flip();
+fireTransferProgress( transferEvent, buffer.array(),
buffer.limit() );
+output.write( buffer.array(), 0, buffer.limit() );
+}
+
break;
}
-fireTransferProgress( transferEvent, buffer, n );
-
-output.write( buffer, 0, n );
+// Prevent minichunking / fragmentation: when less than half the
buffer is utilized,
+// read some more bytes before writing and firing progress.
+if ( buffer.position() < halfBufferCapacity )
+{
+continue;
+}
-remaining -= n;
+buffer.flip();
+fireTransferProgress( transferEvent, buffer.array(),
buffer.limit() );
+output.write( buffer.array(), 0, buffer.limit() );
+remaining -= buffer.limit();
+buffer.clear();
}
output.flush();
}
+/**
+ * Provides a buffer size for efficiently transferring the given amount of
bytes, such that
+ * it is not fragmented into to many chunks. 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
[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=16687105#comment-16687105
]
Michael Osipov commented on WAGON-537:
--
Just tried the upload with curl, no issue on our side:
{noformat}
$ curl --upload big.bin
http://mika-ion:8081/nexus/content/repositories/snapshots/test/test-big/0.0.1-SNAPSHOT/toll.bin
--verbose -u admin:admin123
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
34 4768M0 0 34 1633M 0 22.5M 0:03:31 0:01:12 0:02:19 23.1M
{noformat}
Must be some other reason for the speed. I will now go ahead and merge it.
> Maven transfer speed of large artifacts is slow due to unsuitable buffer
> strategy
> -
>
> Key: WAGON-537
> URL: https://issues.apache.org/jira/browse/WAGON-537
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http, wagon-provider-api
>Affects Versions: 3.2.0
> Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s
> network connection.
>Reporter: Olaf Otto
>Assignee: Michael Osipov
>Priority: Major
> Labels: perfomance
> Fix For: 3.2.1
>
> Attachments: wagon-issue.png
>
>
> We are using maven for build process automation with docker. This sometimes
> involves uploading and downloading artifacts with a few gigabytes in size.
> Here, maven's transfer speed is consistently and reproducibly slow. For
> instance, an artifact with 7,5 GB in size took almost two hours to transfer
> in spite of a 100 MB/s connection with respective reproducible download speed
> from the remote nexus artifact repository when using a browser to download.
> The same is true when uploding such an artifact.
> I have investigated the issue using JProfiler. The result shows an issue in
> AbstractWagon's transfer( Resource resource, InputStream input, OutputStream
> output, int requestType, long maxSize ) method used for remote artifacts and
> the same issue in AbstractHttpClientWagon#writeTo(OutputStream).
> Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data
> is received, the received data is pushed to downstream listeners via
> fireTransferProgress. These listeners (or rather consumers) perform expensive
> tasks.
> Now, the underlying InputStream implementation used in transfer will return
> calls to read(buffer, offset, length) as soon as *some* data is available.
> That is, fireTransferProgress may well be invoked with an average number of
> bytes less than half the buffer capacity (this varies with the underlying
> network and hardware architecture). Consequently, fireTransferProgress is
> invoked *millions of times* for large files. As this is a blocking operation,
> the time spent in fireTransferProgress dominates and drastically slows down
> the transfers by at least one order of magnitude.
> !wagon-issue.png!
> In our case, we found download speed reduced from a theoretical optimum of
> ~80 seconds to to more than 3200 seconds.
> From an architectural perspective, I would not want to make the consumers /
> listeners invoked via fireTransferProgress aware of their potential impact on
> download speed, but rather refactor the transfer method such that it uses a
> buffer strategy reducing the the number of fireTransferProgress invocations.
> This should be done with regard to the expected file size of the transfer,
> such that fireTransferProgress is invoked often enough but not to frequent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] jglick commented on a change in pull request #199: Surefire 1593
jglick commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r233595772
##
File path:
maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfigurationTest.java
##
@@ -0,0 +1,216 @@
+package org.apache.maven.plugin.surefire.booterclient;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.io.IOException;
+import java.net.URI;
+import java.net.URISyntaxException;
+import java.nio.file.Path;
+
+import
org.apache.maven.plugin.surefire.booterclient.output.InPluginProcessDumpSingleton;
+
+import static
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.relativize;
+import static
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toAbsoluteUri;
+import static
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toClasspathElementUri;
+import static org.fest.assertions.Assertions.assertThat;
+
+import org.junit.BeforeClass;
+import org.junit.ClassRule;
+import org.junit.Test;
+import org.junit.rules.TemporaryFolder;
+import org.junit.runner.RunWith;
+import static org.mockito.ArgumentMatchers.same;
+import static org.powermock.api.mockito.PowerMockito.mock;
+import static org.powermock.api.mockito.PowerMockito.mockStatic;
+import static org.powermock.api.mockito.PowerMockito.when;
+
+import org.mockito.invocation.InvocationOnMock;
+import org.mockito.stubbing.Answer;
+import org.powermock.core.classloader.annotations.PrepareForTest;
+import org.powermock.modules.junit4.PowerMockRunner;
+
+/**
+ * Unit tests for {@link JarManifestForkConfiguration}.
+ */
+@RunWith( PowerMockRunner.class )
+@PrepareForTest( { JarManifestForkConfiguration.class,
InPluginProcessDumpSingleton.class } )
+public class JarManifestForkConfigurationTest
+{
+@ClassRule
+public static final TemporaryFolder TMP = new TemporaryFolder();
+
+private static File dumpDirectory;
+
+@BeforeClass
+public static void createSystemTemporaryDir()
+throws IOException
+{
+TMP.create();
Review comment:
Unnecessary; implied by it being registered as a `@ClassRule` (called by
`TemporaryFolder.before`).
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] jglick commented on a change in pull request #199: Surefire 1593
jglick commented on a change in pull request #199: Surefire 1593
URL: https://github.com/apache/maven-surefire/pull/199#discussion_r233594305
##
File path:
maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfigurationTest.java
##
@@ -0,0 +1,190 @@
+package org.apache.maven.plugin.surefire.booterclient;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.net.URI;
+
+import
org.apache.maven.plugin.surefire.booterclient.output.InPluginProcessDumpSingleton;
+import static org.fest.assertions.Assertions.assertThat;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.ArgumentMatchers.anyString;
+import static org.powermock.api.mockito.PowerMockito.mock;
+import static org.powermock.api.mockito.PowerMockito.mockStatic;
+import static org.powermock.api.mockito.PowerMockito.when;
+import org.powermock.core.classloader.annotations.PrepareForTest;
+import org.powermock.modules.junit4.PowerMockRunner;
+
+/**
+ * Unit tests for {@link JarManifestForkConfiguration}.
+ */
+@RunWith( PowerMockRunner.class )
+@PrepareForTest( { JarManifestForkConfiguration.class,
InPluginProcessDumpSingleton.class } )
+public class JarManifestForkConfigurationTest
+{
+private static final String BASE_DIR = System.getProperty( "user.dir" );
+
+@Test
+public void relativeClasspathUnixSimple()
+throws Exception
+{
+mockStatic( JarManifestForkConfiguration.class );
+String parent = "/home/me/prj/target/surefire";
+String classPathElement =
"/home/me/.m2/repository/grp/art/1.0/art-1.0.jar";
+when( JarManifestForkConfiguration.relativize( parent,
classPathElement ) )
+.thenReturn( "../../../.m2/repository/grp/art/1.0/art-1.0.jar"
);
+when( JarManifestForkConfiguration.toClasspathElementUri( anyString(),
anyString(), any( File.class ) ) )
+.thenCallRealMethod();
+File dump = new File( BASE_DIR, "target/test-dump" );
+//noinspection ResultOfMethodCallIgnored
+dump.mkdir();
+assertThat( JarManifestForkConfiguration.toClasspathElementUri(
parent, classPathElement, dump ) )
+.isEqualTo( "../../../.m2/repository/grp/art/1.0/art-1.0.jar"
);
+}
+
+@Test
+public void relativeClasspathUnixTricky()
+throws Exception
+{
+mockStatic( JarManifestForkConfiguration.class );
+String parent = "/home/me/prj/target/surefire";
+String classPathElement = "/the Maven repo/grp/art/1.0/art-1.0.jar";
+when( JarManifestForkConfiguration.relativize( parent,
classPathElement ) )
+.thenReturn( "../../../../../the Maven
repo/grp/art/1.0/art-1.0.jar" );
+when( JarManifestForkConfiguration.toClasspathElementUri( anyString(),
anyString(), any( File.class ) ) )
+.thenCallRealMethod();
+File dump = new File( BASE_DIR, "target/test-dump" );
+assertThat( JarManifestForkConfiguration.toClasspathElementUri(
parent, classPathElement, dump ) )
+.isEqualTo(
"../../../../../the%20Maven%20repo/grp/art/1.0/art-1.0.jar" );
+}
+
+@Test
+public void relativeClasspathWindowsSimple()
+throws Exception
+{
+mockStatic( JarManifestForkConfiguration.class );
+String parent = "C:\\Windows\\Temp\\surefire";
+String classPathElement =
"C:\\Users\\me\\.m2\\repository\\grp\\art\\1.0\\art-1.0.jar";
+when( JarManifestForkConfiguration.relativize( parent,
classPathElement ) )
+.thenReturn(
"..\\..\\..\\Users\\me\\.m2\\repository\\grp\\art\\1.0\\art-1.0.jar" );
+when( JarManifestForkConfiguration.toClasspathElementUri( anyString(),
anyString(), any( File.class ) ) )
+.thenCallRealMethod();
+File dump = new File( BASE_DIR, "target/test-dump" );
+assertThat( JarManifestForkConfiguration.toClasspathElementUri(
parent, classPathElement, dump ) )
+.isEqualTo(
"../../../Users/me/.m2/repository/grp/art/1.0/art-1.0.jar" );
+}
+
+@Test
+
[jira] [Commented] (MNG-5180) Versioning's snapshot version list is not included in metadata merge
[
https://issues.apache.org/jira/browse/MNG-5180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687031#comment-16687031
]
ASF GitHub Bot commented on MNG-5180:
-
fuss86 closed pull request #191: [MNG-5180] - Versioning's snapshot version
list is not included in metadata merge
URL: https://github.com/apache/maven/pull/191
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-repository-metadata/src/main/mdo/metadata.mdo
b/maven-repository-metadata/src/main/mdo/metadata.mdo
index e2d0753397..82f3cc1575 100644
--- a/maven-repository-metadata/src/main/mdo/metadata.mdo
+++ b/maven-repository-metadata/src/main/mdo/metadata.mdo
@@ -202,6 +202,30 @@ under the License.
changed = true;
}
}
+
+for ( SnapshotVersion snapshotVersion :
versioning.getSnapshotVersions() )
+{
+boolean exists = false;
+
+for ( SnapshotVersion sv : v.getSnapshotVersions() )
+{
+if ( java.util.Objects.equals(
snapshotVersion.getClassifier(), sv.getClassifier() ) &&
+ java.util.Objects.equals(
snapshotVersion.getExtension(), sv.getExtension() ) &&
+ java.util.Objects.equals(
snapshotVersion.getUpdated(), sv.getUpdated() ) &&
+ java.util.Objects.equals(
snapshotVersion.getVersion(), sv.getVersion() ) )
+{
+exists = true;
+break;
+}
+}
+
+if (!exists)
+{
+changed = true;
+v.getSnapshotVersions().add( snapshotVersion );
+}
+}
+
}
}
return changed;
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
> Versioning's snapshot version list is not included in metadata merge
> --
>
> Key: MNG-5180
> URL: https://issues.apache.org/jira/browse/MNG-5180
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.0.3
>Reporter: Noam Y. Tenne
>Priority: Major
> Attachments: MavenMetadataSnapshotVersionsMergeTest.java
>
>
> Versioning#snapshotVersions is not being merged when using Metadata#merge.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-5180) Versioning's snapshot version list is not included in metadata merge
[ https://issues.apache.org/jira/browse/MNG-5180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687030#comment-16687030 ] ASF GitHub Bot commented on MNG-5180: - fuss86 commented on issue #191: [MNG-5180] - Versioning's snapshot version list is not included in metadata merge URL: https://github.com/apache/maven/pull/191#issuecomment-438792816 Based on http://maven.apache.org/ref/3.6.0/maven-repository-metadata/repository-metadata.html > Versioning information for a sub-artifact of the current snapshot artifact. this fix is wrong 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 > Versioning's snapshot version list is not included in metadata merge > -- > > Key: MNG-5180 > URL: https://issues.apache.org/jira/browse/MNG-5180 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0.3 >Reporter: Noam Y. Tenne >Priority: Major > Attachments: MavenMetadataSnapshotVersionsMergeTest.java > > > Versioning#snapshotVersions is not being merged when using Metadata#merge. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] fuss86 closed pull request #191: [MNG-5180] - Versioning's snapshot version list is not included in metadata merge
fuss86 closed pull request #191: [MNG-5180] - Versioning's snapshot version
list is not included in metadata merge
URL: https://github.com/apache/maven/pull/191
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-repository-metadata/src/main/mdo/metadata.mdo
b/maven-repository-metadata/src/main/mdo/metadata.mdo
index e2d0753397..82f3cc1575 100644
--- a/maven-repository-metadata/src/main/mdo/metadata.mdo
+++ b/maven-repository-metadata/src/main/mdo/metadata.mdo
@@ -202,6 +202,30 @@ under the License.
changed = true;
}
}
+
+for ( SnapshotVersion snapshotVersion :
versioning.getSnapshotVersions() )
+{
+boolean exists = false;
+
+for ( SnapshotVersion sv : v.getSnapshotVersions() )
+{
+if ( java.util.Objects.equals(
snapshotVersion.getClassifier(), sv.getClassifier() ) &&
+ java.util.Objects.equals(
snapshotVersion.getExtension(), sv.getExtension() ) &&
+ java.util.Objects.equals(
snapshotVersion.getUpdated(), sv.getUpdated() ) &&
+ java.util.Objects.equals(
snapshotVersion.getVersion(), sv.getVersion() ) )
+{
+exists = true;
+break;
+}
+}
+
+if (!exists)
+{
+changed = true;
+v.getSnapshotVersions().add( snapshotVersion );
+}
+}
+
}
}
return changed;
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] fuss86 commented on issue #191: [MNG-5180] - Versioning's snapshot version list is not included in metadata merge
fuss86 commented on issue #191: [MNG-5180] - Versioning's snapshot version list is not included in metadata merge URL: https://github.com/apache/maven/pull/191#issuecomment-438792816 Based on http://maven.apache.org/ref/3.6.0/maven-repository-metadata/repository-metadata.html > Versioning information for a sub-artifact of the current snapshot artifact. this fix is wrong 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] (MRESOLVER-63) FileTransformer#transformData(File) should also throw TransformException
[ https://issues.apache.org/jira/browse/MRESOLVER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686853#comment-16686853 ] ASF GitHub Bot commented on MRESOLVER-63: - rfscholte commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233527820 ## File path: maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformationException.java ## @@ -0,0 +1,79 @@ +package org.eclipse.aether.transform; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import java.io.File; + +import org.eclipse.aether.RepositoryException; + +/** + * Thrown when file transformation failed. + */ +public class FileTransformationException +extends RepositoryException Review comment: This is not really a repository exception. Consider the following usecase: we want to transform the pom.xml during upload with xslt. When trying to generate the XMLParser you must catch the SaxException. This one should be wrapped and thrown by this method. 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 > FileTransformer#transformData(File) should also throw TransformException > > > Key: MRESOLVER-63 > URL: https://issues.apache.org/jira/browse/MRESOLVER-63 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: 1.3.1 >Reporter: Robert Scholte >Priority: Major > Labels: up-for-grabs > Fix For: 1.3.2 > > > 1.3.1 introduced the FileTransformer to allow on-the-fly transforming of data. > For XML files it makes sense to use XMLFilters and create an XMLReader. This > can throw a SAXException, which is a checked exception, which shouldn't be > rethrown as an IOException. > Better to introduce a new Exception to handle this case properly. > Assuming this class isn't used anywhere yet, it should be good to introduce > it asap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRESOLVER-63) FileTransformer#transformData(File) should also throw TransformException
[
https://issues.apache.org/jira/browse/MRESOLVER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686855#comment-16686855
]
ASF GitHub Bot commented on MRESOLVER-63:
-
rfscholte commented on a change in pull request #23: [MRESOLVER-63]
FileTransformer#transformData(File) should also throw TransformException
URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233528072
##
File path:
maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformationException.java
##
@@ -0,0 +1,79 @@
+package org.eclipse.aether.transform;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+
+import org.eclipse.aether.RepositoryException;
+
+/**
+ * Thrown when file transformation failed.
+ */
+public class FileTransformationException
+extends RepositoryException
+{
+
+private final transient File file;
+
+/**
+ * Creates a new exception with the specified file.
+ *
+ * @param file The file which transformation failed, may be {@code null}.
+ */
+public FileTransformationException( File file )
Review comment:
There's not always a file involved yet, no need to use this.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> FileTransformer#transformData(File) should also throw TransformException
>
>
> Key: MRESOLVER-63
> URL: https://issues.apache.org/jira/browse/MRESOLVER-63
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.3.1
>Reporter: Robert Scholte
>Priority: Major
> Labels: up-for-grabs
> Fix For: 1.3.2
>
>
> 1.3.1 introduced the FileTransformer to allow on-the-fly transforming of data.
> For XML files it makes sense to use XMLFilters and create an XMLReader. This
> can throw a SAXException, which is a checked exception, which shouldn't be
> rethrown as an IOException.
> Better to introduce a new Exception to handle this case properly.
> Assuming this class isn't used anywhere yet, it should be good to introduce
> it asap.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOLVER-63) FileTransformer#transformData(File) should also throw TransformException
[ https://issues.apache.org/jira/browse/MRESOLVER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686854#comment-16686854 ] ASF GitHub Bot commented on MRESOLVER-63: - rfscholte commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233528693 ## File path: maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformer.java ## @@ -47,5 +46,5 @@ * @param file the file with the original data * @return the transformed data */ -InputStream transformData( File file ) throws IOException; +InputStream transformData( File file ) throws FileTransformationException; Review comment: Both IOException and TransformException must be thrown. Better not make it too explicit, we might do other transformations as well in the future, not only filebased. 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 > FileTransformer#transformData(File) should also throw TransformException > > > Key: MRESOLVER-63 > URL: https://issues.apache.org/jira/browse/MRESOLVER-63 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: 1.3.1 >Reporter: Robert Scholte >Priority: Major > Labels: up-for-grabs > Fix For: 1.3.2 > > > 1.3.1 introduced the FileTransformer to allow on-the-fly transforming of data. > For XML files it makes sense to use XMLFilters and create an XMLReader. This > can throw a SAXException, which is a checked exception, which shouldn't be > rethrown as an IOException. > Better to introduce a new Exception to handle this case properly. > Assuming this class isn't used anywhere yet, it should be good to introduce > it asap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] rfscholte commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException
rfscholte commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233528693 ## File path: maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformer.java ## @@ -47,5 +46,5 @@ * @param file the file with the original data * @return the transformed data */ -InputStream transformData( File file ) throws IOException; +InputStream transformData( File file ) throws FileTransformationException; Review comment: Both IOException and TransformException must be thrown. Better not make it too explicit, we might do other transformations as well in the future, not only filebased. 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] rfscholte commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException
rfscholte commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233527820 ## File path: maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformationException.java ## @@ -0,0 +1,79 @@ +package org.eclipse.aether.transform; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import java.io.File; + +import org.eclipse.aether.RepositoryException; + +/** + * Thrown when file transformation failed. + */ +public class FileTransformationException +extends RepositoryException Review comment: This is not really a repository exception. Consider the following usecase: we want to transform the pom.xml during upload with xslt. When trying to generate the XMLParser you must catch the SaxException. This one should be wrapped and thrown by this method. 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] rfscholte commented on a change in pull request #23: [MRESOLVER-63] FileTransformer#transformData(File) should also throw TransformException
rfscholte commented on a change in pull request #23: [MRESOLVER-63]
FileTransformer#transformData(File) should also throw TransformException
URL: https://github.com/apache/maven-resolver/pull/23#discussion_r233528072
##
File path:
maven-resolver-api/src/main/java/org/eclipse/aether/transform/FileTransformationException.java
##
@@ -0,0 +1,79 @@
+package org.eclipse.aether.transform;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+
+import org.eclipse.aether.RepositoryException;
+
+/**
+ * Thrown when file transformation failed.
+ */
+public class FileTransformationException
+extends RepositoryException
+{
+
+private final transient File file;
+
+/**
+ * Creates a new exception with the specified file.
+ *
+ * @param file The file which transformation failed, may be {@code null}.
+ */
+public FileTransformationException( File file )
Review comment:
There's not always a file involved yet, no need to use this.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (MSITE-828) Jdk 1.8 required
[ https://issues.apache.org/jira/browse/MSITE-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686839#comment-16686839 ] ASF GitHub Bot commented on MSITE-828: -- slachiewicz commented on issue #3: [MSITE-828] Upgrade jetty to recent version. Update to java 1.8 (required for jetty) URL: https://github.com/apache/maven-site-plugin/pull/3#issuecomment-438729622 Just for reference https://issues.apache.org/jira/browse/MSITE-830 more libs to update This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Jdk 1.8 required > > > Key: MSITE-828 > URL: https://issues.apache.org/jira/browse/MSITE-828 > Project: Maven Site Plugin > Issue Type: Task >Reporter: Olivier Lamy (*$^¨%`£) >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > Fix For: 3.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSITE-830) Dependency upgrades related to identified security reports
Sylwester Lachiewicz created MSITE-830: -- Summary: Dependency upgrades related to identified security reports Key: MSITE-830 URL: https://issues.apache.org/jira/browse/MSITE-830 Project: Maven Site Plugin Issue Type: Improvement Reporter: Sylwester Lachiewicz Fix problems reported by [Snyk.io|https://snyk.io/] |H|[Arbitrary File Write via Archive Extraction (Zip Slip)|https://app.snyk.io/vuln/SNYK-JAVA-ORGCODEHAUSPLEXUS-31680] in org.codehaus.plexus:plexus-archiver| |H| [Arbitrary Code Execution|https://app.snyk.io/vuln/SNYK-JAVA-COMMONSBEANUTILS-30077] in commons-beanutils:commons-beanutils| |H| [Arbitrary Code Execution|https://app.snyk.io/vuln/SNYK-JAVA-COMMONSCOLLECTIONS-30078] in commons-collections:commons-collections| |H| [XML External Entity (XXE) Injection|https://app.snyk.io/vuln/SNYK-JAVA-DOM4J-72444] in dom4j:dom4j| |H| [Denial of Service (DoS)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEPDFBOX-32417] in org.apache.pdfbox:fontbox| |H| [Arbitrary Code Injection|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHESTRUTS-30763] in org.apache.struts:struts-core| |H| [Arbitrary Command Execution|https://app.snyk.io/vuln/SNYK-JAVA-ORGMORTBAYJETTY-32091] in org.mortbay.jetty:jetty| |M|[Denial of Service (DoS)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHECOMMONS-32122] in org.apache.commons:commons-compress| |M|[Directory Traversal|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHECOMMONS-72275] in org.apache.commons:commons-compress| |M| [Man-in-the-Middle (MitM)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-30646] in org.apache.httpcomponents:httpclient| |M| [Directory Traversal|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-31517] in org.apache.httpcomponents:httpclient| |M| [Improper Input Validation|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-30645] in org.apache.httpcomponents:httpclient| |M| [Information Exposure|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-30644] in org.apache.httpcomponents:httpclient| |M| [Denial of Service (DoS)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEHTTPCOMPONENTS-30647] in org.apache.httpcomponents:httpclient| |M| [Denial of Service (DoS)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHEPDFBOX-72426] in org.apache.pdfbox:pdfbox| |L|[Denial of Service (DoS)|https://app.snyk.io/vuln/SNYK-JAVA-ORGAPACHECOMMONS-32473] in org.apache.commons:commons-compress| -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MSITE-758) upgrade wagon-api from 1.0 to 2.x
[ https://issues.apache.org/jira/browse/MSITE-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686811#comment-16686811 ] Sylwester Lachiewicz edited comment on MSITE-758 at 11/14/18 4:23 PM: -- \+1 to support only 3.0.5+ was (Author: slachiewicz): +1 to support only 3.0.5+ > upgrade wagon-api from 1.0 to 2.x > - > > Key: MSITE-758 > URL: https://issues.apache.org/jira/browse/MSITE-758 > Project: Maven Site Plugin > Issue Type: Task > Components: site:deploy >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Priority: Major > > I don't really know what changed from wagon-api 1.0 to 2.0 > or from 2.0 to 2.10 (= latest when writing this) > but this is just about the general idea of dropping old wagon 1.0 dependency > to get a newer one > for reference: > - Maven 2..x to 3.0.3 use wagon 1.0-beta > http://maven.apache.org/ref/3.0.3/apache-maven/dependencies.html > - Maven 3.0.4 uses wagon 2.2 > http://maven.apache.org/ref/3.0.4/apache-maven/dependencies.html > - Maven 3.0.5 uses wagon 2.4 > http://maven.apache.org/ref/3.0.5/apache-maven/dependencies.html > ... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSITE-758) upgrade wagon-api from 1.0 to 2.x
[ https://issues.apache.org/jira/browse/MSITE-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686811#comment-16686811 ] Sylwester Lachiewicz commented on MSITE-758: +1 to support only 3.0.5+ > upgrade wagon-api from 1.0 to 2.x > - > > Key: MSITE-758 > URL: https://issues.apache.org/jira/browse/MSITE-758 > Project: Maven Site Plugin > Issue Type: Task > Components: site:deploy >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Priority: Major > > I don't really know what changed from wagon-api 1.0 to 2.0 > or from 2.0 to 2.10 (= latest when writing this) > but this is just about the general idea of dropping old wagon 1.0 dependency > to get a newer one > for reference: > - Maven 2..x to 3.0.3 use wagon 1.0-beta > http://maven.apache.org/ref/3.0.3/apache-maven/dependencies.html > - Maven 3.0.4 uses wagon 2.2 > http://maven.apache.org/ref/3.0.4/apache-maven/dependencies.html > - Maven 3.0.5 uses wagon 2.4 > http://maven.apache.org/ref/3.0.5/apache-maven/dependencies.html > ... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-772) maven-dependency-analyzer not working on OpenJDK 11
[
https://issues.apache.org/jira/browse/MSHARED-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686766#comment-16686766
]
Karl Heinz Marbaise commented on MSHARED-772:
-
Than why are filling in an issue for the dependency-analyzer here? And if you
already using the most recent version of the maven-compiler-plugin you don't
have to add the asm dependency ...It would help if you could make an example
project which shows the failure ...otherwise it's hard to reproduce? Apart from
that maven-compiler-plugin 3.8.0 works on JDK 11 ...?
> maven-dependency-analyzer not working on OpenJDK 11
>
>
> Key: MSHARED-772
> URL: https://issues.apache.org/jira/browse/MSHARED-772
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Reporter: khalid el boukhari
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
>
> Hi,
> Maven-dependency-analyzer is not supporting java 11.
> Here is my conf :
> {code:xml}
>
> maven-compiler-plugin
>
>
> org.ow2.asm
> asm
> 7.0
>
>
>
> 11
>
>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-772) maven-dependency-analyzer not working on OpenJDK 11
[
https://issues.apache.org/jira/browse/MSHARED-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686697#comment-16686697
]
khalid el boukhari commented on MSHARED-772:
maven-compiler-plugin is *3.8.0*
> maven-dependency-analyzer not working on OpenJDK 11
>
>
> Key: MSHARED-772
> URL: https://issues.apache.org/jira/browse/MSHARED-772
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Reporter: khalid el boukhari
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
>
> Hi,
> Maven-dependency-analyzer is not supporting java 11.
> Here is my conf :
> {code:xml}
>
> maven-compiler-plugin
>
>
> org.ow2.asm
> asm
> 7.0
>
>
>
> 11
>
>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-772) maven-dependency-analyzer not working on OpenJDK 11
[
https://issues.apache.org/jira/browse/MSHARED-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686663#comment-16686663
]
Karl Heinz Marbaise commented on MSHARED-772:
-
Can you please share which version of maven-compiler-plugin you are using?
> maven-dependency-analyzer not working on OpenJDK 11
>
>
> Key: MSHARED-772
> URL: https://issues.apache.org/jira/browse/MSHARED-772
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Reporter: khalid el boukhari
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
>
> Hi,
> Maven-dependency-analyzer is not supporting java 11.
> Here is my conf :
> {code:xml}
>
> maven-compiler-plugin
>
>
> org.ow2.asm
> asm
> 7.0
>
>
>
> 11
>
>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-770) Upgrade org.ow2.asm:asm to 7.0
[ https://issues.apache.org/jira/browse/MSHARED-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686664#comment-16686664 ] Hudson commented on MSHARED-770: Build succeeded in Jenkins: Maven TLP » maven-dependency-analyzer » master #49 See https://builds.apache.org/job/maven-box/job/maven-dependency-analyzer/job/master/49/ > Upgrade org.ow2.asm:asm to 7.0 > -- > > Key: MSHARED-770 > URL: https://issues.apache.org/jira/browse/MSHARED-770 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.10 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-dependency-analyzer-1.11 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MSHARED-770) Upgrade org.ow2.asm:asm to 7.0
[ https://issues.apache.org/jira/browse/MSHARED-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-770. --- Resolution: Done > Upgrade org.ow2.asm:asm to 7.0 > -- > > Key: MSHARED-770 > URL: https://issues.apache.org/jira/browse/MSHARED-770 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.10 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-dependency-analyzer-1.11 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-770) Upgrade org.ow2.asm:asm to 7.0
[ https://issues.apache.org/jira/browse/MSHARED-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686658#comment-16686658 ] Karl Heinz Marbaise commented on MSHARED-770: - Done in [3c753fdb643471503215aded591c9d197017697b|https://gitbox.apache.org/repos/asf?p=maven-dependency-analyzer.git;a=commitdiff;h=3c753fdb643471503215aded591c9d197017697b] > Upgrade org.ow2.asm:asm to 7.0 > -- > > Key: MSHARED-770 > URL: https://issues.apache.org/jira/browse/MSHARED-770 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.10 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-dependency-analyzer-1.11 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MSHARED-772) maven-dependency-analyzer not working on OpenJDK 11
[
https://issues.apache.org/jira/browse/MSHARED-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MSHARED-772.
---
Resolution: Duplicate
Assignee: Karl Heinz Marbaise
> maven-dependency-analyzer not working on OpenJDK 11
>
>
> Key: MSHARED-772
> URL: https://issues.apache.org/jira/browse/MSHARED-772
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Reporter: khalid el boukhari
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
>
> Hi,
> Maven-dependency-analyzer is not supporting java 11.
> Here is my conf :
> {code:xml}
>
> maven-compiler-plugin
>
>
> org.ow2.asm
> asm
> 7.0
>
>
>
> 11
>
>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MSHARED-772) maven-dependency-analyzer not working on OpenJDK 11
[
https://issues.apache.org/jira/browse/MSHARED-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
khalid el boukhari updated MSHARED-772:
---
Priority: Blocker (was: Major)
> maven-dependency-analyzer not working on OpenJDK 11
>
>
> Key: MSHARED-772
> URL: https://issues.apache.org/jira/browse/MSHARED-772
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Reporter: khalid el boukhari
>Priority: Blocker
>
> Hi,
> Maven-dependency-analyzer is not supporting java 11.
> Here is my conf :
> {code:xml}
>
> maven-compiler-plugin
>
>
> org.ow2.asm
> asm
> 7.0
>
>
>
> 11
>
>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MSHARED-772) maven-dependency-analyzer not working on OpenJDK 11
khalid el boukhari created MSHARED-772:
--
Summary: maven-dependency-analyzer not working on OpenJDK 11
Key: MSHARED-772
URL: https://issues.apache.org/jira/browse/MSHARED-772
Project: Maven Shared Components
Issue Type: Bug
Components: maven-dependency-analyzer
Reporter: khalid el boukhari
Hi,
Maven-dependency-analyzer is not supporting java 11.
Here is my conf :
{code:xml}
maven-compiler-plugin
org.ow2.asm
asm
7.0
11
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MENFORCER-314) DependencyConvergence fails sporadically with a null message
[
https://issues.apache.org/jira/browse/MENFORCER-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-314:
--
Fix Version/s: 3.0.0
> DependencyConvergence fails sporadically with a null message
>
>
> Key: MENFORCER-314
> URL: https://issues.apache.org/jira/browse/MENFORCER-314
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1, 3.0.0-M1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Java version: 1.8.0_162, vendor: Oracle Corporation
>Reporter: Falko Modler
>Priority: Major
> Fix For: 3.0.0
>
>
> Our Jenkins builds fail sporadically without providing a message:
> {noformat}
> 17:08:28 [WARNING] Rule 4:
> org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:
> 17:08:28 null
> {noformat}
> Looking at the code, I suspect that this can happen [on line 132 of the
> rule|https://github.com/apache/maven-enforcer/blob/enforcer-3.0.0-M2/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java#L132]
> when some underlying exception is caught which itself does not provide a
> (localized) message.
> As the plugin [does not include the
> cause|https://github.com/apache/maven-enforcer/blob/enforcer-3.0.0-M2/maven-enforcer-plugin/src/main/java/org/apache/maven/plugins/enforcer/EnforceMojo.java#L212]
> (unless {{failFast}} is set), you will just see a null message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-319) UTF-8 BOM in pom.xml breaks banDuplicatePomDependencyVersions rule
[
https://issues.apache.org/jira/browse/MENFORCER-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686572#comment-16686572
]
ASF GitHub Bot commented on MENFORCER-319:
--
wilx commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when parsing
pom.xml files
URL: https://github.com/apache/maven-enforcer/pull/45#issuecomment-438678773
[**@khmarbaise**](https://github.com/khmarbaise) commented on [14 Nov 2018,
14:48
CET](https://github.com/apache/maven-enforcer/pull/45#issuecomment-438667508
"2018-11-14T13:48:38Z - Replied by Github Reply Comments"):
> Please don't change existing tests...please add a new one!
This does not make any sense in this case, IMHO. I have only added the BOM
to the existing test so that it exercises the modification. I cannot think of
any other that that would not be exact duplicate of the current
`banDuplicatePomDependencyVersions` with the 3 bytes of UTF-8 BOM added.
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
> UTF-8 BOM in pom.xml breaks banDuplicatePomDependencyVersions rule
> --
>
> Key: MENFORCER-319
> URL: https://issues.apache.org/jira/browse/MENFORCER-319
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M2
>Reporter: Václav Haisman
>Priority: Major
> Attachments:
> Handle_parsing_of_pom_xml_in_BanDuplicatePomDependencyVersions_java_similarly_to_how_actua.patch,
> pom.xml
>
>
> Having UTF-8 BOM at the beginning of {{pom.xml}} causes the
> banDuplicatePomDependencyVersions rule to fail to parse the file with the
> following exception being shown by {{-X}} output:
> {noformat}
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Unable to retrieve
> the MavenProject:
> at
> org.apache.maven.plugins.enforcer.BanDuplicatePomDependencyVersions.execute
> (BanDuplicatePomDependencyVersions.java:87)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:194)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (Unknown Source)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (Unknown
> Source)
> at java.lang.reflect.Method.invoke (Unknown Source)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
> Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: only
> whitespace content allowed before start tag and not \uef (position:
> START_DOCUMENT seen \uef... @1:1)
> at org.codehaus.plexus.util.xml.pull.MXParser.parseProlog
> (MXParser.java:1862)
> at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl
> (MXParser.java:1698)
> at org.codehaus.plexus.util.xml.pull.MXParser.next (MXParser.java:1317)
> at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read
> (MavenXpp3Reader.java:3856)
> at
[GitHub] wilx commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when parsing pom.xml files
wilx commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when parsing pom.xml files URL: https://github.com/apache/maven-enforcer/pull/45#issuecomment-438678773 [**@khmarbaise**](https://github.com/khmarbaise) commented on [14 Nov 2018, 14:48 CET](https://github.com/apache/maven-enforcer/pull/45#issuecomment-438667508 "2018-11-14T13:48:38Z - Replied by Github Reply Comments"): > Please don't change existing tests...please add a new one! This does not make any sense in this case, IMHO. I have only added the BOM to the existing test so that it exercises the modification. I cannot think of any other that that would not be exact duplicate of the current `banDuplicatePomDependencyVersions` with the 3 bytes of UTF-8 BOM added. 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] (MENFORCER-319) UTF-8 BOM in pom.xml breaks banDuplicatePomDependencyVersions rule
[
https://issues.apache.org/jira/browse/MENFORCER-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686514#comment-16686514
]
ASF GitHub Bot commented on MENFORCER-319:
--
khmarbaise commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when
parsing pom.xml files
URL: https://github.com/apache/maven-enforcer/pull/45#issuecomment-438667508
Please don't change existing tests...please add a new one!
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
> UTF-8 BOM in pom.xml breaks banDuplicatePomDependencyVersions rule
> --
>
> Key: MENFORCER-319
> URL: https://issues.apache.org/jira/browse/MENFORCER-319
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M2
>Reporter: Václav Haisman
>Priority: Major
> Attachments:
> Handle_parsing_of_pom_xml_in_BanDuplicatePomDependencyVersions_java_similarly_to_how_actua.patch,
> pom.xml
>
>
> Having UTF-8 BOM at the beginning of {{pom.xml}} causes the
> banDuplicatePomDependencyVersions rule to fail to parse the file with the
> following exception being shown by {{-X}} output:
> {noformat}
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Unable to retrieve
> the MavenProject:
> at
> org.apache.maven.plugins.enforcer.BanDuplicatePomDependencyVersions.execute
> (BanDuplicatePomDependencyVersions.java:87)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:194)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (Unknown Source)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (Unknown
> Source)
> at java.lang.reflect.Method.invoke (Unknown Source)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
> Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: only
> whitespace content allowed before start tag and not \uef (position:
> START_DOCUMENT seen \uef... @1:1)
> at org.codehaus.plexus.util.xml.pull.MXParser.parseProlog
> (MXParser.java:1862)
> at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl
> (MXParser.java:1698)
> at org.codehaus.plexus.util.xml.pull.MXParser.next (MXParser.java:1317)
> at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read
> (MavenXpp3Reader.java:3856)
> at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read
> (MavenXpp3Reader.java:595)
> at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read
> (MavenXpp3Reader.java:609)
> at
> org.apache.maven.plugins.enforcer.BanDuplicatePomDependencyVersions.execute
> (BanDuplicatePomDependencyVersions.java:75)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:194)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at
[GitHub] khmarbaise commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when parsing pom.xml files
khmarbaise commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when parsing pom.xml files URL: https://github.com/apache/maven-enforcer/pull/45#issuecomment-438667508 Please don't change existing tests...please add a new one! 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] (MSOURCES-119) Archiving to jar is very slow
[
https://issues.apache.org/jira/browse/MSOURCES-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686474#comment-16686474
]
Claes Nordmark commented on MSOURCES-119:
-
Also some more input using maven-profiler:
Run package on 2018/11/14 13:55:19 with parameters: \{maven.test.skip=true,
profile=true, disableTimeSorting=true}
my-app (44.61 s)
Plugin execution Duration
org.apache.maven.plugins:maven-resources-plugin:2.6:resources \{execution:
default-resources} 889.8 ms
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile \{execution:
default-compile} 1.402 s
org.apache.maven.plugins:maven-resources-plugin:2.6:testResources \{execution:
default-testResources} 2.019 ms
org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile \{execution:
default-testCompile} 1.383 ms
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test \{execution:
default-test} 480.9 ms
org.apache.maven.plugins:maven-jar-plugin:*3.1.0*:jar \{execution: default-jar}
6.388 s
org.apache.maven.plugins:maven-javadoc-plugin:*3.0.1*:jar \{execution:
attach-javadocs} 21.25 s
org.apache.maven.plugins:maven-source-plugin:*3.0.0*:jar \{execution:
attach-sources} 11.33 s
my-app (11.86 s)
Run package on 2018/11/14 13:56:33 with parameters: \{maven.test.skip=true,
profile=true, disableTimeSorting=true}
my-app (11.37 s)
Plugin execution Duration
org.apache.maven.plugins:maven-resources-plugin:2.6:resources \{execution:
default-resources} 801.5 ms
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile \{execution:
default-compile} 2.328 s
org.apache.maven.plugins:maven-resources-plugin:2.6:testResources \{execution:
default-testResources} 3.180 ms
org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile \{execution:
default-testCompile} 1.603 ms
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test \{execution:
default-test} 414.0 ms
org.apache.maven.plugins:maven-jar-plugin:*2.6*:jar \{execution: default-jar}
1.892 s
org.apache.maven.plugins:maven-javadoc-plugin*:2.10.1*:jar \{execution:
attach-javadocs} 2.921 s
org.apache.maven.plugins:maven-source-plugin:*2.4*:jar \{execution:
attach-sources} 1.242 s
> Archiving to jar is very slow
> -
>
> Key: MSOURCES-119
> URL: https://issues.apache.org/jira/browse/MSOURCES-119
> Project: Maven Source Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: RedHat 7
>Reporter: Claes Nordmark
>Priority: Major
>
> Doing a stackdump while "maven-source-plugin:3.0.0:jar-no-fork
> (attach-sources)" shows thread spending a lot of time in
> UnixNativeDispatcher.getgrgid.
> This was not visible in java 8 and source plugin version 2.4.
> Our previous build time has been increased from 5min to 3h 30min.
> Tested version Java 11 and 3.0.0 of maven-source-plugin
> maven config:
> {code:java}
>
> org.apache.maven.plugins
> maven-source-plugin
> 3.0.0
>
>
> attach-sources
>
>jar-no-fork
>
>
>
> {code}
> {{java.lang.Thread.State: RUNNABLE}}
> {{ at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)}}
> {{ at
> sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)}}
> {{ at
> sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)}}
> {{ - locked <0x0006b0773fd8> (a sun.nio.fs.UnixFileAttributes)}}
> {{ at
> sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)}}
> {{ at
> sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)}}
> {{ at
> sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)}}
> {{ at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)}}
> {{ at
> org.codehaus.plexus.components.io.attributes.Java7FileAttributes.(Java7FileAttributes.java:65)}}
> {{ at
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResourcesJava7(PlexusIoFileResourceCollection.java:192)}}
> {{ at
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:287)}}
> {{ at
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:504)}}
> {{ at
> org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:287)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSOURCES-119) Archiving to jar is very slow
[
https://issues.apache.org/jira/browse/MSOURCES-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686458#comment-16686458
]
Claes Nordmark commented on MSOURCES-119:
-
Ive made a test with [https://github.com/ThomasJaspers/java-junit-sample]
project.
I just added this in the pom.xml:
{code:java}
org.apache.maven.plugins
maven-javadoc-plugin
${maven.javadoc.plugin.version}
attach-javadocs
jar
false
org.apache.maven.plugins
maven-source-plugin
${maven.source.plugin.version}
attach-sources
jar
org.apache.maven.plugins
maven-jar-plugin
${maven.jar.plugin.version}
true
true
{code}
with new versions of maven plugins I get:
{code:java}
1.8
1.8
3.0.0
3.0.1
3.1.0 {code}
[INFO] Building jar: /test-project/target/my-app-1.0-SNAPSHOT-sources.jar
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 44.479 s
[INFO] Finished at: 2018-11-14T13:22:46+01:00
[INFO] Final Memory: 33M/597M
[INFO]
and with old:
{code:java}
1.8
1.8
2.4
2.10.1
2.6 {code}
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 11.710 s
[INFO] Finished at: 2018-11-14T13:25:28+01:00
[INFO] Final Memory: 40M/482M
[INFO]
> Archiving to jar is very slow
> -
>
> Key: MSOURCES-119
> URL: https://issues.apache.org/jira/browse/MSOURCES-119
> Project: Maven Source Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: RedHat 7
>Reporter: Claes Nordmark
>Priority: Major
>
> Doing a stackdump while "maven-source-plugin:3.0.0:jar-no-fork
> (attach-sources)" shows thread spending a lot of time in
> UnixNativeDispatcher.getgrgid.
> This was not visible in java 8 and source plugin version 2.4.
> Our previous build time has been increased from 5min to 3h 30min.
> Tested version Java 11 and 3.0.0 of maven-source-plugin
> maven config:
> {code:java}
>
> org.apache.maven.plugins
> maven-source-plugin
> 3.0.0
>
>
> attach-sources
>
>jar-no-fork
>
>
>
> {code}
> {{java.lang.Thread.State: RUNNABLE}}
> {{ at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)}}
> {{ at
> sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)}}
> {{ at
> sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)}}
> {{ - locked <0x0006b0773fd8> (a sun.nio.fs.UnixFileAttributes)}}
> {{ at
> sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)}}
> {{ at
> sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)}}
> {{ at
> sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)}}
> {{ at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)}}
> {{ at
> org.codehaus.plexus.components.io.attributes.Java7FileAttributes.(Java7FileAttributes.java:65)}}
> {{ at
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResourcesJava7(PlexusIoFileResourceCollection.java:192)}}
> {{ at
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:287)}}
> {{ at
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:504)}}
> {{ at
> org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:287)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MSOURCES-119) Archiving to jar is very slow
[
https://issues.apache.org/jira/browse/MSOURCES-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686408#comment-16686408
]
Claes Nordmark edited comment on MSOURCES-119 at 11/14/18 11:47 AM:
I've checked and java version seems to be irrelevant at least. Tried with both
java 8 and java 11.
Different maven versions have been tested as well, 3.2.1 and 3.5.4.
I've raised another ticket on plexus archiver, which could be something to take
as input:
[https://github.com/codehaus-plexus/plexus-archiver/issues/105]
maven is run like this: "mvn package -Dmaven.skip.test=true"
was (Author: nordmcla):
I've checked and java version seems to be irrelevant at least. Tried with both
java 8 and java 11.
Different maven versions have been tested as well, 3.2.1 and 3.5.4.
I've raised another ticket on plexus archiver, which could be something to take
as input:
[https://github.com/codehaus-plexus/plexus-archiver/issues/105]
> Archiving to jar is very slow
> -
>
> Key: MSOURCES-119
> URL: https://issues.apache.org/jira/browse/MSOURCES-119
> Project: Maven Source Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: RedHat 7
>Reporter: Claes Nordmark
>Priority: Major
>
> Doing a stackdump while "maven-source-plugin:3.0.0:jar-no-fork
> (attach-sources)" shows thread spending a lot of time in
> UnixNativeDispatcher.getgrgid.
> This was not visible in java 8 and source plugin version 2.4.
> Our previous build time has been increased from 5min to 3h 30min.
> Tested version Java 11 and 3.0.0 of maven-source-plugin
> maven config:
> {code:java}
>
> org.apache.maven.plugins
> maven-source-plugin
> 3.0.0
>
>
> attach-sources
>
>jar-no-fork
>
>
>
> {code}
> {{java.lang.Thread.State: RUNNABLE}}
> {{ at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)}}
> {{ at
> sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)}}
> {{ at
> sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)}}
> {{ - locked <0x0006b0773fd8> (a sun.nio.fs.UnixFileAttributes)}}
> {{ at
> sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)}}
> {{ at
> sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)}}
> {{ at
> sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)}}
> {{ at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)}}
> {{ at
> org.codehaus.plexus.components.io.attributes.Java7FileAttributes.(Java7FileAttributes.java:65)}}
> {{ at
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResourcesJava7(PlexusIoFileResourceCollection.java:192)}}
> {{ at
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:287)}}
> {{ at
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:504)}}
> {{ at
> org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:287)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSOURCES-119) Archiving to jar is very slow
[
https://issues.apache.org/jira/browse/MSOURCES-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686408#comment-16686408
]
Claes Nordmark commented on MSOURCES-119:
-
I've checked and java version seems to be irrelevant at least. Tried with both
java 8 and java 11.
Different maven versions have been tested as well, 3.2.1 and 3.5.4.
I've raised another ticket on plexus archiver, which could be something to take
as input:
[https://github.com/codehaus-plexus/plexus-archiver/issues/105]
> Archiving to jar is very slow
> -
>
> Key: MSOURCES-119
> URL: https://issues.apache.org/jira/browse/MSOURCES-119
> Project: Maven Source Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: RedHat 7
>Reporter: Claes Nordmark
>Priority: Major
>
> Doing a stackdump while "maven-source-plugin:3.0.0:jar-no-fork
> (attach-sources)" shows thread spending a lot of time in
> UnixNativeDispatcher.getgrgid.
> This was not visible in java 8 and source plugin version 2.4.
> Our previous build time has been increased from 5min to 3h 30min.
> Tested version Java 11 and 3.0.0 of maven-source-plugin
> maven config:
> {code:java}
>
> org.apache.maven.plugins
> maven-source-plugin
> 3.0.0
>
>
> attach-sources
>
>jar-no-fork
>
>
>
> {code}
> {{java.lang.Thread.State: RUNNABLE}}
> {{ at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)}}
> {{ at
> sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)}}
> {{ at
> sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)}}
> {{ - locked <0x0006b0773fd8> (a sun.nio.fs.UnixFileAttributes)}}
> {{ at
> sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)}}
> {{ at
> sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)}}
> {{ at
> sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)}}
> {{ at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)}}
> {{ at
> org.codehaus.plexus.components.io.attributes.Java7FileAttributes.(Java7FileAttributes.java:65)}}
> {{ at
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResourcesJava7(PlexusIoFileResourceCollection.java:192)}}
> {{ at
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:287)}}
> {{ at
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:504)}}
> {{ at
> org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:287)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-319) UTF-8 BOM in pom.xml breaks banDuplicatePomDependencyVersions rule
[
https://issues.apache.org/jira/browse/MENFORCER-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686382#comment-16686382
]
ASF GitHub Bot commented on MENFORCER-319:
--
wilx commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when parsing
pom.xml files
URL: https://github.com/apache/maven-enforcer/pull/45#issuecomment-438628257
[**@khmarbaise**](https://github.com/khmarbaise) commented on [14 Nov 2018,
00:59
CET](https://github.com/apache/maven-enforcer/pull/45#issuecomment-438485075
"2018-11-13T23:59:34Z - Replied by Github Reply Comments"):
> The patch looks good so far but unfortunately I don't see a test case for
that..
I have updated pom.xml of integration test of
banDuplicatePomDependencyVersions rule to be in UTF-8 BOM encoding.
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
> UTF-8 BOM in pom.xml breaks banDuplicatePomDependencyVersions rule
> --
>
> Key: MENFORCER-319
> URL: https://issues.apache.org/jira/browse/MENFORCER-319
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M2
>Reporter: Václav Haisman
>Priority: Major
> Attachments:
> Handle_parsing_of_pom_xml_in_BanDuplicatePomDependencyVersions_java_similarly_to_how_actua.patch,
> pom.xml
>
>
> Having UTF-8 BOM at the beginning of {{pom.xml}} causes the
> banDuplicatePomDependencyVersions rule to fail to parse the file with the
> following exception being shown by {{-X}} output:
> {noformat}
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Unable to retrieve
> the MavenProject:
> at
> org.apache.maven.plugins.enforcer.BanDuplicatePomDependencyVersions.execute
> (BanDuplicatePomDependencyVersions.java:87)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:194)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (Unknown Source)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (Unknown
> Source)
> at java.lang.reflect.Method.invoke (Unknown Source)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
> Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: only
> whitespace content allowed before start tag and not \uef (position:
> START_DOCUMENT seen \uef... @1:1)
> at org.codehaus.plexus.util.xml.pull.MXParser.parseProlog
> (MXParser.java:1862)
> at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl
> (MXParser.java:1698)
> at org.codehaus.plexus.util.xml.pull.MXParser.next (MXParser.java:1317)
> at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read
> (MavenXpp3Reader.java:3856)
> at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read
> (MavenXpp3Reader.java:595)
> at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read
>
[GitHub] wilx commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when parsing pom.xml files
wilx commented on issue #45: [MENFORCER-319] Handle UTF-8 BOM when parsing pom.xml files URL: https://github.com/apache/maven-enforcer/pull/45#issuecomment-438628257 [**@khmarbaise**](https://github.com/khmarbaise) commented on [14 Nov 2018, 00:59 CET](https://github.com/apache/maven-enforcer/pull/45#issuecomment-438485075 "2018-11-13T23:59:34Z - Replied by Github Reply Comments"): > The patch looks good so far but unfortunately I don't see a test case for that.. I have updated pom.xml of integration test of banDuplicatePomDependencyVersions rule to be in UTF-8 BOM encoding. 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] (MSOURCES-119) Archiving to jar is very slow
[
https://issues.apache.org/jira/browse/MSOURCES-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686304#comment-16686304
]
Karl Heinz Marbaise commented on MSOURCES-119:
--
Do you have an example project which shows the behaviour ? Can you also add
informations like which Maven version? Java Version? How you call Maven etc. ?
> Archiving to jar is very slow
> -
>
> Key: MSOURCES-119
> URL: https://issues.apache.org/jira/browse/MSOURCES-119
> Project: Maven Source Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: RedHat 7
>Reporter: Claes Nordmark
>Priority: Major
>
> Doing a stackdump while "maven-source-plugin:3.0.0:jar-no-fork
> (attach-sources)" shows thread spending a lot of time in
> UnixNativeDispatcher.getgrgid.
> This was not visible in java 8 and source plugin version 2.4.
> Our previous build time has been increased from 5min to 3h 30min.
> Tested version Java 11 and 3.0.0 of maven-source-plugin
> maven config:
> {code:java}
>
> org.apache.maven.plugins
> maven-source-plugin
> 3.0.0
>
>
> attach-sources
>
>jar-no-fork
>
>
>
> {code}
> {{java.lang.Thread.State: RUNNABLE}}
> {{ at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@11/Native Method)}}
> {{ at
> sun.nio.fs.UnixUserPrincipals.fromGid(java.base@11/UnixUserPrincipals.java:129)}}
> {{ at
> sun.nio.fs.UnixFileAttributes.group(java.base@11/UnixFileAttributes.java:208)}}
> {{ - locked <0x0006b0773fd8> (a sun.nio.fs.UnixFileAttributes)}}
> {{ at
> sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@11/UnixFileAttributeViews.java:214)}}
> {{ at
> sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@11/UnixFileAttributeViews.java:362)}}
> {{ at
> sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@11/AbstractFileSystemProvider.java:94)}}
> {{ at java.nio.file.Files.readAttributes(java.base@11/Files.java:1996)}}
> {{ at
> org.codehaus.plexus.components.io.attributes.Java7FileAttributes.(Java7FileAttributes.java:65)}}
> {{ at
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResourcesJava7(PlexusIoFileResourceCollection.java:192)}}
> {{ at
> org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:287)}}
> {{ at
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:504)}}
> {{ at
> org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:287)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
