[GitHub] [maven-resolver] michael-o commented on pull request #77: [MRESOLVER-145] SyncContext implementations
michael-o commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-817388228 > yes but the problem is that the lock is at the same level as the collection. It should be at the level of individual file and the JVM together with OS would lock it by itself within the process. I don't understand why you make this conclusion. The lock per artifact is JVM wide. -- 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 #77: [MRESOLVER-145] SyncContext implementations
Tibor17 commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-817385696 yes but the problem is that the lock is at the same level as the collection. It should be at the level of individual file and the JVM together with OS would lock it by itself within the process. -- 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 #77: [MRESOLVER-145] SyncContext implementations
michael-o commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-817384481 We need one lock per artifact to coordinate access to files. -- 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 #77: [MRESOLVER-145] SyncContext implementations
Tibor17 edited a comment on pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-817381029
I think no lock is needed if you use the thread pool because there you say
that the fixed number of threads is e.g. 5.
Deadlock happens if you use multiple lock objects. Why we need to have
multiple locks?
If we want to block the business method until `Collection` is
processed completely then we can do it via listeners notified by the thread
pool and we can use `CountdownLatch` but the `CountdownLatch` would be only one
in business-method stack and the size of the countdown would be equal to the
size of the input collection.
The basic principle of the deadlock using the mutex is this:
**T1**:
```
synchronized(lock1) {
synchronized(lock2) {
// job here
}
}
```
**T2**:
```
synchronized(lock2) {
synchronized(lock1) {
// another job here
}
}
```
--
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 #77: [MRESOLVER-145] SyncContext implementations
Tibor17 commented on pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-817381029
I think no lock is needed if you use the thread pool because there you say
that the fixed number of threads is e.g. 5.
Deadlock happens if you use multiple lock objects. Why we need to have
multiple locks?
If we want to block the business method until `Collection` is
processes then we can do it via listeners notified by the thread pool and we
can use `CountdownLatch` but the `CountdownLatch` would be only one in
business-method stack and the size of the countdown would be equal to the size
of the input collection.
The basic principle of the deadlock using the mutex is this:
**T1**:
```
synchronized(lock1) {
synchronized(lock2) {
// job here
}
}
```
**T2**:
```
synchronized(lock2) {
synchronized(lock1) {
// another job here
}
}
```
--
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 #77: [MRESOLVER-145] SyncContext implementations
michael-o commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-817376215 @Tibor17 If I understand you correctly you want to obtain locks concurrently. If yes, this will be a source of deadlocks because they have to be acquired in serial from within one thread and then released in reversed in the same thread. I have done unsorted order and it deadlocked the process. -- 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 #77: [MRESOLVER-145] SyncContext implementations
Tibor17 edited a comment on pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-817372645
Hey guys,
I did not want to participate because the impl and API is too complicated.
We all have experiences but this PR is a signal for me that when I start
implementing my own Lock then there must be something wrong with me. I did it
with Java's `LockSupport` parking and unparking the Threads and it was somehow
working but rather used Java's lock. Here it is similar and I think it is due
to the API. The concept starts with the `Collection` passed to the method
`acquire`:
```
try {
syncContext.acquire( artifacts, metadatas );
// work with the artifacts and metadatas
} finally {
syncContext.close();
}
```
It would be more simple to use make the parallelism at one layer below, this
means the collection may become a stream but the lock would be in the thread
pool. It may be so simple that you create the Artifact and push it to the queue
of `ThreadPoolExecutor`.
--
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 #77: [MRESOLVER-145] SyncContext implementations
Tibor17 commented on pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-817372645
Hey guys,
I did not want to participate because the impl and API is too complicated.
We all have experiences but it is a signal for me that if I start
implementing my own Lock then there must be something wrong with me. I did it
with Java's `LockSupport` parking and unparking the Threads and it was somehow
working but rather used Java's lock. Here it is similar and I think it is due
to the API. The concept starts with the `Collection` passed to the method
`acquire`:
```
try {
syncContext.acquire( artifacts, metadatas );
// work with the artifacts and metadatas
} finally {
syncContext.close();
}
```
It would be more simple to use make the parallelism at one layer below, this
means the collection may become a stream but the lock would be in the thread
pool. It may be so simple that you create the Artifact and push it to the queue
of `ThreadPoolExecutor`.
--
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] (MDEP-743) go-offline doesn't resolve dependencies from non-central repos
[ https://issues.apache.org/jira/browse/MDEP-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318937#comment-17318937 ] Mitchell Skaggs commented on MDEP-743: -- Thanks, that build fixes it! Hopefully there's an official release or snapshot with the fix soon! > go-offline doesn't resolve dependencies from non-central repos > -- > > Key: MDEP-743 > URL: https://issues.apache.org/jira/browse/MDEP-743 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: go-offline >Affects Versions: 3.1.2 > Environment: Windows 10 Powershell; WSL 2 Debian >Reporter: Mitchell Skaggs >Priority: Major > > To reproduce, create a Maven project with a dependency that is not in Maven > Central. The one I used is located at > [https://jitpack.io/#bhlangonijr/chesslib]. Add Jitpack as a repository like > normal, and then run `go-offline`. The task fails because it can't resolve > the artifact in Maven Central. > > I did some debugging and found that the task doesn't have the Jitpack > repository in the list to check, even though the artifact is resolved > normally for compilation and running. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] michael-o edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations
michael-o edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-817367241 There is one more thing I do not understand and think that this undermines reentrancy: While I understand that you maintain a concurrent map in `NamedLockFactorySupport` to manage locks (counts) between threads in one JVM to properly obtain and release them, but I fail to understand why both `AdaptedReadWriteLockNamedLock` and `AdaptedSemaphoreNamedLock` use thread locals to manage these locks. Looking at how lock and unlock are done, I don't see how underlying locks are used when reentrancy happens. Thus, the internal lock count is not increased, but you turn reentrancy into a `NOOP` and the end. Each call to `lockShared()`/`lockExclusively()` should be delegated to the underlying lock , no matter what. Please explain! -- 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 #77: [MRESOLVER-145] SyncContext implementations
michael-o commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-817367241 There is one more thing I do not understand and think that this undermines reentrancy: While I understand that you maintain a concurrent map in `NamedLockFactorySupport` to manage locks (counts) between threads in one JVM to properly obtain and release them, but I fail to understand why both `AdaptedReadWriteLockNamedLock` and `AdaptedSemaphoreNamedLock` use thread locals to manage these locks. Looking at how lock and unlock is done, I don't see how underlying locks are used when reentrancy happens. Thus, the internal lock count is not increased, but you turn reentrancy into a `NOOP` and the end. Each call to `lockShared()`/`lockExclusively()` should be delegated to the underlying lock , no matter what. Please explain! -- 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] (MDEP-743) go-offline doesn't resolve dependencies from non-central repos
[ https://issues.apache.org/jira/browse/MDEP-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318932#comment-17318932 ] Piotr Zygielo commented on MDEP-743: I suppose it is fixed by MDEP-680, which, sadly, is not released yet. [~magneticflux-] You can try to use [https://jitpack.io/#pzygielo/maven-dependency-plugin/3.1.2-pz-1] to verify that fix for MDEP-680 helps in your case. > go-offline doesn't resolve dependencies from non-central repos > -- > > Key: MDEP-743 > URL: https://issues.apache.org/jira/browse/MDEP-743 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: go-offline >Affects Versions: 3.1.2 > Environment: Windows 10 Powershell; WSL 2 Debian >Reporter: Mitchell Skaggs >Priority: Major > > To reproduce, create a Maven project with a dependency that is not in Maven > Central. The one I used is located at > [https://jitpack.io/#bhlangonijr/chesslib]. Add Jitpack as a repository like > normal, and then run `go-offline`. The task fails because it can't resolve > the artifact in Maven Central. > > I did some debugging and found that the task doesn't have the Jitpack > repository in the list to check, even though the artifact is resolved > normally for compilation and running. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] michael-o commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
michael-o commented on a change in pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#discussion_r611219268
##
File path:
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/NamedLock.java
##
@@ -0,0 +1,71 @@
+package org.eclipse.aether.named;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.concurrent.TimeUnit;
+
+/**
+ * A named lock, functionally similar to existing JVM and other
implementations. Must support boxing (reentrancy), but
+ * no lock upgrade is supported. Usual pattern to use this lock:
+ *
+ * try (NamedLock lock = factory.getLock("resourceName")) {
+ * if (lock.lockExclusively(10L, Timeunit.SECONDS)) {
+ * try {
+ * ... exclusive access to "resourceName" resource gained here
+ * }
+ * finally {
+ * lock.unlock();
+ * }
+ * }
+ * else {
+ * ... failed to gain access within specified time, handle it
+ * }
+ * }
+ *
+ */
+public interface NamedLock
+extends AutoCloseable
+{
+ /**
+ * Returns this instance name, never null.
+ */
+ String name();
+
+ /**
+ * Tries to lock shared, may block for given time. If successful, returns
{@code true}.
+ */
+ boolean lockShared( long time, TimeUnit unit ) throws InterruptedException;
+
+ /**
+ * Tries to lock exclusively, may block for given time. If successful,
returns {@code true}.
+ */
+ boolean lockExclusively( long time, TimeUnit unit ) throws
InterruptedException;
+
+ /**
+ * Unlocks the lock.
+ */
+ void unlock();
+
+ /**
+ * Closes the lock.
+ */
+ @Override
+ void close();
Review comment:
One should describe whether there is a difference between `close()` and
`unlock()`.
##
File path:
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/NamedLock.java
##
@@ -0,0 +1,71 @@
+package org.eclipse.aether.named;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.concurrent.TimeUnit;
+
+/**
+ * A named lock, functionally similar to existing JVM and other
implementations. Must support boxing (reentrancy), but
+ * no lock upgrade is supported. Usual pattern to use this lock:
+ *
+ * try (NamedLock lock = factory.getLock("resourceName")) {
+ * if (lock.lockExclusively(10L, Timeunit.SECONDS)) {
+ * try {
+ * ... exclusive access to "resourceName" resource gained here
+ * }
+ * finally {
+ * lock.unlock();
+ * }
+ * }
+ * else {
+ * ... failed to gain access within specified time, handle it
+ * }
+ * }
+ *
+ */
+public interface NamedLock
+extends AutoCloseable
+{
+ /**
+ * Returns this instance name, never null.
+ */
+ String name();
+
+ /**
+ * Tries to lock shared, may block for given time. If successful, returns
{@code true}.
+ */
+ boolean lockShared( long time, TimeUnit unit ) throws InterruptedException;
+
+ /**
+ * Tries to lock exclusively, may block for given time. If successful,
returns {@code true}.
+ */
+ boolean lockExclusively( long time, TimeUnit unit ) throws
InterruptedException;
Review comment:
I think that those two method should resemble Java's `Lock`:
`tryLock...(long, TimeUnit)`.
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/named/NameMapper.java
##
@@ -0,0 +1,41 @@
+package
[jira] [Created] (MDEP-743) go-offline doesn't resolve dependencies from non-central repos
Mitchell Skaggs created MDEP-743: Summary: go-offline doesn't resolve dependencies from non-central repos Key: MDEP-743 URL: https://issues.apache.org/jira/browse/MDEP-743 Project: Maven Dependency Plugin Issue Type: Bug Components: go-offline Affects Versions: 3.1.2 Environment: Windows 10 Powershell; WSL 2 Debian Reporter: Mitchell Skaggs To reproduce, create a Maven project with a dependency that is not in Maven Central. The one I used is located at [https://jitpack.io/#bhlangonijr/chesslib]. Add Jitpack as a repository like normal, and then run `go-offline`. The task fails because it can't resolve the artifact in Maven Central. I did some debugging and found that the task doesn't have the Jitpack repository in the list to check, even though the artifact is resolved normally for compilation and running. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-1016.
Fix Version/s: 3.0.0-M3
Assignee: Robert Scholte
Resolution: Fixed
I've done some small message related fixes in
[402b093374fdeee1a3daa8163aec96389581d861|https://gitbox.apache.org/repos/asf?p=maven-release.git;a=commit;h=402b093374fdeee1a3daa8163aec96389581d861]
I did a small test, and to me it looks like the branch picks up the right
version.
Either it is already fixed by another commit or I could be wrong.
I'll close it for now, don't hesitate to reopen it if you still have the issue.
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: Apache Maven 3.3.9
> Java version: 1.8.0_60, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> git version 2.16.2.windows.1
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 3.0.0-M3
>
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6397) Maven Transitive Dependency Resolution Does Not Respect Repository Definition in pom.xml
[
https://issues.apache.org/jira/browse/MNG-6397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-6397:
---
Fix Version/s: (was: 4.0.0-alpha-1)
(was: 4.0.0)
(was: wontfix-candidate)
> Maven Transitive Dependency Resolution Does Not Respect Repository Definition
> in pom.xml
>
>
> Key: MNG-6397
> URL: https://issues.apache.org/jira/browse/MNG-6397
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories, Dependencies, POM
>Affects Versions: 3.0, 3.5.0, 3.5.2, 3.5.3, 3.6.0, 3.6.1, 3.6.3
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> Maven home: /usr/local/share/maven
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Alan Czajkowski
>Priority: Critical
> Labels: maven
> Fix For: 4.0.x-candidate, waiting-for-feedback
>
>
> _*Note:* I am trying to do a build behind a firewall which means I cannot
> access the Internet, I can only access my internal Maven repository inside my
> network, so:_
> - _grabbing artifacts from https://artifacts.example.com/repository/maven/
> works fine_
> - _grabbing artifacts from anywhere else fails due to firewall restrictions_
> Let's begin:
> My {{pom.xml}} has the following:
> {code:xml}
> ...
>
> ...
>
> org.springframework.boot
> spring-boot-starter-web
> 2.0.0.RELEASE
>
> ...
>
> ...
>
> ...
>
> central
> Public
> https://artifacts.example.com/repository/maven/
>
> true
>
>
> true
>
>
> ...
>
> ...
> {code}
> The {{dependency:tree}} for the {{spring-boot-starter-web}} is as follows:
> {code:java}
> +- org.springframework.boot:spring-boot-starter-web:jar:2.0.0.RELEASE:compile
> | +-
> org.springframework.boot:spring-boot-starter-json:jar:2.0.0.RELEASE:compile
> | | +-
> com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.9.4:compile
> | | +-
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.9.4:compile
> | | \-
> com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.9.4:compile
> | +-
> org.springframework.boot:spring-boot-starter-tomcat:jar:2.0.0.RELEASE:compile
> | | \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.5.28:compile
> | +- org.hibernate.validator:hibernate-validator:jar:6.0.7.Final:compile
> | | +- javax.validation:validation-api:jar:2.0.1.Final:compile
> | | +- org.jboss.logging:jboss-logging:jar:3.3.0.Final:compile
> | | \- com.fasterxml:classmate:jar:1.3.1:compile
> | \- org.springframework:spring-web:jar:5.0.4.RELEASE:compile
> {code}
> How is it that the build fails as such:
> {code:java}
> ...
> Downloading:
> https://repo.spring.io/milestone/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://repo.spring.io/snapshot/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://dl.bintray.com/rabbitmq/maven-milestones/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://repo.maven.apache.org/maven2/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> ...
> [ERROR] Failed to execute goal on project maven-multi-module-demo-backend:
> Could not resolve dependencies for project
> com.example.pipe:maven-multi-module-demo-backend:war:1.0.0-SNAPSHOT: Failed
> to collect dependencies at
> org.springframework.boot:spring-boot-starter-web:jar:2.0.0.RELEASE ->
> org.hibernate.validator:hibernate-validator:jar:6.0.7.Final: Failed to read
> artifact descriptor for
> org.hibernate.validator:hibernate-validator:jar:6.0.7.Final: Could not
> transfer artifact org.jboss.shrinkwrap:shrinkwrap-bom:pom:1.2.3 from/to
> spring-milestone (https://repo.spring.io/milestone): Connection reset ->
> [Help 1]
> ...
> {code}
> when I did not even reference this repo {{spring-milestone
> ([https://repo.spring.io/milestone])}} anywhere in my {{pom.xml}}?
> When you go down the Spring Boot rabbit hole (go into the
> {{spring-boot-starter-web}}'s {{pom.xml}} and then traverse up its parent-pom
> structure a few jumps) you'll eventually get to a parent-pom
> {{spring-boot-dependencies}} with this definition:
> {code:xml}
> ...
>
>
>
> false
>
> spring-milestone
>
[jira] [Commented] (MRESOLVER-168) add DEBUG message when downloading an artifact from repositories
[
https://issues.apache.org/jira/browse/MRESOLVER-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318903#comment-17318903
]
Hudson commented on MRESOLVER-168:
--
Build failed in Jenkins: Maven » Maven TLP » maven-resolver » 1.6.x #10
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-resolver/job/1.6.x/10/
> add DEBUG message when downloading an artifact from repositories
>
>
> Key: MRESOLVER-168
> URL: https://issues.apache.org/jira/browse/MRESOLVER-168
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
>
> currently, when download artifacts, we have many DEBUG messages on low level
> technical details
> {noformat}[DEBUG] Writing tracking file
> /home/user/.m2/repository/org/apache/apache/23/apache-23.pom.lastUpdated
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for
> https://repo.maven.apache.org/maven2/
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https://repo.maven.apache.org/maven2/
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/apache/23/apache-23.pom
> Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/apache/23/apache-23.pom (18
> kB at 1.3 MB/s)
> [DEBUG] Writing tracking file
> /home/user/.m2/repository/org/apache/apache/23/_remote.repositories
> [DEBUG] Writing tracking file
> /home/user/.m2/repository/org/apache/apache/23/apache-23.pom.lastUpdated
> {noformat}
> adding before a message about what artifact is being resolver, and in which
> repositories (with explicit order that will be used) would be a lot more
> useful:
> {noformat}[DEBUG] Resolving artifact org.apache:apache:pom:23 from [central
> (https://repo.maven.apache.org/maven2/, default, releases), apache.snapshots
> (https://repository.apache.org/snapshots, default, snapshots)]{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-168) add DEBUG message when downloading an artifact from repositories
[
https://issues.apache.org/jira/browse/MRESOLVER-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318900#comment-17318900
]
Herve Boutemy commented on MRESOLVER-168:
-
cherry picked for 1.6.3 in
https://gitbox.apache.org/repos/asf?p=maven-resolver.git=commit=6f13b7ce6623c786c93b78f86019c164007fef79
> add DEBUG message when downloading an artifact from repositories
>
>
> Key: MRESOLVER-168
> URL: https://issues.apache.org/jira/browse/MRESOLVER-168
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
>
> currently, when download artifacts, we have many DEBUG messages on low level
> technical details
> {noformat}[DEBUG] Writing tracking file
> /home/user/.m2/repository/org/apache/apache/23/apache-23.pom.lastUpdated
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for
> https://repo.maven.apache.org/maven2/
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https://repo.maven.apache.org/maven2/
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/apache/23/apache-23.pom
> Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/apache/23/apache-23.pom (18
> kB at 1.3 MB/s)
> [DEBUG] Writing tracking file
> /home/user/.m2/repository/org/apache/apache/23/_remote.repositories
> [DEBUG] Writing tracking file
> /home/user/.m2/repository/org/apache/apache/23/apache-23.pom.lastUpdated
> {noformat}
> adding before a message about what artifact is being resolver, and in which
> repositories (with explicit order that will be used) would be a lot more
> useful:
> {noformat}[DEBUG] Resolving artifact org.apache:apache:pom:23 from [central
> (https://repo.maven.apache.org/maven2/, default, releases), apache.snapshots
> (https://repository.apache.org/snapshots, default, snapshots)]{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOLVER-168) add DEBUG message when downloading an artifact from repositories
[
https://issues.apache.org/jira/browse/MRESOLVER-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MRESOLVER-168:
Fix Version/s: 1.6.3
> add DEBUG message when downloading an artifact from repositories
>
>
> Key: MRESOLVER-168
> URL: https://issues.apache.org/jira/browse/MRESOLVER-168
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
>
> currently, when download artifacts, we have many DEBUG messages on low level
> technical details
> {noformat}[DEBUG] Writing tracking file
> /home/user/.m2/repository/org/apache/apache/23/apache-23.pom.lastUpdated
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for
> https://repo.maven.apache.org/maven2/
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https://repo.maven.apache.org/maven2/
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/apache/23/apache-23.pom
> Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/apache/23/apache-23.pom (18
> kB at 1.3 MB/s)
> [DEBUG] Writing tracking file
> /home/user/.m2/repository/org/apache/apache/23/_remote.repositories
> [DEBUG] Writing tracking file
> /home/user/.m2/repository/org/apache/apache/23/apache-23.pom.lastUpdated
> {noformat}
> adding before a message about what artifact is being resolver, and in which
> repositories (with explicit order that will be used) would be a lot more
> useful:
> {noformat}[DEBUG] Resolving artifact org.apache:apache:pom:23 from [central
> (https://repo.maven.apache.org/maven2/, default, releases), apache.snapshots
> (https://repository.apache.org/snapshots, default, snapshots)]{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318898#comment-17318898
]
Michael Osipov commented on MDEPLOY-254:
I will purpsue the fix backport to 3.8.2.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2021-04-11-23-55-48-005.png,
> log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MRESOLVER-142) maven does not honour configured in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MRESOLVER-142. Fix Version/s: (was: waiting-for-feedback) Resolution: Incomplete Closing until someone can provide a complete sample project. > maven does not honour configured in some cases > - > > Key: MRESOLVER-142 > URL: https://issues.apache.org/jira/browse/MRESOLVER-142 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Igor Fedorenko >Priority: Major > > There appear to be a bug in artifact descriptor cache implemented in aether > DefaultDependencyCollector. The cache allows use of cached descriptors when > descriptor parent(s) are not accessible from any enabled repository. > This is particularly problematic during multithreaded builds, where timing of > individual module project builds is not guaranteed, and the invalid artifact > descriptor cache implementation can result in infrequent and hard to > troubleshoot dependency resolution failures. > I'll provide small standalone example project that demonstrates the problem > shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-142) maven does not honour configured in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318894#comment-17318894 ] Igor Fedorenko commented on MRESOLVER-142: -- Sorry, it's been awhile, I don't recall any details about this issue, feel free to close. > maven does not honour configured in some cases > - > > Key: MRESOLVER-142 > URL: https://issues.apache.org/jira/browse/MRESOLVER-142 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Igor Fedorenko >Priority: Major > Fix For: waiting-for-feedback > > > There appear to be a bug in artifact descriptor cache implemented in aether > DefaultDependencyCollector. The cache allows use of cached descriptors when > descriptor parent(s) are not accessible from any enabled repository. > This is particularly problematic during multithreaded builds, where timing of > individual module project builds is not guaranteed, and the invalid artifact > descriptor cache implementation can result in infrequent and hard to > troubleshoot dependency resolution failures. > I'll provide small standalone example project that demonstrates the problem > shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318882#comment-17318882
]
Alexander Kriegisch edited comment on MDEPLOY-254 at 4/11/21, 5:07 PM:
---
Sorry, [~michael-o], we posted at the same time. I just documented the same fix
in my edit above, see links and screenshot.
Whatever "CVE fixes" might mean, 3.8.x should contain this fix too. It is
rather difficult to understand for users that the upcoming 3.6.4 will contain a
fix which in a higher version 3.8.x is not fixed. It might urge people to
downgrade, which always feels a bit odd. Sorry for not knowing the ins and outs
of Maven version numbers, I am sure there is a good explanation for it - just
not an intuitive one.
*Update:* I see, [CVE = Common Vulnerabilities and
Exposures|https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures].
was (Author: kriegaex):
Sorry, [~michael-o], we posted at the same time. I just documented the same fix
in my edit above, see links and screenshot.
Whatever "CVE fixes" might mean, 3.8.x should contain this fix too. It is
rather difficult to understand for users that the upcoming 3.6.4 will contain a
fix which in a higher version 3.8.x is not fixed. It might urge people to
downgrade, which always feels a bit odd. Sorry for not knowing the ins and outs
of Maven version numbers, I am sure there is a good explanation for it - just
not an intuitive one.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2021-04-11-23-55-48-005.png,
> log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318794#comment-17318794
]
Alexander Kriegisch edited comment on MDEPLOY-254 at 4/11/21, 5:02 PM:
---
OK, what the heck - I cloned and built Maven myself. The current master on the
3.6.x branch works correctly. So if this is the feedback you were waiting for
in this ticket and if that was blocking the 3.6.4 release, maybe we are down
one blocker now.
*Update:* Just in case anyone is interested: when I checked
[here|https://gitbox.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/maven-3.6.x],
I found the [bugfix backport
commit|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=9fbd3cfa82aa5aa3d45fe0c2891d70b904f5fe34]
we were talking about:
!image-2021-04-11-23-55-48-005.png!
was (Author: kriegaex):
OK, what the heck - I cloned and built Maven myself. The current master on the
3.6.x branch works correctly. So if this is the feedback you were waiting for
in this ticket and if that was blocking the 3.6.4 release, maybe we are down
one blocker now.
*Update:* Just in case anyone is interested: when I checked
[here|https://gitbox.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/maven-3.6.x],
I found the [bugfix backport
commit@https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=9fbd3cfa82aa5aa3d45fe0c2891d70b904f5fe34]
we were talking about:
!image-2021-04-11-23-55-48-005.png!
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2021-04-11-23-55-48-005.png,
> log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318885#comment-17318885
]
Hudson commented on MRELEASE-1016:
--
Build succeeded in Jenkins: Maven » Maven TLP » maven-release » master #33
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/33/
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: Apache Maven 3.3.9
> Java version: 1.8.0_60, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> git version 2.16.2.windows.1
>Reporter: Anthony Whitford
>Priority: Blocker
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318882#comment-17318882
]
Alexander Kriegisch edited comment on MDEPLOY-254 at 4/11/21, 4:59 PM:
---
Sorry, [~michael-o], we posted at the same time. I just documented the same fix
in my edit above, see links and screenshot.
Whatever "CVE fixes" might mean, 3.8.x should contain this fix too. It is
rather difficult to understand for users that the upcoming 3.6.4 will contain a
fix which in a higher version 3.8.x is not fixed. It might urge people to
downgrade, which always feels a bit odd. Sorry for not knowing the ins and outs
of Maven version numbers, I am sure there is a good explanation for it - just
not an intuitive one.
was (Author: kriegaex):
Sorry, [~michael-o], we posted at the same time. I just documented the same fix
in my edit above, see links and screenshot.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2021-04-11-23-55-48-005.png,
> log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318882#comment-17318882
]
Alexander Kriegisch commented on MDEPLOY-254:
-
Sorry, [~michael-o], we posted at the same time. I just documented the same fix
in my edit above, see links and screenshot.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2021-04-11-23-55-48-005.png,
> log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318794#comment-17318794
]
Alexander Kriegisch edited comment on MDEPLOY-254 at 4/11/21, 4:55 PM:
---
OK, what the heck - I cloned and built Maven myself. The current master on the
3.6.x branch works correctly. So if this is the feedback you were waiting for
in this ticket and if that was blocking the 3.6.4 release, maybe we are down
one blocker now.
*Update:* Just in case anyone is interested: when I checked
[here|https://gitbox.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/maven-3.6.x],
I found the [bugfix backport
commit@https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=9fbd3cfa82aa5aa3d45fe0c2891d70b904f5fe34]
we were talking about:
!image-2021-04-11-23-55-48-005.png!
was (Author: kriegaex):
OK, what the heck - I cloned and built Maven myself. The current master on the
3.6.x branch works correctly. So if this is the feedback you were waiting for
in this ticket and if that was blocking the 3.6.4 release, maybe we are down
one blocker now.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2021-04-11-23-55-48-005.png,
> log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318879#comment-17318879
]
Michael Osipov commented on MDEPLOY-254:
MNG-5868 is the fix. 3.8.1 contains CVE fixes only. It does not include this
fix.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318877#comment-17318877
]
Alexander Kriegisch edited comment on MDEPLOY-254 at 4/11/21, 4:45 PM:
---
[~michael-o], I am afraid I do not understand your very terse previous comment.
What is here?
BTW, I just happened to notice that there is a release 3.8.1 now which is less
than a week old. Gonna try that one too. *Update:* In Maven 3.8.1 the bug
unfortunately is *not* fixed.
was (Author: kriegaex):
[~michael-o], I am afraid I do not understand your very terse previous comment.
What is here?
BTW, I just happened to notice that there is a release 3.8.1 now which is less
than a week old. Gonna try that one too.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318877#comment-17318877
]
Alexander Kriegisch edited comment on MDEPLOY-254 at 4/11/21, 4:45 PM:
---
[~michael-o], I am afraid I do not understand your very terse previous comment.
What is here?
BTW, I just happened to notice that there is a release 3.8.1 now which is less
than a week old. Gonna try that one too.
*Update:* In Maven 3.8.1 the bug unfortunately is *not* fixed.
was (Author: kriegaex):
[~michael-o], I am afraid I do not understand your very terse previous comment.
What is here?
BTW, I just happened to notice that there is a release 3.8.1 now which is less
than a week old. Gonna try that one too. *Update:* In Maven 3.8.1 the bug
unfortunately is *not* fixed.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318877#comment-17318877
]
Alexander Kriegisch commented on MDEPLOY-254:
-
[~michael-o], I am afraid I do not understand your very terse previous comment.
What is here?
BTW, I just happened to notice that there is a release 3.8.1 now which is less
than a week old. Gonna try that one too.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-142) maven does not honour configured in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318866#comment-17318866 ] Michael Osipov commented on MRESOLVER-142: -- [~igorf], can you add more detail as requested last year? > maven does not honour configured in some cases > - > > Key: MRESOLVER-142 > URL: https://issues.apache.org/jira/browse/MRESOLVER-142 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Igor Fedorenko >Priority: Major > Fix For: waiting-for-feedback > > > There appear to be a bug in artifact descriptor cache implemented in aether > DefaultDependencyCollector. The cache allows use of cached descriptors when > descriptor parent(s) are not accessible from any enabled repository. > This is particularly problematic during multithreaded builds, where timing of > individual module project builds is not guaranteed, and the invalid artifact > descriptor cache implementation can result in infrequent and hard to > troubleshoot dependency resolution failures. > I'll provide small standalone example project that demonstrates the problem > shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRESOLVER-142) maven does not honour configured in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-142: - Fix Version/s: waiting-for-feedback > maven does not honour configured in some cases > - > > Key: MRESOLVER-142 > URL: https://issues.apache.org/jira/browse/MRESOLVER-142 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Igor Fedorenko >Priority: Major > Fix For: waiting-for-feedback > > > There appear to be a bug in artifact descriptor cache implemented in aether > DefaultDependencyCollector. The cache allows use of cached descriptors when > descriptor parent(s) are not accessible from any enabled repository. > This is particularly problematic during multithreaded builds, where timing of > individual module project builds is not guaranteed, and the invalid artifact > descriptor cache implementation can result in infrequent and hard to > troubleshoot dependency resolution failures. > I'll provide small standalone example project that demonstrates the problem > shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRESOLVER-153:
-
Fix Version/s: 1.7.0
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.7.0
>
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than
> Linux or Windows ones. After some investigations we saw that as part of
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has
> been removed on the {{TrackingFileManager}}
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to
> concurrent writes on the {{resolver-status.properties}} file in our tests and
> causes the error during the {{Properties#load()}} method wich then throws the
> above error. See this screenshot on how these files look like (cannot add the
> text here as {{null}} characters aren't shown):
>
[jira] [Updated] (MRESOLVER-145) Introduce more SyncContext implementations
[ https://issues.apache.org/jira/browse/MRESOLVER-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-145: - Fix Version/s: 1.7.0 > Introduce more SyncContext implementations > -- > > Key: MRESOLVER-145 > URL: https://issues.apache.org/jira/browse/MRESOLVER-145 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Michael Osipov >Priority: Minor > Fix For: 1.7.0 > > > Aside of existing "global" (too coarse, not really usable) and "redisson" > sync context implementations, we may try out more implementations and maybe > even benchmark/compare them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRESOLVER-90) HTML content in POM: Maven should validate content before storing in local repo
[
https://issues.apache.org/jira/browse/MRESOLVER-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MRESOLVER-90.
---
Fix Version/s: (was: version-next)
(was: waiting-for-feedback)
1.7.0
Assignee: Michael Osipov
Resolution: Fixed
Implicitly solved by issues mentioned in the comments.
> HTML content in POM: Maven should validate content before storing in local
> repo
> ---
>
> Key: MRESOLVER-90
> URL: https://issues.apache.org/jira/browse/MRESOLVER-90
> Project: Maven Resolver
> Issue Type: New Feature
>Affects Versions: 1.4.0
> Environment: both with maven 3.6.0 in CMD or in Eclipse 4.9.0
>Reporter: Jörg Hohwiller
>Assignee: Michael Osipov
>Priority: Major
> Labels: intern
> Fix For: 1.7.0
>
>
> For some odd reasons somethimes errors just happen and a maven repo delivers
> an HTML error or login page for a request of a POM or JAR file. It seems as
> if the status code is valid then Maven (might be anything under the hood,
> maybe even ether?) is saving the result without any sanity check or
> validation.
> Therefore I frequently end up with "POM" or "JAR" files in my local repo that
> are no XML but HTML nonsens.
>
> Example:
> {code:java}
>
>
>
>
> Please Wait While Redirecting to Login page
>
>
>
>
>
>
> {code}
> I would expect maven to verify the content before officially placing it in
> the correct location inside the local maven repository on my disc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-714) Add analyze parameter "ignoreUnusedRuntime"
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318862#comment-17318862 ] Michael Osipov commented on MDEP-714: - I hope this will happen before 2021, but if it won't before summer, feel free to ping me by June. > Add analyze parameter "ignoreUnusedRuntime" > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.3 > > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-6967) Improve the command line output from maven-artifact
[
https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MNG-6967.
--
Resolution: Fixed
improved in
https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=9166805a068ff176c237e9f340234f5132d6b4dd
> Improve the command line output from maven-artifact
> ---
>
> Key: MNG-6967
> URL: https://issues.apache.org/jira/browse/MNG-6967
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.3
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> As is documented here
> https://maven.apache.org/pom.html#version-order-testing
> you can use the maven-artifact JAR file to test version numbers and their
> relative order.
> Unfortunately the output does not match what is used in
> https://maven.apache.org/pom.html#version-order-specification
> when describing the "Trimming Examples". It's matter of {{==}} versus
> {{\->}}. I prefer the one used in the documentation, so I'd like to change
> maven-artifact to use {{->}}. It represents a transformation (trimming in
> this case) -- not a an equality test.
> Another problem is that it does not show you the list of tokens that are the
> result of parsing the version numbers. This can be quite useful when trying
> to figure out why you are getting the results you are.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6967) Improve the command line output from maven-artifact
[
https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-6967:
---
Comment: was deleted
(was: Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6555
#14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/14/)
> Improve the command line output from maven-artifact
> ---
>
> Key: MNG-6967
> URL: https://issues.apache.org/jira/browse/MNG-6967
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.3
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> As is documented here
> https://maven.apache.org/pom.html#version-order-testing
> you can use the maven-artifact JAR file to test version numbers and their
> relative order.
> Unfortunately the output does not match what is used in
> https://maven.apache.org/pom.html#version-order-specification
> when describing the "Trimming Examples". It's matter of {{==}} versus
> {{\->}}. I prefer the one used in the documentation, so I'd like to change
> maven-artifact to use {{->}}. It represents a transformation (trimming in
> this case) -- not a an equality test.
> Another problem is that it does not show you the list of tokens that are the
> result of parsing the version numbers. This can be quite useful when trying
> to figure out why you are getting the results you are.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6967) Improve the command line output from maven-artifact
[
https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-6967:
---
Comment: was deleted
(was: Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551
#14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/)
> Improve the command line output from maven-artifact
> ---
>
> Key: MNG-6967
> URL: https://issues.apache.org/jira/browse/MNG-6967
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.3
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> As is documented here
> https://maven.apache.org/pom.html#version-order-testing
> you can use the maven-artifact JAR file to test version numbers and their
> relative order.
> Unfortunately the output does not match what is used in
> https://maven.apache.org/pom.html#version-order-specification
> when describing the "Trimming Examples". It's matter of {{==}} versus
> {{\->}}. I prefer the one used in the documentation, so I'd like to change
> maven-artifact to use {{->}}. It represents a transformation (trimming in
> this case) -- not a an equality test.
> Another problem is that it does not show you the list of tokens that are the
> result of parsing the version numbers. This can be quite useful when trying
> to figure out why you are getting the results you are.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6967) Improve the command line output from maven-artifact
[
https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-6967:
---
Comment: was deleted
(was: Build succeeded in Jenkins: Maven TLP » maven » master #448
See https://builds.apache.org/job/maven-box/job/maven/job/master/448/)
> Improve the command line output from maven-artifact
> ---
>
> Key: MNG-6967
> URL: https://issues.apache.org/jira/browse/MNG-6967
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.3
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> As is documented here
> https://maven.apache.org/pom.html#version-order-testing
> you can use the maven-artifact JAR file to test version numbers and their
> relative order.
> Unfortunately the output does not match what is used in
> https://maven.apache.org/pom.html#version-order-specification
> when describing the "Trimming Examples". It's matter of {{==}} versus
> {{\->}}. I prefer the one used in the documentation, so I'd like to change
> maven-artifact to use {{->}}. It represents a transformation (trimming in
> this case) -- not a an equality test.
> Another problem is that it does not show you the list of tokens that are the
> result of parsing the version numbers. This can be quite useful when trying
> to figure out why you are getting the results you are.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6967) Improve the command line output from maven-artifact
[
https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-6967:
---
Comment: was deleted
(was: Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556
#14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/)
> Improve the command line output from maven-artifact
> ---
>
> Key: MNG-6967
> URL: https://issues.apache.org/jira/browse/MNG-6967
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.3
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> As is documented here
> https://maven.apache.org/pom.html#version-order-testing
> you can use the maven-artifact JAR file to test version numbers and their
> relative order.
> Unfortunately the output does not match what is used in
> https://maven.apache.org/pom.html#version-order-specification
> when describing the "Trimming Examples". It's matter of {{==}} versus
> {{\->}}. I prefer the one used in the documentation, so I'd like to change
> maven-artifact to use {{->}}. It represents a transformation (trimming in
> this case) -- not a an equality test.
> Another problem is that it does not show you the list of tokens that are the
> result of parsing the version numbers. This can be quite useful when trying
> to figure out why you are getting the results you are.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6967) Improve the command line output from maven-artifact
[
https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-6967:
---
Comment: was deleted
(was: Build failed in Jenkins: Maven » Maven TLP » maven » master #92
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/92/)
> Improve the command line output from maven-artifact
> ---
>
> Key: MNG-6967
> URL: https://issues.apache.org/jira/browse/MNG-6967
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.3
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> As is documented here
> https://maven.apache.org/pom.html#version-order-testing
> you can use the maven-artifact JAR file to test version numbers and their
> relative order.
> Unfortunately the output does not match what is used in
> https://maven.apache.org/pom.html#version-order-specification
> when describing the "Trimming Examples". It's matter of {{==}} versus
> {{\->}}. I prefer the one used in the documentation, so I'd like to change
> maven-artifact to use {{->}}. It represents a transformation (trimming in
> this case) -- not a an equality test.
> Another problem is that it does not show you the list of tokens that are the
> result of parsing the version numbers. This can be quite useful when trying
> to figure out why you are getting the results you are.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6967) Improve the command line output from maven-artifact
[
https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-6967:
---
Comment: was deleted
(was: Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6553
#14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/14/)
> Improve the command line output from maven-artifact
> ---
>
> Key: MNG-6967
> URL: https://issues.apache.org/jira/browse/MNG-6967
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.3
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> As is documented here
> https://maven.apache.org/pom.html#version-order-testing
> you can use the maven-artifact JAR file to test version numbers and their
> relative order.
> Unfortunately the output does not match what is used in
> https://maven.apache.org/pom.html#version-order-specification
> when describing the "Trimming Examples". It's matter of {{==}} versus
> {{\->}}. I prefer the one used in the documentation, so I'd like to change
> maven-artifact to use {{->}}. It represents a transformation (trimming in
> this case) -- not a an equality test.
> Another problem is that it does not show you the list of tokens that are the
> result of parsing the version numbers. This can be quite useful when trying
> to figure out why you are getting the results you are.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6967) Improve the command line output from maven-artifact
[
https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-6967:
---
Description:
As is documented here
https://maven.apache.org/pom.html#version-order-testing
you can use the maven-artifact JAR file to test version numbers and their
relative order.
Unfortunately the output does not match what is used in
https://maven.apache.org/pom.html#version-order-specification
when describing the "Trimming Examples". It's matter of {{==}} versus {{\->}}.
I prefer the one used in the documentation, so I'd like to change
maven-artifact to use {{->}}. It represents a transformation (trimming in this
case) -- not a an equality test.
Another problem is that it does not show you the list of tokens that are the
result of parsing the version numbers. This can be quite useful when trying to
figure out why you are getting the results you are.
was:
As is documented here
https://maven.apache.org/pom.html#version-order-testing
you can use the maven-artifact JAR file to test version numbers and their
relative order.
Unfortunately the output does not match what is used in
https://maven.apache.org/pom.html#version-order-specification
when describing the "Trimming Examples". It's matter of {{==}} versus {{->}}. I
prefer the one used in the documentation, so I'd like to change maven-artifact
to use {{->}}. It respresents a transformation (trimming in this case) -- not a
an equality test.
Another problem is that it does not show you the list of tokens that are the
result of parsing the version numbers. This can be quite useful when trying to
figure out why you are getting the results you are.
> Improve the command line output from maven-artifact
> ---
>
> Key: MNG-6967
> URL: https://issues.apache.org/jira/browse/MNG-6967
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.3
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> As is documented here
> https://maven.apache.org/pom.html#version-order-testing
> you can use the maven-artifact JAR file to test version numbers and their
> relative order.
> Unfortunately the output does not match what is used in
> https://maven.apache.org/pom.html#version-order-specification
> when describing the "Trimming Examples". It's matter of {{==}} versus
> {{\->}}. I prefer the one used in the documentation, so I'd like to change
> maven-artifact to use {{->}}. It represents a transformation (trimming in
> this case) -- not a an equality test.
> Another problem is that it does not show you the list of tokens that are the
> result of parsing the version numbers. This can be quite useful when trying
> to figure out why you are getting the results you are.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-714) Add analyze parameter "ignoreUnusedRuntime"
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318854#comment-17318854 ] Lars Knickrehm commented on MDEP-714: - We can work around this for now by ignoring those dependencies, therefore a release unteil 2022 would be helpful, but this is not a blocking thing. > Add analyze parameter "ignoreUnusedRuntime" > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.3 > > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6772) Super POM overwrites remapped central repository in nested dependencyManagement import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-6772:
---
Fix Version/s: 4.0.x-candidate
> Super POM overwrites remapped central repository in nested
> dependencyManagement import POMs
> ---
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
> Fix For: 4.0.x-candidate
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested dependencyManagement import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318837#comment-17318837
]
Herve Boutemy commented on MNG-6772:
notice that I implemented MRESOLVER-168 to ease debugging order of repositories
when resolving artifacts
> Super POM overwrites remapped central repository in nested
> dependencyManagement import POMs
> ---
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6397) Maven Transitive Dependency Resolution Does Not Respect Repository Definition in pom.xml
[
https://issues.apache.org/jira/browse/MNG-6397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318835#comment-17318835
]
Herve Boutemy commented on MNG-6397:
to ease debugging of repositories order when resolving an artifact, I
implemented MRESOLVER-168
> Maven Transitive Dependency Resolution Does Not Respect Repository Definition
> in pom.xml
>
>
> Key: MNG-6397
> URL: https://issues.apache.org/jira/browse/MNG-6397
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories, Dependencies, POM
>Affects Versions: 3.0, 3.5.0, 3.5.2, 3.5.3, 3.6.0, 3.6.1, 3.6.3
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> Maven home: /usr/local/share/maven
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Alan Czajkowski
>Priority: Critical
> Labels: maven
> Fix For: 4.0.x-candidate, waiting-for-feedback,
> wontfix-candidate, 4.0.0, 4.0.0-alpha-1
>
>
> _*Note:* I am trying to do a build behind a firewall which means I cannot
> access the Internet, I can only access my internal Maven repository inside my
> network, so:_
> - _grabbing artifacts from https://artifacts.example.com/repository/maven/
> works fine_
> - _grabbing artifacts from anywhere else fails due to firewall restrictions_
> Let's begin:
> My {{pom.xml}} has the following:
> {code:xml}
> ...
>
> ...
>
> org.springframework.boot
> spring-boot-starter-web
> 2.0.0.RELEASE
>
> ...
>
> ...
>
> ...
>
> central
> Public
> https://artifacts.example.com/repository/maven/
>
> true
>
>
> true
>
>
> ...
>
> ...
> {code}
> The {{dependency:tree}} for the {{spring-boot-starter-web}} is as follows:
> {code:java}
> +- org.springframework.boot:spring-boot-starter-web:jar:2.0.0.RELEASE:compile
> | +-
> org.springframework.boot:spring-boot-starter-json:jar:2.0.0.RELEASE:compile
> | | +-
> com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.9.4:compile
> | | +-
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.9.4:compile
> | | \-
> com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.9.4:compile
> | +-
> org.springframework.boot:spring-boot-starter-tomcat:jar:2.0.0.RELEASE:compile
> | | \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.5.28:compile
> | +- org.hibernate.validator:hibernate-validator:jar:6.0.7.Final:compile
> | | +- javax.validation:validation-api:jar:2.0.1.Final:compile
> | | +- org.jboss.logging:jboss-logging:jar:3.3.0.Final:compile
> | | \- com.fasterxml:classmate:jar:1.3.1:compile
> | \- org.springframework:spring-web:jar:5.0.4.RELEASE:compile
> {code}
> How is it that the build fails as such:
> {code:java}
> ...
> Downloading:
> https://repo.spring.io/milestone/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://repo.spring.io/snapshot/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://dl.bintray.com/rabbitmq/maven-milestones/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://repo.maven.apache.org/maven2/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> ...
> [ERROR] Failed to execute goal on project maven-multi-module-demo-backend:
> Could not resolve dependencies for project
> com.example.pipe:maven-multi-module-demo-backend:war:1.0.0-SNAPSHOT: Failed
> to collect dependencies at
> org.springframework.boot:spring-boot-starter-web:jar:2.0.0.RELEASE ->
> org.hibernate.validator:hibernate-validator:jar:6.0.7.Final: Failed to read
> artifact descriptor for
> org.hibernate.validator:hibernate-validator:jar:6.0.7.Final: Could not
> transfer artifact org.jboss.shrinkwrap:shrinkwrap-bom:pom:1.2.3 from/to
> spring-milestone (https://repo.spring.io/milestone): Connection reset ->
> [Help 1]
> ...
> {code}
> when I did not even reference this repo {{spring-milestone
> ([https://repo.spring.io/milestone])}} anywhere in my {{pom.xml}}?
> When you go down the Spring Boot rabbit hole (go into the
> {{spring-boot-starter-web}}'s {{pom.xml}} and then traverse up its parent-pom
> structure a few jumps) you'll eventually get to a parent-pom
> {{spring-boot-dependencies}} with this definition:
> {code:xml}
> ...
>
>
>
>
[jira] [Updated] (MNG-6772) Super POM overwrites remapped central repository in nested dependencyManagement import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-6772:
---
Summary: Super POM overwrites remapped central repository in nested
dependencyManagement import POMs (was: Super POM overwrites remapped central
repository in nested import POMs)
> Super POM overwrites remapped central repository in nested
> dependencyManagement import POMs
> ---
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6397) Maven Transitive Dependency Resolution Does Not Respect Repository Definition in pom.xml
[
https://issues.apache.org/jira/browse/MNG-6397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-6397:
---
Affects Version/s: 3.0
> Maven Transitive Dependency Resolution Does Not Respect Repository Definition
> in pom.xml
>
>
> Key: MNG-6397
> URL: https://issues.apache.org/jira/browse/MNG-6397
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories, Dependencies, POM
>Affects Versions: 3.0, 3.5.0, 3.5.2, 3.5.3, 3.6.0, 3.6.1, 3.6.3
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> Maven home: /usr/local/share/maven
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Alan Czajkowski
>Priority: Critical
> Labels: maven
> Fix For: 4.0.x-candidate, waiting-for-feedback,
> wontfix-candidate, 4.0.0, 4.0.0-alpha-1
>
>
> _*Note:* I am trying to do a build behind a firewall which means I cannot
> access the Internet, I can only access my internal Maven repository inside my
> network, so:_
> - _grabbing artifacts from https://artifacts.example.com/repository/maven/
> works fine_
> - _grabbing artifacts from anywhere else fails due to firewall restrictions_
> Let's begin:
> My {{pom.xml}} has the following:
> {code:xml}
> ...
>
> ...
>
> org.springframework.boot
> spring-boot-starter-web
> 2.0.0.RELEASE
>
> ...
>
> ...
>
> ...
>
> central
> Public
> https://artifacts.example.com/repository/maven/
>
> true
>
>
> true
>
>
> ...
>
> ...
> {code}
> The {{dependency:tree}} for the {{spring-boot-starter-web}} is as follows:
> {code:java}
> +- org.springframework.boot:spring-boot-starter-web:jar:2.0.0.RELEASE:compile
> | +-
> org.springframework.boot:spring-boot-starter-json:jar:2.0.0.RELEASE:compile
> | | +-
> com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.9.4:compile
> | | +-
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.9.4:compile
> | | \-
> com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.9.4:compile
> | +-
> org.springframework.boot:spring-boot-starter-tomcat:jar:2.0.0.RELEASE:compile
> | | \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.5.28:compile
> | +- org.hibernate.validator:hibernate-validator:jar:6.0.7.Final:compile
> | | +- javax.validation:validation-api:jar:2.0.1.Final:compile
> | | +- org.jboss.logging:jboss-logging:jar:3.3.0.Final:compile
> | | \- com.fasterxml:classmate:jar:1.3.1:compile
> | \- org.springframework:spring-web:jar:5.0.4.RELEASE:compile
> {code}
> How is it that the build fails as such:
> {code:java}
> ...
> Downloading:
> https://repo.spring.io/milestone/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://repo.spring.io/snapshot/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://dl.bintray.com/rabbitmq/maven-milestones/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://repo.maven.apache.org/maven2/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> ...
> [ERROR] Failed to execute goal on project maven-multi-module-demo-backend:
> Could not resolve dependencies for project
> com.example.pipe:maven-multi-module-demo-backend:war:1.0.0-SNAPSHOT: Failed
> to collect dependencies at
> org.springframework.boot:spring-boot-starter-web:jar:2.0.0.RELEASE ->
> org.hibernate.validator:hibernate-validator:jar:6.0.7.Final: Failed to read
> artifact descriptor for
> org.hibernate.validator:hibernate-validator:jar:6.0.7.Final: Could not
> transfer artifact org.jboss.shrinkwrap:shrinkwrap-bom:pom:1.2.3 from/to
> spring-milestone (https://repo.spring.io/milestone): Connection reset ->
> [Help 1]
> ...
> {code}
> when I did not even reference this repo {{spring-milestone
> ([https://repo.spring.io/milestone])}} anywhere in my {{pom.xml}}?
> When you go down the Spring Boot rabbit hole (go into the
> {{spring-boot-starter-web}}'s {{pom.xml}} and then traverse up its parent-pom
> structure a few jumps) you'll eventually get to a parent-pom
> {{spring-boot-dependencies}} with this definition:
> {code:xml}
> ...
>
>
>
> false
>
> spring-milestone
> Spring Milestone
>
[GitHub] [maven-surefire] reinhapa commented on pull request #343: SUREFIRE-1881 Adds additional debug log and fork connection timeout
reinhapa commented on pull request #343: URL: https://github.com/apache/maven-surefire/pull/343#issuecomment-817324741 Reset this PR to the actual changes from @Tibor17 that I've tested -- 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] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318806#comment-17318806
]
Michael Osipov commented on MDEPLOY-254:
Here it is.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318794#comment-17318794
]
Alexander Kriegisch commented on MDEPLOY-254:
-
OK, what the heck - I cloned and built Maven myself. The current master on the
3.6.x branch works correctly. So if this is the feedback you were waiting for
in this ticket and if that was blocking the 3.6.4 release, maybe we are down
one blocker now.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318790#comment-17318790
]
Alexander Kriegisch commented on MDEPLOY-254:
-
There was no recent build of [branch
maven-3.6.x|https://github.com/apache/maven/tree/maven-3.6.x], but I tried [one
from
2020-11-25|https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/3.7.0-SNAPSHOT/apache-maven-3.7.0-20201125.221643-204-bin.zip]
and it worked correctly. So unless the fix there was somehow reverted in the
meantime, it is looking good. But actually, I might have tested the wrong
branch, because branch maven-3.6.x uses version 3.6.4-SNAPSHOT and the one I
tested sports libraries with 3.7.0-SNAPSHOT versions. If you could point me to
a recent 3.6.4 snapshot, I would download and re-test it.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7114) Publish XSDs as artifact to Central
[
https://issues.apache.org/jira/browse/MNG-7114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318786#comment-17318786
]
Robert Scholte commented on MNG-7114:
-
Just to keep focus: this seems unrelated to the title of this issue, so better
discuss it in a separate ticket.
> Publish XSDs as artifact to Central
> ---
>
> Key: MNG-7114
> URL: https://issues.apache.org/jira/browse/MNG-7114
> Project: Maven
> Issue Type: Improvement
>Reporter: Andreas Sewe
>Priority: Minor
>
> At the moment, a number of XML Schema files for descriptor-like file formats
> like archetype or assembly descriptors are only available at
> [https://maven.apache.org/xsd/].
> This makes them hard to consume, for example, by the {{xml:validate}} goal,
> which is IMHO quite well suited for sanity-checking your descriptor files
> before packaging and subsequently releasing them.
> Would it be possible to release the XSDs under {{org.apache.maven:maven-xsd}}
> or a similar coordinate?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on pull request #343: SUREFIRE-1881 Adds additional debug log and fork connection timeout
Tibor17 commented on pull request #343: URL: https://github.com/apache/maven-surefire/pull/343#issuecomment-817308673 @eolivelli Nice to see you again. I tried to finish the branch `dry-pipes-tcp-guarantees`. I fixed the tests but one could not be finished. It is the `E2ETest`. It fails because something is 80 times slower and the test times out. I will push test fixes but first I need to cleanup my workspace changes. Not sure how fast is this test in the master but I guess there wouldn't be this problem. -- 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] (MDEP-714) Add analyze parameter "ignoreUnusedRuntime"
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318776#comment-17318776 ] Michael Osipov commented on MDEP-714: - There is no real plan because a release solely depends on the motivation of a release manager. Is this change paritucalairy important for you? If yes, how? > Add analyze parameter "ignoreUnusedRuntime" > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.3 > > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dist-tool] hboutemy merged pull request #2: Added a menu to point to maven test bench project that run a daily check of memory allocation
hboutemy merged pull request #2: URL: https://github.com/apache/maven-dist-tool/pull/2 -- 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] (MDEP-714) Add analyze parameter "ignoreUnusedRuntime"
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318762#comment-17318762 ] Lars Knickrehm commented on MDEP-714: - [~michael-o], thanks for your support and integrating the request. One last question: Is there any release plan, that allows me to plan the availability of this change? > Add analyze parameter "ignoreUnusedRuntime" > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.3 > > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on pull request #343: SUREFIRE-1881 Adds additional debug log and fork connection timeout
Tibor17 commented on pull request #343: URL: https://github.com/apache/maven-surefire/pull/343#issuecomment-817297279 @kriegaex I think Patrick used my branch dry-pipes-tcp-guarantees. So for everybody, we did not mean a code in 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] [Commented] (SUREFIRE-1907) maven run test when surefire skipTest enabled by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318752#comment-17318752
]
Tibor Digana commented on SUREFIRE-1907:
[~mah454]
skipTest is not enabled by defaul, for sure!
We had another guy who had the same problem in stackoverflow but he found by
himself that skipTest was set to true in the parent POM or another POM in
dependencyManagement. Pls check it!
> maven run test when surefire skipTest enabled by default
>
>
> Key: SUREFIRE-1907
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1907
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Mahdi
>Priority: Critical
>
> according to your documents :
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-tests.html
> I try to disable tests by default and run this tests on cli with this command
> :
> {quote}mvn clean compile test -DskipTests=false
> {quote}
> but still tests skipped in this case .
> I also ask this question on StackOverflow with more explanation :
> https://stackoverflow.com/questions/67032138/maven-run-test-when-surefire-skiptest-enabled-by-default/67032191?noredirect=1#comment118486523_67032191
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1837) NullPointerException at AbstractSurefireMojo$ClasspathCache.setCachedClasspath
[
https://issues.apache.org/jira/browse/SUREFIRE-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318749#comment-17318749
]
Tibor Digana commented on SUREFIRE-1837:
[~Enigo]
The problematic artifact {{apiguardian-api-1.0.0}} is part of JUnit5, right?
If two or more modules are running in parallel, it would be fine to list all of
them which prooves the hypothesis that they attempt to download the artifact
concurrently, lock it which probably cause the issue that the artifact could
not be properly resolved, or the collections are not threadsafe (JMM concept
JSR-133) and the artifact is not visible in the plugin's Thread.
> NullPointerException at AbstractSurefireMojo$ClasspathCache.setCachedClasspath
> --
>
> Key: SUREFIRE-1837
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1837
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
> Environment: mvn --version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /opt/apache-maven-3.6.3
> Java version: 11.0.8, vendor: Amazon.com Inc., runtime:
> /usr/lib/jvm/java-11-amazon-corretto
> Jenkins ver. 2.204.6 on Ubuntu 18
>Reporter: Ruslan Sibgatullin
>Priority: Major
>
> While migrating a rather old and big project from Java 8 to Java 11 the
> following exception happens occasionally (once in 3-4 builds):
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test)
> on project my_project: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test
> (default-test) on project cachereloader-validation: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:190)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:186)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> at java.lang.Thread.run (Thread.java:834)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:190)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:186)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> at java.lang.Thread.run (Thread.java:834)
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.setCachedClasspath
> (AbstractSurefireMojo.java:4121)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.access$200
> (AbstractSurefireMojo.java:4102)
> at
>
[jira] [Commented] (MNG-7114) Publish XSDs as artifact to Central
[
https://issues.apache.org/jira/browse/MNG-7114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318744#comment-17318744
]
Michael Osipov commented on MNG-7114:
-
Can you observe the same behavior with regular dependencies, not plugins?
[~rfscholte], I guess this is by design although it makes not always sense,
does it?
> Publish XSDs as artifact to Central
> ---
>
> Key: MNG-7114
> URL: https://issues.apache.org/jira/browse/MNG-7114
> Project: Maven
> Issue Type: Improvement
>Reporter: Andreas Sewe
>Priority: Minor
>
> At the moment, a number of XML Schema files for descriptor-like file formats
> like archetype or assembly descriptors are only available at
> [https://maven.apache.org/xsd/].
> This makes them hard to consume, for example, by the {{xml:validate}} goal,
> which is IMHO quite well suited for sanity-checking your descriptor files
> before packaging and subsequently releasing them.
> Would it be possible to release the XSDs under {{org.apache.maven:maven-xsd}}
> or a similar coordinate?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318743#comment-17318743
]
Michael Osipov commented on MDEPLOY-254:
Can you try the {{maven-3.6.x}} branch? There is one backport which might solve
the issue for you.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-714) Add analyze parameter "ignoreUnusedRuntime"
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318722#comment-17318722 ] Hudson commented on MDEP-714: - Build succeeded in Jenkins: Maven » Maven TLP » maven-dependency-plugin » master #54 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-dependency-plugin/job/master/54/ > Add analyze parameter "ignoreUnusedRuntime" > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.3 > > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dist-tool] hboutemy commented on pull request #2: Added a menu to point to maven test bench project that run a daily check of memory allocation
hboutemy commented on pull request #2: URL: https://github.com/apache/maven-dist-tool/pull/2#issuecomment-817284677 > Thx for the effort, but adding a link to the static site will not help here. It's not a static site: it's the result of the last check against Maven HEAD, and it's failing if the execution hits a threshold. As it is currently, it's useful to detect if there is a bad move. But, as a user, I don't only want "build passing" vs "build failing" on HEAD, I also want to see historical results, with the effective memory allocation value that each key past version has attained. Patrice is working on this = storing values in a S3 bucket to have more that the last success/failure, but a time series of memory allocation values, which in the future can also be shown as a nice graph... This PR is only the first step, the MVP, of a new type of performance tests: it's not yet the ideal dream we have, but it's what we currently can do in the right direction, while working on next steps -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MDEP-714) Add analyze parameter "ignoreUnusedRuntime"
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MDEP-714. --- Resolution: Fixed Fixed with [9aa0fc026dccb64d4dc5529583ed9e936e37c394|https://gitbox.apache.org/repos/asf?p=maven-dependency-plugin.git=commit=9aa0fc026dccb64d4dc5529583ed9e936e37c394]. > Add analyze parameter "ignoreUnusedRuntime" > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.3 > > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dependency-plugin] asfgit closed pull request #123: [MDEP-714] - Add analyze parameter "ignoreUnusedRuntime"
asfgit closed pull request #123: URL: https://github.com/apache/maven-dependency-plugin/pull/123 -- 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-1837) NullPointerException at AbstractSurefireMojo$ClasspathCache.setCachedClasspath
[
https://issues.apache.org/jira/browse/SUREFIRE-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318704#comment-17318704
]
Tibor Digana commented on SUREFIRE-1837:
[~Enigo]
Hi Ruslan,
IMO the compiler would not change the behavior but you can try with it if you
really want to.
For me it is clear that the issue is related to {{maven-compact:3.0}} and other
libraries extending it, e.g. Takari, i.e.:
{{LegacyRepositorySystem.resolve}} > {{DefaultArtifactResolver.resolve}} >
{{org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact}} >
{{org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads}}
> {{io.takari.aether.localrepo.TrackingFileManager.update}}
You should create the ticket in MNG, see
https://maven.apache.org/ref/3.8.1/maven-compat/issue-management.html
After you created the ticket in MNG, make this ticket dependent on MNG-x
and provide a the developers with a link to my previous comment. They will
understand what I am talking about there. Thx
> NullPointerException at AbstractSurefireMojo$ClasspathCache.setCachedClasspath
> --
>
> Key: SUREFIRE-1837
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1837
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
> Environment: mvn --version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /opt/apache-maven-3.6.3
> Java version: 11.0.8, vendor: Amazon.com Inc., runtime:
> /usr/lib/jvm/java-11-amazon-corretto
> Jenkins ver. 2.204.6 on Ubuntu 18
>Reporter: Ruslan Sibgatullin
>Priority: Major
>
> While migrating a rather old and big project from Java 8 to Java 11 the
> following exception happens occasionally (once in 3-4 builds):
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test)
> on project my_project: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test
> (default-test) on project cachereloader-validation: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:190)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:186)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> at java.lang.Thread.run (Thread.java:834)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:190)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:186)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> at java.lang.Thread.run
[jira] [Updated] (MDEP-714) Add analyze parameter "ignoreUnusedRuntime"
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MDEP-714: Summary: Add analyze parameter "ignoreUnusedRuntime" (was: runtime dependencies reported as unused) > Add analyze parameter "ignoreUnusedRuntime" > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.3 > > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MDEP-714) runtime dependencies reported as unused
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318700#comment-17318700 ] Michael Osipov edited comment on MDEP-714 at 4/11/21, 9:09 AM: --- I don't see as a bug because it is rooted in the nature of the system. An improvement can be done to remove those deps from analysis. was (Author: michael-o): I don't see as a bug becuase it is rooted in the nature of the system. An improvement can be done to remove those deps from analysis. > runtime dependencies reported as unused > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.3 > > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-714) runtime dependencies reported as unused
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MDEP-714: Fix Version/s: 3.1.3 > runtime dependencies reported as unused > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.3 > > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEP-714) runtime dependencies reported as unused
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318700#comment-17318700 ] Michael Osipov commented on MDEP-714: - I don't see as a bug becuase it is rooted in the nature of the system. An improvement can be done to remove those deps from analysis. > runtime dependencies reported as unused > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-714) runtime dependencies reported as unused
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MDEP-714: Issue Type: New Feature (was: Bug) > runtime dependencies reported as unused > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MDEP-714) runtime dependencies reported as unused
[ https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MDEP-714: --- Assignee: Michael Osipov > runtime dependencies reported as unused > --- > > Key: MDEP-714 > URL: https://issues.apache.org/jira/browse/MDEP-714 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > > Typical output when analyzing the maven-archetype-plugin: > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime > However since this is needed at runtime, possibly via reflection, it seems > likely that it is used but the dependency analyzer can't figure this out. > Confirm and consider whether the plugin should simply never report runtime > dependencies as unused. > This is tricky because it's certainly possible that a runtime dependency is > unused, but in practice it seems more likely than not to be a false positive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dependency-plugin] michael-o commented on pull request #123: [MDEP-714] - Add analyze parameter "ignoreUnusedRuntime"
michael-o commented on pull request #123: URL: https://github.com/apache/maven-dependency-plugin/pull/123#issuecomment-817272824 Looking at... -- 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
