[GitHub] [maven-filtering] olamy commented on a change in pull request #13: replace deprecated code in favor of Java 7 core and apache commons libraries
olamy commented on a change in pull request #13: URL: https://github.com/apache/maven-filtering/pull/13#discussion_r456840568 ## File path: src/test/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFilteringTest.java ## @@ -758,20 +752,20 @@ private void createTestDataStructure( File sourceDirectory ) File dir1 = new File( sourceDirectory, "dir1" ); dir1.mkdirs(); -FileUtils.fileWrite( new File( dir1, "foo.txt" ), "UTF-8", "This is a Test File" ); +FileUtils.write( new File( dir1, "foo.txt" ), "This is a Test File", "UTF-8" ); File emptyDirectory = new File( sourceDirectory, "empty-directory" ); emptyDirectory.mkdirs(); -FileUtils.fileWrite( new File( emptyDirectory, ".gitignore" ), "UTF-8", "# .gitignore file" ); +FileUtils.write( new File( emptyDirectory, ".gitignore" ), "# .gitignore file", "UTF-8" ); File emptyDirectoryChild = new File( sourceDirectory, "empty-directory-child" ); emptyDirectory.mkdirs(); File emptyDirectoryChildEmptyChild = new File( emptyDirectoryChild, "empty-child" ); emptyDirectoryChildEmptyChild.mkdirs(); -FileUtils.fileWrite( new File( emptyDirectoryChildEmptyChild, ".gitignore" ), "UTF-8", "# .gitignore file" ); +FileUtils.write( new File( emptyDirectoryChildEmptyChild, ".gitignore" ), "# .gitignore file", "UTF-8" ); Review comment: simply using Files.write could avoid external dependencies This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[jira] [Updated] (SUREFIRE-1820) Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
[
https://issues.apache.org/jira/browse/SUREFIRE-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1820:
---
Fix Version/s: 3.0.0-M6
> Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
>
>
> Key: SUREFIRE-1820
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1820
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.0.0-M5
>Reporter: Robert Varga
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> Attempting to use TCP channels for communication with JDK 1.8 results in the
> following splat:
> {noformat}
> xception in thread "commands-fork-1" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:76)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:44)
> at
> org.apache.maven.plugin.surefire.extensions.StreamFeeder.run(StreamFeeder.java:92)
> Exception in thread "fork-1-event-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.decode(EventConsumerThread.java:140)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:113)
> Exception in thread "fork-1-err-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleReadableChannel.read(AbstractNoninterruptibleReadableChannel.java:54)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:274)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.Reader.read(Reader.java:100)
> at java.util.Scanner.readInput(Scanner.java:804)
> at java.util.Scanner.findWithinHorizon(Scanner.java:1685)
> at java.util.Scanner.hasNextLine(Scanner.java:1500)
> at
> org.apache.maven.surefire.extensions.util.LineConsumerThread.run(LineConsumerThread.java:67)
> {noformat}
> at least in the following configuration:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default) on
> project pt-triemap: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /home/nite/pt/triemap/pt-triemap/target/surefire-reports for the individual
> test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> [ERROR] Command was /bin/sh -c cd /home/nite/pt/triemap/pt-triemap &&
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64/jre/bin/java -jar
> /home/nite/pt/triemap/pt-triemap/target/surefire/surefirebooter5389144270021152085.jar
> /home/nite/pt/triemap/pt-triemap/target/surefire
> 2020-07-14T09-05-53_813-jvmRun1 surefire4432899852251024839tmp
> surefire_06735691049687446297tmp{noformat}
> Based on the discussion here:
> [https://github.com/eclipse/jetty.project/issues/3244] , it would seem the
> cause is that surefire release was compiled with JDK9+ without setting
> --release to 8-or-lower.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SUREFIRE-1826) Improved performance of ThreadedStreamConsumer
Tibor Digana created SUREFIRE-1826: -- Summary: Improved performance of ThreadedStreamConsumer Key: SUREFIRE-1826 URL: https://issues.apache.org/jira/browse/SUREFIRE-1826 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin, Maven Surefire Plugin, process forking Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 3.0.0-M6 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] cstamas commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
cstamas commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r456833473
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultSyncContextFactory.java
##
@@ -28,31 +30,59 @@
import org.eclipse.aether.artifact.Artifact;
import org.eclipse.aether.impl.SyncContextFactory;
import org.eclipse.aether.metadata.Metadata;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import com.google.inject.Singleton;
/**
- * A factory to create synchronization contexts. This default implementation
actually does not provide any real
- * synchronization but merely completes the repository system.
+ * A factory to create synchronization contexts. This default implementation
uses fair global locking
+ * based on {@link ReentrantReadWriteLock}. Explicit artifacts and metadata
passed are ignored.
*/
@Named
+@Singleton
public class DefaultSyncContextFactory
implements SyncContextFactory
{
+private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock(
true );
public SyncContext newInstance( RepositorySystemSession session, boolean
shared )
{
-return new DefaultSyncContext();
+return new DefaultSyncContext( shared ? lock.readLock() :
lock.writeLock(), shared );
}
static class DefaultSyncContext
implements SyncContext
{
+private static final Logger LOGGER = LoggerFactory.getLogger(
DefaultSyncContext.class );
+
+private final Lock lock;
+private final boolean shared;
+private int lockHoldCount;
+
+DefaultSyncContext( Lock lock, boolean shared )
+{
+this.lock = lock;
+this.shared = shared;
+}
public void acquire( Collection artifact,
Collection metadata )
{
+LOGGER.trace( "Acquiring global {} lock (currently held: {})",
+ shared ? "read" : "write", lockHoldCount );
+lock.lock();
Review comment:
Without having knowledge about use of SyncConext API and it's usage, I
don't quite get: with CountDownLatch, how would you know how many to count down
upfront?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
[jira] [Created] (MCOMPILER-425) Compiler argument with newline treated as multiple arguments in fork mode
David Phillips created MCOMPILER-425:
Summary: Compiler argument with newline treated as multiple
arguments in fork mode
Key: MCOMPILER-425
URL: https://issues.apache.org/jira/browse/MCOMPILER-425
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.8.1
Reporter: David Phillips
In the below example, we want to pass the second argument as a single argument
to the compiler, but we add newlines in the XML for readability. This works
correctly when not forking, but when forking, the argument is treated as
multiple arguments.
{code:xml}
true
-XDcompilePolicy=simple
-Xplugin:ErrorProne
-Xep:ObjectToString:ERROR
com.google.errorprone
error_prone_core
2.4.0
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SUREFIRE-1825) Unable to zip the Cucumber TXT report file on Linux and MacOS
Tibor Digana created SUREFIRE-1825:
--
Summary: Unable to zip the Cucumber TXT report file on Linux and
MacOS
Key: SUREFIRE-1825
URL: https://issues.apache.org/jira/browse/SUREFIRE-1825
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin, Maven Surefire Plugin
Environment: Nix systems
Reporter: Tibor Digana
Assignee: Tibor Digana
Fix For: 3.0.0-M6
We have the GitHub Workflow (CI system) and we are not able to upload the
artifacts because the TXT file contains illegal characters.
{noformat}
Run actions/upload-artifact@v2-preview
With the provided path, there will be 20483 files uploaded
##[error]Artifact path is not valid:
/JUnit47WithCucumberIT_testWithParallelClasses/target/surefire-reports/Scenario:
Do a failing test.txt. Contains character: ":". Invalid characters include:
",:,<,>,|,*,?.
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MRESOURCES-232) Resource copy filtering should use different encoding for source and output
[
https://issues.apache.org/jira/browse/MRESOURCES-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg reassigned MRESOURCES-232:
--
Fix Version/s: (was: 3.2.0)
Assignee: (was: Dennis Lundberg)
> Resource copy filtering should use different encoding for source and output
> ---
>
> Key: MRESOURCES-232
> URL: https://issues.apache.org/jira/browse/MRESOURCES-232
> Project: Maven Resources Plugin
> Issue Type: New Feature
> Components: copy, filtering
>Affects Versions: 3.0.1
> Environment: Ubuntu 16.04 JDK 1.8 maven 3.3.4
>Reporter: Peng Cheng
>Priority: Major
> Labels: maven
>
> In copy-resources goal. The configuration option 'encoding' is documented to
> be capable of changing the encoding of source files and copy to output
> directory, e.g.:
> {code}
>
>
> ${project.basedir}/sbin-ebcdic
>
>
> ${project.basedir}/sbin
>
>
> IBM037
>
> {code}
> However, it is pointed out in the answer section of this post:
> http://stackoverflow.com/questions/40095716/why-maven-resources-plugin-ignores-my-charset-encoding-setting
> that this option affects both reading of source file and writing of output
> file, resulting in most of the file encodings not converted. This should be
> corrected by dividing this option into 2:
> sourceEncoding & outputEncoding, which controls reading and writing
> separately. This is the most simple way to make encoding conversion practical.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-script-interpreter] dependabot[bot] commented on pull request #10: Bump groovy from 2.4.16 to 2.5.12
dependabot[bot] commented on pull request #10: URL: https://github.com/apache/maven-script-interpreter/pull/10#issuecomment-660488133 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-script-interpreter] asfgit closed pull request #10: Bump groovy from 2.4.16 to 2.5.12
asfgit closed pull request #10: URL: https://github.com/apache/maven-script-interpreter/pull/10 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-script-interpreter] asfgit closed pull request #9: Bump ant from 1.8.1 to 1.9.15
asfgit closed pull request #9: URL: https://github.com/apache/maven-script-interpreter/pull/9 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-script-interpreter] dependabot[bot] commented on pull request #9: Bump ant from 1.8.1 to 1.9.15
dependabot[bot] commented on pull request #9: URL: https://github.com/apache/maven-script-interpreter/pull/9#issuecomment-660488198 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[jira] [Created] (MJAVADOC-656) Following redirects breaks valid links
Robert Važan created MJAVADOC-656: - Summary: Following redirects breaks valid links Key: MJAVADOC-656 URL: https://issues.apache.org/jira/browse/MJAVADOC-656 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 3.2.0, 3.0.1 Reporter: Robert Važan Version 3.0.1 fixed #427 by following redirects. This feature unfortunately breaks when HTTP server is configured as follows: /apidocs/package-list -> 200 /apidocs -> 301 /apidocs/com/example/package-summary.html /apidocs/ -> 301 /apidocs/com/example/package-summary.html /apidocs/com/example/package-summary.html -> 200 Without following redirects (in version 3.0.0), the link is passed to javadoc tool unchanged, the javadoc tool fetches /apidocs/package-list, and everything works fine. Since 3.0.1, javadoc plugin follows one of the redirects (/apidocs or /apidocs/), passes the package summary URL to javadoc tool, which then fails like this: [WARNING] javadoc: warning - Error fetching URL: [https://example.com/apidocs/com/example/package-summary.html/] And if you have failOnWarnings set to true, this will fail the whole build. The solution is fairly simple. Construct the whole URL (.../package-list) and follow redirects on that one. Then check whether the final destination ends in /package-list, strip the /package-list suffix, and pass the result to the javadoc tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] Tibor17 commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
Tibor17 commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r456789312
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultSyncContextFactory.java
##
@@ -28,31 +30,59 @@
import org.eclipse.aether.artifact.Artifact;
import org.eclipse.aether.impl.SyncContextFactory;
import org.eclipse.aether.metadata.Metadata;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import com.google.inject.Singleton;
/**
- * A factory to create synchronization contexts. This default implementation
actually does not provide any real
- * synchronization but merely completes the repository system.
+ * A factory to create synchronization contexts. This default implementation
uses fair global locking
+ * based on {@link ReentrantReadWriteLock}. Explicit artifacts and metadata
passed are ignored.
*/
@Named
+@Singleton
public class DefaultSyncContextFactory
implements SyncContextFactory
{
+private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock(
true );
public SyncContext newInstance( RepositorySystemSession session, boolean
shared )
{
-return new DefaultSyncContext();
+return new DefaultSyncContext( shared ? lock.readLock() :
lock.writeLock(), shared );
}
static class DefaultSyncContext
implements SyncContext
{
+private static final Logger LOGGER = LoggerFactory.getLogger(
DefaultSyncContext.class );
+
+private final Lock lock;
+private final boolean shared;
+private int lockHoldCount;
+
+DefaultSyncContext( Lock lock, boolean shared )
+{
+this.lock = lock;
+this.shared = shared;
+}
public void acquire( Collection artifact,
Collection metadata )
{
+LOGGER.trace( "Acquiring global {} lock (currently held: {})",
+ shared ? "read" : "write", lockHoldCount );
+lock.lock();
Review comment:
@michael-o
@elharo
See my comment above as well
https://github.com/apache/maven-resolver/pull/65/commits/782659ac9a7e708bc61695c964cf0bf9646f652d#r456789040.
I think all you wanted to use was the `CountDownLatch`.
In case you are wishing to use the Java Concurrency API, pls ping me on the
Slack! I have very long experiences with this API.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
[GitHub] [maven-resolver] Tibor17 commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
Tibor17 commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r456789312
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultSyncContextFactory.java
##
@@ -28,31 +30,59 @@
import org.eclipse.aether.artifact.Artifact;
import org.eclipse.aether.impl.SyncContextFactory;
import org.eclipse.aether.metadata.Metadata;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import com.google.inject.Singleton;
/**
- * A factory to create synchronization contexts. This default implementation
actually does not provide any real
- * synchronization but merely completes the repository system.
+ * A factory to create synchronization contexts. This default implementation
uses fair global locking
+ * based on {@link ReentrantReadWriteLock}. Explicit artifacts and metadata
passed are ignored.
*/
@Named
+@Singleton
public class DefaultSyncContextFactory
implements SyncContextFactory
{
+private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock(
true );
public SyncContext newInstance( RepositorySystemSession session, boolean
shared )
{
-return new DefaultSyncContext();
+return new DefaultSyncContext( shared ? lock.readLock() :
lock.writeLock(), shared );
}
static class DefaultSyncContext
implements SyncContext
{
+private static final Logger LOGGER = LoggerFactory.getLogger(
DefaultSyncContext.class );
+
+private final Lock lock;
+private final boolean shared;
+private int lockHoldCount;
+
+DefaultSyncContext( Lock lock, boolean shared )
+{
+this.lock = lock;
+this.shared = shared;
+}
public void acquire( Collection artifact,
Collection metadata )
{
+LOGGER.trace( "Acquiring global {} lock (currently held: {})",
+ shared ? "read" : "write", lockHoldCount );
+lock.lock();
Review comment:
@michael-o
@elharo
See my comment above as well
https://github.com/apache/maven-resolver/pull/65/commits/782659ac9a7e708bc61695c964cf0bf9646f652d#r456789040.
I think all you wanted was the `CountDownLatch`.
In case you are wishing to use the Java Concurrency API, pls ping me on the
Slack! I have very long experiences with this API.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
[GitHub] [maven-resolver] Tibor17 commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
Tibor17 commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r456789312
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultSyncContextFactory.java
##
@@ -28,31 +30,59 @@
import org.eclipse.aether.artifact.Artifact;
import org.eclipse.aether.impl.SyncContextFactory;
import org.eclipse.aether.metadata.Metadata;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import com.google.inject.Singleton;
/**
- * A factory to create synchronization contexts. This default implementation
actually does not provide any real
- * synchronization but merely completes the repository system.
+ * A factory to create synchronization contexts. This default implementation
uses fair global locking
+ * based on {@link ReentrantReadWriteLock}. Explicit artifacts and metadata
passed are ignored.
*/
@Named
+@Singleton
public class DefaultSyncContextFactory
implements SyncContextFactory
{
+private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock(
true );
public SyncContext newInstance( RepositorySystemSession session, boolean
shared )
{
-return new DefaultSyncContext();
+return new DefaultSyncContext( shared ? lock.readLock() :
lock.writeLock(), shared );
}
static class DefaultSyncContext
implements SyncContext
{
+private static final Logger LOGGER = LoggerFactory.getLogger(
DefaultSyncContext.class );
+
+private final Lock lock;
+private final boolean shared;
+private int lockHoldCount;
+
+DefaultSyncContext( Lock lock, boolean shared )
+{
+this.lock = lock;
+this.shared = shared;
+}
public void acquire( Collection artifact,
Collection metadata )
{
+LOGGER.trace( "Acquiring global {} lock (currently held: {})",
+ shared ? "read" : "write", lockHoldCount );
+lock.lock();
Review comment:
@michael-o
@elharo
See my comment above as well
https://github.com/apache/maven-resolver/pull/65/commits/782659ac9a7e708bc61695c964cf0bf9646f652d#r456789040.
I think all you wanted was the `CountDownLatch`.
In can you are wishing to use Java Concurrency API, pls ping me on the
Slack! I have very long experiences with this API.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
[GitHub] [maven-resolver] Tibor17 commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
Tibor17 commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r456789040
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultSyncContextFactory.java
##
@@ -28,31 +30,59 @@
import org.eclipse.aether.artifact.Artifact;
import org.eclipse.aether.impl.SyncContextFactory;
import org.eclipse.aether.metadata.Metadata;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import com.google.inject.Singleton;
/**
- * A factory to create synchronization contexts. This default implementation
actually does not provide any real
- * synchronization but merely completes the repository system.
+ * A factory to create synchronization contexts. This default implementation
uses fair global locking
+ * based on {@link ReentrantReadWriteLock}. Explicit artifacts and metadata
passed are ignored.
*/
@Named
+@Singleton
public class DefaultSyncContextFactory
implements SyncContextFactory
{
+private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock(
true );
public SyncContext newInstance( RepositorySystemSession session, boolean
shared )
{
-return new DefaultSyncContext();
+return new DefaultSyncContext( shared ? lock.readLock() :
lock.writeLock(), shared );
}
static class DefaultSyncContext
implements SyncContext
{
+private static final Logger LOGGER = LoggerFactory.getLogger(
DefaultSyncContext.class );
+
+private final Lock lock;
+private final boolean shared;
+private int lockHoldCount;
+
+DefaultSyncContext( Lock lock, boolean shared )
+{
+this.lock = lock;
+this.shared = shared;
+}
public void acquire( Collection artifact,
Collection metadata )
{
+LOGGER.trace( "Acquiring global {} lock (currently held: {})",
+ shared ? "read" : "write", lockHoldCount );
+lock.lock();
Review comment:
This is really dangerous and antipattern because you here can call
lock/unlock in different threads since you have two methods. See the Javadoc.
It says to use try-finally. And it is because the method contaxt is always
called in one thread and that's the point of locking that you lock and unlock
your thread. But unparking another thread is dangerous.
Maybe change the API or the abstraction in this class but do not use these
principles.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
[jira] [Closed] (MNG-6963) mirrors and proxies options via profiles
[ https://issues.apache.org/jira/browse/MNG-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6963. --- Resolution: Duplicate > mirrors and proxies options via profiles > > > Key: MNG-6963 > URL: https://issues.apache.org/jira/browse/MNG-6963 > Project: Maven > Issue Type: New Feature > Components: core, Profiles >Reporter: John Patrick >Priority: Major > > Depending what office I'm working in, if I'm at home, if I'm a vpn or not I > have to change my mirror and proxy settings. > One office has a slow internet connection so has a local mirror (aka nexus). > Another office also has a local mirror (but artifactory not nexus) so it's on > a different url. > So being able to enable mirrors and proxies via profiles would be very > helpful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6963) mirrors and proxies options via profiles
[ https://issues.apache.org/jira/browse/MNG-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160417#comment-17160417 ] Michael Osipov commented on MNG-6963: - I think this has already been reported before. > mirrors and proxies options via profiles > > > Key: MNG-6963 > URL: https://issues.apache.org/jira/browse/MNG-6963 > Project: Maven > Issue Type: New Feature > Components: core, Profiles >Reporter: John Patrick >Priority: Major > > Depending what office I'm working in, if I'm at home, if I'm a vpn or not I > have to change my mirror and proxy settings. > One office has a slow internet connection so has a local mirror (aka nexus). > Another office also has a local mirror (but artifactory not nexus) so it's on > a different url. > So being able to enable mirrors and proxies via profiles would be very > helpful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-123) Provide a global locking sync context by default
[
https://issues.apache.org/jira/browse/MRESOLVER-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160413#comment-17160413
]
Hudson commented on MRESOLVER-123:
--
Build succeeded in Jenkins: Maven TLP » maven-resolver » master #96
See https://builds.apache.org/job/maven-box/job/maven-resolver/job/master/96/
> Provide a global locking sync context by default
>
>
> Key: MRESOLVER-123
> URL: https://issues.apache.org/jira/browse/MRESOLVER-123
> Project: Maven Resolver
> Issue Type: New Feature
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 1.5.0
>
> Attachments: checksum-error-debug.log, mvn-debug-1.4.3-123.txt.gz
>
>
> This is an umbrella ticket for a long standing issue with Maven Resolver: Our
> concurrency support is mediocre in a way that if two or more threads try to
> download the same file and fail to queue those write actions nicely. The
> problem is that The {{SyncContext}} and the its factory provided by Maven
> Resolver does not employ any locking at all. As layed out in detail in
> MRESOLVER-114 we need striped read write locks on artifacts and its metadata.
> This issue shall track progress on it. Even Takari Concurrent Repository
> extension does not help because it is only intended to synchronize concurrent
> access by multple JVMs and not threads.
> This improvement will provide solely a global locking sync context which will
> work in *single* JVM. It is a non-goal to make it work with mulitple JVMs. A
> downside of this solution is that is coarse, possible degregation of
> performance for the sake of stability.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MRESOLVER-114.
Resolution: Fixed
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: BasicRepositoryConnector.java,
> DefaultArtifactResolver.java, maven-debug-log.txt, mvn-build-120-sorted.txt,
> mvn-build-120.log, mvn-build-134-sorted.txt, mvn-build-134.log,
> mvn-build-144-sorted.txt, mvn-build-144.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> [2019-11-18T16:46:30.894Z] at
>
[jira] [Closed] (MRESOLVER-25) Resume support is broken under high concurrency
[
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MRESOLVER-25.
---
Resolution: Fixed
> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: dependency-list-x.zip, dependency-list.txt, out.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MRESOLVER-123) Provide a global locking sync context by default
[
https://issues.apache.org/jira/browse/MRESOLVER-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MRESOLVER-123.
Resolution: Fixed
Fixed with
[86654e04e4d05abc961e3fa1ae8ae875a85d4d76|https://gitbox.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=86654e04e4d05abc961e3fa1ae8ae875a85d4d76].
> Provide a global locking sync context by default
>
>
> Key: MRESOLVER-123
> URL: https://issues.apache.org/jira/browse/MRESOLVER-123
> Project: Maven Resolver
> Issue Type: New Feature
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 1.5.0
>
> Attachments: checksum-error-debug.log, mvn-debug-1.4.3-123.txt.gz
>
>
> This is an umbrella ticket for a long standing issue with Maven Resolver: Our
> concurrency support is mediocre in a way that if two or more threads try to
> download the same file and fail to queue those write actions nicely. The
> problem is that The {{SyncContext}} and the its factory provided by Maven
> Resolver does not employ any locking at all. As layed out in detail in
> MRESOLVER-114 we need striped read write locks on artifacts and its metadata.
> This issue shall track progress on it. Even Takari Concurrent Repository
> extension does not help because it is only intended to synchronize concurrent
> access by multple JVMs and not threads.
> This improvement will provide solely a global locking sync context which will
> work in *single* JVM. It is a non-goal to make it work with mulitple JVMs. A
> downside of this solution is that is coarse, possible degregation of
> performance for the sake of stability.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-resolver] asfgit closed pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
asfgit closed pull request #65: URL: https://github.com/apache/maven-resolver/pull/65 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-script-interpreter] dependabot[bot] closed pull request #7: Bump groovy from 2.4.16 to 3.0.0
dependabot[bot] closed pull request #7: URL: https://github.com/apache/maven-script-interpreter/pull/7 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-script-interpreter] dependabot[bot] closed pull request #8: Bump ant from 1.8.1 to 1.10.0
dependabot[bot] closed pull request #8: URL: https://github.com/apache/maven-script-interpreter/pull/8 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-script-interpreter] dependabot[bot] opened a new pull request #9: Bump ant from 1.8.1 to 1.9.15
dependabot[bot] opened a new pull request #9: URL: https://github.com/apache/maven-script-interpreter/pull/9 Bumps ant from 1.8.1 to 1.9.15. [](https://help.github.com/articles/configuring-automated-security-fixes) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-script-interpreter] dependabot[bot] commented on pull request #7: Bump groovy from 2.4.16 to 3.0.0
dependabot[bot] commented on pull request #7: URL: https://github.com/apache/maven-script-interpreter/pull/7#issuecomment-660469670 Looks like org.codehaus.groovy:groovy is no longer being updated by Dependabot, so this is no longer needed. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-script-interpreter] dependabot[bot] commented on pull request #8: Bump ant from 1.8.1 to 1.10.0
dependabot[bot] commented on pull request #8: URL: https://github.com/apache/maven-script-interpreter/pull/8#issuecomment-660469672 Looks like org.apache.ant:ant is no longer being updated by Dependabot, so this is no longer needed. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-script-interpreter] dependabot[bot] opened a new pull request #10: Bump groovy from 2.4.16 to 2.5.12
dependabot[bot] opened a new pull request #10: URL: https://github.com/apache/maven-script-interpreter/pull/10 Bumps [groovy](https://github.com/apache/groovy) from 2.4.16 to 2.5.12. Commits See full diff in https://github.com/apache/groovy/commits;>compare view [](https://help.github.com/articles/configuring-automated-security-fixes) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-script-interpreter] dependabot[bot] opened a new pull request #8: Bump ant from 1.8.1 to 1.10.0
dependabot[bot] opened a new pull request #8: URL: https://github.com/apache/maven-script-interpreter/pull/8 Bumps ant from 1.8.1 to 1.10.0. [](https://help.github.com/articles/configuring-automated-security-fixes) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-script-interpreter] dependabot[bot] opened a new pull request #7: Bump groovy from 2.4.16 to 3.0.0
dependabot[bot] opened a new pull request #7: URL: https://github.com/apache/maven-script-interpreter/pull/7 Bumps [groovy](https://github.com/apache/groovy) from 2.4.16 to 3.0.0. Commits See full diff in https://github.com/apache/groovy/commits;>compare view [](https://help.github.com/articles/configuring-automated-security-fixes) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-dependency-plugin] ThStock commented on pull request #76: avoid trailing whitespace
ThStock commented on pull request #76: URL: https://github.com/apache/maven-dependency-plugin/pull/76#issuecomment-660441146 Ping @michael-o This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
