[GitHub] olamy closed pull request #85: Fix minor typos in javadocs
olamy closed pull request #85: Fix minor typos in javadocs URL: https://github.com/apache/maven-scm/pull/85 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/maven-scm-providers/maven-scm-provider-integrity/src/main/java/org/apache/maven/scm/provider/integrity/Sandbox.java b/maven-scm-providers/maven-scm-provider-integrity/src/main/java/org/apache/maven/scm/provider/integrity/Sandbox.java index 3a3bb9f88..c15234cc4 100644 --- a/maven-scm-providers/maven-scm-provider-integrity/src/main/java/org/apache/maven/scm/provider/integrity/Sandbox.java +++ b/maven-scm-providers/maven-scm-provider-integrity/src/main/java/org/apache/maven/scm/provider/integrity/Sandbox.java @@ -155,7 +155,7 @@ private boolean isValidSandbox( String sandbox ) } /** - * Inspects the MKS API Response object's Item field to determine whether or nor a working file delta exists + * Inspects the MKS API Response object's Item field to determine whether or not a working file delta exists * * @param wfdelta MKS API Response object's Item representing the Working File Delta * @return true if the working file is a delta; false otherwise @@ -735,7 +735,7 @@ public Response createSubproject( String dirPath ) * * @param startDate The date range for the beginning of the operation * @param endDate The date range for the end of the operation - * @return ChangeLogSet containing a list of changes grouped by Change Pacakge ID + * @return ChangeLogSet containing a list of changes grouped by Change Package ID * @throws APIException */ public ChangeLogSet getChangeLog( Date startDate, Date endDate ) @@ -833,4 +833,4 @@ public ChangeLogSet getChangeLog( Date startDate, Date endDate ) return changeLog; } -} \ No newline at end of file +} 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=16584525#comment-16584525
]
ASF GitHub Bot commented on MNG-2802:
-
olamy 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_r211057067
##
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 );
Review comment:
please avoid System.exit this can fail to correctly report failures with
surefire
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)
[GitHub] olamy commented on a change in pull request #49: [MNG-2802] Concurrent-safe access to local Maven repository
olamy 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_r211057067
##
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 );
Review comment:
please avoid System.exit this can fail to correctly report failures with
surefire
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=16584521#comment-16584521
]
ASF GitHub Bot commented on MNG-2802:
-
olamy 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_r211057038
##
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:
please avoid System.exit this can fail to correctly report failures with
surefire
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)
[GitHub] olamy commented on a change in pull request #49: [MNG-2802] Concurrent-safe access to local Maven repository
olamy 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_r211057038
##
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:
please avoid System.exit this can fail to correctly report failures with
surefire
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=16584420#comment-16584420 ] Erik Håkansson commented on MNG-2802: - The PR mentioned above is for the File wagon in maven-wagon, and is only tested isolated in there. Since it's pretty much impossible to reliably reproduce this with a real maven, I had to be satisfied with that. > 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] (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=16584418#comment-16584418 ] ASF GitHub Bot commented on MNG-2802: - erikhakansson opened a new pull request #49: [MNG-2802] Concurrent-safe access to local Maven repository URL: https://github.com/apache/maven-wagon/pull/49 Made file wagon optionally lock files using an adapted version of LockableFileWriter from commons-io. Integration test is made by forking two separate java processes that attempts to lock the same file. Only the first will succeed. At first I tried using Java's FileLock, but that proved impossible on Windows Subsystem for Linux as that doesn't reliably support file locks, and after some googling I realized the native FileLocks are generally unreliable from Java. Instead I opted to use lockfiles using the commons-io approach. Use system property maven.wagon.file.fileLock=true to enable file lock. Default is off, default timeout is 300 seconds, but configurable with maven.wagon.file.fileLock.timeout 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)
[GitHub] erikhakansson opened a new pull request #49: [MNG-2802] Concurrent-safe access to local Maven repository
erikhakansson opened a new pull request #49: [MNG-2802] Concurrent-safe access to local Maven repository URL: https://github.com/apache/maven-wagon/pull/49 Made file wagon optionally lock files using an adapted version of LockableFileWriter from commons-io. Integration test is made by forking two separate java processes that attempts to lock the same file. Only the first will succeed. At first I tried using Java's FileLock, but that proved impossible on Windows Subsystem for Linux as that doesn't reliably support file locks, and after some googling I realized the native FileLocks are generally unreliable from Java. Instead I opted to use lockfiles using the commons-io approach. Use system property maven.wagon.file.fileLock=true to enable file lock. Default is off, default timeout is 300 seconds, but configurable with maven.wagon.file.fileLock.timeout This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] jean-philippe-martin commented on issue #4: (doc) - mention include tag
jean-philippe-martin commented on issue #4: (doc) - mention include tag URL: https://github.com/apache/maven-shade-plugin/pull/4#issuecomment-413987396 Sure thing @khmarbaise , done! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] sebthom commented on issue #28: Add support for detecting and using of KiTTY's klink.exe and kscp.exe
sebthom commented on issue #28: Add support for detecting and using of KiTTY's klink.exe and kscp.exe URL: https://github.com/apache/maven-wagon/pull/28#issuecomment-413962566 At last: https://issues.apache.org/jira/browse/WAGON-525 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (WAGON-525) Support for detecting and using of KiTTY's klink.exe and kscp.exe
Sebastian created WAGON-525: --- Summary: Support for detecting and using of KiTTY's klink.exe and kscp.exe Key: WAGON-525 URL: https://issues.apache.org/jira/browse/WAGON-525 Project: Maven Wagon Issue Type: Improvement Components: wagon-ssh-external Reporter: Sebastian KiTTY is a PuTTY fork available at [http://www.9bis.net/kitty/] When using KiTTY's klink.exe/kscp.exe instead of PuTTY's plink.exe/pscp.exe, the ScpExternalWagon implementation passes the command line arguments "-o BatchMode yes" to these executables which fail with "unknown option -o". The PR [https://github.com/apache/maven-wagon/pull/28] changes the ScpExternalWagon class to treat KiTTY executables like PuTTY executables. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEP-425) dependency:list-repositories ignores pluginRepository (only lists repository)
[ https://issues.apache.org/jira/browse/MDEP-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16584288#comment-16584288 ] ASF GitHub Bot commented on MDEP-425: - mattnelson opened a new pull request #3: [MDEP-425] - Add list-plugin-repositories goal URL: https://github.com/apache/maven-dependency-plugin/pull/3 https://issues.apache.org/jira/browse/MDEP-425 Replacement PR for https://github.com/apache/maven-plugins/pull/113 Add list-plugin-repositories goal to supplement the list-repositories goal. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MDEP) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MDEP-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MDEP-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). 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 > dependency:list-repositories ignores pluginRepository (only lists repository) > - > > Key: MDEP-425 > URL: https://issues.apache.org/jira/browse/MDEP-425 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Michael Vorburger >Priority: Major > > http://maven.apache.org/plugins/maven-dependency-plugin/list-repositories-mojo.html > can be very useful! But unless we've missed something, it seems to only > gather & list all but doesn't know about / ignores > any ? > What I'm suggesting is more that something like 'mvn > org.apache.maven.plugins:maven-dependency-plugin:2.8:list-repositories' also > lists plugin repositories (with an indication of which is a plugin vs. a > dependency plug-in?) than a new list-plugin-repositories goal (just because I > think in practice one would typically want to see both). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEP-425) dependency:list-repositories ignores pluginRepository (only lists repository)
[ https://issues.apache.org/jira/browse/MDEP-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16584289#comment-16584289 ] ASF GitHub Bot commented on MDEP-425: - Github user mattnelson closed the pull request at: https://github.com/apache/maven-plugins/pull/113 > dependency:list-repositories ignores pluginRepository (only lists repository) > - > > Key: MDEP-425 > URL: https://issues.apache.org/jira/browse/MDEP-425 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Michael Vorburger >Priority: Major > > http://maven.apache.org/plugins/maven-dependency-plugin/list-repositories-mojo.html > can be very useful! But unless we've missed something, it seems to only > gather & list all but doesn't know about / ignores > any ? > What I'm suggesting is more that something like 'mvn > org.apache.maven.plugins:maven-dependency-plugin:2.8:list-repositories' also > lists plugin repositories (with an indication of which is a plugin vs. a > dependency plug-in?) than a new list-plugin-repositories goal (just because I > think in practice one would typically want to see both). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] mattnelson opened a new pull request #3: [MDEP-425] - Add list-plugin-repositories goal
mattnelson opened a new pull request #3: [MDEP-425] - Add list-plugin-repositories goal URL: https://github.com/apache/maven-dependency-plugin/pull/3 https://issues.apache.org/jira/browse/MDEP-425 Replacement PR for https://github.com/apache/maven-plugins/pull/113 Add list-plugin-repositories goal to supplement the list-repositories goal. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MDEP) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MDEP-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MDEP-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] khmarbaise commented on issue #4: (doc) - mention include tag
khmarbaise commented on issue #4: (doc) - mention include tag URL: https://github.com/apache/maven-shade-plugin/pull/4#issuecomment-413941663 Could you do another favour and squash those two commits into a single onewould greatly help me...afterwards I appreciate to merge this... This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (SUREFIRE-1550) The surefire XSD published on maven site lacks of some rerun element
[ https://issues.apache.org/jira/browse/SUREFIRE-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1550. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=429a2390ce943be0fbeb471032f1c2085d684c05 > The surefire XSD published on maven site lacks of some rerun element > > > Key: SUREFIRE-1550 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1550 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.22.0 >Reporter: Nikolas Falco >Assignee: Tibor Digana >Priority: Minor > Fix For: 2.22.1 > > > The surefire XSD published on maven site lacks of most XML element created in > case of rerun count is defined. > Actually in the XSD only rerunFailure is defined. Are missing rerunError, > flakyError and flakyFailure elements described > [here|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1550) The surefire XSD published on maven site lacks of some rerun element
[ https://issues.apache.org/jira/browse/SUREFIRE-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16584210#comment-16584210 ] ASF GitHub Bot commented on SUREFIRE-1550: -- asfgit closed pull request #192: [SUREFIRE-1550] The surefire XSD published on maven site lacks of some URL: https://github.com/apache/maven-surefire/pull/192 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/maven-surefire-plugin/src/site/resources/xsd/surefire-test-report.xsd b/maven-surefire-plugin/src/site/resources/xsd/surefire-test-report.xsd index 2bad4aca7..684f17516 100644 --- a/maven-surefire-plugin/src/site/resources/xsd/surefire-test-report.xsd +++ b/maven-surefire-plugin/src/site/resources/xsd/surefire-test-report.xsd @@ -18,6 +18,11 @@ ~ under the License. --> http://www.w3.org/2001/XMLSchema;> + + + + + @@ -42,14 +47,7 @@ - - - - - - - + @@ -60,18 +58,21 @@ - - - - - - - + + + + + + + + + + + @@ -91,30 +92,38 @@ + + + + + + + + + + + + + + + + + + + + - - - - - - - + - - - - - - - + diff --git a/maven-surefire-report-plugin/pom.xml b/maven-surefire-report-plugin/pom.xml index b19151524..1450d5262 100644 --- a/maven-surefire-report-plugin/pom.xml +++ b/maven-surefire-report-plugin/pom.xml @@ -103,6 +103,12 @@ 1.2 test + +
[GitHub] asfgit closed pull request #192: [SUREFIRE-1550] The surefire XSD published on maven site lacks of some
asfgit closed pull request #192: [SUREFIRE-1550] The surefire XSD published on maven site lacks of some URL: https://github.com/apache/maven-surefire/pull/192 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/maven-surefire-plugin/src/site/resources/xsd/surefire-test-report.xsd b/maven-surefire-plugin/src/site/resources/xsd/surefire-test-report.xsd index 2bad4aca7..684f17516 100644 --- a/maven-surefire-plugin/src/site/resources/xsd/surefire-test-report.xsd +++ b/maven-surefire-plugin/src/site/resources/xsd/surefire-test-report.xsd @@ -18,6 +18,11 @@ ~ under the License. --> http://www.w3.org/2001/XMLSchema;> + + + + + @@ -42,14 +47,7 @@ - - - - - - - + @@ -60,18 +58,21 @@ - - - - - - - + + + + + + + + + + + @@ -91,30 +92,38 @@ + + + + + + + + + + + + + + + + + + + + - - - - - - - + - - - - - - - + diff --git a/maven-surefire-report-plugin/pom.xml b/maven-surefire-report-plugin/pom.xml index b19151524..1450d5262 100644 --- a/maven-surefire-report-plugin/pom.xml +++ b/maven-surefire-report-plugin/pom.xml @@ -103,6 +103,12 @@ 1.2 test + + org.xmlunit + xmlunit-core + 2.6.0 + test + diff --git a/maven-surefire-report-plugin/src/test/java/org/apache/maven/plugins/surefire/report/SurefireSchemaValidationTest.java
[GitHub] jean-philippe-martin commented on a change in pull request #4: (doc) - mention include tag
jean-philippe-martin commented on a change in pull request #4: (doc) - mention include tag URL: https://github.com/apache/maven-shade-plugin/pull/4#discussion_r210976084 ## File path: src/site/apt/examples/class-relocation.apt.vm ## @@ -70,3 +70,20 @@ Relocating Classes into the package <<>> by moving the corresponding JAR file entries and rewritting the affected bytecode. The class <<>> and some others will remain in their original package. + + It's also possible to narrow the pattern with the "include" tag: Review comment: Sure thing! Done. 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] (MNGSITE-348) Multi-module builds staging uses "staging" for the first module and "Staging" for subsequent stagings
[
https://issues.apache.org/jira/browse/MNGSITE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16584087#comment-16584087
]
Mykel Alvis commented on MNGSITE-348:
-
Sorry. Sent this to mngsite and not msite. Apologies.
> Multi-module builds staging uses "staging" for the first module and "Staging"
> for subsequent stagings
> -
>
> Key: MNGSITE-348
> URL: https://issues.apache.org/jira/browse/MNGSITE-348
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment: Case-sensitive filesystems (i.e. unix-like, primarily)
> with maven 3.5.4
>Reporter: Mykel Alvis
>Priority: Major
>
> I have a project that is a hierarchical tree of parents (i..e everything is a
> "pom" type).
> Only the root project has a
>
> nexus
>
> [https://artifacts.example.io/repository/sites/DELETE/io.example/example-parent-support/25-SNAPSHOT/]
>
> and all sub-modules are intended to inherit the "standard" site structure
> based on the fact that module names are the same as the artifact identifier.
> No config has a topSiteURL set
> Current config of the site plugin is as follows (but has been juggled many
> times with equivalent results):
> {quote}
> org.apache.maven.plugins
> maven-site-plugin
> 3.7.1
>
>
>
>
> org.apache.maven.doxia
> doxia-site-renderer
> 1.8.1
>
>
> org.apache.maven.doxia
> doxia-module-markdown
> 1.8
> compile
>
>
> org.apache.maven.doxia
> doxia-module-fml
> 1.8
> compile
>
>
> org.apache.maven.doxia
> doxia-module-latex
> 1.8
> compile
>
>
> org.apache.maven.doxia
> doxia-module-apt
> 1.8
> compile
>
>
> org.apache.maven.doxia
> doxia-module-xdoc
> 1.8
> compile
>
>
> org.apache.maven.wagon
> wagon-webdav-jackrabbit
> 3.1.0
> compile
>
>
>
> {quote}
>
>
> site:site works essentially as-expected.
> site:stage does something totally weird.
> {{mvn site:stage}}
> {{[INFO] Scanning for projects...}}
> {{[INFO]
> }}
> {{[INFO] Reactor Build Order:}}
> {{[INFO] }}
> {{[INFO] example-parent-support [pom]}}
> {{[INFO] example-parent-minimal [pom]}}
> {{[INFO] example-oss-root [pom]}}
> {{.}}
> {{.}}
> {{.}}
> {{.}}
> {{[INFO] }}
> {{[INFO] < io.example:example-parent-support
> >-}}
> {{[INFO] Building example-parent-support 25-SNAPSHOT [1/10]}}
> {{[INFO] [ pom
> ]-}}
> {{[INFO]}}
> {{[INFO] — maven-site-plugin:3.7.1:stage (default-cli) @
> example-parent-support ---}}
> {{[INFO] Using this base directory for staging:
> /home/mykel.alvis/git/example-parent-support/target/staging}}
> {{[INFO] Pushing /home/mykel.alvis/git/example-parent-support/target/site}}
> {{[INFO] >>> to
> [file:///home/mykel.alvis/git/example-parent-support/target/staging/./|file:///home/mykel.alvis/git/example-parent-support/target/staging/]}}
> {{[INFO] }}
> {{[INFO] < io.example:example-parent-minimal
> >-}}
> {{[INFO] Building example-parent-minimal 25-SNAPSHOT [2/10]}}
> {{[INFO] [ pom
> ]-}}
> {{[INFO] }}
> {{[INFO] — maven-site-plugin:3.7.1:stage (default-cli) @
> example-parent-minimal ---}}
> {{[INFO] Using this base directory for staging:
> /home/mykel.alvis/git/example-parent-support/example-parent-minimal/target/Staging}}
> {{[INFO] Pushing
> /home/mykel.alvis/git/example-parent-support/example-parent-minimal/target/site}}
> {{[INFO] >>> to
> [file:///home/mykel.alvis/git/example-parent-support/example-parent-minimal/target/Staging/../../../DELETE/io.example/example-parent-support/25-SNAPSHOT/example-parent-minimal|file:///home/mykel.alvis/git/example-parent-support/DELETE/io.example/example-parent-support/25-SNAPSHOT/example-parent-minimal]}}
> {{[INFO]}}{{ }}
>
> Note that the first target was
> {{target/staging}}
> and the second was
> {{target/Staging}}
> What's up with that?
> It appears to be causing staging to fail, and I've been live-debugging maven
> site runs for 3 days trying to spot where the
> "staging" -> "Staging"
> change occurs, but so far all I can tell is that the LifecycleModuleBuilder
> (and/or something above it inthe call chain) is supplying the subsequent
> iterations of the plugin execution from the reactor with `...target/Staging`
> somehow. I just don't know how because single-stepping through maven is
> somewhat like getting caught in a maze of twisty passages, all alike.
> I accept (somewhat) that some people consider sites as second-class citizens
> outside of plugins, but I really want them to work correctly. Audits go a
> lot easier with good docs.
[jira] [Updated] (MNGSITE-348) Multi-module builds staging uses "staging" for the first module and "Staging" for subsequent stagings
[
https://issues.apache.org/jira/browse/MNGSITE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mykel Alvis updated MNGSITE-348:
Description:
I have a project that is a hierarchical tree of parents (i..e everything is a
"pom" type).
Only the root project has a
nexus
[https://artifacts.example.io/repository/sites/DELETE/io.example/example-parent-support/25-SNAPSHOT/]
and all sub-modules are intended to inherit the "standard" site structure based
on the fact that module names are the same as the artifact identifier.
No config has a topSiteURL set
Current config of the site plugin is as follows (but has been juggled many
times with equivalent results):
{quote}
org.apache.maven.plugins
maven-site-plugin
${maven.site.plugin.version}
org.apache.maven.doxia
doxia-site-renderer
1.8.1
org.apache.maven.doxia
doxia-module-markdown
1.8
compile
org.apache.maven.doxia
doxia-module-fml
1.8
compile
org.apache.maven.doxia
doxia-module-latex
1.8
compile
org.apache.maven.doxia
doxia-module-apt
1.8
compile
org.apache.maven.doxia
doxia-module-xdoc
1.8
compile
org.apache.maven.wagon
wagon-webdav-jackrabbit
3.1.0
compile
{quote}
site:site works essentially as-expected.
site:stage does something totally weird.
{{mvn site:stage}}
{{[INFO] Scanning for projects...}}
{{[INFO]
}}
{{[INFO] Reactor Build Order:}}
{{[INFO] }}
{{[INFO] example-parent-support [pom]}}
{{[INFO] example-parent-minimal [pom]}}
{{[INFO] example-oss-root [pom]}}
{{.}}
{{.}}
{{.}}
{{.}}
{{[INFO] }}
{{[INFO] < io.example:example-parent-support
>-}}
{{[INFO] Building example-parent-support 25-SNAPSHOT [1/10]}}
{{[INFO] [ pom
]-}}
{{[INFO]}}
{{[INFO] — maven-site-plugin:3.7.1:stage (default-cli) @
example-parent-support ---}}
{{[INFO] Using this base directory for staging:
/home/mykel.alvis/git/example-parent-support/target/staging}}
{{[INFO] Pushing /home/mykel.alvis/git/example-parent-support/target/site}}
{{[INFO] >>> to
[file:///home/mykel.alvis/git/example-parent-support/target/staging/./|file:///home/mykel.alvis/git/example-parent-support/target/staging/]}}
{{[INFO] }}
{{[INFO] < io.example:example-parent-minimal
>-}}
{{[INFO] Building example-parent-minimal 25-SNAPSHOT [2/10]}}
{{[INFO] [ pom
]-}}
{{[INFO] }}
{{[INFO] — maven-site-plugin:3.7.1:stage (default-cli) @
example-parent-minimal ---}}
{{[INFO] Using this base directory for staging:
/home/mykel.alvis/git/example-parent-support/example-parent-minimal/target/Staging}}
{{[INFO] Pushing
/home/mykel.alvis/git/example-parent-support/example-parent-minimal/target/site}}
{{[INFO] >>> to
[file:///home/mykel.alvis/git/example-parent-support/example-parent-minimal/target/Staging/../../../DELETE/io.example/example-parent-support/25-SNAPSHOT/example-parent-minimal|file:///home/mykel.alvis/git/example-parent-support/DELETE/io.example/example-parent-support/25-SNAPSHOT/example-parent-minimal]}}
{{[INFO]}}{{ }}
Note that the first target was
{{target/staging}}
and the second was
{{target/Staging}}
What's up with that?
It appears to be causing staging to fail, and I've been live-debugging maven
site runs for 3 days trying to spot where the
"staging" -> "Staging"
change occurs, but so far all I can tell is that the LifecycleModuleBuilder
(and/or something above it inthe call chain) is supplying the subsequent
iterations of the plugin execution from the reactor with `...target/Staging`
somehow. I just don't know how because single-stepping through maven is
somewhat like getting caught in a maze of twisty passages, all alike.
I accept (somewhat) that some people consider sites as second-class citizens
outside of plugins, but I really want them to work correctly. Audits go a lot
easier with good docs.
was:
I have a project that is a hierarchical tree of parents (i..e everything is a
"pom" type).
Only the root project has a
nexus
https://artifacts.example.io/repository/sites/DELETE/io.example/example-parent-support/25-SNAPSHOT/
and all sub-modules are intended to inherit the "standard" site structure based
on the fact that module names are the same as the artifact identifier.
No config has a topSiteURL set
Current config of the site plugin is as follows (but has been juggled many
times with equivalent results):
{{ }}
{{ org.apache.maven.plugins}}
{{ maven-site-plugin}}
{{ 3.7.1}}
{{ }}
{{ }}
{{ }}
{{ }}
{{ org.apache.maven.doxia}}
{{ doxia-site-renderer}}
{{ 1.8.1}}
{{ }}
{{ }}
{{ org.apache.maven.doxia}}
{{ doxia-module-markdown}}
{{ 1.8}}
{{ compile}}
{{ }}
{{ }}
{{ org.apache.maven.doxia}}
{{ doxia-module-fml}}
[jira] [Updated] (MNGSITE-348) Multi-module builds staging uses "staging" for the first module and "Staging" for subsequent stagings
[
https://issues.apache.org/jira/browse/MNGSITE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mykel Alvis updated MNGSITE-348:
Description:
I have a project that is a hierarchical tree of parents (i..e everything is a
"pom" type).
Only the root project has a
nexus
[https://artifacts.example.io/repository/sites/DELETE/io.example/example-parent-support/25-SNAPSHOT/]
and all sub-modules are intended to inherit the "standard" site structure based
on the fact that module names are the same as the artifact identifier.
No config has a topSiteURL set
Current config of the site plugin is as follows (but has been juggled many
times with equivalent results):
{quote}
org.apache.maven.plugins
maven-site-plugin
3.7.1
org.apache.maven.doxia
doxia-site-renderer
1.8.1
org.apache.maven.doxia
doxia-module-markdown
1.8
compile
org.apache.maven.doxia
doxia-module-fml
1.8
compile
org.apache.maven.doxia
doxia-module-latex
1.8
compile
org.apache.maven.doxia
doxia-module-apt
1.8
compile
org.apache.maven.doxia
doxia-module-xdoc
1.8
compile
org.apache.maven.wagon
wagon-webdav-jackrabbit
3.1.0
compile
{quote}
site:site works essentially as-expected.
site:stage does something totally weird.
{{mvn site:stage}}
{{[INFO] Scanning for projects...}}
{{[INFO]
}}
{{[INFO] Reactor Build Order:}}
{{[INFO] }}
{{[INFO] example-parent-support [pom]}}
{{[INFO] example-parent-minimal [pom]}}
{{[INFO] example-oss-root [pom]}}
{{.}}
{{.}}
{{.}}
{{.}}
{{[INFO] }}
{{[INFO] < io.example:example-parent-support
>-}}
{{[INFO] Building example-parent-support 25-SNAPSHOT [1/10]}}
{{[INFO] [ pom
]-}}
{{[INFO]}}
{{[INFO] — maven-site-plugin:3.7.1:stage (default-cli) @
example-parent-support ---}}
{{[INFO] Using this base directory for staging:
/home/mykel.alvis/git/example-parent-support/target/staging}}
{{[INFO] Pushing /home/mykel.alvis/git/example-parent-support/target/site}}
{{[INFO] >>> to
[file:///home/mykel.alvis/git/example-parent-support/target/staging/./|file:///home/mykel.alvis/git/example-parent-support/target/staging/]}}
{{[INFO] }}
{{[INFO] < io.example:example-parent-minimal
>-}}
{{[INFO] Building example-parent-minimal 25-SNAPSHOT [2/10]}}
{{[INFO] [ pom
]-}}
{{[INFO] }}
{{[INFO] — maven-site-plugin:3.7.1:stage (default-cli) @
example-parent-minimal ---}}
{{[INFO] Using this base directory for staging:
/home/mykel.alvis/git/example-parent-support/example-parent-minimal/target/Staging}}
{{[INFO] Pushing
/home/mykel.alvis/git/example-parent-support/example-parent-minimal/target/site}}
{{[INFO] >>> to
[file:///home/mykel.alvis/git/example-parent-support/example-parent-minimal/target/Staging/../../../DELETE/io.example/example-parent-support/25-SNAPSHOT/example-parent-minimal|file:///home/mykel.alvis/git/example-parent-support/DELETE/io.example/example-parent-support/25-SNAPSHOT/example-parent-minimal]}}
{{[INFO]}}{{ }}
Note that the first target was
{{target/staging}}
and the second was
{{target/Staging}}
What's up with that?
It appears to be causing staging to fail, and I've been live-debugging maven
site runs for 3 days trying to spot where the
"staging" -> "Staging"
change occurs, but so far all I can tell is that the LifecycleModuleBuilder
(and/or something above it inthe call chain) is supplying the subsequent
iterations of the plugin execution from the reactor with `...target/Staging`
somehow. I just don't know how because single-stepping through maven is
somewhat like getting caught in a maze of twisty passages, all alike.
I accept (somewhat) that some people consider sites as second-class citizens
outside of plugins, but I really want them to work correctly. Audits go a lot
easier with good docs.
was:
I have a project that is a hierarchical tree of parents (i..e everything is a
"pom" type).
Only the root project has a
nexus
[https://artifacts.example.io/repository/sites/DELETE/io.example/example-parent-support/25-SNAPSHOT/]
and all sub-modules are intended to inherit the "standard" site structure based
on the fact that module names are the same as the artifact identifier.
No config has a topSiteURL set
Current config of the site plugin is as follows (but has been juggled many
times with equivalent results):
{quote}
org.apache.maven.plugins
maven-site-plugin
${maven.site.plugin.version}
org.apache.maven.doxia
doxia-site-renderer
1.8.1
org.apache.maven.doxia
doxia-module-markdown
1.8
compile
org.apache.maven.doxia
doxia-module-fml
1.8
compile
org.apache.maven.doxia
doxia-module-latex
1.8
compile
[jira] [Comment Edited] (MNGSITE-347) Maven Download page : MD5 not match the download
[ https://issues.apache.org/jira/browse/MNGSITE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583960#comment-16583960 ] Jean-Patrick BOYET edited comment on MNGSITE-347 at 8/17/18 2:13 PM: - Hi, The .md5 files have changed to .sh1 since I created this ticket. The archive with .md5 I checked was only to verify the tools and method used to verify the checksum. Sothis ticket can be closed due to migration of .md5 to .sha1 checksum files on the download page. Regards. JP PS: @[khmarbaise|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=khmarbaise] the .md5 file I download was a link like: [https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip.md5] which gave me directly in navigator the value: 8a0d9cc9d4da3fac195de8e1e99fe07158d54192 I did not load it as a file on my computer. Now if you use this link you can have a correct value as: 235db716537989e9e949e5bf23f965c0 witch match the md5 of the file: apache-maven-3.5.4-bin.zip [apache-maven-3.5.4-bin.tar.gz.md5 |https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gz.md5]updated 2018-06-17 19:05 32 The download page has been changed : Last Published: 2018-08-17 it seems that the link to .MD5 has been changed to .sha1 link on the download page, but others checksum availables at: [https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/] was (Author: tiptopflite): Hi, The .md5 files have changed to .sh1 since I created this ticket. The archive with .md5 I checked was only to verify the tools and method used to verify the checksum. Sothis ticket can be closed due to migration of .md5 to .sha1 checksum files on the download page. Regards. JP PS: the .md5 file I download was a link like: [https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip.md5] which gave me directly in navigator the value: 8a0d9cc9d4da3fac195de8e1e99fe07158d54192 I did not load it as a file on my computer. Now if you use this link you can have a correct value as: 235db716537989e9e949e5bf23f965c0 witch match the md5 of the file: apache-maven-3.5.4-bin.zip [apache-maven-3.5.4-bin.tar.gz.md5 |https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gz.md5]updated 2018-06-17 19:05 32 The download page has been changed : Last Published: 2018-08-17 it seems that the link to .MD5 has been changed to .sha1 link on the download page, but others checksum availables at: [https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/] > Maven Download page : MD5 not match the download > > > Key: MNGSITE-347 > URL: https://issues.apache.org/jira/browse/MNGSITE-347 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Windows >Reporter: Jean-Patrick BOYET >Priority: Trivial > Labels: security > > Dear All, > After dowloading the latest maven release from: > [http://maven.apache.org/download.cgi] > with the following link: > [http://mirror.ibcp.fr/pub/apache/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip] > and verifying the MD5 checksum with both MD5 and WinMD5Free, they do not > match: > 235db716537989e9e949e5bf23f965c0 # 8a0d9cc9d4da3fac195de8e1e99fe07158d54192 > trying with other mirror: the same. > Verifying with older version: > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip] > and > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip.md5] > They match ! > > MD5 not updated on the download page ? > Regards > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNGSITE-347) Maven Download page : MD5 not match the download
[ https://issues.apache.org/jira/browse/MNGSITE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583960#comment-16583960 ] Jean-Patrick BOYET edited comment on MNGSITE-347 at 8/17/18 2:11 PM: - Hi, The .md5 files have changed to .sh1 since I created this ticket. The archive with .md5 I checked was only to verify the tools and method used to verify the checksum. Sothis ticket can be closed due to migration of .md5 to .sha1 checksum files on the download page. Regards. JP PS: the .md5 file I download was a link like: [https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip.md5] which gave me directly in navigator the value: 8a0d9cc9d4da3fac195de8e1e99fe07158d54192 I did not load it as a file on my computer. Now if you use this link you can have a correct value as: 235db716537989e9e949e5bf23f965c0 witch match the md5 of the file: apache-maven-3.5.4-bin.zip [apache-maven-3.5.4-bin.tar.gz.md5 |https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gz.md5]updated 2018-06-17 19:05 32 The download page has been changed : Last Published: 2018-08-17 it seems that the link to .MD5 has been changed to .sha1 link on the download page, but others checksum availables at: [https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/] was (Author: tiptopflite): Hi, The .md5 files have changed to .sh1 since I created this ticket. The archive with .md5 I checked was only to verify the tools and method used to verify the checksum. Sothis ticket can be closed due to migration of .md5 to .sha1 checksum files on the download page. Regards. JP PS: the .md5 file I download was a link like: [https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip.md5] which gave me directly in navigator the value: 8a0d9cc9d4da3fac195de8e1e99fe07158d54192 I did not load it as a file on my computer. Now if you use this link you can have a correct value as: 235db716537989e9e949e5bf23f965c0 witch match the md5 of the file: apache-maven-3.5.4-bin.zip The download page has been changed : Last Published: 2018-08-17 it seems that the link to .MD5 has been changed to .sha1 link > Maven Download page : MD5 not match the download > > > Key: MNGSITE-347 > URL: https://issues.apache.org/jira/browse/MNGSITE-347 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Windows >Reporter: Jean-Patrick BOYET >Priority: Trivial > Labels: security > > Dear All, > After dowloading the latest maven release from: > [http://maven.apache.org/download.cgi] > with the following link: > [http://mirror.ibcp.fr/pub/apache/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip] > and verifying the MD5 checksum with both MD5 and WinMD5Free, they do not > match: > 235db716537989e9e949e5bf23f965c0 # 8a0d9cc9d4da3fac195de8e1e99fe07158d54192 > trying with other mirror: the same. > Verifying with older version: > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip] > and > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip.md5] > They match ! > > MD5 not updated on the download page ? > Regards > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNGSITE-347) Maven Download page : MD5 not match the download
[ https://issues.apache.org/jira/browse/MNGSITE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNGSITE-347. -- Resolution: Not A Problem > Maven Download page : MD5 not match the download > > > Key: MNGSITE-347 > URL: https://issues.apache.org/jira/browse/MNGSITE-347 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Windows >Reporter: Jean-Patrick BOYET >Priority: Trivial > Labels: security > > Dear All, > After dowloading the latest maven release from: > [http://maven.apache.org/download.cgi] > with the following link: > [http://mirror.ibcp.fr/pub/apache/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip] > and verifying the MD5 checksum with both MD5 and WinMD5Free, they do not > match: > 235db716537989e9e949e5bf23f965c0 # 8a0d9cc9d4da3fac195de8e1e99fe07158d54192 > trying with other mirror: the same. > Verifying with older version: > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip] > and > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip.md5] > They match ! > > MD5 not updated on the download page ? > Regards > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNGSITE-347) Maven Download page : MD5 not match the download
[ https://issues.apache.org/jira/browse/MNGSITE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583960#comment-16583960 ] Jean-Patrick BOYET edited comment on MNGSITE-347 at 8/17/18 2:07 PM: - Hi, The .md5 files have changed to .sh1 since I created this ticket. The archive with .md5 I checked was only to verify the tools and method used to verify the checksum. Sothis ticket can be closed due to migration of .md5 to .sha1 checksum files on the download page. Regards. JP PS: the .md5 file I download was a link like: [https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip.md5] which gave me directly in navigator the value: 8a0d9cc9d4da3fac195de8e1e99fe07158d54192 I did not load it as a file on my computer. Now if you use this link you can have a correct value as: 235db716537989e9e949e5bf23f965c0 witch match the md5 of the file: apache-maven-3.5.4-bin.zip The download page has been changed : Last Published: 2018-08-17 it seems that the link to .MD5 has been changed to .sha1 link was (Author: tiptopflite): Hi, The .md5 files have changed to .sh1 since I created this ticket. The archive with .md5 I checked was only to verify the tools and method used to verify the checksum. Sothis ticket can be closed due to migration of .md5 to .sha1 checksum files on the download page. Regards. JP PS: the .md5 file I dowload was a link like: [https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip.md5] which gave me directly in firefox the value: > Maven Download page : MD5 not match the download > > > Key: MNGSITE-347 > URL: https://issues.apache.org/jira/browse/MNGSITE-347 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Windows >Reporter: Jean-Patrick BOYET >Priority: Trivial > Labels: security > > Dear All, > After dowloading the latest maven release from: > [http://maven.apache.org/download.cgi] > with the following link: > [http://mirror.ibcp.fr/pub/apache/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip] > and verifying the MD5 checksum with both MD5 and WinMD5Free, they do not > match: > 235db716537989e9e949e5bf23f965c0 # 8a0d9cc9d4da3fac195de8e1e99fe07158d54192 > trying with other mirror: the same. > Verifying with older version: > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip] > and > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip.md5] > They match ! > > MD5 not updated on the download page ? > Regards > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNGSITE-347) Maven Download page : MD5 not match the download
[ https://issues.apache.org/jira/browse/MNGSITE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583960#comment-16583960 ] Jean-Patrick BOYET edited comment on MNGSITE-347 at 8/17/18 2:00 PM: - Hi, The .md5 files have changed to .sh1 since I created this ticket. The archive with .md5 I checked was only to verify the tools and method used to verify the checksum. Sothis ticket can be closed due to migration of .md5 to .sha1 checksum files on the download page. Regards. JP PS: the .md5 file I dowload was a link like: [https://www.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip.md5] which gave me directly in firefox the value: was (Author: tiptopflite): Hi, The .md5 files have changed to .sh1 since I created this ticket. The archive with .md5 I checked was only to verify the tools and method used to verify the checksum. Sothis ticket can be closed due to migration of .md5 to .sha1 checksum files on the download page. Regards. JP > Maven Download page : MD5 not match the download > > > Key: MNGSITE-347 > URL: https://issues.apache.org/jira/browse/MNGSITE-347 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Windows >Reporter: Jean-Patrick BOYET >Priority: Trivial > Labels: security > > Dear All, > After dowloading the latest maven release from: > [http://maven.apache.org/download.cgi] > with the following link: > [http://mirror.ibcp.fr/pub/apache/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip] > and verifying the MD5 checksum with both MD5 and WinMD5Free, they do not > match: > 235db716537989e9e949e5bf23f965c0 # 8a0d9cc9d4da3fac195de8e1e99fe07158d54192 > trying with other mirror: the same. > Verifying with older version: > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip] > and > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip.md5] > They match ! > > MD5 not updated on the download page ? > Regards > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNGSITE-347) Maven Download page : MD5 not match the download
[ https://issues.apache.org/jira/browse/MNGSITE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583960#comment-16583960 ] Jean-Patrick BOYET commented on MNGSITE-347: Hi, The .md5 files have changed to .sh1 since I created this ticket. The archive with .md5 I checked was only to verify the tools and method used to verify the checksum. Sothis ticket can be closed due to migration of .md5 to .sha1 checksum files on the download page. Regards. JP > Maven Download page : MD5 not match the download > > > Key: MNGSITE-347 > URL: https://issues.apache.org/jira/browse/MNGSITE-347 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Windows >Reporter: Jean-Patrick BOYET >Priority: Trivial > Labels: security > > Dear All, > After dowloading the latest maven release from: > [http://maven.apache.org/download.cgi] > with the following link: > [http://mirror.ibcp.fr/pub/apache/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip] > and verifying the MD5 checksum with both MD5 and WinMD5Free, they do not > match: > 235db716537989e9e949e5bf23f965c0 # 8a0d9cc9d4da3fac195de8e1e99fe07158d54192 > trying with other mirror: the same. > Verifying with older version: > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip] > and > [https://archive.apache.org/dist/maven/binaries/apache-maven-3.2.2-bin.zip.md5] > They match ! > > MD5 not updated on the download page ? > Regards > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6460) Maven resolves old snapshot jars when an artifact changes from jar to pom deployment
[ https://issues.apache.org/jira/browse/MNG-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583959#comment-16583959 ] Andy Grove commented on MNG-6460: - [~rfscholte] Thanks for the quick response. Let me have one more attempt at explaining (more concisely) what I consider the bug to be, and I will close this ticket if this is considered desired behavior. I have a project with a declared dependency on g: com.acme a: foo v: 1.2.3-SNAPSHOT. I am using the maven dependency plugin to resolve these dependencies. I have not specified the dependency type so I guess I assumed it defaulted to "jar". I am using artifactory and snapshots are stored with timestamps. Latest deployed snapshot of com.acme:foo:1.2.3-SNAPSHOT has a pom.xml with pom packaging. There are no deployed jar files for this snapshot. Expected behavior: Compiling my project that depends on this artifact now fails with "dependency has no jar" or just fails to resolve the classes. Actual behavior: The maven dependency plugin ignores the latest snapshot and looks for an older snapshot that did have a jar file deployed, despite me using `-U` to force the latest snapshot to be used. > Maven resolves old snapshot jars when an artifact changes from jar to pom > deployment > > > Key: MNG-6460 > URL: https://issues.apache.org/jira/browse/MNG-6460 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.5.0 >Reporter: Andy Grove >Priority: Major > > I have two projects, A and B. > A started out as a simple project with single pom with jar packaging. > B had a dependency on A. > A was refactored to be multi module where each module has jar packaging. The > parent pom now has pom packaging. > After building A and deploying new artifacts to artifactory, and making > changes to B's pom I saw compilation errors with references to to the old A > and the new A. > I eventually realized that B still had a reference to the original artifact > from A (which was originally had jar packaging but now has pom packaging). > Even though the latest snapshot for the parent pom in A was correctly > published with pom packaging and no corresponding jar file, the > maven-dependency-plugin was resolving the jar file from the previous snapshot > release from before the refactor. > This seems like a bug to me. It should have looked at the pom for the latest > snapshot and seen that it had pom packaging and then failed to resolve the > jar. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1531) Option to switch-off Java 9 modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583862#comment-16583862
]
Stephen Colebourne commented on SUREFIRE-1531:
--
The PR is basically what I want. Note sure that "disableModules" is clear
enough as a property name though.
The existing plugin also contains the same bug as MJAVADOC-506, namely that
excluding the module-info.java file using configuration does not cause the
plugin to ignore it when determining how to test. ( existsModuleDescriptor()
does not take into account file excludes).
> Option to switch-off Java 9 modules
> ---
>
> Key: SUREFIRE-1531
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1531
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Lukáš Křečan
>Priority: Major
>
> I am working on a library and I am adding support for Java 9 modules.
> Surefire 2.21.0 by default executes tests with Java 9 modules switched-on if
> it detects module-info.java While it may make sense in some cases, in my case
> I'd like the switch it off.
> The reason is simple. I am using Mockito to mock an interface that extends a
> Spring interface. Mockito has to create an implementation of this interface
> (proxy or subclass) and for this it needs to have access to the Spring
> interfaces. If Java 9 modules are enabled for the tests I have to manually
> add each such dependencies to Surefire configuration, which does not make
> much sense. To makes things worse, the interface actually extends two Spring
> interfaces form two different Spring modules so the configuration is almost
> impossible to get right.
> So far I am at ( and I am still getting IllegalAccessErrors)
> {code:java}
> --add-exports spring.context/org.springframework.scheduling=org.mockito
> --add-exports spring.beans/org.springframework.beans.factory=org.mockito
> {code}
> I would prefer to switch-off the Java 9 modules for the test module
> altogether (same behavior as pre 2.21.0)
>
> The test is here
> [https://github.com/lukas-krecan/ShedLock/blob/java9/shedlock-spring/src/test/java/net/javacrumbs/shedlock/spring/CleanupTest.java]
>
> If you want, I can send a pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1497) Flag to select modulepath or classpath
[ https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583853#comment-16583853 ] Stephen Colebourne commented on SUREFIRE-1497: -- Not sure about that. Failsafe is all about setup and teardown of expensive (server-based) envionments. Whereas all that is needed here is to run the same unit tests in two ways. A bit like this: https://github.com/JodaOrg/joda-convert/blob/4a91619ea3762e9be960fd8e63991a1d7e205f30/pom.xml#L55-L85 ie. I don't think this is an integration testing problem. To me its a unit testing one. > Flag to select modulepath or classpath > -- > > Key: SUREFIRE-1497 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1497 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.21.0 >Reporter: Stephen Colebourne >Priority: Major > Labels: jigsaw > Attachments: maven-issue4.zip > > > SUREFIRE-1262 added the ability to run tests using the modulepath, which is > great. However, as a library developer I cannot guarantee that the code will > be run on the modulepath, it might well be run on the classpath. > As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on > and off? This would allow a single pom.xml to run surefire twice, once with > the code on the modulepath and once with the code on the classpath, to ensure > that the behaviour always works however the code is run. (Other solutions to > achieve the same goal may be possible, but this seems the most obvious). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1550) The surefire XSD published on maven site lacks of some rerun element
[ https://issues.apache.org/jira/browse/SUREFIRE-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583823#comment-16583823 ] ASF GitHub Bot commented on SUREFIRE-1550: -- Tibor17 commented on issue #192: [SUREFIRE-1550] The surefire XSD published on maven site lacks of some URL: https://github.com/apache/maven-surefire/pull/192#issuecomment-413846260 This is the branch running in CI https://builds.apache.org/job/maven-box/job/maven-surefire/job/SUREFIRE-1550/ Maybe we will have a problem with integration test Surefire1177 but that will be fixed in another PR. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > The surefire XSD published on maven site lacks of some rerun element > > > Key: SUREFIRE-1550 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1550 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.22.0 >Reporter: Nikolas Falco >Assignee: Tibor Digana >Priority: Minor > Fix For: 2.22.1 > > > The surefire XSD published on maven site lacks of most XML element created in > case of rerun count is defined. > Actually in the XSD only rerunFailure is defined. Are missing rerunError, > flakyError and flakyFailure elements described > [here|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] Tibor17 commented on issue #192: [SUREFIRE-1550] The surefire XSD published on maven site lacks of some
Tibor17 commented on issue #192: [SUREFIRE-1550] The surefire XSD published on maven site lacks of some URL: https://github.com/apache/maven-surefire/pull/192#issuecomment-413846260 This is the branch running in CI https://builds.apache.org/job/maven-box/job/maven-surefire/job/SUREFIRE-1550/ Maybe we will have a problem with integration test Surefire1177 but that will be fixed in another PR. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] kinow opened a new pull request #85: Fix minor typos in javadocs
kinow opened a new pull request #85: Fix minor typos in javadocs URL: https://github.com/apache/maven-scm/pull/85 Hi, just a couple of typos in the javadocs. Not a native speaker, so feel free to suggest changes. Happy to review/edit/commit/rebase changes. Cheers Bruno 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] [Closed] (MDEPLOY-150) deploy-file does not use repository in the same way as deploy
[
https://issues.apache.org/jira/browse/MDEPLOY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEPLOY-150.
--
Resolution: Won't Fix
There's always the option to execute {{mvn deploy -pl :contract-artifact}},
which will only deploy the contract-artifact.
I really like to demotivate people to use deploy-file as part of the project,
that's just an antipattern to me.
> deploy-file does not use repository in the same way as deploy
>
>
> Key: MDEPLOY-150
> URL: https://issues.apache.org/jira/browse/MDEPLOY-150
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy-file
>Affects Versions: 2.7
> Environment: Windows 7, Maven 2.2.1
>Reporter: Kai Hofmann
>Assignee: Robert Scholte
>Priority: Critical
>
> We use an own lifecycle here which creates a zip file instead of a jar file.
> So we use
> {noformat}org.apache.maven.plugins:maven-install-plugin:install,org.apache.maven.plugins:maven-install-plugin:install-file{noformat}
> which installs the zip file correctly.
> Additionally I now wanted to also allow deploying of this zip file to nexus
> by:
> {noformat}org.apache.maven.plugins:maven-deploy-plugin:deploy,org.apache.maven.plugins:maven-deploy-plugin:deploy-file{noformat}
> in the pom I have then:
> {code:xml}
>
>
> ${project.build.directory}/${project.artifactId}-${project.version}.zip
>
>
>
>
>
>
> org.apache.maven.plugins
>
> maven-install-plugin
> 2.3.1
>
>
>
> install-service-zip
>
>
> install-file
>
>
>
>
>
>
>
> org.apache.maven.plugins
>
> maven-deploy-plugin
> 2.7
>
>
>
> deploy-service-zip
>
>
> deploy-file
>
>
>
>
>
>
> {code}
> as well as settings for the repositories within the maven {{settings.xml}}.
> As said the install process works perfectly, but I have trouble with the
> {{deploy-file}}.
> When working without the {{deploy-file}} (only with the {{deploy}})
> everything also works correct for the deployment.
> After adding the {{deploy-file}} as shown above I come into trouble, because
> beside the property the deploy-plugin requests for the required
> parameter.
> I wonder about this, because I assumed that the parameter will come
> from the choosen repository (release vs snapshot) settings?
> When I set the as property beside the property, then I can
> deploy a snapshot.
> But to deploying snapshot/release this will not work.
> In {{deploy}} the url parameter is implicitly correctly choosen, why not in
> {{deploy-file}}? this would make the url parameter optional.
> So I see this as a bug/feature, because when deploy works in this way, then
> {{deploy-file}} should work analogous. Or have I missed something here?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPATCH-20) support exclude pattern
[
https://issues.apache.org/jira/browse/MPATCH-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583744#comment-16583744
]
Robert Scholte commented on MPATCH-20:
--
Could you change {{String excludePattern}} to {{List excludes}} ? This
is more like most other plugins define it.
> support exclude pattern
> ---
>
> Key: MPATCH-20
> URL: https://issues.apache.org/jira/browse/MPATCH-20
> Project: Maven Patch Plugin
> Issue Type: New Feature
>Affects Versions: 1.2, 1.3
>Reporter: Matthias Balke
>Priority: Major
>
> The maven-patch-plugin should provide a feature to configure an exclude
> pattern which is applied, when searching for patch files within
> {{patchDirectory}}.
>
> I'll provide a PR on GitHub for this feature.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1497) Flag to select modulepath or classpath
[ https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583708#comment-16583708 ] Robert Scholte commented on SUREFIRE-1497: -- I've been thinking about this, shouldn't this be a failsafe option only? Just me keep the difference clear between unittesting and integrationtesting. For the same reason you can and should test multirelease jars with failsafe only (MRJARs doesn't work with the classes-directory, it _*must*_ be a jar) > Flag to select modulepath or classpath > -- > > Key: SUREFIRE-1497 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1497 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.21.0 >Reporter: Stephen Colebourne >Priority: Major > Labels: jigsaw > Attachments: maven-issue4.zip > > > SUREFIRE-1262 added the ability to run tests using the modulepath, which is > great. However, as a library developer I cannot guarantee that the code will > be run on the modulepath, it might well be run on the classpath. > As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on > and off? This would allow a single pom.xml to run surefire twice, once with > the code on the modulepath and once with the code on the classpath, to ensure > that the behaviour always works however the code is run. (Other solutions to > achieve the same goal may be possible, but this seems the most obvious). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1531) Option to switch-off Java 9 modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583705#comment-16583705
]
Robert Scholte commented on SUREFIRE-1531:
--
I consider this as a duplicate of SUREFIRE-1497
> Option to switch-off Java 9 modules
> ---
>
> Key: SUREFIRE-1531
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1531
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Lukáš Křečan
>Priority: Major
>
> I am working on a library and I am adding support for Java 9 modules.
> Surefire 2.21.0 by default executes tests with Java 9 modules switched-on if
> it detects module-info.java While it may make sense in some cases, in my case
> I'd like the switch it off.
> The reason is simple. I am using Mockito to mock an interface that extends a
> Spring interface. Mockito has to create an implementation of this interface
> (proxy or subclass) and for this it needs to have access to the Spring
> interfaces. If Java 9 modules are enabled for the tests I have to manually
> add each such dependencies to Surefire configuration, which does not make
> much sense. To makes things worse, the interface actually extends two Spring
> interfaces form two different Spring modules so the configuration is almost
> impossible to get right.
> So far I am at ( and I am still getting IllegalAccessErrors)
> {code:java}
> --add-exports spring.context/org.springframework.scheduling=org.mockito
> --add-exports spring.beans/org.springframework.beans.factory=org.mockito
> {code}
> I would prefer to switch-off the Java 9 modules for the test module
> altogether (same behavior as pre 2.21.0)
>
> The test is here
> [https://github.com/lukas-krecan/ShedLock/blob/java9/shedlock-spring/src/test/java/net/javacrumbs/shedlock/spring/CleanupTest.java]
>
> If you want, I can send a pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] khmarbaise commented on a change in pull request #4: (doc) - mention include tag
khmarbaise commented on a change in pull request #4: (doc) - mention include tag URL: https://github.com/apache/maven-shade-plugin/pull/4#discussion_r210854920 ## File path: src/site/apt/examples/class-relocation.apt.vm ## @@ -70,3 +70,20 @@ Relocating Classes into the package <<>> by moving the corresponding JAR file entries and rewritting the affected bytecode. The class <<>> and some others will remain in their original package. + + It's also possible to narrow the pattern with the "include" tag: Review comment: Could you please replace `"` with `<<<` and the closing with `>>>` accordingly. 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] [Closed] (MRELEASE-274) autoVersionSubModules could be improved for release:branch
[ https://issues.apache.org/jira/browse/MRELEASE-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-274. --- Resolution: Fixed No logs provided that show this issue isn't fixed, so closing it. > autoVersionSubModules could be improved for release:branch > -- > > Key: MRELEASE-274 > URL: https://issues.apache.org/jira/browse/MRELEASE-274 > Project: Maven Release Plugin > Issue Type: Improvement > Components: branch >Affects Versions: 2.0-beta-7, 2.1 > Environment: All >Reporter: Wouter Hermeling >Assignee: Robert Scholte >Priority: Minor > Attachments: MRELEASE-274.zip, detailedLogs, logs > > > When doing a release:branch and setting autoVersionSubModules to true, i > would like to have the versions of the submodules modified the same way as > the parent instead of asking for the new version to use. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MRELEASE-750) String index out of range: -1 in ReleaseUtils.loadResolvedDependencies() when using Parent-Module-Layout
[
https://issues.apache.org/jira/browse/MRELEASE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-750.
---
Resolution: Fixed
> String index out of range: -1 in ReleaseUtils.loadResolvedDependencies() when
> using Parent-Module-Layout
>
>
> Key: MRELEASE-750
> URL: https://issues.apache.org/jira/browse/MRELEASE-750
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3
>Reporter: Thomas Baldauf
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 2.4
>
> Attachments: MNG-750-release.patch, ReleaseUtils.java
>
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.XXX:prepare (default-cli) on
> project XXX: Execution default-cli of goal
> org.apache.maven.plugins:maven-release-plugin:2.XXX:prepare failed: String
> index out of range: -1 -> [Help 1]
> This is happening in
> org.apache.maven.shared.release.config.ReleaseUtils.loadResolvedDependencies(..),
> line number 250:
> artifactVersionlessKey = propertyName.substring( startIndex, endIndex );
> Apparently endIndex can be -1 under special circumstances. Defensive
> programming fixes the problem.
> Proposed patch (see attachment):
> if (endIndex > startIndex) {
> artifactVersionlessKey = propertyName.substring( startIndex,
> endIndex );
> } else {
> artifactVersionlessKey = propertyName.substring( startIndex );
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MRELEASE-750) String index out of range: -1 in ReleaseUtils.loadResolvedDependencies() when using Parent-Module-Layout
[
https://issues.apache.org/jira/browse/MRELEASE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14445469#comment-14445469
]
Robert Scholte edited comment on MRELEASE-750 at 8/17/18 9:07 AM:
--
Update: I just figured out it was because of
-Ddependency.locations.enabled=false, see MRELEASE-834. Removing this property
repaired the broken build.
was (Author: semeion):
Update: I just figured out it was because of
-Ddependency.locations.enabled=false, see
https://jira.codehaus.org/browse/MRELEASE-834. Removing this property repaired
the broken build.
> String index out of range: -1 in ReleaseUtils.loadResolvedDependencies() when
> using Parent-Module-Layout
>
>
> Key: MRELEASE-750
> URL: https://issues.apache.org/jira/browse/MRELEASE-750
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3
>Reporter: Thomas Baldauf
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 2.4
>
> Attachments: MNG-750-release.patch, ReleaseUtils.java
>
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.XXX:prepare (default-cli) on
> project XXX: Execution default-cli of goal
> org.apache.maven.plugins:maven-release-plugin:2.XXX:prepare failed: String
> index out of range: -1 -> [Help 1]
> This is happening in
> org.apache.maven.shared.release.config.ReleaseUtils.loadResolvedDependencies(..),
> line number 250:
> artifactVersionlessKey = propertyName.substring( startIndex, endIndex );
> Apparently endIndex can be -1 under special circumstances. Defensive
> programming fixes the problem.
> Proposed patch (see attachment):
> if (endIndex > startIndex) {
> artifactVersionlessKey = propertyName.substring( startIndex,
> endIndex );
> } else {
> artifactVersionlessKey = propertyName.substring( startIndex );
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JXR-110) Use equivalent css/images of javadoc
[ https://issues.apache.org/jira/browse/JXR-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated JXR-110: --- Description: Right now jxr still uses the classes javadoc style. However, if the project is built with jdk7 or jdk8, the results of the javadoc and jxr reports are very different due to css and images. It would be best if these look the same. was: Right now jxr still uses the classes javadoc style. However, if the project is built with jdk7 or jdk8, the results of the javadoc and jxr reprots are very different due to css and images. It would be best if these look the same. > Use equivalent css/images of javadoc > > > Key: JXR-110 > URL: https://issues.apache.org/jira/browse/JXR-110 > Project: Maven JXR > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Robert Scholte >Priority: Major > > Right now jxr still uses the classes javadoc style. However, if the project > is built with jdk7 or jdk8, the results of the javadoc and jxr reports are > very different due to css and images. > It would be best if these look the same. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJDEPS-16) Include project dependencies in scan
[
https://issues.apache.org/jira/browse/MJDEPS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583591#comment-16583591
]
Robert Scholte commented on MJDEPS-16:
--
[~KathrynNewbould] suggested that she might pick this one up.
> Include project dependencies in scan
>
>
> Key: MJDEPS-16
> URL: https://issues.apache.org/jira/browse/MJDEPS-16
> Project: Maven JDeps Plugin
> Issue Type: New Feature
>Affects Versions: 3.1.1
> Environment: Apache Maven 3.5.3
> (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> Maven home: /Users/aalmiray/.sdkman/candidates/maven/current
> Java version: 1.8.0_171, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre
> Default locale: en_CH, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.5", arch: "x86_64", family: "mac"
>Reporter: Andres Almiray
>Assignee: Robert Scholte
>Priority: Major
> Labels: up-for-grabs
>
>
> Version 3.1.1 executes jdeps on production (goal: jdkinternals) and test
> (goal: test-jdkinternals) sources but does not consider dependencies. This
> means the report will tell you if product sources are complaint or not but
> does not tell you if the packaged/deployed project would encounter problems
> or not.
> At the very least Compile/Runtime dependencies should be scanned. Please make
> this the default behavior. Perhaps it would be good to have a flag to skip
> this behavior if anyone would like to have the previous behavior.
> For reference, this issue was discussed with Robert Scholte during JCrete
> 2018.
> *Minimum POM example:*
> {code:java}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
> 4.0.0
> com.acme
> sample
> jar
> 0.0.0-SNAPSHOT
>
>
>
> org.apache.maven.plugins
> maven-jdeps-plugin
> 3.1.1
>
>
>
> jdkinternals
>
>
>
>
>
>
>
>
> com.google.inject
> guice
> 4.2.0
>
>
> com.google.guava
> guava
> 25.1-jre
>
>
>
> {code}
> Output
> {code:java}
> $ mvn jdeps:jdkinternals
> [INFO] Scanning for projects...
> [INFO]
> [INFO] --< com.acme:sample
> >---
> [INFO] Building sample 0.0.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-jdeps-plugin:3.1.1:jdkinternals (default-cli) @ sample ---
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.506 s
> [INFO] Finished at: 2018-07-27T09:50:39+02:00
> [INFO]
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-534) Support element-list links from java10 dependencies
[
https://issues.apache.org/jira/browse/MJAVADOC-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MJAVADOC-534:
Labels: jdk10 up-for-grabs (was: jdk10)
> Support element-list links from java10 dependencies
> ---
>
> Key: MJAVADOC-534
> URL: https://issues.apache.org/jira/browse/MJAVADOC-534
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Reporter: Matt Nelson
>Priority: Major
> Labels: jdk10, up-for-grabs
>
> Java 10+ produces[1,2,3] {{element-list}} instead of {{package-list}} files.
> The plugin assumes[4,5] {{package-list}} is quite a few places.
> [1] https://bugs.openjdk.java.net/browse/JDK-8191363
> [2]
> https://docs.oracle.com/javase/10/tools/javadoc.htm#GUID-9D532574-1CDB-4D30-99F3-A308DCAEE55F__GUID-29EABEE0-310E-4131-9577-8B2CE569992A
> [3]
> https://stackoverflow.com/questions/49457896/cant-link-to-jdk10-in-javadoc-comments
> [4]
> https://github.com/apache/maven-javadoc-plugin/blob/maven-javadoc-plugin-3.0.1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
> [5 ]
> https://github.com/apache/maven-javadoc-plugin/search?utf8=%E2%9C%93=package-list
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6460) Maven resolves old snapshot jars when an artifact changes from jar to pom deployment
[
https://issues.apache.org/jira/browse/MNG-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583580#comment-16583580
]
Robert Scholte commented on MNG-6460:
-
Maven doesn't care about the type of dependencies, that's all the
responsibility of the user. You can even add {{sh}} or
{{cmd}} as dependencies if they exist.
Maven dependency resolution has 2 phases: collection and resolution, and
depending on the plugin none, only collection or both are done. Collection will
only download pom files, since every dependency will have such file. Resolution
will download the matching artifacts based on the type.
Unless I've misunderstood the issue, I wouldn't call this a bug but "works as
designed".
> Maven resolves old snapshot jars when an artifact changes from jar to pom
> deployment
>
>
> Key: MNG-6460
> URL: https://issues.apache.org/jira/browse/MNG-6460
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.5.0
>Reporter: Andy Grove
>Priority: Major
>
> I have two projects, A and B.
> A started out as a simple project with single pom with jar packaging.
> B had a dependency on A.
> A was refactored to be multi module where each module has jar packaging. The
> parent pom now has pom packaging.
> After building A and deploying new artifacts to artifactory, and making
> changes to B's pom I saw compilation errors with references to to the old A
> and the new A.
> I eventually realized that B still had a reference to the original artifact
> from A (which was originally had jar packaging but now has pom packaging).
> Even though the latest snapshot for the parent pom in A was correctly
> published with pom packaging and no corresponding jar file, the
> maven-dependency-plugin was resolving the jar file from the previous snapshot
> release from before the refactor.
> This seems like a bug to me. It should have looked at the pom for the latest
> snapshot and seen that it had pom packaging and then failed to resolve the
> jar.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1550) The surefire XSD published on maven site lacks of some rerun element
[ https://issues.apache.org/jira/browse/SUREFIRE-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583502#comment-16583502 ] ASF GitHub Bot commented on SUREFIRE-1550: -- Tibor17 commented on issue #192: [SUREFIRE-1550] The surefire XSD published on maven site lacks of some URL: https://github.com/apache/maven-surefire/pull/192#issuecomment-413783931 Not sure if this would be possible with current ASF Pipeline. 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 > The surefire XSD published on maven site lacks of some rerun element > > > Key: SUREFIRE-1550 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1550 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.22.0 >Reporter: Nikolas Falco >Assignee: Tibor Digana >Priority: Minor > Fix For: 2.22.1 > > > The surefire XSD published on maven site lacks of most XML element created in > case of rerun count is defined. > Actually in the XSD only rerunFailure is defined. Are missing rerunError, > flakyError and flakyFailure elements described > [here|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] Tibor17 commented on issue #192: [SUREFIRE-1550] The surefire XSD published on maven site lacks of some
Tibor17 commented on issue #192: [SUREFIRE-1550] The surefire XSD published on maven site lacks of some URL: https://github.com/apache/maven-surefire/pull/192#issuecomment-413783931 Not sure if this would be possible with current ASF Pipeline. 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
