[jira] [Commented] (MPLUGINTESTING-60) Referring to very old/alpha artifacts
[
https://issues.apache.org/jira/browse/MPLUGINTESTING-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591231#comment-16591231
]
Hervé Boutemy commented on MPLUGINTESTING-60:
-
updating plexus archiver makes sense
on plexus-container-default, it's about migrating from Plexus container
(1.0-alpha-9-stable-1 is stable, I don't know if there is a version really more
stable) to Sisu to match what Maven did when switching from Maven 2 to Maven 3
I'd prefer to have a separate "move from Plexus container to Sisu" issue for
plexus-container-default
> Referring to very old/alpha artifacts
> -
>
> Key: MPLUGINTESTING-60
> URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-60
> Project: Maven Plugin Testing
> Issue Type: Dependency upgrade
> Components: plugin-testing-harness
>Affects Versions: 3.3.0
>Reporter: Christian Stein
>Priority: Major
>
> {{...}}
> {{[INFO] +-
> org.apache.maven.plugin-testing:maven-plugin-testing-harness:jar:3.3.0:test}}
> {{[INFO] | - org.codehaus.plexus:plexus-archiver:jar:2.2:test}}
> {{[INFO] | +-
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:test}}
> {{[INFO] | | +- junit:junit:jar:3.8.1:test}}
> {{[INFO] | | - classworlds:classworlds:jar:1.1-alpha-2:test}}
> {{[INFO] | - org.codehaus.plexus:plexus-io:jar:2.0.4:test}}
> {{...}}
>
> This is really old stuff in the tree. An update from plexus-archiver:2.2 to
> 3.6.0 (?) would be great.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] cloorc commented on issue #52: add --cached option for git rm
cloorc commented on issue #52: add --cached option for git rm URL: https://github.com/apache/maven-scm/pull/52#issuecomment-415673868 Hi @michael-o , you are right. And I've already updated my PR. I thought scm should only remove paths from the index instead of removing these files definitely, which would result in file lost. Thanks for your patient. 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] (MRELEASE-933) maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
[
https://issues.apache.org/jira/browse/MRELEASE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591285#comment-16591285
]
Jesko Jochum commented on MRELEASE-933:
---
why is this still not fixed and why is the latest release almost 3 years old
(Oktober 2015)?
it seems like there is some quite recent activity in the project
[GitHub|https://github.com/apache/maven-release]/[Gitbox|https://gitbox.apache.org/repos/asf?p=maven-release.git]!?
> maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
> --
>
> Key: MRELEASE-933
> URL: https://issues.apache.org/jira/browse/MRELEASE-933
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Eric Leventhal Arthen
>Priority: Major
>
> We are also blocked from using {{maven-release-plugin:2.5:perform}} for Git
> releases because it no longer passes in the tag name so the "git clone" fails.
> This worked correctly in {{maven-release-plugin:2.3.2:perform}}, with that
> version we got a command like this:
> {noformat}
> git clone --branch my-base-1.4.6 git@bithub:abcde/fghij.git
> /home/buildacct/work/5f89075470257ef1/base/target/checkout
> {noformat}
> (Note that the name here is (correctly) a tag name created by
> release:prepare, even though it is passed to --branch.)
> With {{maven-release-plugin:2.5:perform}} it does not include the actual tag
> name after "--branch" so the command fails.
> {noformat}
> git clone --branch g...@bithub.brightcove.com:abcde/fghij.git
> /home/buildacct/work/7483cd6cc5ce81ea/target/checkout
>[ERROR] The git-clone command failed.
> {noformat}
> We have to downgrade to the older maven-release-plugin, 2.3.2. From the
> ticket below this also worked in 2.2.1. I have not tried other versions.
> Found a description of this problem in SCM-729 in a comment in Feb 2015, but
> are creating this ticket because the issue is a recently introduced bug and
> that ticket is a feature request for a different component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (WAGON-526) Make the retry handling of HttpClient configurable
[ https://issues.apache.org/jira/browse/WAGON-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-526: - Summary: Make the retry handling of HttpClient configurable (was: making the retry handle of http client configurable) > Make the retry handling of HttpClient configurable > -- > > Key: WAGON-526 > URL: https://issues.apache.org/jira/browse/WAGON-526 > Project: Maven Wagon > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.0 > > > Provide a way to customize a lot (until a custom impl) the way wagon retries > downloads. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] erikhakansson commented on a change in pull request #49: [MNG-2802] Concurrent-safe access to local Maven repository
erikhakansson commented on a change in pull request #49: [MNG-2802]
Concurrent-safe access to local Maven repository
URL: https://github.com/apache/maven-wagon/pull/49#discussion_r212562988
##
File path:
wagon-providers/wagon-file-test/src/main/java/org/apache/maven/wagon/providers/file/LazyLockableFileOutputStreamTestDriver.java
##
@@ -0,0 +1,75 @@
+package org.apache.maven.wagon.providers.file;
+
+/*
+ * 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.io.OutputStream;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Test driver for LazyLockableFileOutputStreamIntegrationTest
+ */
+public class LazyLockableFileOutputStreamTestDriver
+{
+public static void main( String[] args ) throws Exception
+{
+File file = new File( args[0] );
+long timeout = Long.parseLong( args[1] );
+long startTime = System.currentTimeMillis();
+OutputStream outputStream = new LazyLockableFileOutputStream( file,
timeout, TimeUnit.SECONDS );
+try
+{
+outputStream.write( 1 );
+}
+catch ( IOException e )
+{
+if ( e.getMessage().equals( "Can't write file, lock " +
file.getAbsolutePath() + ".lck exists" ) )
+{
+System.out.println( "ready" );
+// CHECKSTYLE_OFF: MagicNumber
+System.exit( 126 );
+// CHECKSTYLE_ON: MagicNumber
+}
+else if ( e.getMessage().equals( "Failed to create lockfile " +
file.getAbsolutePath()
++ ".lck after waiting " + timeout + " seconds. File
already exists." ) )
+{
+long diff = System.currentTimeMillis() - startTime;
+if ( diff < TimeUnit.SECONDS.toMillis( timeout ) )
+{
+throw new Exception( "We were supposed to wait for " +
timeout
++ " seconds, but Exception came early at " + diff
+ " milliseconds." );
+}
+System.out.println( "ready" );
+// CHECKSTYLE_OFF: MagicNumber
+System.exit( 127 );
Review comment:
ping @olamy
what do you think?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (MNG-2802) Concurrent-safe access to local Maven repository
[
https://issues.apache.org/jira/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591349#comment-16591349
]
ASF GitHub Bot commented on MNG-2802:
-
erikhakansson commented on a change in pull request #49: [MNG-2802]
Concurrent-safe access to local Maven repository
URL: https://github.com/apache/maven-wagon/pull/49#discussion_r212562988
##
File path:
wagon-providers/wagon-file-test/src/main/java/org/apache/maven/wagon/providers/file/LazyLockableFileOutputStreamTestDriver.java
##
@@ -0,0 +1,75 @@
+package org.apache.maven.wagon.providers.file;
+
+/*
+ * 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.io.OutputStream;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Test driver for LazyLockableFileOutputStreamIntegrationTest
+ */
+public class LazyLockableFileOutputStreamTestDriver
+{
+public static void main( String[] args ) throws Exception
+{
+File file = new File( args[0] );
+long timeout = Long.parseLong( args[1] );
+long startTime = System.currentTimeMillis();
+OutputStream outputStream = new LazyLockableFileOutputStream( file,
timeout, TimeUnit.SECONDS );
+try
+{
+outputStream.write( 1 );
+}
+catch ( IOException e )
+{
+if ( e.getMessage().equals( "Can't write file, lock " +
file.getAbsolutePath() + ".lck exists" ) )
+{
+System.out.println( "ready" );
+// CHECKSTYLE_OFF: MagicNumber
+System.exit( 126 );
+// CHECKSTYLE_ON: MagicNumber
+}
+else if ( e.getMessage().equals( "Failed to create lockfile " +
file.getAbsolutePath()
++ ".lck after waiting " + timeout + " seconds. File
already exists." ) )
+{
+long diff = System.currentTimeMillis() - startTime;
+if ( diff < TimeUnit.SECONDS.toMillis( timeout ) )
+{
+throw new Exception( "We were supposed to wait for " +
timeout
++ " seconds, but Exception came early at " + diff
+ " milliseconds." );
+}
+System.out.println( "ready" );
+// CHECKSTYLE_OFF: MagicNumber
+System.exit( 127 );
Review comment:
ping @olamy
what do you think?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Concurrent-safe access to local Maven repository
>
>
> Key: MNG-2802
> URL: https://issues.apache.org/jira/browse/MNG-2802
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: Stepan Roh
>Assignee: John Casey
>Priority: Major
> Fix For: Issues to be reviewed for 3.x
>
>
> It seems that access to local Maven repository is not concurrent-safe that is
> multiple Mavens running in parallel may damage contents of local Maven
> repository. It would be a nice improvement, because sharing of local
> repository will lower the need for contacting any other repository. I know
> that Maven proxy can be used, but that adds another layer which may
> unnecessarily stress the machine it runs on.
> *NOTE:*
> http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository is
> a Takari Extension for Apache Maven that introduces a concurrent-safe
> local-repository.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-933) maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
[
https://issues.apache.org/jira/browse/MRELEASE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591360#comment-16591360
]
Robert Scholte commented on MRELEASE-933:
-
bq. why is this still not fixed
AFAIK there's still no test to confirm this issue and there's no patch to fix
it.
bq. and why is the latest release almost 3 years old (Oktober 2015)?
This plugin seems in good condition, while a small team of volunteers is
working on one of the other 90+ subprojects of Maven.
bq. it seems like there is some quite recent activity in the project
GitHub/[Gitbox|https://gitbox.apache.org/repos/asf?p=maven-release.git]!?
Activities are mainly related to increasing coverage of OS/JDK/Maven
combinations and to fix support of Java 7.
I have started a redesign of the plugin, to make it more flexible. However,
other more important topics came by (Java9+, Maven 3.5.x) so I had to move that
aside.
In other words: any help is appreciated! See also
http://maven.apache.org/guides/development/guide-helping.html
> maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
> --
>
> Key: MRELEASE-933
> URL: https://issues.apache.org/jira/browse/MRELEASE-933
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Eric Leventhal Arthen
>Priority: Major
>
> We are also blocked from using {{maven-release-plugin:2.5:perform}} for Git
> releases because it no longer passes in the tag name so the "git clone" fails.
> This worked correctly in {{maven-release-plugin:2.3.2:perform}}, with that
> version we got a command like this:
> {noformat}
> git clone --branch my-base-1.4.6 git@bithub:abcde/fghij.git
> /home/buildacct/work/5f89075470257ef1/base/target/checkout
> {noformat}
> (Note that the name here is (correctly) a tag name created by
> release:prepare, even though it is passed to --branch.)
> With {{maven-release-plugin:2.5:perform}} it does not include the actual tag
> name after "--branch" so the command fails.
> {noformat}
> git clone --branch g...@bithub.brightcove.com:abcde/fghij.git
> /home/buildacct/work/7483cd6cc5ce81ea/target/checkout
>[ERROR] The git-clone command failed.
> {noformat}
> We have to downgrade to the older maven-release-plugin, 2.3.2. From the
> ticket below this also worked in 2.2.1. I have not tried other versions.
> Found a description of this problem in SCM-729 in a comment in Feb 2015, but
> are creating this ticket because the issue is a recently introduced bug and
> that ticket is a feature request for a different component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-933) maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
[
https://issues.apache.org/jira/browse/MRELEASE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591383#comment-16591383
]
Jesko Jochum commented on MRELEASE-933:
---
thanks for the quick response. apparently it is just a matter of changing the
superclass of PerformReleaseMojo.
it definitely works in version 2.3.2.
i will see whether i can fix this myself and contribute a patch to the project.
> maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
> --
>
> Key: MRELEASE-933
> URL: https://issues.apache.org/jira/browse/MRELEASE-933
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Eric Leventhal Arthen
>Priority: Major
>
> We are also blocked from using {{maven-release-plugin:2.5:perform}} for Git
> releases because it no longer passes in the tag name so the "git clone" fails.
> This worked correctly in {{maven-release-plugin:2.3.2:perform}}, with that
> version we got a command like this:
> {noformat}
> git clone --branch my-base-1.4.6 git@bithub:abcde/fghij.git
> /home/buildacct/work/5f89075470257ef1/base/target/checkout
> {noformat}
> (Note that the name here is (correctly) a tag name created by
> release:prepare, even though it is passed to --branch.)
> With {{maven-release-plugin:2.5:perform}} it does not include the actual tag
> name after "--branch" so the command fails.
> {noformat}
> git clone --branch g...@bithub.brightcove.com:abcde/fghij.git
> /home/buildacct/work/7483cd6cc5ce81ea/target/checkout
>[ERROR] The git-clone command failed.
> {noformat}
> We have to downgrade to the older maven-release-plugin, 2.3.2. From the
> ticket below this also worked in 2.2.1. I have not tried other versions.
> Found a description of this problem in SCM-729 in a comment in Feb 2015, but
> are creating this ticket because the issue is a recently introduced bug and
> that ticket is a feature request for a different component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MRELEASE-933) maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
[
https://issues.apache.org/jira/browse/MRELEASE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591383#comment-16591383
]
Jesko Jochum edited comment on MRELEASE-933 at 8/24/18 9:30 AM:
thanks for the quick response. apparently it is just a matter of changing the
superclass of
PerformReleaseMojo|https://issues.apache.org/jira/browse/SCM-729?focusedCommentId=14448351&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14448351].
it definitely works in version 2.3.2.
i will see whether i can fix this myself and contribute a patch to the project.
was (Author: jejo86):
thanks for the quick response. apparently it is just a matter of changing the
superclass of PerformReleaseMojo.
it definitely works in version 2.3.2.
i will see whether i can fix this myself and contribute a patch to the project.
> maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
> --
>
> Key: MRELEASE-933
> URL: https://issues.apache.org/jira/browse/MRELEASE-933
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Eric Leventhal Arthen
>Priority: Major
>
> We are also blocked from using {{maven-release-plugin:2.5:perform}} for Git
> releases because it no longer passes in the tag name so the "git clone" fails.
> This worked correctly in {{maven-release-plugin:2.3.2:perform}}, with that
> version we got a command like this:
> {noformat}
> git clone --branch my-base-1.4.6 git@bithub:abcde/fghij.git
> /home/buildacct/work/5f89075470257ef1/base/target/checkout
> {noformat}
> (Note that the name here is (correctly) a tag name created by
> release:prepare, even though it is passed to --branch.)
> With {{maven-release-plugin:2.5:perform}} it does not include the actual tag
> name after "--branch" so the command fails.
> {noformat}
> git clone --branch g...@bithub.brightcove.com:abcde/fghij.git
> /home/buildacct/work/7483cd6cc5ce81ea/target/checkout
>[ERROR] The git-clone command failed.
> {noformat}
> We have to downgrade to the older maven-release-plugin, 2.3.2. From the
> ticket below this also worked in 2.2.1. I have not tried other versions.
> Found a description of this problem in SCM-729 in a comment in Feb 2015, but
> are creating this ticket because the issue is a recently introduced bug and
> that ticket is a feature request for a different component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MRELEASE-933) maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
[
https://issues.apache.org/jira/browse/MRELEASE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591383#comment-16591383
]
Jesko Jochum edited comment on MRELEASE-933 at 8/24/18 9:30 AM:
thanks for the quick response. apparently it is just a matter of [changing the
superclass of
PerformReleaseMojo|https://issues.apache.org/jira/browse/SCM-729?focusedCommentId=14448351&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14448351].
it definitely works in version 2.3.2.
i will see whether i can fix this myself and contribute a patch to the project.
was (Author: jejo86):
thanks for the quick response. apparently it is just a matter of changing the
superclass of
PerformReleaseMojo|https://issues.apache.org/jira/browse/SCM-729?focusedCommentId=14448351&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14448351].
it definitely works in version 2.3.2.
i will see whether i can fix this myself and contribute a patch to the project.
> maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
> --
>
> Key: MRELEASE-933
> URL: https://issues.apache.org/jira/browse/MRELEASE-933
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Eric Leventhal Arthen
>Priority: Major
>
> We are also blocked from using {{maven-release-plugin:2.5:perform}} for Git
> releases because it no longer passes in the tag name so the "git clone" fails.
> This worked correctly in {{maven-release-plugin:2.3.2:perform}}, with that
> version we got a command like this:
> {noformat}
> git clone --branch my-base-1.4.6 git@bithub:abcde/fghij.git
> /home/buildacct/work/5f89075470257ef1/base/target/checkout
> {noformat}
> (Note that the name here is (correctly) a tag name created by
> release:prepare, even though it is passed to --branch.)
> With {{maven-release-plugin:2.5:perform}} it does not include the actual tag
> name after "--branch" so the command fails.
> {noformat}
> git clone --branch g...@bithub.brightcove.com:abcde/fghij.git
> /home/buildacct/work/7483cd6cc5ce81ea/target/checkout
>[ERROR] The git-clone command failed.
> {noformat}
> We have to downgrade to the older maven-release-plugin, 2.3.2. From the
> ticket below this also worked in 2.2.1. I have not tried other versions.
> Found a description of this problem in SCM-729 in a comment in Feb 2015, but
> are creating this ticket because the issue is a recently introduced bug and
> that ticket is a feature request for a different component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-933) maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
[
https://issues.apache.org/jira/browse/MRELEASE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591399#comment-16591399
]
Robert Scholte commented on MRELEASE-933:
-
Changing the superclass is the quick and dirty workaround. Keep in mind:
{{prepare}} is about scm, {{perform}} is about deliverables. The real issue has
to do with merging configuration. This has already changed a lot on master, so
should be easier to fix (if it hasn't been fixed yet)
> maven-release-plugin:perform from a tag is broken for Git in version 2.5.3
> --
>
> Key: MRELEASE-933
> URL: https://issues.apache.org/jira/browse/MRELEASE-933
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Eric Leventhal Arthen
>Priority: Major
>
> We are also blocked from using {{maven-release-plugin:2.5:perform}} for Git
> releases because it no longer passes in the tag name so the "git clone" fails.
> This worked correctly in {{maven-release-plugin:2.3.2:perform}}, with that
> version we got a command like this:
> {noformat}
> git clone --branch my-base-1.4.6 git@bithub:abcde/fghij.git
> /home/buildacct/work/5f89075470257ef1/base/target/checkout
> {noformat}
> (Note that the name here is (correctly) a tag name created by
> release:prepare, even though it is passed to --branch.)
> With {{maven-release-plugin:2.5:perform}} it does not include the actual tag
> name after "--branch" so the command fails.
> {noformat}
> git clone --branch g...@bithub.brightcove.com:abcde/fghij.git
> /home/buildacct/work/7483cd6cc5ce81ea/target/checkout
>[ERROR] The git-clone command failed.
> {noformat}
> We have to downgrade to the older maven-release-plugin, 2.3.2. From the
> ticket below this also worked in 2.2.1. I have not tried other versions.
> Found a description of this problem in SCM-729 in a comment in Feb 2015, but
> are creating this ticket because the issue is a recently introduced bug and
> that ticket is a feature request for a different component.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6442) Run tests with Maven on pre-compiled project
[
https://issues.apache.org/jira/browse/MNG-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591476#comment-16591476
]
Lasse Westh-Nielsen commented on MNG-6442:
--
Hey Karl Heinz,
We already use a VCS: [https://github.com/neo4j/neo4j]
Compiling from same sources is one thing, but we want to ensure the artifacts
we produce come from one specific JDK, have tests run on a bunch of platforms/
JDKs/ version, and then shipped to users. If you are doing things differently,
good luck to you - we have in past spotted problems using our approach ;)
So never mind the qualifications, what I am after is just running tests using
these artifacts. I realise it is an exotic use case, I am just wondering if it
is even possible? Maven tooling will of course make assumptions about workflow
but I am surprised no one has never done this before.
> Run tests with Maven on pre-compiled project
>
>
> Key: MNG-6442
> URL: https://issues.apache.org/jira/browse/MNG-6442
> Project: Maven
> Issue Type: Wish
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.5.2
> Environment: Linux, Windows
>Reporter: Lasse Westh-Nielsen
>Priority: Minor
>
> Hello,
> This is not so much a bug as it is a support request. The mailing list link
> was out of order. Please do triage into the right category.
> I tried my luck on Stack Overflow
> (https://stackoverflow.com/questions/51079816/run-tests-with-maven-on-pre-compiled-project),
> but got nothing, and I really need some direction.
> Here is what I wrote on SO:
> _Using Maven, I want to run unit and integration tests on a pre-compiled/
> pre-jar'ed multi-module project. I am finding this exceedingly difficult._
> _My business case is, I want to compile and jar up a multi-module Maven
> project in one place, and then have the unit test and integration tests run
> using different Java versions and on different operating systems, to check
> for compatibility. Let's just say \{Java 8, Java 10} x \{Ubuntu, Windows} to
> keep it simple._
> _The reason I want to compile and jar up in one pace is, I want to ensure
> that I run tests on the actual code getting shipped. If I re-compiled
> everywhere I fear I might introduce errors unwittingly._
> _One solution is to do {{mvn deploy -DaltDeploymentRepository=$mydir}} on
> Ubuntu to produce a compiled project tree and a directory full of jars; then
> zipping up the project tree and deploy directory and shipping them off to a
> Windows machine; and there running {{mvn surefire:test
> -Dmaven.repo.local=$mydir}} on the project tree._
> _That works but it is hella clumsy. Surefire seems to read the test classes
> in the project tree and use the classes in the same project + jar
> dependencies from the deployment repo to link against. A problem there is,
> with {{-Dmaven.repo.local}} Maven needs to download all 3rd party
> dependencies again because that repo only contains my project artifacts. So a
> solid solution, but not great._
> _Instead what I have been trying to do is, just use the compiled project
> tree:_
> * _If I just do {{mvn surefire:test}} I get problems resolving dependencies_
> * _I have tried {{mvn compile -Dmaven.main.skip surefire:test}} to fix
> dependency resolution, which seems to work - just not for test dependencies_
> * _I further tried {{mvn compile -Dmaven.main.skip test-compile
> -Dmaven.test.skip surefire:test}}, but for some reason that also does not
> work, the build again fails trying to resolve test dependencies._
> _Interestingly, it is not deterministic, the failures happen at different
> stages and sometimes not at all - I get the occasional green build!_
> _And now I am at my wits' end: I keep thinking this should be simple, and
> that I can't possible be the first person struggling with this simple
> problem._
> _It is opaque to me what happens with the reactor, when and how it triggers.
> The dependency graph must have been well-formed, or it couldn't compile. So
> why can I not get Maven to reproduce the same dependency graph for running
> tests?_
> Further to that:
> * I tried installing artifacts in cache using `mvn install:install`, that
> didn't work
> * I tried `mvn install` but was unable to get it to _not_ re-compile and
> re-jar my artifacts
> * I have tried simply copying files as a way to install my artifacts on
> machines
> Current status is, copying files manually to ~/.m2/repository is most
> promising, it seems to work on Linux. However, it does not work on Windows,
> I'm still trying to figure out why - line endings perhaps, the artifacts come
> from a Linux machine. The problem is artifact lookup.
> Anyway, going back to first principles: what's the recommended way to achieve
> _running tests with
[GitHub] Tibor17 commented on a change in pull request #112: Adding support for externally passed random seed and printing used seed on console
Tibor17 commented on a change in pull request #112: Adding support for
externally passed random seed and printing used seed on console
URL: https://github.com/apache/maven-surefire/pull/112#discussion_r212600811
##
File path:
surefire-its/src/test/resources/testng-parallel-suites/src/test/java/testng/suiteXml/TestNGSuiteTest.java
##
@@ -28,16 +28,23 @@
* @author mailto:tibordig...@apache.org";>Tibor Digana (tibor17)
* @since 2.19
*/
-public class TestNGSuiteTest {
- private static final AtomicInteger counter = new AtomicInteger();
+public class TestNGSuiteTest
+{
+private static final AtomicInteger counter = new AtomicInteger();
- @Test
- public void shouldRunAndPrintItself()
- throws Exception
- {
- System.out.println( getClass().getSimpleName() +
"#shouldRunAndPrintItself() "
- +
counter.incrementAndGet() + ".");
+@Test
+public void shouldRunAndPrintItself() throws Exception
+{
+String message = String.format(
+"%s#shouldRunAndPrintItself() %d.",
+getClass().getSimpleName(),
+counter.incrementAndGet()
+);
+TimeUnit.SECONDS.sleep( 1 );
- TimeUnit.SECONDS.sleep( 2 );
- }
+synchronized ( System.out )
Review comment:
@cardil
Thx for pointing out the synchronization issue with `System.out`.
I have noticed the same problem yesterday, see
https://github.com/cbeust/testng/issues/1908
Treating the stream in test would fix our builds but we still have this
issue on Ubuntu and not on Windows. Does it mean that the Sysout should be
synchronized in the application run? We are setting the delegate via
`System.setOut()` and the delegate in `ForkingRunListener` is synchronized. Why
we do not see same issue in JUnit tests?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (MNG-6442) Run tests with Maven on pre-compiled project
[
https://issues.apache.org/jira/browse/MNG-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591523#comment-16591523
]
Robert Scholte commented on MNG-6442:
-
I agree that the CI server is the preferred solution here. But did you try to
create a new project without main sourcefiles, only with the tests? Add a
dependency to the jar you want to test and run {{mvn verify}}?
> Run tests with Maven on pre-compiled project
>
>
> Key: MNG-6442
> URL: https://issues.apache.org/jira/browse/MNG-6442
> Project: Maven
> Issue Type: Wish
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.5.2
> Environment: Linux, Windows
>Reporter: Lasse Westh-Nielsen
>Priority: Minor
>
> Hello,
> This is not so much a bug as it is a support request. The mailing list link
> was out of order. Please do triage into the right category.
> I tried my luck on Stack Overflow
> (https://stackoverflow.com/questions/51079816/run-tests-with-maven-on-pre-compiled-project),
> but got nothing, and I really need some direction.
> Here is what I wrote on SO:
> _Using Maven, I want to run unit and integration tests on a pre-compiled/
> pre-jar'ed multi-module project. I am finding this exceedingly difficult._
> _My business case is, I want to compile and jar up a multi-module Maven
> project in one place, and then have the unit test and integration tests run
> using different Java versions and on different operating systems, to check
> for compatibility. Let's just say \{Java 8, Java 10} x \{Ubuntu, Windows} to
> keep it simple._
> _The reason I want to compile and jar up in one pace is, I want to ensure
> that I run tests on the actual code getting shipped. If I re-compiled
> everywhere I fear I might introduce errors unwittingly._
> _One solution is to do {{mvn deploy -DaltDeploymentRepository=$mydir}} on
> Ubuntu to produce a compiled project tree and a directory full of jars; then
> zipping up the project tree and deploy directory and shipping them off to a
> Windows machine; and there running {{mvn surefire:test
> -Dmaven.repo.local=$mydir}} on the project tree._
> _That works but it is hella clumsy. Surefire seems to read the test classes
> in the project tree and use the classes in the same project + jar
> dependencies from the deployment repo to link against. A problem there is,
> with {{-Dmaven.repo.local}} Maven needs to download all 3rd party
> dependencies again because that repo only contains my project artifacts. So a
> solid solution, but not great._
> _Instead what I have been trying to do is, just use the compiled project
> tree:_
> * _If I just do {{mvn surefire:test}} I get problems resolving dependencies_
> * _I have tried {{mvn compile -Dmaven.main.skip surefire:test}} to fix
> dependency resolution, which seems to work - just not for test dependencies_
> * _I further tried {{mvn compile -Dmaven.main.skip test-compile
> -Dmaven.test.skip surefire:test}}, but for some reason that also does not
> work, the build again fails trying to resolve test dependencies._
> _Interestingly, it is not deterministic, the failures happen at different
> stages and sometimes not at all - I get the occasional green build!_
> _And now I am at my wits' end: I keep thinking this should be simple, and
> that I can't possible be the first person struggling with this simple
> problem._
> _It is opaque to me what happens with the reactor, when and how it triggers.
> The dependency graph must have been well-formed, or it couldn't compile. So
> why can I not get Maven to reproduce the same dependency graph for running
> tests?_
> Further to that:
> * I tried installing artifacts in cache using `mvn install:install`, that
> didn't work
> * I tried `mvn install` but was unable to get it to _not_ re-compile and
> re-jar my artifacts
> * I have tried simply copying files as a way to install my artifacts on
> machines
> Current status is, copying files manually to ~/.m2/repository is most
> promising, it seems to work on Linux. However, it does not work on Windows,
> I'm still trying to figure out why - line endings perhaps, the artifacts come
> from a Linux machine. The problem is artifact lookup.
> Anyway, going back to first principles: what's the recommended way to achieve
> _running tests with Maven on pre-compiled project_? I'm hoping someone has
> solved this before...
> Regards,
> Lasse
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6462) Add. DS_Store to .gitignore
Elliotte Rusty Harold created MNG-6462: -- Summary: Add. DS_Store to .gitignore Key: MNG-6462 URL: https://issues.apache.org/jira/browse/MNG-6462 Project: Maven Issue Type: Improvement Components: General Affects Versions: 3.5.4 Environment: Mac Reporter: Elliotte Rusty Harold Useful for devs who use Macs: Untracked files: (use "git add ..." to include in what will be committed) .DS_Store content/.DS_Store content/odt/.DS_Store content/resources/.DS_Store content/xdoc/.DS_Store -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6463) Copy edit and rewrite the docs
Elliotte Rusty Harold created MNG-6463: -- Summary: Copy edit and rewrite the docs Key: MNG-6463 URL: https://issues.apache.org/jira/browse/MNG-6463 Project: Maven Issue Type: Improvement Components: Documentation: Guides Reporter: Elliotte Rusty Harold Catch-all issue for editing and improvement -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6463) Copy edit and rewrite the docs
[ https://issues.apache.org/jira/browse/MNG-6463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MNG-6463: --- Attachment: MNG-6463-edit-guide-maven-development.patch > Copy edit and rewrite the docs > -- > > Key: MNG-6463 > URL: https://issues.apache.org/jira/browse/MNG-6463 > Project: Maven > Issue Type: Improvement > Components: Documentation: Guides >Reporter: Elliotte Rusty Harold >Priority: Major > Attachments: MNG-6463-edit-guide-maven-development.patch > > > Catch-all issue for editing and improvement -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6463) Copy edit and rewrite the docs
[ https://issues.apache.org/jira/browse/MNG-6463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591544#comment-16591544 ] Elliotte Rusty Harold commented on MNG-6463: Assorted edits for grammar and clarity on https://maven.apache.org/guides/development/guide-maven-development.html [^MNG-6463-edit-guide-maven-development.patch] > Copy edit and rewrite the docs > -- > > Key: MNG-6463 > URL: https://issues.apache.org/jira/browse/MNG-6463 > Project: Maven > Issue Type: Improvement > Components: Documentation: Guides >Reporter: Elliotte Rusty Harold >Priority: Major > Attachments: MNG-6463-edit-guide-maven-development.patch > > > Catch-all issue for editing and improvement -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6464) RAT checks failing in site
Elliotte Rusty Harold created MNG-6464: -- Summary: RAT checks failing in site Key: MNG-6464 URL: https://issues.apache.org/jira/browse/MNG-6464 Project: Maven Issue Type: Bug Components: Documentation: General Affects Versions: 3.5.4 Reporter: Elliotte Rusty Harold 1. Clone https://gitbox.apache.org/repos/asf/maven-site.git 2. Run mvn test: [ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.12:check (rat-check) on project maven-site: Too many files with unapproved license: 100 See RAT report in: /Users/elharo/maven-site/target/rat.txt -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6463) Copy edit and rewrite the docs
[ https://issues.apache.org/jira/browse/MNG-6463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591546#comment-16591546 ] Robert Scholte commented on MNG-6463: - Hi Elliotte, could you use the edit-button on these pages? It's in the top navigation bar, behind the title of the page (there's a small icon). > Copy edit and rewrite the docs > -- > > Key: MNG-6463 > URL: https://issues.apache.org/jira/browse/MNG-6463 > Project: Maven > Issue Type: Improvement > Components: Documentation: Guides >Reporter: Elliotte Rusty Harold >Priority: Major > Attachments: MNG-6463-edit-guide-maven-development.patch > > > Catch-all issue for editing and improvement -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6465) Artifact download failures
Lasse Westh-Nielsen created MNG-6465: Summary: Artifact download failures Key: MNG-6465 URL: https://issues.apache.org/jira/browse/MNG-6465 Project: Maven Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.5.0 Environment: Windows, Ubuntu Reporter: Lasse Westh-Nielsen Hey, We often run Maven builds of [https://github.com/neo4j/neo4j] on machines with cold caches/ empty ~/.m2/repository folders. There are rather a lot of dependencies to download, so even though the failure rate of individual artifact downloads is small, at our scale it causes significant build failures. I am working on seeding caches. Separately though it would be great to be able to configure retries and timeouts for dependency downloads - optimise for build throughput rather than latency as it were. How do I do that? I can't find it documented anywhere, and trying to browse "wagon" source code got me nowhere. Regards, Lasse -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6465) Artifact download failures
[
https://issues.apache.org/jira/browse/MNG-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591559#comment-16591559
]
Robert Scholte commented on MNG-6465:
-
It is onclear what you mean by "machines" and if you have enough control.
First thing that comes to my mind: consider using a [repository
manager|https://maven.apache.org/repository-management.html], which makes it
much easier to control these kind of settings.
If machine is a build server, try adding the following option by default:
{{-C,--strict-checksums Fail the build if checksums don't
match}}
This will at least fail the build fast.
> Artifact download failures
> --
>
> Key: MNG-6465
> URL: https://issues.apache.org/jira/browse/MNG-6465
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.0
> Environment: Windows, Ubuntu
>Reporter: Lasse Westh-Nielsen
>Priority: Major
>
> Hey,
> We often run Maven builds of [https://github.com/neo4j/neo4j] on machines
> with cold caches/ empty ~/.m2/repository folders.
> There are rather a lot of dependencies to download, so even though the
> failure rate of individual artifact downloads is small, at our scale it
> causes significant build failures.
> I am working on seeding caches. Separately though it would be great to be
> able to configure retries and timeouts for dependency downloads - optimise
> for build throughput rather than latency as it were.
> How do I do that? I can't find it documented anywhere, and trying to browse
> "wagon" source code got me nowhere.
> Regards,
> Lasse
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6466) Fix documentation edit instructions
Elliotte Rusty Harold created MNG-6466: -- Summary: Fix documentation edit instructions Key: MNG-6466 URL: https://issues.apache.org/jira/browse/MNG-6466 Project: Maven Issue Type: Bug Components: Documentation: General Reporter: Elliotte Rusty Harold https://maven.apache.org/scm.html and https://maven.apache.org/guides/development/guide-maven-development.html to include instructions on how to edit the site, which is apparently different than how to work on the rest of the code. I.e. press the edit button and use github to create a PR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6442) Run tests with Maven on pre-compiled project
[
https://issues.apache.org/jira/browse/MNG-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591561#comment-16591561
]
Lasse Westh-Nielsen commented on MNG-6442:
--
[~rfscholte] we use TeamCity for CI, with first step being artifact production,
and subsequent steps being running tests on a variety of machines/ operating
systems/ JDKs/ Java versions/ ...
As for taking a project, deleting src/main/java/*, running `mvn verify`: gets
me a compilation failure, i.e. Maven expects to resolve class files in
target/classes for stuff that's in same module.
> Run tests with Maven on pre-compiled project
>
>
> Key: MNG-6442
> URL: https://issues.apache.org/jira/browse/MNG-6442
> Project: Maven
> Issue Type: Wish
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.5.2
> Environment: Linux, Windows
>Reporter: Lasse Westh-Nielsen
>Priority: Minor
>
> Hello,
> This is not so much a bug as it is a support request. The mailing list link
> was out of order. Please do triage into the right category.
> I tried my luck on Stack Overflow
> (https://stackoverflow.com/questions/51079816/run-tests-with-maven-on-pre-compiled-project),
> but got nothing, and I really need some direction.
> Here is what I wrote on SO:
> _Using Maven, I want to run unit and integration tests on a pre-compiled/
> pre-jar'ed multi-module project. I am finding this exceedingly difficult._
> _My business case is, I want to compile and jar up a multi-module Maven
> project in one place, and then have the unit test and integration tests run
> using different Java versions and on different operating systems, to check
> for compatibility. Let's just say \{Java 8, Java 10} x \{Ubuntu, Windows} to
> keep it simple._
> _The reason I want to compile and jar up in one pace is, I want to ensure
> that I run tests on the actual code getting shipped. If I re-compiled
> everywhere I fear I might introduce errors unwittingly._
> _One solution is to do {{mvn deploy -DaltDeploymentRepository=$mydir}} on
> Ubuntu to produce a compiled project tree and a directory full of jars; then
> zipping up the project tree and deploy directory and shipping them off to a
> Windows machine; and there running {{mvn surefire:test
> -Dmaven.repo.local=$mydir}} on the project tree._
> _That works but it is hella clumsy. Surefire seems to read the test classes
> in the project tree and use the classes in the same project + jar
> dependencies from the deployment repo to link against. A problem there is,
> with {{-Dmaven.repo.local}} Maven needs to download all 3rd party
> dependencies again because that repo only contains my project artifacts. So a
> solid solution, but not great._
> _Instead what I have been trying to do is, just use the compiled project
> tree:_
> * _If I just do {{mvn surefire:test}} I get problems resolving dependencies_
> * _I have tried {{mvn compile -Dmaven.main.skip surefire:test}} to fix
> dependency resolution, which seems to work - just not for test dependencies_
> * _I further tried {{mvn compile -Dmaven.main.skip test-compile
> -Dmaven.test.skip surefire:test}}, but for some reason that also does not
> work, the build again fails trying to resolve test dependencies._
> _Interestingly, it is not deterministic, the failures happen at different
> stages and sometimes not at all - I get the occasional green build!_
> _And now I am at my wits' end: I keep thinking this should be simple, and
> that I can't possible be the first person struggling with this simple
> problem._
> _It is opaque to me what happens with the reactor, when and how it triggers.
> The dependency graph must have been well-formed, or it couldn't compile. So
> why can I not get Maven to reproduce the same dependency graph for running
> tests?_
> Further to that:
> * I tried installing artifacts in cache using `mvn install:install`, that
> didn't work
> * I tried `mvn install` but was unable to get it to _not_ re-compile and
> re-jar my artifacts
> * I have tried simply copying files as a way to install my artifacts on
> machines
> Current status is, copying files manually to ~/.m2/repository is most
> promising, it seems to work on Linux. However, it does not work on Windows,
> I'm still trying to figure out why - line endings perhaps, the artifacts come
> from a Linux machine. The problem is artifact lookup.
> Anyway, going back to first principles: what's the recommended way to achieve
> _running tests with Maven on pre-compiled project_? I'm hoping someone has
> solved this before...
> Regards,
> Lasse
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6463) Copy edit and rewrite the docs
[ https://issues.apache.org/jira/browse/MNG-6463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591563#comment-16591563 ] Elliotte Rusty Harold commented on MNG-6463: Done. Also filed MNG-6465 to include these instructions in the docs. > Copy edit and rewrite the docs > -- > > Key: MNG-6463 > URL: https://issues.apache.org/jira/browse/MNG-6463 > Project: Maven > Issue Type: Improvement > Components: Documentation: Guides >Reporter: Elliotte Rusty Harold >Priority: Major > Attachments: MNG-6463-edit-guide-maven-development.patch > > > Catch-all issue for editing and improvement -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] joergsesterhenn opened a new pull request #1: (doc) fix page title: help -> ejb
joergsesterhenn opened a new pull request #1: (doc) fix page title: help -> ejb URL: https://github.com/apache/maven-ejb-plugin/pull/1 see title 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] (MNG-6465) Artifact download failures
[ https://issues.apache.org/jira/browse/MNG-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591568#comment-16591568 ] Lasse Westh-Nielsen commented on MNG-6465: -- [~rfscholte] I am using a repository manager - Maven Central. I am just downloading things via HTTP from Maven Central, nothing exotic. I don't see what checksums would help with. The HTTP downloads fail with e.g. status code 502. There _seems_ to be retries - I mean it is bog standard HTTP stuff innit. I just want to have extra many retries and maybe longer timeouts because I know my problem domain: that intermittent HTTP downloads failing cause my builds to fail. > Artifact download failures > -- > > Key: MNG-6465 > URL: https://issues.apache.org/jira/browse/MNG-6465 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.5.0 > Environment: Windows, Ubuntu >Reporter: Lasse Westh-Nielsen >Priority: Major > > Hey, > We often run Maven builds of [https://github.com/neo4j/neo4j] on machines > with cold caches/ empty ~/.m2/repository folders. > There are rather a lot of dependencies to download, so even though the > failure rate of individual artifact downloads is small, at our scale it > causes significant build failures. > I am working on seeding caches. Separately though it would be great to be > able to configure retries and timeouts for dependency downloads - optimise > for build throughput rather than latency as it were. > How do I do that? I can't find it documented anywhere, and trying to browse > "wagon" source code got me nowhere. > Regards, > Lasse > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6442) Run tests with Maven on pre-compiled project
[
https://issues.apache.org/jira/browse/MNG-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591572#comment-16591572
]
Robert Scholte commented on MNG-6442:
-
So the lifecycle of TeamCity CI is the challenge here...
Is a setup like this possible:
- /neo4j
- /neo4j-its
During the artifact-production you run {{mvn deploy -f neo4j/pom.xml}}, and
during testing you run {{mvn deploy -f neo4j-its/pom.xml}}, which has a
dependency on neo4j.
> Run tests with Maven on pre-compiled project
>
>
> Key: MNG-6442
> URL: https://issues.apache.org/jira/browse/MNG-6442
> Project: Maven
> Issue Type: Wish
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.5.2
> Environment: Linux, Windows
>Reporter: Lasse Westh-Nielsen
>Priority: Minor
>
> Hello,
> This is not so much a bug as it is a support request. The mailing list link
> was out of order. Please do triage into the right category.
> I tried my luck on Stack Overflow
> (https://stackoverflow.com/questions/51079816/run-tests-with-maven-on-pre-compiled-project),
> but got nothing, and I really need some direction.
> Here is what I wrote on SO:
> _Using Maven, I want to run unit and integration tests on a pre-compiled/
> pre-jar'ed multi-module project. I am finding this exceedingly difficult._
> _My business case is, I want to compile and jar up a multi-module Maven
> project in one place, and then have the unit test and integration tests run
> using different Java versions and on different operating systems, to check
> for compatibility. Let's just say \{Java 8, Java 10} x \{Ubuntu, Windows} to
> keep it simple._
> _The reason I want to compile and jar up in one pace is, I want to ensure
> that I run tests on the actual code getting shipped. If I re-compiled
> everywhere I fear I might introduce errors unwittingly._
> _One solution is to do {{mvn deploy -DaltDeploymentRepository=$mydir}} on
> Ubuntu to produce a compiled project tree and a directory full of jars; then
> zipping up the project tree and deploy directory and shipping them off to a
> Windows machine; and there running {{mvn surefire:test
> -Dmaven.repo.local=$mydir}} on the project tree._
> _That works but it is hella clumsy. Surefire seems to read the test classes
> in the project tree and use the classes in the same project + jar
> dependencies from the deployment repo to link against. A problem there is,
> with {{-Dmaven.repo.local}} Maven needs to download all 3rd party
> dependencies again because that repo only contains my project artifacts. So a
> solid solution, but not great._
> _Instead what I have been trying to do is, just use the compiled project
> tree:_
> * _If I just do {{mvn surefire:test}} I get problems resolving dependencies_
> * _I have tried {{mvn compile -Dmaven.main.skip surefire:test}} to fix
> dependency resolution, which seems to work - just not for test dependencies_
> * _I further tried {{mvn compile -Dmaven.main.skip test-compile
> -Dmaven.test.skip surefire:test}}, but for some reason that also does not
> work, the build again fails trying to resolve test dependencies._
> _Interestingly, it is not deterministic, the failures happen at different
> stages and sometimes not at all - I get the occasional green build!_
> _And now I am at my wits' end: I keep thinking this should be simple, and
> that I can't possible be the first person struggling with this simple
> problem._
> _It is opaque to me what happens with the reactor, when and how it triggers.
> The dependency graph must have been well-formed, or it couldn't compile. So
> why can I not get Maven to reproduce the same dependency graph for running
> tests?_
> Further to that:
> * I tried installing artifacts in cache using `mvn install:install`, that
> didn't work
> * I tried `mvn install` but was unable to get it to _not_ re-compile and
> re-jar my artifacts
> * I have tried simply copying files as a way to install my artifacts on
> machines
> Current status is, copying files manually to ~/.m2/repository is most
> promising, it seems to work on Linux. However, it does not work on Windows,
> I'm still trying to figure out why - line endings perhaps, the artifacts come
> from a Linux machine. The problem is artifact lookup.
> Anyway, going back to first principles: what's the recommended way to achieve
> _running tests with Maven on pre-compiled project_? I'm hoping someone has
> solved this before...
> Regards,
> Lasse
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6465) Artifact download failures
[ https://issues.apache.org/jira/browse/MNG-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591577#comment-16591577 ] Robert Scholte commented on MNG-6465: - Maven Central it not *_your_* repository manager. I would expect an Archiva, Artifactory or Nexus, which is connected to Maven Central. This repository manager is installed within your infra and acts like the cache you are looking for. So your builds are not downloading direcly from Central anymore, but from this manager. > Artifact download failures > -- > > Key: MNG-6465 > URL: https://issues.apache.org/jira/browse/MNG-6465 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.5.0 > Environment: Windows, Ubuntu >Reporter: Lasse Westh-Nielsen >Priority: Major > > Hey, > We often run Maven builds of [https://github.com/neo4j/neo4j] on machines > with cold caches/ empty ~/.m2/repository folders. > There are rather a lot of dependencies to download, so even though the > failure rate of individual artifact downloads is small, at our scale it > causes significant build failures. > I am working on seeding caches. Separately though it would be great to be > able to configure retries and timeouts for dependency downloads - optimise > for build throughput rather than latency as it were. > How do I do that? I can't find it documented anywhere, and trying to browse > "wagon" source code got me nowhere. > Regards, > Lasse > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] rfscholte closed pull request #1: (doc) fix page title: help -> ejb
rfscholte closed pull request #1: (doc) fix page title: help -> ejb URL: https://github.com/apache/maven-ejb-plugin/pull/1 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/README.md b/README.md index 48c99c0..3985283 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ See the License for the specific language governing permissions and limitations under the License. --> -Contributing to Apache Maven Help Plugin +Contributing to Apache Maven EJB Plugin == [][license] 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] (MNG-6442) Run tests with Maven on pre-compiled project
[
https://issues.apache.org/jira/browse/MNG-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591583#comment-16591583
]
Lasse Westh-Nielsen commented on MNG-6442:
--
[~rfscholte] well that's just clumsy; I already have a clumsy solution. What I
am after is just a simple way of doing this "interrupted lifecycle",
effectively.
But thanks for the tip anyway.
> Run tests with Maven on pre-compiled project
>
>
> Key: MNG-6442
> URL: https://issues.apache.org/jira/browse/MNG-6442
> Project: Maven
> Issue Type: Wish
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.5.2
> Environment: Linux, Windows
>Reporter: Lasse Westh-Nielsen
>Priority: Minor
>
> Hello,
> This is not so much a bug as it is a support request. The mailing list link
> was out of order. Please do triage into the right category.
> I tried my luck on Stack Overflow
> (https://stackoverflow.com/questions/51079816/run-tests-with-maven-on-pre-compiled-project),
> but got nothing, and I really need some direction.
> Here is what I wrote on SO:
> _Using Maven, I want to run unit and integration tests on a pre-compiled/
> pre-jar'ed multi-module project. I am finding this exceedingly difficult._
> _My business case is, I want to compile and jar up a multi-module Maven
> project in one place, and then have the unit test and integration tests run
> using different Java versions and on different operating systems, to check
> for compatibility. Let's just say \{Java 8, Java 10} x \{Ubuntu, Windows} to
> keep it simple._
> _The reason I want to compile and jar up in one pace is, I want to ensure
> that I run tests on the actual code getting shipped. If I re-compiled
> everywhere I fear I might introduce errors unwittingly._
> _One solution is to do {{mvn deploy -DaltDeploymentRepository=$mydir}} on
> Ubuntu to produce a compiled project tree and a directory full of jars; then
> zipping up the project tree and deploy directory and shipping them off to a
> Windows machine; and there running {{mvn surefire:test
> -Dmaven.repo.local=$mydir}} on the project tree._
> _That works but it is hella clumsy. Surefire seems to read the test classes
> in the project tree and use the classes in the same project + jar
> dependencies from the deployment repo to link against. A problem there is,
> with {{-Dmaven.repo.local}} Maven needs to download all 3rd party
> dependencies again because that repo only contains my project artifacts. So a
> solid solution, but not great._
> _Instead what I have been trying to do is, just use the compiled project
> tree:_
> * _If I just do {{mvn surefire:test}} I get problems resolving dependencies_
> * _I have tried {{mvn compile -Dmaven.main.skip surefire:test}} to fix
> dependency resolution, which seems to work - just not for test dependencies_
> * _I further tried {{mvn compile -Dmaven.main.skip test-compile
> -Dmaven.test.skip surefire:test}}, but for some reason that also does not
> work, the build again fails trying to resolve test dependencies._
> _Interestingly, it is not deterministic, the failures happen at different
> stages and sometimes not at all - I get the occasional green build!_
> _And now I am at my wits' end: I keep thinking this should be simple, and
> that I can't possible be the first person struggling with this simple
> problem._
> _It is opaque to me what happens with the reactor, when and how it triggers.
> The dependency graph must have been well-formed, or it couldn't compile. So
> why can I not get Maven to reproduce the same dependency graph for running
> tests?_
> Further to that:
> * I tried installing artifacts in cache using `mvn install:install`, that
> didn't work
> * I tried `mvn install` but was unable to get it to _not_ re-compile and
> re-jar my artifacts
> * I have tried simply copying files as a way to install my artifacts on
> machines
> Current status is, copying files manually to ~/.m2/repository is most
> promising, it seems to work on Linux. However, it does not work on Windows,
> I'm still trying to figure out why - line endings perhaps, the artifacts come
> from a Linux machine. The problem is artifact lookup.
> Anyway, going back to first principles: what's the recommended way to achieve
> _running tests with Maven on pre-compiled project_? I'm hoping someone has
> solved this before...
> Regards,
> Lasse
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6465) Artifact download failures
[ https://issues.apache.org/jira/browse/MNG-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591585#comment-16591585 ] Lasse Westh-Nielsen commented on MNG-6465: -- [~rfscholte] we already have a proxy cache - same deal. As soon as requests start crossing the network, there is a small failure rate. Multiplied to our scale, it is an unacceptable failure rate. So effectively there is Maven client going to our proxy cache, which in turns goes to Maven Central CDN - and _still_ failure rates are too high. Our proxy cache improved things and we got more throughput (less builds failing due to artifact download errors) but it is still not good enough. So in my view this is a client issue: I need my Maven client to behave more leniently, taking more retries and perhaps longer timeouts to ensure better throughput. And I am happy to pay with reduced latency. So is this stuff configurable or not? > Artifact download failures > -- > > Key: MNG-6465 > URL: https://issues.apache.org/jira/browse/MNG-6465 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.5.0 > Environment: Windows, Ubuntu >Reporter: Lasse Westh-Nielsen >Priority: Major > > Hey, > We often run Maven builds of [https://github.com/neo4j/neo4j] on machines > with cold caches/ empty ~/.m2/repository folders. > There are rather a lot of dependencies to download, so even though the > failure rate of individual artifact downloads is small, at our scale it > causes significant build failures. > I am working on seeding caches. Separately though it would be great to be > able to configure retries and timeouts for dependency downloads - optimise > for build throughput rather than latency as it were. > How do I do that? I can't find it documented anywhere, and trying to browse > "wagon" source code got me nowhere. > Regards, > Lasse > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6442) Run tests with Maven on pre-compiled project
[
https://issues.apache.org/jira/browse/MNG-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591645#comment-16591645
]
Robert Scholte commented on MNG-6442:
-
I don't agree with you: you want to test a jar, so in a Maven world that should
be a dependency in a separate project. You're trying to abuse the
build-lifecycle to do testing without building. The surefire plugin fits very
well in the build-lifecycle, but not in this testing lifecycle you have in
mind. This is one of those examples where you are fighting Maven, which should
be a sign to wonder if you are on the right path.
If you really really want to solve this within 1 project, (I hate to say this)
think of profiles. But this will imply a couple of tricks with plugins, which
will make it really clumsy. My proposal with the 2 modules will at least keep
the poms clean.
> Run tests with Maven on pre-compiled project
>
>
> Key: MNG-6442
> URL: https://issues.apache.org/jira/browse/MNG-6442
> Project: Maven
> Issue Type: Wish
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.5.2
> Environment: Linux, Windows
>Reporter: Lasse Westh-Nielsen
>Priority: Minor
>
> Hello,
> This is not so much a bug as it is a support request. The mailing list link
> was out of order. Please do triage into the right category.
> I tried my luck on Stack Overflow
> (https://stackoverflow.com/questions/51079816/run-tests-with-maven-on-pre-compiled-project),
> but got nothing, and I really need some direction.
> Here is what I wrote on SO:
> _Using Maven, I want to run unit and integration tests on a pre-compiled/
> pre-jar'ed multi-module project. I am finding this exceedingly difficult._
> _My business case is, I want to compile and jar up a multi-module Maven
> project in one place, and then have the unit test and integration tests run
> using different Java versions and on different operating systems, to check
> for compatibility. Let's just say \{Java 8, Java 10} x \{Ubuntu, Windows} to
> keep it simple._
> _The reason I want to compile and jar up in one pace is, I want to ensure
> that I run tests on the actual code getting shipped. If I re-compiled
> everywhere I fear I might introduce errors unwittingly._
> _One solution is to do {{mvn deploy -DaltDeploymentRepository=$mydir}} on
> Ubuntu to produce a compiled project tree and a directory full of jars; then
> zipping up the project tree and deploy directory and shipping them off to a
> Windows machine; and there running {{mvn surefire:test
> -Dmaven.repo.local=$mydir}} on the project tree._
> _That works but it is hella clumsy. Surefire seems to read the test classes
> in the project tree and use the classes in the same project + jar
> dependencies from the deployment repo to link against. A problem there is,
> with {{-Dmaven.repo.local}} Maven needs to download all 3rd party
> dependencies again because that repo only contains my project artifacts. So a
> solid solution, but not great._
> _Instead what I have been trying to do is, just use the compiled project
> tree:_
> * _If I just do {{mvn surefire:test}} I get problems resolving dependencies_
> * _I have tried {{mvn compile -Dmaven.main.skip surefire:test}} to fix
> dependency resolution, which seems to work - just not for test dependencies_
> * _I further tried {{mvn compile -Dmaven.main.skip test-compile
> -Dmaven.test.skip surefire:test}}, but for some reason that also does not
> work, the build again fails trying to resolve test dependencies._
> _Interestingly, it is not deterministic, the failures happen at different
> stages and sometimes not at all - I get the occasional green build!_
> _And now I am at my wits' end: I keep thinking this should be simple, and
> that I can't possible be the first person struggling with this simple
> problem._
> _It is opaque to me what happens with the reactor, when and how it triggers.
> The dependency graph must have been well-formed, or it couldn't compile. So
> why can I not get Maven to reproduce the same dependency graph for running
> tests?_
> Further to that:
> * I tried installing artifacts in cache using `mvn install:install`, that
> didn't work
> * I tried `mvn install` but was unable to get it to _not_ re-compile and
> re-jar my artifacts
> * I have tried simply copying files as a way to install my artifacts on
> machines
> Current status is, copying files manually to ~/.m2/repository is most
> promising, it seems to work on Linux. However, it does not work on Windows,
> I'm still trying to figure out why - line endings perhaps, the artifacts come
> from a Linux machine. The problem is artifact lookup.
> Anyway, going back to first principles: what's the recommended way to achieve
> _running tests with Ma
[jira] [Commented] (MNG-6465) Artifact download failures
[ https://issues.apache.org/jira/browse/MNG-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591646#comment-16591646 ] Robert Scholte commented on MNG-6465: - I'm not aware of such configuration. However, I would expect this to be a responsibility of [Maven Artifact Resolver|https://maven.apache.org/resolver/index.html] and not Wagon. > Artifact download failures > -- > > Key: MNG-6465 > URL: https://issues.apache.org/jira/browse/MNG-6465 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.5.0 > Environment: Windows, Ubuntu >Reporter: Lasse Westh-Nielsen >Priority: Major > > Hey, > We often run Maven builds of [https://github.com/neo4j/neo4j] on machines > with cold caches/ empty ~/.m2/repository folders. > There are rather a lot of dependencies to download, so even though the > failure rate of individual artifact downloads is small, at our scale it > causes significant build failures. > I am working on seeding caches. Separately though it would be great to be > able to configure retries and timeouts for dependency downloads - optimise > for build throughput rather than latency as it were. > How do I do that? I can't find it documented anywhere, and trying to browse > "wagon" source code got me nowhere. > Regards, > Lasse > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6465) Artifact download failures
[ https://issues.apache.org/jira/browse/MNG-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591700#comment-16591700 ] Lasse Westh-Nielsen commented on MNG-6465: -- [~rfscholte] aight I have duplicated the bug over there: https://issues.apache.org/jira/browse/MRESOLVER-54 > Artifact download failures > -- > > Key: MNG-6465 > URL: https://issues.apache.org/jira/browse/MNG-6465 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.5.0 > Environment: Windows, Ubuntu >Reporter: Lasse Westh-Nielsen >Priority: Major > > Hey, > We often run Maven builds of [https://github.com/neo4j/neo4j] on machines > with cold caches/ empty ~/.m2/repository folders. > There are rather a lot of dependencies to download, so even though the > failure rate of individual artifact downloads is small, at our scale it > causes significant build failures. > I am working on seeding caches. Separately though it would be great to be > able to configure retries and timeouts for dependency downloads - optimise > for build throughput rather than latency as it were. > How do I do that? I can't find it documented anywhere, and trying to browse > "wagon" source code got me nowhere. > Regards, > Lasse > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MRESOLVER-54) Artifact download failures
Lasse Westh-Nielsen created MRESOLVER-54: Summary: Artifact download failures Key: MRESOLVER-54 URL: https://issues.apache.org/jira/browse/MRESOLVER-54 Project: Maven Resolver Issue Type: Bug Components: resolver Affects Versions: Maven Artifact Resolver 1.1.1 Environment: Windows, Ubuntu Reporter: Lasse Westh-Nielsen Hey, We often run Maven builds of [https://github.com/neo4j/neo4j] on machines with cold caches/ empty ~/.m2/repository folders. There are rather a lot of dependencies to download, so even though the failure rate of individual artifact downloads is small, at our scale it causes significant build failures. I am working on seeding caches. Separately though it would be great to be able to configure retries and timeouts for dependency downloads - optimise for build throughput rather than latency as it were. How do I do that? I can't find it documented anywhere, and trying to browse source code got me nowhere. Regards, Lasse -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRESOLVER-54) Artifact download failures
[ https://issues.apache.org/jira/browse/MRESOLVER-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591701#comment-16591701 ] Lasse Westh-Nielsen commented on MRESOLVER-54: -- This is a duplicate of https://issues.apache.org/jira/browse/MNG-6465, I was directed here from there. > Artifact download failures > -- > > Key: MRESOLVER-54 > URL: https://issues.apache.org/jira/browse/MRESOLVER-54 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 > Environment: Windows, Ubuntu >Reporter: Lasse Westh-Nielsen >Priority: Major > > Hey, > We often run Maven builds of [https://github.com/neo4j/neo4j] on machines > with cold caches/ empty ~/.m2/repository folders. > There are rather a lot of dependencies to download, so even though the > failure rate of individual artifact downloads is small, at our scale it > causes significant build failures. > I am working on seeding caches. Separately though it would be great to be > able to configure retries and timeouts for dependency downloads - optimise > for build throughput rather than latency as it were. > How do I do that? I can't find it documented anywhere, and trying to browse > source code got me nowhere. > Regards, > Lasse > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SUREFIRE-1558) IOException not caught/declared in StatelessXmlReporter.java after maven-shared-utils update
Tiago Stürmer Daitx created SUREFIRE-1558:
-
Summary: IOException not caught/declared in
StatelessXmlReporter.java after maven-shared-utils update
Key: SUREFIRE-1558
URL: https://issues.apache.org/jira/browse/SUREFIRE-1558
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.22.0, 2.21.0
Environment: debian testing and unstable, ubuntu cosmic
Reporter: Tiago Stürmer Daitx
Attachments: surefire_2.21.0-1.rbuild.log
maven-surefire-common fails to build with the following error message:
{{maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java:[482,28]
error: unreported exception IOException; must be caught or declared to be
thrown
}}
This seems to be caused by maven-shared-utils update from 3.1 to 3.2, in
particular by the fix of [maven-shared-util's
MSHARED-610|https://issues.apache.org/jira/browse/MSHARED-610].
More details and [full build logs are available in
Debian|https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/surefire_2.21.0-1.rbuild.log.gz]
and
[Ubuntu|https://launchpadlibrarian.net/385098232/buildlog_ubuntu-cosmic-amd64.surefire_2.21.0-1_BUILDING.txt.gz].
The reproducible builds bot in Debian also [opened a bug
report|https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906411] in case you
want to add something there or ask additional questions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1558) IOException not caught/declared in StatelessXmlReporter.java after maven-shared-utils update
[
https://issues.apache.org/jira/browse/SUREFIRE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tiago Stürmer Daitx updated SUREFIRE-1558:
--
Attachment: surefire_2.21.0-1.rbuild.log
> IOException not caught/declared in StatelessXmlReporter.java after
> maven-shared-utils update
>
>
> Key: SUREFIRE-1558
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1558
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.21.0, 2.22.0
> Environment: debian testing and unstable, ubuntu cosmic
>Reporter: Tiago Stürmer Daitx
>Priority: Major
> Attachments: surefire_2.21.0-1.rbuild.log
>
>
> maven-surefire-common fails to build with the following error message:
> {{maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java:[482,28]
> error: unreported exception IOException; must be caught or declared to be
> thrown
> }}
> This seems to be caused by maven-shared-utils update from 3.1 to 3.2, in
> particular by the fix of [maven-shared-util's
> MSHARED-610|https://issues.apache.org/jira/browse/MSHARED-610].
> More details and [full build logs are available in
> Debian|https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/surefire_2.21.0-1.rbuild.log.gz]
> and
> [Ubuntu|https://launchpadlibrarian.net/385098232/buildlog_ubuntu-cosmic-amd64.surefire_2.21.0-1_BUILDING.txt.gz].
> The reproducible builds bot in Debian also [opened a bug
> report|https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906411] in case you
> want to add something there or ask additional questions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on issue #37: [WAGON-526] making the retry handle of http client configurable
michael-o commented on issue #37: [WAGON-526] making the retry handle of http client configurable URL: https://github.com/apache/maven-wagon/pull/37#issuecomment-415832866 I have pushed a cleaned up branch. Please have a look. If all is fine, I will merge. 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-526) Make the retry handling of HttpClient configurable
[ https://issues.apache.org/jira/browse/WAGON-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591980#comment-16591980 ] ASF GitHub Bot commented on WAGON-526: -- michael-o commented on issue #37: [WAGON-526] making the retry handle of http client configurable URL: https://github.com/apache/maven-wagon/pull/37#issuecomment-415832866 I have pushed a cleaned up branch. Please have a look. If all is fine, I will merge. 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 > Make the retry handling of HttpClient configurable > -- > > Key: WAGON-526 > URL: https://issues.apache.org/jira/browse/WAGON-526 > Project: Maven Wagon > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.0 > > > Provide a way to customize a lot (until a custom impl) the way wagon retries > downloads. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] michael-o commented on issue #18: Implemented mkdirs method to use the webdav MKCOL HTTP verb to create directories
michael-o commented on issue #18: Implemented mkdirs method to use the webdav MKCOL HTTP verb to create directories URL: https://github.com/apache/maven-wagon/pull/18#issuecomment-415860479 Any response? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (WAGON-526) Make the retry handling of HttpClient configurable
[ https://issues.apache.org/jira/browse/WAGON-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-526: - Component/s: wagon-http > Make the retry handling of HttpClient configurable > -- > > Key: WAGON-526 > URL: https://issues.apache.org/jira/browse/WAGON-526 > Project: Maven Wagon > Issue Type: New Feature > Components: wagon-http >Affects Versions: 3.1.0 >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.0 > > > Provide a way to customize a lot (until a custom impl) the way wagon retries > downloads. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-526) Make the retry handling of HttpClient configurable
[ https://issues.apache.org/jira/browse/WAGON-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-526: - Affects Version/s: 3.1.0 > Make the retry handling of HttpClient configurable > -- > > Key: WAGON-526 > URL: https://issues.apache.org/jira/browse/WAGON-526 > Project: Maven Wagon > Issue Type: New Feature > Components: wagon-http >Affects Versions: 3.1.0 >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.0 > > > Provide a way to customize a lot (until a custom impl) the way wagon retries > downloads. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MRESOLVER-54) Artifact download failures
[ https://issues.apache.org/jira/browse/MRESOLVER-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MRESOLVER-54. --- Resolution: Duplicate > Artifact download failures > -- > > Key: MRESOLVER-54 > URL: https://issues.apache.org/jira/browse/MRESOLVER-54 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 > Environment: Windows, Ubuntu >Reporter: Lasse Westh-Nielsen >Priority: Major > > Hey, > We often run Maven builds of [https://github.com/neo4j/neo4j] on machines > with cold caches/ empty ~/.m2/repository folders. > There are rather a lot of dependencies to download, so even though the > failure rate of individual artifact downloads is small, at our scale it > causes significant build failures. > I am working on seeding caches. Separately though it would be great to be > able to configure retries and timeouts for dependency downloads - optimise > for build throughput rather than latency as it were. > How do I do that? I can't find it documented anywhere, and trying to browse > source code got me nowhere. > Regards, > Lasse > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Moved] (MRESOLVER-55) Artifact download failures
[ https://issues.apache.org/jira/browse/MRESOLVER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov moved MNG-6465 to MRESOLVER-55: -- Affects Version/s: (was: 3.5.0) Maven Artifact Resolver 1.1.1 Component/s: (was: Artifacts and Repositories) resolver Key: MRESOLVER-55 (was: MNG-6465) Project: Maven Resolver (was: Maven) > Artifact download failures > -- > > Key: MRESOLVER-55 > URL: https://issues.apache.org/jira/browse/MRESOLVER-55 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 > Environment: Windows, Ubuntu >Reporter: Lasse Westh-Nielsen >Priority: Major > > Hey, > We often run Maven builds of [https://github.com/neo4j/neo4j] on machines > with cold caches/ empty ~/.m2/repository folders. > There are rather a lot of dependencies to download, so even though the > failure rate of individual artifact downloads is small, at our scale it > causes significant build failures. > I am working on seeding caches. Separately though it would be great to be > able to configure retries and timeouts for dependency downloads - optimise > for build throughput rather than latency as it were. > How do I do that? I can't find it documented anywhere, and trying to browse > "wagon" source code got me nowhere. > Regards, > Lasse > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRESOLVER-52) https for artifact resolution
[ https://issues.apache.org/jira/browse/MRESOLVER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16592094#comment-16592094 ] Michael Osipov commented on MRESOLVER-52: - Unless we see your configuration and Maven version, I'd say that this one is invalid. > https for artifact resolution > - > > Key: MRESOLVER-52 > URL: https://issues.apache.org/jira/browse/MRESOLVER-52 > Project: Maven Resolver > Issue Type: Bug > Components: resolver >Affects Versions: Maven Artifact Resolver 1.1.1 >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's an exception I saw recently: > Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not > transfer artifact com.google.auth:google-auth-library-credentials:pom:0.4.0 > from/to central (http://repo1.maven.org/maven2/): repo1.maven.org: nodename > nor servname provided, or not known > The exception is probably a glitch in my network or DNS. Not resolver's fault > and no big deal. However the message surprised me. Why > *http*://repo1.maven.org/maven2/ and not *https*://repo1.maven.org/maven2/? > One of three things is likely happening here: > 1. Resolver is really using http instead of https to transfer artifacts. This > is a major issue, and should be fixed. > 2. It's using https to transfer, but is forming the URL in the error message > by string concatenation with "http", which is not critical but should still > be fixed. > 3. It's relying on repo1 to redirect to https, which it seems to do; but > shouldn't be required since this leaves the connection vulnerable to MITM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MJAVADOC-536) Wrong option argument (--class-path) if using Java 9 or higher
[
https://issues.apache.org/jira/browse/MJAVADOC-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-536:
Summary: Wrong option argument (--class-path) if using Java 9 or higher
(was: Wrong option argument (--class-path) if using Java 1.9 or higher)
> Wrong option argument (--class-path) if using Java 9 or higher
> --
>
> Key: MJAVADOC-536
> URL: https://issues.apache.org/jira/browse/MJAVADOC-536
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.1
> Environment: JDK 10.0.1
> Maven 3.5.4
> Windows 10
>Reporter: Christoph Pfeiffer
>Priority: Blocker
>
> If I build a project with Java 1.9 or higher (setup in compiler plugin) the
> javadoc plugin creates a wrong option argument named _--class-path_ instead
> of _-classpath_. I found no work arounds for this.
>
> I get this error message:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:jar (generate-javadoc) on
> project jremote-api: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - javadoc: error - invalid flag: --class-path
> [ERROR]
> [ERROR] Command line was: "C:\Program Files\Java\jdk1.8.0_72\bin\javadoc.exe"
> @options @packages @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'C:\Workspace\Java\Frameworks\jremote\api\target\apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :jremote-api
> {noformat}
>
> Please see this github project and remove the _skip_ tag in root pom in
> _javadoc_ plugin section to see this error:
> [https://github.com/KleinerHacker/jremote/|http://example.com]
>
> With this error I cannot deploy to maven central repo cause I need a javadoc
> JAR.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-536) Wrong option argument (--class-path) if using Java 9 or higher
[
https://issues.apache.org/jira/browse/MJAVADOC-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-536:
Description:
If I build a project with Java 9 or higher (setup in compiler plugin) the
javadoc plugin creates a wrong option argument named _--class-path_ instead of
_-classpath_. I found no work arounds for this.
I get this error message:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:jar (generate-javadoc) on
project jremote-api: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: error - invalid flag: --class-path
[ERROR]
[ERROR] Command line was: "C:\Program Files\Java\jdk1.8.0_72\bin\javadoc.exe"
@options @packages @argfile
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'C:\Workspace\Java\Frameworks\jremote\api\target\apidocs' dir.
[ERROR]
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :jremote-api
{noformat}
Please see this github project and remove the _skip_ tag in root pom in
_javadoc_ plugin section to see this error:
[https://github.com/KleinerHacker/jremote/|http://example.com]
With this error I cannot deploy to maven central repo cause I need a javadoc
JAR.
was:
If I build a project with Java 1.9 or higher (setup in compiler plugin) the
javadoc plugin creates a wrong option argument named _--class-path_ instead of
_-classpath_. I found no work arounds for this.
I get this error message:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:jar (generate-javadoc) on
project jremote-api: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: error - invalid flag: --class-path
[ERROR]
[ERROR] Command line was: "C:\Program Files\Java\jdk1.8.0_72\bin\javadoc.exe"
@options @packages @argfile
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'C:\Workspace\Java\Frameworks\jremote\api\target\apidocs' dir.
[ERROR]
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :jremote-api
{noformat}
Please see this github project and remove the _skip_ tag in root pom in
_javadoc_ plugin section to see this error:
[https://github.com/KleinerHacker/jremote/|http://example.com]
With this error I cannot deploy to maven central repo cause I need a javadoc
JAR.
> Wrong option argument (--class-path) if using Java 9 or higher
> --
>
> Key: MJAVADOC-536
> URL: https://issues.apache.org/jira/browse/MJAVADOC-536
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.1
> Environment: JDK 10.0.1
> Maven 3.5.4
> Windows 10
>Reporter: Christoph Pfeiffer
>Priority: Blocker
>
> If I build a project with Java 9 or higher (setup in compiler plugin) the
> javadoc plugin creates a wrong option argument named _--class-path_ instead
> of _-classpath_. I found no work arounds for this.
>
> I get this error message:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:jar (generate-javadoc) on
> project jremote-api: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - javadoc: error - invalid flag: --class-path
> [ERROR]
> [ERROR] Command line was: "C:\Program Files\Java\jdk1.8.0_72\bin\javadoc.exe"
> @options @packages @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'C:\Workspace\Java\Frameworks\jremote\api\target\apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecution
[jira] [Commented] (MNG-6462) Add. DS_Store to .gitignore
[
https://issues.apache.org/jira/browse/MNG-6462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16592096#comment-16592096
]
Michael Osipov commented on MNG-6462:
-
It is already:
{noformat}
mosipov@mikaw10 MINGW64 /d/Entwicklung/Projekte/maven (master)
$ cat .gitignore
target/
.project
.classpath
.settings/
.svn/
bin/
# Intellij
*.ipr
*.iml
.idea
out/
.DS_Store
/bootstrap
/dependencies.xml
.java-version
{noformat}
> Add. DS_Store to .gitignore
> ---
>
> Key: MNG-6462
> URL: https://issues.apache.org/jira/browse/MNG-6462
> Project: Maven
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.5.4
> Environment: Mac
>Reporter: Elliotte Rusty Harold
>Priority: Trivial
>
> Useful for devs who use Macs:
> Untracked files:
> (use "git add ..." to include in what will be committed)
> .DS_Store
> content/.DS_Store
> content/odt/.DS_Store
> content/resources/.DS_Store
> content/xdoc/.DS_Store
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6461) lombok + assembly + jar 打包冲突
[ https://issues.apache.org/jira/browse/MNG-6461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6461. --- Resolution: Invalid This is not a support forum in Mandarin. > lombok + assembly + jar 打包冲突 > > > Key: MNG-6461 > URL: https://issues.apache.org/jira/browse/MNG-6461 > Project: Maven > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 3.5.4 > Environment: win10, jdk8，maven 3.5.4 >Reporter: 蓝白 >Priority: Major > Labels: build, maven > Attachments: PagingInfo.java, aa.log > > > 项目依赖： > spring boot 2.0.4 > lombok 1.16.22 > 使用了maven-assembly + maven-jar-plugin后打包失败。 > 因为有一个类既有有参构造函数并且增加了@NoArgsConstructor注解，导致maven编译失败。 > 报错信息如下： > Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: > Compilation failure > /C:/Users/fengz/Desktop/project/demo-web/src/main/java/com/demo/web/page/PagingInfo.java > :[24,1]已在类com.demo.web.page.PagingInfo中定义了构造器PagingInfo() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] michael-o commented on issue #52: add --cached option for git rm
michael-o commented on issue #52: add --cached option for git rm URL: https://github.com/apache/maven-scm/pull/52#issuecomment-415873011 This change will break the contract from `ScmProvider#remove()`. This can be at most a config parameter. What is your real usecase for 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
