[GitHub] [maven-resolver] michael-o commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661648420 Access to files is concurrent. 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-surefire] olamy commented on a change in pull request #308: [SUREFIRE-1827] The console output is not flushed
olamy commented on a change in pull request #308:
URL: https://github.com/apache/maven-surefire/pull/308#discussion_r457827367
##
File path:
surefire-booter/src/main/java/org/apache/maven/surefire/booter/spi/LegacyMasterProcessChannelProcessorFactory.java
##
@@ -36,8 +36,10 @@
* @since 3.0.0-M5
*/
public class LegacyMasterProcessChannelProcessorFactory
-implements MasterProcessChannelProcessorFactory
+extends AbstractMasterProcessChannelProcessorFactory
{
+private static final int FLUSH_PERIOD_MILLIS = 100;
Review comment:
would be good to have this configurable. At least
Integer.getInteger(""whatever name you like", 100)
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] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
Mark Nolan created MNG-6965:
---
Summary: archetype-packaging.jar:3.1.2 requires
org.codehaus.plexus:plexus-utils:jar:1.1
Key: MNG-6965
URL: https://issues.apache.org/jira/browse/MNG-6965
Project: Maven
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.6.3, 3.6.0
Environment: Win7, Win10, at least one variant of Linux (not sure
which)
Reporter: Mark Nolan
Attachments: pom.xml
A simple minimal archetype pom following the manual pages downloads
plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
version is banned at my organization, meaning such a pom always fails.
{{http://maven.apache.org/POM/4.0.0"}}
{{xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"}}
{{xsi:schemaLocation="http://maven.apache.org/POM/4.0.0}}
{{[http://maven.apache.org/xsd/maven-4.0.0.xsd];>}}
{{4.0.0}}
{{test}}
{{test}}
{{0.0.1-SNAPSHOT}}
{{maven-archetype}}
{{test}}
{{}}
{{ }}
{{}}
{{org.apache.maven.archetype}}
{{archetype-packaging}}
{{3.1.2}}
{{}}
{{}}
{{}}
{{}}
{{}}
{{org.apache.maven.plugins}}
{{maven-archetype-plugin}}
{{3.1.2}}
{{}}
{{}}
{{}}
{{}}
{{}}
Running any goal, such as mvn -X clean, produces the following before the goal
is executed:
{{[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
DefaultDependencyCollector.collectTime=66890900,
DefaultDependencyCollector.transformTime=8523500}}}
{{[DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:}}
{{[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:runtime}}
As far as I can see, there is no declared dependency on plexus-utils:1.1.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #308: [SUREFIRE-1827] The console output is not flushed
Tibor17 edited a comment on pull request #308:
URL: https://github.com/apache/maven-surefire/pull/308#issuecomment-661486443
@rmannibucau
I have added two unit tests. But the important thing is the manual test i
made. I have expected that you would like to make the same test on your PC. So
i changed my commit to 100 millis from previous 200 millis because 100 millis
makes the visual effect smooth. So i do not see the business value of config
paramter. I would not bother the user with more and more config params because
anyway they will be lost. Better if it just works with ideally no new config
params. This was my test:
```
for ( int i = 0; i < 100; i++ )
{
System.out.println(
"01234567890123456789012345678901234567890123456789" );
Thread.sleep(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-surefire] Tibor17 commented on pull request #308: [SUREFIRE-1827] The console output is not flushed
Tibor17 commented on pull request #308:
URL: https://github.com/apache/maven-surefire/pull/308#issuecomment-661486443
@rmannibucau
I have added two unit tests. But the important thing is the manual test i
made. I have expected that you would like to make the same test on your PC. So
i changed my commit to 100 millis from previous 200 millis because 100 millis
makes the visual effect smooth. So i do not see the business value of config
paramter. I would not bother the user with more and more config params because
anyway they will be lost. Better if it just works with ideally no new config
params. This was my test:
for ( int i = 0; i < 50; i++ )
```
{
System.out.println(
"01234567890123456789012345678901234567890123456789" );
Thread.sleep(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-resolver] Tibor17 commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
Tibor17 commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661477498 Then why we have the locks due to nothing is concurrent? 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] (MNG-6964) Maven version sorting is internally inconsistent
David M. Lloyd created MNG-6964:
---
Summary: Maven version sorting is internally inconsistent
Key: MNG-6964
URL: https://issues.apache.org/jira/browse/MNG-6964
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 3.6.3
Reporter: David M. Lloyd
There's a bug where version sorting is inconsistent. This manifests like this:
{code}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.alpha == 1-0.alpha
1-0.alpha == 1
2. 1 == 1
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.beta == 1-0.beta
1-0.beta == 1
2. 1 == 1
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1-0.alpha
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.beta == 1-0.beta
1-0.beta > 1-0.alpha
2. 1-0.alpha == 1-0.alpha
{code}
Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though both
{{1-0.beta}} and {{1.0.alpha}} are equal to {{1}}.
I think this is likely due to a logical bug where any dot-separated segments
following a zero or release ({{ga}} or {{final}}) is simply truncated in
certain circumstances:
{code}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.x == 1-0.x
1-0.x == 1-0
2. 1-0 == 1
{code}
but
{code}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.x-1 == 1-0.x-1
1-0.x-1 > 1-0-1
2. 1-0-1 == 1-1
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-resolver] michael-o commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661375379 acquire() is not. Neither is LockSyncContext. This is obvious from the docs. 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] (JXR-155) Unknown packaging waring for type bundle
Alexander Gängel created JXR-155: Summary: Unknown packaging waring for type bundle Key: JXR-155 URL: https://issues.apache.org/jira/browse/JXR-155 Project: Maven JXR Issue Type: Bug Components: maven2 jxr plugin Affects Versions: 3.0.0 Reporter: Alexander Gängel I have a project importing jackson-bom com.fasterxml.jackson jackson-bom 2.11.1 pom import this leads warnings when generation a maven site [WARNING] Unable to create Maven project for com.fasterxml.jackson.module:jackson-module-scala_2.13:jar:2.11.1 from repository. org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs: [ERROR] Unknown packaging: bundle @ line 6, column 16 Is it possible to add the type bundle or configure the plugin to allow this type Regards Alex -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] Tibor17 commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
Tibor17 commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661311488 Is the instance of `LockingSyncContext` concurrent? Is the `acquire` method concurrent? 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] michael-o commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661296728 @Tibor17 I thought the same, but that's not true because map is never shared, but scoped to the current thread. So the access is sequential. The `FileLockManager` has to be theadsafe. Put if absent would be necessary, if and only if the map would be in the factory and passed down to instances. Then I would agree with you. 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 edited a comment on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
Tibor17 edited a comment on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661295037 @rmannibucau i was talking to @michael-o about the `Map` , but having a look at the takari impl i have to say that they are not totally safe wit the [Line60](https://github.com/takari/takari-local-repository/blob/master/src/main/java/io/takari/aether/concurrency/LockingSyncContext.java#L60) because they rewrite the Map entry concurrently. They have to fix it by [Java 8 Functions and ConcurrentHampMap](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentMap.html#computeIfAbsent-K-java.util.function.Function-). 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] michael-o commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r457649439
##
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:
> We are downloading and writing a file. Writing a stream on the disk
must be treated by the write lock because it is exclusive lock
Correct.
> Where is the read lock used and why?
Please look into the code. I am not the caller, but the callee only.
> I guess this issue is about locking the writes to the disk from one JVM
but two or more threads.
Correct also.
> Additionally, the fairness must not be taken as any functionality. No
logic must rely on any fairness.
I take this as a fair point. This can be addressed in a separate
issue/release, but should not make any difference in regard of locking, but
order only.
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 pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
Tibor17 commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661295037 @rmannibucau i was talking to @michael-o about the Map but having a look at the takari impl i have to say that they are not totally safe wt the [Line60](https://github.com/takari/takari-local-repository/blob/master/src/main/java/io/takari/aether/concurrency/LockingSyncContext.java#L60) because they rewrite the Map entry concurrently. They have to fix it by [Java 8 Functions and ConcurrentHampMap](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentMap.html#computeIfAbsent-K-java.util.function.Function-). 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] michael-o edited a comment on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o edited a comment on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661291308 > Syncontext must be global if you want an useful global lock but it uses an int so it is not thread safe. If not global it does not impl its original goal so in all cases it looks incomplete. I absolutely do not agree with that. If SyncContext would be global one would not need the factory at all. It would be ridiculous. Reread the API requirements on SyncContext instances. The global lock resides in the singleton factory and it is used throughout. The int *is* threadsafe because it lives in the SyncContext instance only, it is not shared. Please provide a PR which depicts your understanding of the truth. > Do you have particular links? Also the point to enable to lock per artifact is not bound to these impl issues, the impl still proves there is no mem issue to do it https://github.com/takari/takari-local-repository/issues/12 as well as the MRESOLVER-123, -25 and -114. I requested to use the Takari extension in the spirit that it works. It turned out not to. Read through the discussions, take the time. 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] michael-o commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661291308 > Syncontext must be global if you want an useful global lock but it uses an int so it is not thread safe. If not global it does not impl its original goal so in all cases it looks incomplete. I absolutely do not agree with that. If SyncContext would be global one would not need the factory at all. It would be ridiculous. Reread the API requirements on SyncContext instances. The global lock resides in the singleton factory and it is used throughout. The int *is* threadsafe because it lives in the SyncContext instance only, it is not shared. Please provide a PR which depicts your understanding of the truth. > Do you have particular links? Also the point to enable to lock per artifact is not bound to these impl issues, the impl still proves there is no mem issue to do it https://github.com/takari/takari-local-repository/issues/12 as well as the MRESOLVER-123, -25 and -114. I requested to use the Takari extension in the spirit that it works. It turned out not to. Read through the discussions, take the time. 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] rmannibucau commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
rmannibucau commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661280048 2. Syncontext must be global if you want an useful global lock but it uses an int so it is not thread safe. If not global it does not impl its original goal so in all cases it looks incomplete. 3. Looked at github bugtracker as you requested and it does not look terrible and not worse that this PR was to me. Do you have particular links? Also the point to enable to lock per artifact is not bound to these impl issues, the impl still proves there is no mem issue to do it (was a point against it which is not justified technically so wanted to ensure we mark this topic as done). 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] michael-o commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661272254 Please explain point 2. Why do you consider it as non-thread safe? The lock itself is thread-safe and can be passed around. That's the hole point. The `SyncContext` does not has to be. 3. This one is broken too, mentioned numerous times in tickets and on GitHub. Why does 2 has to be compatible with 3? It has only to comply with the API contract. There is no current implementation, it is a no-op. Also there is no global locking API in the code whatsoever. The global locking is a design decision for this specific implementation. > I'd also add that on windows this kind of impl can just lock silently and never end (so can need a timeout?) :(. Please explain why this is a problem on Windows. 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-surefire] rmannibucau commented on pull request #308: [SUREFIRE-1827] The console output is not flushed
rmannibucau commented on pull request #308: URL: https://github.com/apache/maven-surefire/pull/308#issuecomment-661267659 Can be good to at least support a system property for flush interval and not leak the flush thread (stop the scheduler properly) but otherwise looks good. 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] [Commented] (SUREFIRE-1822) XML report with empty name attribute by 3.0.0-M5 when failing in @BeforeAll/@BeforeClass
[
https://issues.apache.org/jira/browse/SUREFIRE-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161421#comment-17161421
]
Tibor Digana commented on SUREFIRE-1822:
Regarding the option (2) the change between versions could happen only in
RunListenerAdapter.java.
So if we could make a diff, between the code which produced the name and the
HEAD, we would see the bug fixes (SUREFIRE-1688, SUREFIRE-1725, SUREFIRE-1741,
SUREFIRE-1793, SUREFIRE-1797).
> XML report with empty name attribute by 3.0.0-M5 when failing in
> @BeforeAll/@BeforeClass
>
>
> Key: SUREFIRE-1822
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1822
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, xml generation
>Affects Versions: 3.0.0-M5
>Reporter: Marc Guillemot
>Priority: Major
>
> If a JUnit test fails in @BeforeAll (or a JUnit 4 test in @BeforeClass), then
> Surefire reports it correctly on the console and fails the build (what was
> not the case with 3.0.0-M4 with @BeforeAll) *but the testcase name attribute
> in the XML report is now empty*:
> Example:
> {code:java}
>time="0.017">
> type="org.opentest4j.AssertionFailedError">
>
>
> {code}
> As a reference, Surefire 2.2 writes the same content in the classname and
> name attributes:
> {code:java}
>classname="test.TestJUnit5FailingInBeforeAll" time="0.016">
> type="org.opentest4j.AssertionFailedError">org.opentest4j.AssertionFailedError:
> Failure in @BeforeAll method
> at
> test.TestJUnit5FailingInBeforeAll.setup(TestJUnit5FailingInBeforeAll.java:14)
>
>
>
> {code}
> It is not really wrong to consider that the testcase node has no name here
> but it would be a change compared to prior versions that other systems need
> to handle (Jenkins for instance doesn't display the report correctly in this
> case).
> Bug or feature? If this considered as a bug, I can try to provide a patch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161363#comment-17161363
]
Gili commented on SUREFIRE-1811:
Is ClassGraph being loaded on the modulepath or classpath? You say it can see
the module, but that's not the same thing as saying it can find resources
inside that module. Can you prove that ClassGraph can see and open the contents
of the resource file when loaded on the modulepath?
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1811) Add resources to JPMS test module
[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161358#comment-17161358
]
Pavel_K commented on SUREFIRE-1811:
---
[~sor] It seems that we stopped. Can you suggest a solution to this issue?
> Add resources to JPMS test module
> -
>
> Key: SUREFIRE-1811
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Pavel_K
>Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main
> and one for test. My test project is here
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with
> resources. For example, I have src/main/resources/META-INF/persistence.xml
> file that is not copied to test module. Because of this it is not possible to
> find resource in test module and it is necessary to use something like this
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
> .
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home//hibernate-h2-test4/src/main/java,
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under
> test? I mean that test module will NOT contain
> /home//hibernate-h2-test4/src/main/resources?
> That's why I suggest to include src/main/resources in test module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-dependency-plugin] bimargulies-google commented on a change in pull request #80: [MDEP-708] dependency:analyze should recommend test scope where possible
bimargulies-google commented on a change in pull request #80: URL: https://github.com/apache/maven-dependency-plugin/pull/80#discussion_r457525286 ## File path: pom.xml ## @@ -427,14 +428,18 @@ under the License. tree-verbose/pom.xml
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #307: Change default debug options to not use legacy options
Tibor17 edited a comment on pull request #307: URL: https://github.com/apache/maven-surefire/pull/307#issuecomment-661116224 The GH workflows are really crappy. After the MSC has taken it, this CI is unreliable. The jobs are duplicated, the uploads are skipped on Win and MacOS and I do not see the logs if any build fails. I was working on it whole weekend and could not fix 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-surefire] Tibor17 commented on pull request #307: Change default debug options to not use legacy options
Tibor17 commented on pull request #307: URL: https://github.com/apache/maven-surefire/pull/307#issuecomment-661116224 The GH workflows are really crappy. After the MSC has taken it, this CI is unreliable. The jobs are duplicated, the uploads are skipped on Win and MacOS and I do not see the logs if any build fails. I was working on it whole weekend and could not make it working. 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-javadoc-plugin] elharo commented on pull request #31: [MJAVADOC-624] tagletArtifacts throws exception in case artifact is a Java 9+ module
elharo commented on pull request #31: URL: https://github.com/apache/maven-javadoc-plugin/pull/31#issuecomment-661115890 Tests failing: [ERROR] Errors: [ERROR] JavadocReportTest.testTagletArtifacts:1177 » MojoExecution An error has occurr... [INFO] [ERROR] Tests run: 69, Failures: 0, Errors: 1, Skipped: 0 [INFO] 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_r457495658
##
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
Can you explain the concept of clocking critical sections with read and
write lock separately? We are downloading and writing a file. Writing a stream
on the disk must be treated by the write lock because it is exclusive lock.
Where is the read lock used and why? I guess this issue is about locking the
writes to the disk from one JVM but two or more threads.
Additionally, the fairness must not be taken as any functionality. No logic
must rely on any fairness.
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] rmannibucau commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
rmannibucau commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661093235 Well there are multiple options: 1. Do nothing (we keep these issues) - don't think it would be good 2. Do a global not thread safe lock (and you fix a few issues but create new issues and slow down builds when enabled) 3. Do a concurrent lock mecanism (as https://github.com/takari/takari-local-repository/blob/master/src/main/java/io/takari/aether/concurrency/LockingSyncContext.java) I think 2 solves as much as it breaks so I'd like to ensure if it is done that it is compatible with 3. Current impl seems to stack workarounds (lock counter means locking is not cleanly handled in resolver, global locking API vs per artifact or worse case per groupId). I'd also add that on windows this kind of impl can just lock silently and never end (so can need a timeout?) :(. 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-surefire] Thihup edited a comment on pull request #307: Change default debug options to not use legacy options
Thihup edited a comment on pull request #307: URL: https://github.com/apache/maven-surefire/pull/307#issuecomment-661083926 @rmannibucau @Tibor17 I've changed to localhost:5005, however, some tests have failed and I couldn't understand why. Can you have a look? 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-surefire] Thihup commented on pull request #307: Change default debug options to not use legacy options
Thihup commented on pull request #307: URL: https://github.com/apache/maven-surefire/pull/307#issuecomment-661083926 @rmannibucau I've changed to localhost:5005, however, some tests have failed and I couldn't understand why. Can you have a look? 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-javadoc-plugin] XenoAmess edited a comment on pull request #48: [MJAVADOC-653] fix javadoc; fix code smells
XenoAmess edited a comment on pull request #48: URL: https://github.com/apache/maven-javadoc-plugin/pull/48#issuecomment-661078806 @elharo > Absent measurement, it can't be claimed that a PR improves performance; OK, if you see it this way I will not oppose. But I thought changes I made in JavadocUtil.java is easy to be think a performance refine. > and measuring these things is hard. Indeed. A good usecase for performance test can be very hard to built... 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-javadoc-plugin] XenoAmess commented on pull request #48: [MJAVADOC-653] fix javadoc; fix code smells
XenoAmess commented on pull request #48: URL: https://github.com/apache/maven-javadoc-plugin/pull/48#issuecomment-661078806 > Absent measurement, it can't be claimed that a PR improves performance; OK, if you see it this way I will not oppose. > and measuring these things is hard. Indeed. A good usecase for performance test can be very hard to built... 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-javadoc-plugin] XenoAmess edited a comment on pull request #48: [MJAVADOC-653] fix javadoc; fix code smells
XenoAmess edited a comment on pull request #48: URL: https://github.com/apache/maven-javadoc-plugin/pull/48#issuecomment-661078806 @elharo > Absent measurement, it can't be claimed that a PR improves performance; OK, if you see it this way I will not oppose. > and measuring these things is hard. Indeed. A good usecase for performance test can be very hard to built... 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-javadoc-plugin] elharo commented on pull request #48: [MJAVADOC-653] fix javadoc; fix code smells
elharo commented on pull request #48: URL: https://github.com/apache/maven-javadoc-plugin/pull/48#issuecomment-661071504 Absent measurement, it can't be claimed that a PR improves performance; and measuring these things is hard. 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-javadoc-plugin] XenoAmess commented on pull request #48: [MJAVADOC-653] fix javadoc; fix code smells; performance improvement
XenoAmess commented on pull request #48: URL: https://github.com/apache/maven-javadoc-plugin/pull/48#issuecomment-661070559 > Can you put numbers on the performance improvement? @elharo sorry but I didn't get what you mean by "put numbers on". If you need performance test then I think I can try make some jmh tests. But if you need real-time usecases performance test then I can't help with that. 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] michael-o commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661068773 Currently, there is nothing available: broken, see depending issues. Believe, most people don't even know how to enable something via extensions, they will simply file a bug. The only contention is during write and first resolution, but I have expressed several times in the ticket. What would you explicitly do now to the longstanding concurrency issues given that no one did anything at all, I don't expect anyone to add anything more sophisticated?! 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] michael-o commented on pull request #76: avoid trailing whitespace
michael-o commented on pull request #76:
URL:
https://github.com/apache/maven-dependency-plugin/pull/76#issuecomment-661065330
OK, went through the code, here it is:
```
if ( theOutputScope && artifact.isOptional() )
{
messageBuilder.a( " (optional) " );
}
// dependencies:collect won't download jars
if ( artifact.getFile() != null )
{
ModuleDescriptor moduleDescriptor = getModuleDescriptor(
artifact.getFile() );
if ( moduleDescriptor != null )
{
messageBuilder.project( " -- module " +
moduleDescriptor.name );
if ( moduleDescriptor.automatic )
{
if ( "MANIFEST".equals(
moduleDescriptor.moduleNameSource ) )
{
messageBuilder.strong( " [auto]" );
}
else
{
messageBuilder.warning( " (auto)" );
}
}
}
}
artifactStringList.add( messageBuilder.toString() +
System.lineSeparator() );
```
Let's dissect and discuss:
1. If it is not optional, we don't have a problem.
2. If it is optional and "artifact.getFile() == null" or "moduleDescriptor
== null" we'll see the trailing space. Since we'd have, in a positive case:
"(optional)-- module...". Why not simply remove the space from
the optional? @rfscholte @hboutemy Any objections? Is my analysis correct?
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] rmannibucau commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
rmannibucau commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661063742 @michael-o for me any provided impl must be concurrent friendly since it is a core feature of maven otherwise first bug is that the feature is not compatible wiht maven. A enabl-able global lock is ok for me while default impl is aligned on maven, this is my main concern. A first delivery with less features is acceptable while API enables to support it in a coming release. 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] rmannibucau commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
rmannibucau commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r457417864
##
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();
+lockHoldCount++;
}
public void close()
Review comment:
not really, client is the resolver here, it must be a resolver SPI and
it can should async friendly (for better concurrent downloads) IMHO. Also note
it is not worse than a close method.
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] michael-o commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661059577 @rmannibucau If you are unhappy with the SPI, create a JIRA issue we can discuss for Resolver 2.0. The SPI *does* support any kind of locks. I have chosen to provide the simplest one. What do you expect if the requirement says: "Provide a global locking sync context by default"? I do not really understand what you expect. 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] michael-o commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r457412151
##
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();
+lockHoldCount++;
}
public void close()
Review comment:
I cannot change the interface, even if the try-with-resources wouldn't
be usable anymore. You would move the task to the client to fiddle with
lowlevel locks. This makes no sense. Especially because an implementation is
not forced to implement the `Lock` interface.
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] rmannibucau commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
rmannibucau commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661057656 @michael-o fact is current API is not a SPI (as expected) but a specific impl for a global lock. I think this is wrong and is not what is epxected by such work. 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] rmannibucau commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
rmannibucau commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r457409869
##
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();
+lockHoldCount++;
}
public void close()
Review comment:
Since I proposed to not return void but actual locks (to handle errors)
then close() would be useless
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] michael-o commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r457405575
##
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 )
Review comment:
This one is also invalid. Read the specs:
> A synchronization context is meant to be utilized by only one thread and
as such is not thread-safe.
And this is how it works. Nothing is shared among threads.
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-surefire] Tibor17 commented on pull request #305: enable to flush regularly output of the forked process
Tibor17 commented on pull request #305: URL: https://github.com/apache/maven-surefire/pull/305#issuecomment-661052630 @eolivelli @rmannibucau welcome to the PR #308 . 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] michael-o commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r457403082
##
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 )
Review comment:
This point is invalid because you are questioning the interface
definition and the provided implementation. I am just doing what the interface
expects me to.
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] michael-o commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r457401794
##
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 )
Review comment:
This point is invalid because the JIRA issue clearly says that it will
provide a global lock. If you want to provide an additional
`SyncContextFactory` implementation we can easily add this as a separate module.
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-surefire] Tibor17 commented on pull request #308: [SUREFIRE-1827] The console output is not flushed
Tibor17 commented on pull request #308: URL: https://github.com/apache/maven-surefire/pull/308#issuecomment-661051683 Missing the unit tests for this functionality. I will work on it tomorrow. 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-surefire] Tibor17 opened a new pull request #308: [SUREFIRE-1827] The console output is not flushed
Tibor17 opened a new pull request #308: URL: https://github.com/apache/maven-surefire/pull/308 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] michael-o commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r457400875
##
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();
+lockHoldCount++;
}
public void close()
Review comment:
What would yo exactly drop? `acquire()` is `void`.
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] michael-o commented on pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
michael-o commented on pull request #65: URL: https://github.com/apache/maven-resolver/pull/65#issuecomment-661050855 @rmannibucau Thanks, looking trough..judging from your comments you have neither read the API contract not the JIRA issues. 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] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161244#comment-17161244
]
Dennis Lundberg commented on MRESOURCES-254:
I'm not sure that I understand.
Could you give an example?
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-848) Code Improvement in ReaderFactory to get rid of commons-io dependency
[
https://issues.apache.org/jira/browse/MSHARED-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161234#comment-17161234
]
Hudson commented on MSHARED-848:
Build succeeded in Jenkins: Maven TLP » maven-shared-utils » master #92
See
https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/92/
> Code Improvement in ReaderFactory to get rid of commons-io dependency
> -
>
> Key: MSHARED-848
> URL: https://issues.apache.org/jira/browse/MSHARED-848
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-shared-utils
>Affects Versions: maven-shared-utils-3.3.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-shared-utils-3.3.0
>
>
> Currently the dependency to:
> {code:xml}
>
> commons-io
> commons-io
> 2.6
>
> {code}
> is only needed within the class {{ReaderFactory}} which imports
> {{org.apache.commons.io.input.XmlStreamReader}}.
> The question: Can that being replace with something different. In consequence
> we could get rid of the dependency to {{commons-io}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-132) Copying of files with permissions broken
[
https://issues.apache.org/jira/browse/MRESOURCES-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161231#comment-17161231
]
Dennis Lundberg commented on MRESOURCES-132:
MRESOURCES-236 has been fixed and will be included in the upcoming version
3.2.0.
If you have the possiblility, please try 3.2.0-SNAPSHOT.
If you have comments, please do so in MRESOURCES-236.
> Copying of files with permissions broken
>
>
> Key: MRESOURCES-132
> URL: https://issues.apache.org/jira/browse/MRESOURCES-132
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 2.4.3
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300)
> Java version: 1.6.0_19
> Java home: /java/jdk1.6.0_19/jre
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux" version: "2.6.28.5" arch: "i386" Family: "unix"
>Reporter: Martin Todorov
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> Files with permissions are not copied with the permissions as illustrated
> below:
> {noformat}
> root@carlspring:/java/opensource/build-force/zipper-plugin# ls -al `find .
> -name *perm*`
> -rwxr--r-- 1 root root 8 2010-12-09 20:48
> ./src/test/resources/zip/file.with.permission.sh*
> -rw-r--r-- 1 root root 8 2010-12-09 22:56
> ./target/test-classes/zip/file.with.permission.sh
> {noformat}
> Notice the 'x' permission missing from the copied file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-shared-utils] elharo merged pull request #59: [MSHARED-848] deprecate XmlStreamReader
elharo merged pull request #59: URL: https://github.com/apache/maven-shared-utils/pull/59 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] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161228#comment-17161228
]
Andre Brait commented on MRESOURCES-254:
But then I won't be able to use the same property inside the POM.
Which means I would need to duplicate any property I generate that way if I
happen to also use it inside the pom.xml, right?
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1822) XML report with empty name attribute by 3.0.0-M5 when failing in @BeforeAll/@BeforeClass
[
https://issues.apache.org/jira/browse/SUREFIRE-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161227#comment-17161227
]
Marc Guillemot commented on SUREFIRE-1822:
--
Thanks for the link. I have already some experience with the events triggered
during test execution due to contributions to Ant JUnitLauncher task.
Option 3 being excluded, what is with the others?
> XML report with empty name attribute by 3.0.0-M5 when failing in
> @BeforeAll/@BeforeClass
>
>
> Key: SUREFIRE-1822
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1822
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, xml generation
>Affects Versions: 3.0.0-M5
>Reporter: Marc Guillemot
>Priority: Major
>
> If a JUnit test fails in @BeforeAll (or a JUnit 4 test in @BeforeClass), then
> Surefire reports it correctly on the console and fails the build (what was
> not the case with 3.0.0-M4 with @BeforeAll) *but the testcase name attribute
> in the XML report is now empty*:
> Example:
> {code:java}
>time="0.017">
> type="org.opentest4j.AssertionFailedError">
>
>
> {code}
> As a reference, Surefire 2.2 writes the same content in the classname and
> name attributes:
> {code:java}
>classname="test.TestJUnit5FailingInBeforeAll" time="0.016">
> type="org.opentest4j.AssertionFailedError">org.opentest4j.AssertionFailedError:
> Failure in @BeforeAll method
> at
> test.TestJUnit5FailingInBeforeAll.setup(TestJUnit5FailingInBeforeAll.java:14)
>
>
>
> {code}
> It is not really wrong to consider that the testcase node has no name here
> but it would be a change compared to prior versions that other systems need
> to handle (Jenkins for instance doesn't display the report correctly in this
> case).
> Bug or feature? If this considered as a bug, I can try to provide a patch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-archetype] elharo commented on pull request #54: Explicitly declare dependencies
elharo commented on pull request #54: URL: https://github.com/apache/maven-archetype/pull/54#issuecomment-661028920 PT failed on Windows Jdk 7 Jenkins node and passed on others. Rerunning. 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] (MRESOURCES-263) Use non-shapshot maven-filtering
[ https://issues.apache.org/jira/browse/MRESOURCES-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRESOURCES-263: --- Fix Version/s: 3.2.0 > Use non-shapshot maven-filtering > > > Key: MRESOURCES-263 > URL: https://issues.apache.org/jira/browse/MRESOURCES-263 > Project: Maven Resources Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Dennis Lundberg >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-filtering] elharo commented on a change in pull request #13: replace deprecated code in favor of Java 7 core and apache commons libraries
elharo commented on a change in pull request #13: URL: https://github.com/apache/maven-filtering/pull/13#discussion_r457363869 ## 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: not quite a 1:1 replacement. What we really need is Files.writeString from Java 11. We'd also need to change the File objects to Path objects. I'll leave this change for a separate PR if someone wants to take 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-javadoc-plugin] XenoAmess commented on a change in pull request #48: [MJAVADOC-653] fix javadoc; fix code smells; performance improvement
XenoAmess commented on a change in pull request #48: URL: https://github.com/apache/maven-javadoc-plugin/pull/48#discussion_r457360924 ## File path: src/test/java/org/apache/maven/plugins/javadoc/JavadocJarTest.java ## @@ -154,7 +154,7 @@ public void testInvalidDestdir() //check if the javadoc jar file was generated File generatedFile = new File( getBasedir(), "target/test/unit/javadocjar-invalid-destdir/target/javadocjar-invalid-destdir-javadoc.jar" ); -assertTrue( !FileUtils.fileExists( generatedFile.getAbsolutePath() ) ); +assertFalse(FileUtils.fileExists(generatedFile.getAbsolutePath())); Review comment: > please check here: https://maven.apache.org/developers/conventions/code.html @slachiewicz Thanks. btw is there anybody for more reviewings to this pr? 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-shared-utils] elharo merged pull request #58: remove call to deprecated method
elharo merged pull request #58: URL: https://github.com/apache/maven-shared-utils/pull/58 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] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161213#comment-17161213
]
Dennis Lundberg commented on MRESOURCES-254:
Okay I figured this out now.
maven-resource-plugin filters the files that needs to be filtered using the
filtering properties that it knows about. When doing that it is using the
delimiters specified. The defined in the pom.xml are given to the
plugin exactly as they are specified in the POM, except that properties used
inside another property are interpolated.
This means that in your project prop2="1-2" and prop3="1-${buildNumber}". These
are then passed to the resources plugin.
In your project the plugin will try to filter anything that matches the
delimiters @@. Even though there exists a filtering property called
buildNumber, it will not be used because prop3 does not have "@buildNumber@" in
it. It does however have "@{buildNumber}, but that is a no-op because the
default delimiters have been disabled.
The solution to your problem is that you need to use the same delimiters in the
values of the in the POM that you have configured the resource
plugin to use. You need to replace ${buildNumber} in the POM with
@buildNumber@, and then it will work.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MSHARED-431) # (Hash-Sign) should trigger quoting in BourneShell.java
[ https://issues.apache.org/jira/browse/MSHARED-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-431. --- Fix Version/s: maven-shared-utils-3.3.0 Resolution: Fixed > # (Hash-Sign) should trigger quoting in BourneShell.java > > > Key: MSHARED-431 > URL: https://issues.apache.org/jira/browse/MSHARED-431 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Affects Versions: maven-shared-utils-0.8 > Environment: Unix (Linux) >Reporter: Fritz Elfert >Priority: Major > Fix For: maven-shared-utils-3.3.0 > > > When trying to use the latest maven-jarsign-plugin using a keystore-password > which started with a hash (#), signing failed. After enabling debug output > with -X, I got a strange debug message: > [DEBUG] Option lacks argument > Since signtool is invoked using /bin/sh -c ..., of course, any # must be > quoted, because otherwise it acts as a comment-start and thus effectively > cuts-off the rest of the cmdline. > After single-quoting the password in the pom.xml, the jar signing was ok. > => > Adding '#' to BASH_QUOTING_TRIGGER_CHARS in > org.apache.maven.shared.utils.cli.shell.BourneShell.java should fix the > problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHARED-431) # (Hash-Sign) should trigger quoting in BourneShell.java
[ https://issues.apache.org/jira/browse/MSHARED-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-431. - > # (Hash-Sign) should trigger quoting in BourneShell.java > > > Key: MSHARED-431 > URL: https://issues.apache.org/jira/browse/MSHARED-431 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Affects Versions: maven-shared-utils-0.8 > Environment: Unix (Linux) >Reporter: Fritz Elfert >Priority: Major > Fix For: maven-shared-utils-3.3.0 > > > When trying to use the latest maven-jarsign-plugin using a keystore-password > which started with a hash (#), signing failed. After enabling debug output > with -X, I got a strange debug message: > [DEBUG] Option lacks argument > Since signtool is invoked using /bin/sh -c ..., of course, any # must be > quoted, because otherwise it acts as a comment-start and thus effectively > cuts-off the rest of the cmdline. > After single-quoting the password in the pom.xml, the jar signing was ok. > => > Adding '#' to BASH_QUOTING_TRIGGER_CHARS in > org.apache.maven.shared.utils.cli.shell.BourneShell.java should fix the > problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHARED-297) Commandline class shell injection vulnerabilities
[
https://issues.apache.org/jira/browse/MSHARED-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MSHARED-297:
--
Fix Version/s: maven-shared-utils-3.3.0
> Commandline class shell injection vulnerabilities
> -
>
> Key: MSHARED-297
> URL: https://issues.apache.org/jira/browse/MSHARED-297
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Reporter: Charles Duffy
>Priority: Critical
> Labels: SECURITY
> Fix For: maven-shared-utils-3.3.0
>
> Attachments: use-no-shell-r2.patch
>
>
> The Commandline class can emit double-quoted strings without proper escaping,
> allowing shell injection attacks.
> The BourneShell class should unconditionally single-quote emitted strings
> (including the name of the command itself being quoted), with {{'"'"'}} used
> for embedded single quotes, for maximum safety across shells implementing a
> superset of POSIX quoting rules.
> An appropriate fix has been built and applied against PLXUTILS; that patch is
> submitted here in the hope that it will be useful, though it is not expected
> to apply to the maven-shared-utils codebase without modification.
> See PLXUTILS-161 for history/discussion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MSHARED-297) Commandline class shell injection vulnerabilities
[
https://issues.apache.org/jira/browse/MSHARED-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MSHARED-297.
---
Resolution: Fixed
> Commandline class shell injection vulnerabilities
> -
>
> Key: MSHARED-297
> URL: https://issues.apache.org/jira/browse/MSHARED-297
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Reporter: Charles Duffy
>Priority: Critical
> Labels: SECURITY
> Attachments: use-no-shell-r2.patch
>
>
> The Commandline class can emit double-quoted strings without proper escaping,
> allowing shell injection attacks.
> The BourneShell class should unconditionally single-quote emitted strings
> (including the name of the command itself being quoted), with {{'"'"'}} used
> for embedded single quotes, for maximum safety across shells implementing a
> superset of POSIX quoting rules.
> An appropriate fix has been built and applied against PLXUTILS; that patch is
> submitted here in the hope that it will be useful, though it is not expected
> to apply to the maven-shared-utils codebase without modification.
> See PLXUTILS-161 for history/discussion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161177#comment-17161177
]
Dennis Lundberg edited comment on MRESOURCES-254 at 7/20/20, 12:47 PM:
---
Good example to test!
That fails as well.
So we have 3 things that together makes it fail:
* properties added by other plugins in combination with
* normal Maven properties
* using alternate delimiters
I'll do some digging in the source to see if I can find anything.
Forgot to say thank you for the test project! It really helps a lot.
was (Author: dennisl):
Good example to test! But it actually works fine.
So we have 3 things that together makes it fail:
* properties added by other plugins in combination with
* normal Maven properties
* using alternate delimiters
I'll do some digging in the source to see if I can find anything.
Forgot to say thank you for the test project! It really helps a lot.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSHARED-297) Commandline class shell injection vulnerabilities
[
https://issues.apache.org/jira/browse/MSHARED-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MSHARED-297.
-
> Commandline class shell injection vulnerabilities
> -
>
> Key: MSHARED-297
> URL: https://issues.apache.org/jira/browse/MSHARED-297
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Reporter: Charles Duffy
>Priority: Critical
> Labels: SECURITY
> Attachments: use-no-shell-r2.patch
>
>
> The Commandline class can emit double-quoted strings without proper escaping,
> allowing shell injection attacks.
> The BourneShell class should unconditionally single-quote emitted strings
> (including the name of the command itself being quoted), with {{'"'"'}} used
> for embedded single quotes, for maximum safety across shells implementing a
> superset of POSIX quoting rules.
> An appropriate fix has been built and applied against PLXUTILS; that patch is
> submitted here in the hope that it will be useful, though it is not expected
> to apply to the maven-shared-utils codebase without modification.
> See PLXUTILS-161 for history/discussion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-shared-utils] elharo opened a new pull request #59: [MSHARED-848] deprecate XmlStreamReader
elharo opened a new pull request #59: URL: https://github.com/apache/maven-shared-utils/pull/59 @dennisl 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-shared-utils] elharo opened a new pull request #58: remove call to deprecated method
elharo opened a new pull request #58: URL: https://github.com/apache/maven-shared-utils/pull/58 @dennisl 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] (MDEP-715) Hamcrest used and unsued
Elliotte Rusty Harold created MDEP-715: -- Summary: Hamcrest used and unsued Key: MDEP-715 URL: https://issues.apache.org/jira/browse/MDEP-715 Project: Maven Dependency Plugin Issue Type: Bug Components: analyze Reporter: Elliotte Rusty Harold This is something I've seen when analyzing several Maven plugins. For example, maven-shared-utils circa July 20, 2020: [WARNING] Used undeclared dependencies found: [WARNING] org.hamcrest:hamcrest:jar:2.2:test [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test [WARNING] Unused declared dependencies found: [WARNING] org.hamcrest:hamcrest-core:jar:2.2:test [WARNING] org.apache.maven:maven-core:jar:3.1.0:test [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided Easy fix, right? don't declare org.hamcrest:hamcrest-core:jar:2.2:test and instead declare org.hamcrest:hamcrest:jar:2.2:test But when I do that: [WARNING] Used undeclared dependencies found: [WARNING] org.hamcrest:hamcrest-core:jar:1.3:test [WARNING] org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M2a:test [WARNING] Unused declared dependencies found: [WARNING] org.hamcrest:hamcrest:jar:2.2:test [WARNING] org.apache.maven:maven-core:jar:3.1.0:test [WARNING] org.codehaus.plexus:plexus-container-default:jar:2.1.0:provided Figure out what's going on here and fix it. Is hamcrest-core needed and used or not? is hamcrest needed and used or not? Be consistent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-709) Adding maven-resolver-api to dependency plugin breaks tests
[ https://issues.apache.org/jira/browse/MDEP-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-709: --- Issue Type: Dependency upgrade (was: Bug) > Adding maven-resolver-api to dependency plugin breaks tests > --- > > Key: MDEP-709 > URL: https://issues.apache.org/jira/browse/MDEP-709 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Ian Lavallee >Priority: Major > > In order to re-add verbose tree functionality I use the maven-resolver-api. > However adding this to the maven-dependency-plugin breaks 54 unit tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-709) Adding maven-resolver-api to dependency plugin breaks tests
[ https://issues.apache.org/jira/browse/MDEP-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-709: --- Priority: Major (was: Blocker) > Adding maven-resolver-api to dependency plugin breaks tests > --- > > Key: MDEP-709 > URL: https://issues.apache.org/jira/browse/MDEP-709 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Ian Lavallee >Priority: Major > > In order to re-add verbose tree functionality I use the maven-resolver-api. > However adding this to the maven-dependency-plugin breaks 54 unit tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161177#comment-17161177
]
Dennis Lundberg commented on MRESOURCES-254:
Good example to test! But it actually works fine.
So we have 3 things that together makes it fail:
* properties added by other plugins in combination with
* normal Maven properties
* using alternate delimiters
I'll do some digging in the source to see if I can find anything.
Forgot to say thank you for the test project! It really helps a lot.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161171#comment-17161171
]
Andre Brait commented on MRESOURCES-254:
I guess adding
{code:xml}
${buildNumber}
{code}
And then
{noformat}
But this does: @prop6@
{noformat}
will also make it fail.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161168#comment-17161168
]
Andre Brait commented on MRESOURCES-254:
Sorry, I didn't get that you were still using my example.
Yes, compound properties themselves are ok. It's only an issue if the
properties have been added by a plugin.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161166#comment-17161166
]
Andre Brait commented on MRESOURCES-254:
In your test, have either prop1 or prop2 been added by a plugin?
It's not just buildnumber-maven-plugin. I've tested other plugins that add
properties and it's reproducible with all of them.
You can also try jgitver, for example.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] eolivelli commented on pull request #305: enable to flush regularly output of the forked process
eolivelli commented on pull request #305: URL: https://github.com/apache/maven-surefire/pull/305#issuecomment-660956655 @Tibor17 I left a minor comment on your PR. It is better that you open a new PR, this way it is easier to track comments and discussions. 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-surefire] Tibor17 commented on pull request #305: enable to flush regularly output of the forked process
Tibor17 commented on pull request #305: URL: https://github.com/apache/maven-surefire/pull/305#issuecomment-660949560 @rmannibucau @eolivelli Hye guys. Can you please make a code review for the [commit](https://github.com/apache/maven-surefire/commit/4b4eaf68baa64de6182ab49f8c1984e6da789da0)? It is the fix for this flush problem. I made a manual test 5 console lines and 320 thousands console lines too, and compared the behavior against the previous version. You will see optimization with calling the flush. Without it i felt the console was not that terribly fast as it is now ;-) 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] [Commented] (MRESOURCES-254) Filtering of compound properties using properties added by other plugins fails without ${*} delimiter
[
https://issues.apache.org/jira/browse/MRESOURCES-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161120#comment-17161120
]
Dennis Lundberg commented on MRESOURCES-254:
Hi,
I can confirm the results in your test project.
However if I add this property to the pom.xml
{code:xml}
${prop1}-${prop2}
{code}
and this to src/main/resources/someText.txt
{noformat}
But this does: @prop6@
{noformat}
the output for prop6 is correct, even when I set useDefaultDelimiters to false.
So maven-resources-plugin does have support for compound properties.
This makes me suspect that it might have something to do with
buildnumber-maven-plugin, but I haven't investigated that.
> Filtering of compound properties using properties added by other plugins
> fails without ${*} delimiter
> -
>
> Key: MRESOURCES-254
> URL: https://issues.apache.org/jira/browse/MRESOURCES-254
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: delimiters, filtering
>Affects Versions: 3.1.0
>Reporter: Andre Brait
>Priority: Major
> Attachments: test.zip
>
>
> How to reproduce:
> # Open the project I attached here
> # Run mvn clean compile
> # Check that the file target/classes/someText.txt has a compund property
> that was incorrectly filtered
> # Set useDefaultDelimiters to true and run mvn clean compile again
> # Check that the file target/classes/someText.txt was now filtered properly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-resolver] rmannibucau commented on a change in pull request #65: [MRESOLVER-123] Provide a global locking sync context by default
rmannibucau commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r457240942
##
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 )
Review comment:
1. Is the session needed there? can't it be injected?
2. Is shared needed there, shouldn't the context handle that since it is the
one holding the underlying lock
For me the factory should just load an impl and be useless if there is no
pluggability there, context is where the abstraction is (see next comment)
##
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 )
Review comment:
this class is not threadsafe but should be otherwise this default impl
does not work as soon as you use -T
##
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 )
{
+
[jira] [Commented] (MJAVADOC-656) Following redirects breaks valid links
[ https://issues.apache.org/jira/browse/MJAVADOC-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161097#comment-17161097 ] Robert Važan commented on MJAVADOC-656: --- The only machine-readable location included in javadocs is /package-list, which is what the underlying javadoc tool is accessing. Any machine-readable Javadocs deployment will have this location. Everything else is intended for humans and subject to site-specific customization. The root location that you are using now actually isn't part of javadocs at all. You are relying on the webserver to be configured to (1) append slash, (2) handle directory requests, and (3) serve index.html for directories. That's not a universal setup by any measure. Now of course if the site has broken redirects and it incorrectly redirects only the root location or it redirects everything to the new root location, then the change as proposed would break such setups, but then the original bugfix was intended for http -> https redirects, which generally preserve URL path. The problem with current behavior is that there is no way to workaround this in dependent projects. Specifying correct link in pom.xml (one that would work with the underlying javadoc tool) results in broken build. Even if the redirects don't work in all cases, specifying correct link should always work. The only way to ensure that is to use the /package-list location just like the underlying javadoc tool does. > 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.0.1, 3.2.0 >Reporter: Robert Važan >Priority: Minor > > 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-surefire] Tibor17 commented on pull request #217: [SUREFIRE-1635] Set properties readonly where it doesn't make sense to change values
Tibor17 commented on pull request #217: URL: https://github.com/apache/maven-surefire/pull/217#issuecomment-660930376 @britter Sorry, i was busy with another staff. I have checked the git history and i see the commit `a69f10f` for this issue. Are we missing any changes from this PR? 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] [Assigned] (MRESOURCES-263) Use non-shapshot maven-filtering
[ https://issues.apache.org/jira/browse/MRESOURCES-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg reassigned MRESOURCES-263: -- Assignee: Dennis Lundberg > Use non-shapshot maven-filtering > > > Key: MRESOURCES-263 > URL: https://issues.apache.org/jira/browse/MRESOURCES-263 > Project: Maven Resources Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Dennis Lundberg >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRESOURCES-210) copy-resources erases file permissions
[ https://issues.apache.org/jira/browse/MRESOURCES-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRESOURCES-210. -- Fix Version/s: 3.2.0 Assignee: Olivier Lamy Resolution: Fixed > copy-resources erases file permissions > -- > > Key: MRESOURCES-210 > URL: https://issues.apache.org/jira/browse/MRESOURCES-210 > Project: Maven Resources Plugin > Issue Type: Bug >Reporter: Volodymyr Kyrychenko >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.2.0 > > > rwx posix permission should be kept. There is possibility to do that now: > java.nio.file.Files.setPosixFilePermissions -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRESOURCES-236) Copying of files with permissions broken
[ https://issues.apache.org/jira/browse/MRESOURCES-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRESOURCES-236: --- Fix Version/s: 3.2.0 > Copying of files with permissions broken > > > Key: MRESOURCES-236 > URL: https://issues.apache.org/jira/browse/MRESOURCES-236 > Project: Maven Resources Plugin > Issue Type: Bug > Components: copy >Affects Versions: 2.4.3 >Reporter: Gili >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.2.0 > > > Please reopen MRESOURCES-132 as multiple reporters indicate that the bug > still exists (some provided more concrete repro steps). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRESOURCES-253) Convention over configuration of filtered resources
[
https://issues.apache.org/jira/browse/MRESOURCES-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MRESOURCES-253.
--
Resolution: Won't Fix
This needs to be fixed in maven core. See linked issue.
> Convention over configuration of filtered resources
> ---
>
> Key: MRESOURCES-253
> URL: https://issues.apache.org/jira/browse/MRESOURCES-253
> Project: Maven Resources Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 3.1.0
>Reporter: Hüseyin Kartal
>Priority: Major
>
> We would appreciate if there would be a convention for a resource folder that
> is filtered by convention. Like "resources-filtered" for main and test
> resources. Just omit bloated configurations.
> {{}}
> {{ }}
> {{ ${project.basedir}/src/main/resources}}
> {{ }}
> {{ }}
> {{ ${project.basedir}/src/main/resources-filtered}}
> {{ true}}
> {{ }}
> {{}}
> {{}}
> {{ }}
> {{ ${project.basedir}/src/test/resources}}
> {{ }}
> {{ }}
> {{ ${project.basedir}/src/test/resources-filtered}}
> {{ true}}
> {{ }}
> {{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MRESOURCES-258) Only overwrite filtered resources when contents differ
[
https://issues.apache.org/jira/browse/MRESOURCES-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MRESOURCES-258.
--
Fix Version/s: 3.2.0
Assignee: Olivier Lamy
Resolution: Fixed
> Only overwrite filtered resources when contents differ
> --
>
> Key: MRESOURCES-258
> URL: https://issues.apache.org/jira/browse/MRESOURCES-258
> Project: Maven Resources Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 3.1.0
>Reporter: Robert James Oxspring
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.2.0
>
>
> When using {{mvn resources:copy-resources}} with filtering enabled, the
> destination file should only be overwritten if the contents have changed.
> Given a {{mvn resources:copy-resources}} call with filtering configured
> When an identical {{mvn resources:copy-resources}} operation is performed
> Then the destination file should remain unmodified
> Given a {{mvn resources:copy-resources}} call with filtering configured and
> {{overwrite}} set {{true}}
> When an identical {{mvn resources:copy-resources}} operation is performed
> Then the destination file should be overwritten
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MRESOURCES-261) Make Maven 3.1.0 the minimum version
[ https://issues.apache.org/jira/browse/MRESOURCES-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRESOURCES-261. -- Fix Version/s: 3.2.0 Assignee: Elliotte Rusty Harold Resolution: Fixed > Make Maven 3.1.0 the minimum version > > > Key: MRESOURCES-261 > URL: https://issues.apache.org/jira/browse/MRESOURCES-261 > Project: Maven Resources Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg reassigned MRESOURCES-171: -- Assignee: Dennis Lundberg > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Assignee: Dennis Lundberg >Priority: Minor > Fix For: 3.2.0 > > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRESOURCES-171. -- Resolution: Fixed > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Assignee: Dennis Lundberg >Priority: Minor > Fix For: 3.2.0 > > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHARED-934) Allow using a different encoding when filtering properties files
[ https://issues.apache.org/jira/browse/MSHARED-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSHARED-934. --- Resolution: Fixed > Allow using a different encoding when filtering properties files > > > Key: MSHARED-934 > URL: https://issues.apache.org/jira/browse/MSHARED-934 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-filtering >Affects Versions: maven-filtering-3.1.1 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg >Priority: Major > Fix For: maven-filtering-3.2.0 > > > See MRESOURCES-171 for the full description of the problem. > We need to allow the plugin that uses maven-filtering to specify an encoding > to be used when filtering properties files, that is different from the > encoding used when filtering regular files. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-940) moduleSet - incorrect binary dependencies added to assembly
[ https://issues.apache.org/jira/browse/MASSEMBLY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161066#comment-17161066 ] Nigel Jones commented on MASSEMBLY-940: --- I also tried setting scope=provided in the dependency to see how that might affect behaviour – in this case the assembly failed with: [WARNING] The following patterns were never triggered in this artifact inclusion filter: o 'org.example:logging' even though the build order looked correct. > moduleSet - incorrect binary dependencies added to assembly > > > Key: MASSEMBLY-940 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-940 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Nigel Jones >Priority: Major > > In moduleSet, dependencies are not based on specific modules included: > I have a large multimodule project (https://github.com/odpi/egeria) which has > over 300 modules, mostly java (->jar). > One of our submodules is responsible for creating the composite assembly. > Previously we were doing it 'the wrong way' (IMO) with lots of relative paths > (../../.. etc) and I've recently been trying to switch to using moduleSets, > and follow best practices for assembly. We were also previously doing lots of > building 'jar with dependencies' but this doesn't scale as every possibly > useful for ends up far too big... > I have hit a problem with dependencies and moduleSets > We have a series of 'client' artifacts. These have some dependencies (for > example we use restclient from spring, jackson etc). One section of my > assembly attempts to package the clients into a folder, and include any > dependencies they may need: > > > true > > org.odpi.egeria:asset-catalog-client:* > org.odpi.egeria:asset-consumer-client:* > org.odpi.egeria:asset-owner-client:* > org.odpi.egeria:community-profile-client:* > org.odpi.egeria:data-engine-client:* > org.odpi.egeria:it-infrastructure-client:* > org.odpi.egeria:it-infrastructure-client:* > org.odpi.egeria:data-manager-client:* > org.odpi.egeria:data-privacy-client:* > org.odpi.egeria:data-science-client:* > org.odpi.egeria:dev-ops-client:* > org.odpi.egeria:digital-architecture-client:* > org.odpi.egeria:discovery-engine-client:* > org.odpi.egeria:governance-engine-client:* > org.odpi.egeria:governance-program-client:* > org.odpi.egeria:information-view-client:* > org.odpi.egeria:project-management-client:* > org.odpi.egeria:security-officer-client:* > org.odpi.egeria:software-developer-client:* > org.odpi.egeria:stewardship-action-client:* > org.odpi.egeria:subject-area-client:* > org.odpi.egeria:admin-services-client:* > org.odpi.egeria:project-management-client:* > > > ./clients > false > true > > We have a similar pattern for utilities, samples, connectors etc. > I had thought 'includeDependencies' would JUST pull in dependencies for the > modules listed in the included. However I seem to get every dependency for > the entire project (reactor) > I then tried: > false > > > instead, with the same result. > Then switched to this -- since the pom for the module doing the assembly DOES > have a lot of dependencies (in fact it needs to be everything the assembly > refers to as a module, so that we ensure those modules are built first - and > exist) - so thinking (but unsure) if useProjectArtifact was relevant: > false > > true > false > false > > but yet again this still pulls in all dependencies. > The results are inconsistent with 'mvn dependency:tree' - and in fact > whatever is built I just always seem to get the same. It's not transitively > based off every module in the reactor, but seems to be based of the pom of > the project containing the assembly. > Shouldn't I just be pulling in dependencies of the binaries I specify in the > moduleSet? > I've read the definitive maven book chapter, and the docs, but I can't quite > figure out what I'm missing here. > To clarify as well, here's another example > > > true > > org.odpi.egeria:open-metadata-conformance-suite-client:* > > > ./conformance-suite > false > false > > > true > false > false > > > > > Again, I get the same dependencies - this time into ./conformance-suite yet > that is just a single module I am putting into that dir - and I can simply > show > [INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @ > open-metadata-conformance-suite-client --- > [INFO] org.odpi.egeria:open-metadata-conformance-suite-client:jar:2.1-SNAPSHOT > [INFO] +- > org.odpi.egeria:open-metadata-conformance-suite-api:jar:2.1-SNAPSHOT:compile > [INFO] | +- org.slf4j:slf4j-api:jar:1.7.30:compile > [INFO] | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.11.1:compile > [INFO] +-
[jira] [Commented] (MASSEMBLY-940) moduleSet - incorrect binary dependencies added to assembly
[ https://issues.apache.org/jira/browse/MASSEMBLY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161063#comment-17161063 ] Nigel Jones commented on MASSEMBLY-940: --- I then removed the dependency from the assembly pom - but of course this then fails with an error like: ``` [INFO] --- maven-assembly-plugin:3.3.0:single (default) @ assembly --- [INFO] Reading assembly descriptor: src/main/assembly/assembly.xml [INFO] [INFO] Reactor Summary for coolstuff 1.0-SNAPSHOT: [INFO] [INFO] coolstuff .. SUCCESS [ 0.262 s] [INFO] logging SUCCESS [ 1.244 s] [INFO] assembly ... FAILURE [ 0.493 s] [INFO] time ... SKIPPED [INFO] print .. SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.069 s [INFO] Finished at: 2020-07-20T10:19:35+01:00 [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:3.3.0:single (default) on project assembly: Failed to create assembly: Artifact: org.example:print:jar:1.0-SNAPSHOT (included by module) does not have an artifact with a file. Please ensure the package phase is run before the assembly is generated. -> [Help 1]``` Quite sensibly.. since we try and create the assembly before the modules we need to use > moduleSet - incorrect binary dependencies added to assembly > > > Key: MASSEMBLY-940 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-940 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Nigel Jones >Priority: Major > > In moduleSet, dependencies are not based on specific modules included: > I have a large multimodule project (https://github.com/odpi/egeria) which has > over 300 modules, mostly java (->jar). > One of our submodules is responsible for creating the composite assembly. > Previously we were doing it 'the wrong way' (IMO) with lots of relative paths > (../../.. etc) and I've recently been trying to switch to using moduleSets, > and follow best practices for assembly. We were also previously doing lots of > building 'jar with dependencies' but this doesn't scale as every possibly > useful for ends up far too big... > I have hit a problem with dependencies and moduleSets > We have a series of 'client' artifacts. These have some dependencies (for > example we use restclient from spring, jackson etc). One section of my > assembly attempts to package the clients into a folder, and include any > dependencies they may need: > > > true > > org.odpi.egeria:asset-catalog-client:* > org.odpi.egeria:asset-consumer-client:* > org.odpi.egeria:asset-owner-client:* > org.odpi.egeria:community-profile-client:* > org.odpi.egeria:data-engine-client:* > org.odpi.egeria:it-infrastructure-client:* > org.odpi.egeria:it-infrastructure-client:* > org.odpi.egeria:data-manager-client:* > org.odpi.egeria:data-privacy-client:* > org.odpi.egeria:data-science-client:* > org.odpi.egeria:dev-ops-client:* > org.odpi.egeria:digital-architecture-client:* > org.odpi.egeria:discovery-engine-client:* > org.odpi.egeria:governance-engine-client:* > org.odpi.egeria:governance-program-client:* > org.odpi.egeria:information-view-client:* > org.odpi.egeria:project-management-client:* > org.odpi.egeria:security-officer-client:* > org.odpi.egeria:software-developer-client:* > org.odpi.egeria:stewardship-action-client:* > org.odpi.egeria:subject-area-client:* > org.odpi.egeria:admin-services-client:* > org.odpi.egeria:project-management-client:* > > > ./clients > false > true > > We have a similar pattern for utilities, samples, connectors etc. > I had thought 'includeDependencies' would JUST pull in dependencies for the > modules listed in the included. However I seem to get every dependency for > the entire project (reactor) > I then tried: > false > > > instead, with the same result. > Then switched to this -- since the pom for the module doing the assembly DOES > have a lot of dependencies (in fact it needs to be everything the assembly > refers to as a module, so that we ensure those modules are built first - and > exist) - so thinking (but unsure) if useProjectArtifact was relevant: > false > > true > false > false > > but yet again this still pulls in all dependencies. > The results are inconsistent with 'mvn dependency:tree' - and in fact >
[jira] [Commented] (MASSEMBLY-940) moduleSet - incorrect binary dependencies added to assembly
[ https://issues.apache.org/jira/browse/MASSEMBLY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161058#comment-17161058 ] Nigel Jones commented on MASSEMBLY-940: --- I have created a much simpler test project to demonstrate the problem [https://github.com/planetf1/mvntest] This has a parent & 3 child projects that have java classes to a) log b) just print c) use joda tome – random examples There is also a simple assembly. What I note is that I started off creating an assembly JUST for the 'print' module. This has no additional dependencies, and the assembly output directory, with dependencies is correct. I then added the 'logging' module and noted I now get logging dependencies included both in the 'print' module based moduleSet as well as the new one for logging. I then commented out the moduleSet and realised what we get with the dependencySet (within moduleSet) is ALL the dependencies declared in the POM - which doesn't seem correct. Dependencies in the pom are needed to ensure the build order is correct but should not be added as a moduleSet dependency unless, well, they really are a dependency FOR THAT MODULE. At least that is my understanding of the documentation on moduleSets and what seems to be 'useful' but I may have misunderstood! > moduleSet - incorrect binary dependencies added to assembly > > > Key: MASSEMBLY-940 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-940 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Nigel Jones >Priority: Major > > In moduleSet, dependencies are not based on specific modules included: > I have a large multimodule project (https://github.com/odpi/egeria) which has > over 300 modules, mostly java (->jar). > One of our submodules is responsible for creating the composite assembly. > Previously we were doing it 'the wrong way' (IMO) with lots of relative paths > (../../.. etc) and I've recently been trying to switch to using moduleSets, > and follow best practices for assembly. We were also previously doing lots of > building 'jar with dependencies' but this doesn't scale as every possibly > useful for ends up far too big... > I have hit a problem with dependencies and moduleSets > We have a series of 'client' artifacts. These have some dependencies (for > example we use restclient from spring, jackson etc). One section of my > assembly attempts to package the clients into a folder, and include any > dependencies they may need: > > > true > > org.odpi.egeria:asset-catalog-client:* > org.odpi.egeria:asset-consumer-client:* > org.odpi.egeria:asset-owner-client:* > org.odpi.egeria:community-profile-client:* > org.odpi.egeria:data-engine-client:* > org.odpi.egeria:it-infrastructure-client:* > org.odpi.egeria:it-infrastructure-client:* > org.odpi.egeria:data-manager-client:* > org.odpi.egeria:data-privacy-client:* > org.odpi.egeria:data-science-client:* > org.odpi.egeria:dev-ops-client:* > org.odpi.egeria:digital-architecture-client:* > org.odpi.egeria:discovery-engine-client:* > org.odpi.egeria:governance-engine-client:* > org.odpi.egeria:governance-program-client:* > org.odpi.egeria:information-view-client:* > org.odpi.egeria:project-management-client:* > org.odpi.egeria:security-officer-client:* > org.odpi.egeria:software-developer-client:* > org.odpi.egeria:stewardship-action-client:* > org.odpi.egeria:subject-area-client:* > org.odpi.egeria:admin-services-client:* > org.odpi.egeria:project-management-client:* > > > ./clients > false > true > > We have a similar pattern for utilities, samples, connectors etc. > I had thought 'includeDependencies' would JUST pull in dependencies for the > modules listed in the included. However I seem to get every dependency for > the entire project (reactor) > I then tried: > false > > > instead, with the same result. > Then switched to this -- since the pom for the module doing the assembly DOES > have a lot of dependencies (in fact it needs to be everything the assembly > refers to as a module, so that we ensure those modules are built first - and > exist) - so thinking (but unsure) if useProjectArtifact was relevant: > false > > true > false > false > > but yet again this still pulls in all dependencies. > The results are inconsistent with 'mvn dependency:tree' - and in fact > whatever is built I just always seem to get the same. It's not transitively > based off every module in the reactor, but seems to be based of the pom of > the project containing the assembly. > Shouldn't I just be pulling in dependencies of the binaries I specify in the > moduleSet? > I've read the definitive maven book chapter, and the docs, but I can't quite > figure out what I'm missing here. > To clarify as
[jira] [Commented] (MSHARED-297) Commandline class shell injection vulnerabilities
[
https://issues.apache.org/jira/browse/MSHARED-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161054#comment-17161054
]
Dennis Lundberg commented on MSHARED-297:
-
Can this issue be closed now?
> Commandline class shell injection vulnerabilities
> -
>
> Key: MSHARED-297
> URL: https://issues.apache.org/jira/browse/MSHARED-297
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Reporter: Charles Duffy
>Priority: Critical
> Labels: SECURITY
> Attachments: use-no-shell-r2.patch
>
>
> The Commandline class can emit double-quoted strings without proper escaping,
> allowing shell injection attacks.
> The BourneShell class should unconditionally single-quote emitted strings
> (including the name of the command itself being quoted), with {{'"'"'}} used
> for embedded single quotes, for maximum safety across shells implementing a
> superset of POSIX quoting rules.
> An appropriate fix has been built and applied against PLXUTILS; that patch is
> submitted here in the hope that it will be useful, though it is not expected
> to apply to the maven-shared-utils codebase without modification.
> See PLXUTILS-161 for history/discussion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-431) # (Hash-Sign) should trigger quoting in BourneShell.java
[ https://issues.apache.org/jira/browse/MSHARED-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161053#comment-17161053 ] Dennis Lundberg commented on MSHARED-431: - Can this issue be closed now? > # (Hash-Sign) should trigger quoting in BourneShell.java > > > Key: MSHARED-431 > URL: https://issues.apache.org/jira/browse/MSHARED-431 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Affects Versions: maven-shared-utils-0.8 > Environment: Unix (Linux) >Reporter: Fritz Elfert >Priority: Major > > When trying to use the latest maven-jarsign-plugin using a keystore-password > which started with a hash (#), signing failed. After enabling debug output > with -X, I got a strange debug message: > [DEBUG] Option lacks argument > Since signtool is invoked using /bin/sh -c ..., of course, any # must be > quoted, because otherwise it acts as a comment-start and thus effectively > cuts-off the rest of the cmdline. > After single-quoting the password in the pom.xml, the jar signing was ok. > => > Adding '#' to BASH_QUOTING_TRIGGER_CHARS in > org.apache.maven.shared.utils.cli.shell.BourneShell.java should fix the > problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MJAVADOC-656) Following redirects breaks valid links
[
https://issues.apache.org/jira/browse/MJAVADOC-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161051#comment-17161051
]
Michael Osipov commented on MJAVADOC-656:
-
There redirects aren't standard, they seem to be specific to the deploy of the
specific package on a webserver:
{noformat}
/apidocs -> 301 /apidocs/com/example/package-summary.html
/apidocs/ -> 301 /apidocs/com/example/package-summary.html
{noformat}
How are we supposed to support any kind of custom redirect approach?
> 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.0.1, 3.2.0
>Reporter: Robert Važan
>Priority: Minor
>
> 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)
[jira] [Commented] (MSHARED-860) Deprecate obsolete functionality
[ https://issues.apache.org/jira/browse/MSHARED-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161045#comment-17161045 ] Dennis Lundberg commented on MSHARED-860: - Are we ready to close this issue? All pull request seems to have been merged. > Deprecate obsolete functionality > > > Key: MSHARED-860 > URL: https://issues.apache.org/jira/browse/MSHARED-860 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > Large chunks of org.apache.maven.shared.utils are out of date and duplicate > better maintained code in the Java class libraries, Apache Commons Lang, > Apache Commons I/O, or even all three. > > Add deprecation comments and annotations to such methods, classes, and fields > with pointers to the modern replacements for this functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
