[jira] [Comment Edited] (MDEP-579) Regression: get goal does not pass server credentials to BasicRepositoryConnector
[
https://issues.apache.org/jira/browse/MDEP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906092#comment-16906092
]
Kent Granström edited comment on MDEP-579 at 8/14/19 4:35 AM:
--
Hi [~pmoerenhout].
We're actually using a usertoken and pwtoken generated by our Nexus instance
but that basically equals to username and pw. I'm not allowed to hand out
anything from our environment but for the sake of this issue I have written a
somewhat equivalent configuration of what I'm doing to get this behaviour.
Obviously the path, user and pw doesn't map to the real world but perhaps its
enough for you to be able to reproduce the issue.
Running a bat-file from the commandline in Windows:
{code:java}
In get.bat (toggling 3.1.1 and 3.1.2-SNAPSHOT):
mvn clean -X
org.apache.maven.plugins:maven-dependency-plugin:3.1.2-SNAPSHOT:get ^
-Dartifact= com.test.note:note-docker:4.1:zip ^
-DremoteRepositories=internal-repo-id::default::https://example.com/nexus/repository/internal-repo
^
-Dtransitive=false
This is settings.xml:
nexus
SomeUser
APassword
internal-repo-id
SomeUSer
APAssword
nexus
Our Public repo group
https://example.com/nexus/repository/public-repo
*,!internal-repo
internal-repo-id
Our internal artifact group
https://example.com/nexus/repository/internal-repo
internal-repo
{code}
Hope this helps.
was (Author: kentgran):
Hi [~pmoerenhout].
We're actually using a usertoken and pwtoken generated by our Nexus instance
but that basically equals to username and pw. I'm not allowed to hand out
anything from our environment but for the sake of this issue I have written a
somewhat equivalent configuration of what I'm doing to get this behaviour.
Obviously the path, user and pw doesn't map to the real world but perhaps its
enough for you to be able to reproduce the issue.
Running a bat-file from the commandline in Windows:
{code:java}
In get.bat (toggling 3.1.1 and 3.1.2-SNAPSHOT):
mvn clean -X
org.apache.maven.plugins:maven-dependency-plugin:3.1.2-SNAPSHOT:get ^
-Dartifact= com.test.note:note-docker:4.1:zip ^
-DremoteRepositories=internal-repo-id::default::https://example.com/nexus/repository/internal-repo
^
-Dtransitive=false
This is settings.xml:
nexus
SomeUser
APassword
internal-repo-id
SomeUSer
APAssword
nexus
Our Public repo group
https://example.com/nexus/repository/public-repo
*,!internal-repo
internal-repo
Our internal artifact group
https://example.com/nexus/repository/internal-repo
internal-repo
{code}
Hope this helps.
> Regression: get goal does not pass server credentials to
> BasicRepositoryConnector
> -
>
> Key: MDEP-579
> URL: https://issues.apache.org/jira/browse/MDEP-579
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: get
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Richard W. Eggert II
>Priority: Critical
> Labels: credentials
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{get}} goal does not pass the server credentials from {{settings.xml}}
> to the {{BasicRepositoryConnector}} in version 3.0.1 (and, presumably 3.0.0),
> resulting in {{NotAuthorized}} errors when resolving artifacts against
> repositories that require authentication. It works correctly in version 2.9.
> Background: I discovered this in the course of debugging a Jenkins job in
> which I'm using the {{get}} and {{copy}} goals from the command line (with no
> POM) to download artifacts to deploy. After spending several hours thinking
> that Jenkins was not properly configuring {{settings.xml}}, I noticed from
> the Maven debug output that the credentials were being passed when resolving
> the maven-dependency-plugin and its dependencies, but not being passed when
> resolving the artifact I requested. On a hunch I downgraded from
> maven-dependency-plugin version 3.0.1 to 2.9, and suddenly everything
> magically worked.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (SUREFIRE-1553) @Unroll forces usage of JUnit Vintage
[
https://issues.apache.org/jira/browse/SUREFIRE-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906679#comment-16906679
]
Tibor Digana commented on SUREFIRE-1553:
[~clarkperkins]
I have observed the same results. Maybe you should help us and debug the class
{{org.apache.maven.surefire.junitplatform.RunListenerAdapter}} and we will
concentrate on another issues where you cannot. This will speed up the release.
I do not know where the problem is but the debugger will uncover more.
> @Unroll forces usage of JUnit Vintage
> -
>
> Key: SUREFIRE-1553
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1553
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Sergey Skryabin
>Assignee: Tibor Digana
>Priority: Major
>
> If run
> {code}mvn clean test{code}
> JUnit4 tests and Spock tests (which not contain @Unroll) are executed
> normally. Once Spock test with @Unroll annotation appears, then Surefire
> execute
> {code}[INFO] Running JUnit Vintage{code}
> and all other JUnit4 tests and Spock tests are wrapped with this runner.
> In surefire-reports I see _TEST- @Unroll>.xml_ s and than
> _TEST-JUnit Vintage.xml_
> Though it could be done by intention, behaviour is different from 2.21.0 (no
> wrapping with Vintage). Also it much more visible to have separate reports
> per test class (both in console output and surefire-reports folder).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MDEP-579) Regression: get goal does not pass server credentials to BasicRepositoryConnector
[
https://issues.apache.org/jira/browse/MDEP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906622#comment-16906622
]
Robert Scholte commented on MDEP-579:
-
I've added a link to https://github.com/mojohaus/mrm/issues/23 which, once
implemented, should make it easier to verify this usecase as part of the
integration tests
> Regression: get goal does not pass server credentials to
> BasicRepositoryConnector
> -
>
> Key: MDEP-579
> URL: https://issues.apache.org/jira/browse/MDEP-579
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: get
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Richard W. Eggert II
>Priority: Critical
> Labels: credentials
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{get}} goal does not pass the server credentials from {{settings.xml}}
> to the {{BasicRepositoryConnector}} in version 3.0.1 (and, presumably 3.0.0),
> resulting in {{NotAuthorized}} errors when resolving artifacts against
> repositories that require authentication. It works correctly in version 2.9.
> Background: I discovered this in the course of debugging a Jenkins job in
> which I'm using the {{get}} and {{copy}} goals from the command line (with no
> POM) to download artifacts to deploy. After spending several hours thinking
> that Jenkins was not properly configuring {{settings.xml}}, I noticed from
> the Maven debug output that the credentials were being passed when resolving
> the maven-dependency-plugin and its dependencies, but not being passed when
> resolving the artifact I requested. On a hunch I downgraded from
> maven-dependency-plugin version 3.0.1 to 2.9, and suddenly everything
> magically worked.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [maven-dependency-plugin] aiannucci commented on issue #2: MDEP-568 respect excludeGroupIds in go-offline
aiannucci commented on issue #2: MDEP-568 respect excludeGroupIds in go-offline URL: https://github.com/apache/maven-dependency-plugin/pull/2#issuecomment-521006435 Are you considering merging this change for an upcoming release? Thanks! 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 With regards, Apache Git Services
[jira] [Commented] (MNG-6516) Build maven-mojo using Java9 fails
[ https://issues.apache.org/jira/browse/MNG-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906586#comment-16906586 ] Robert Scholte commented on MNG-6516: - [~heruan] these are 2 different issues. If you can't generate Javadoc on a hybrid project, that's something that needs to be fixed by the maven-javadoc-plugin if possible (it might be the Javadoc tool can't handle it). > Build maven-mojo using Java9 fails > -- > > Key: MNG-6516 > URL: https://issues.apache.org/jira/browse/MNG-6516 > Project: Maven > Issue Type: Bug > Components: Plugin API > Environment: java 9 >Reporter: Matthias Fuchs >Assignee: Robert Scholte >Priority: Major > Labels: java9, modules > > I'm upgrading my Java8 framework to Java9, but I have major problems > upgrading my mojos > (https://github.com/spot-next/spot-framework/tree/develop/spot-maven-plugin). > The problem is that my dependecies maven-artifact a maven-core contain the > same classes. This causes the java9 compiler to fail. It also seems that > those libraries haven't been upgraded to use module-info.java or at least > automatic module name in META-INF. > Expected solution: > restructure the libraries to conform to the java module system. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MNG-6516) Build maven-mojo using Java9 fails
[ https://issues.apache.org/jira/browse/MNG-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906578#comment-16906578 ] Giovanni Lovato commented on MNG-6516: -- [~rfscholte] Does this mean one cannot adopt JPMS in his own plugin? I have several plugins part of a Maven multi-module project which I'm porting to JPMS and the JavaDoc plugin fails to produce aggregate docs if there's even just one module not adopting JPMS. > Build maven-mojo using Java9 fails > -- > > Key: MNG-6516 > URL: https://issues.apache.org/jira/browse/MNG-6516 > Project: Maven > Issue Type: Bug > Components: Plugin API > Environment: java 9 >Reporter: Matthias Fuchs >Assignee: Robert Scholte >Priority: Major > Labels: java9, modules > > I'm upgrading my Java8 framework to Java9, but I have major problems > upgrading my mojos > (https://github.com/spot-next/spot-framework/tree/develop/spot-maven-plugin). > The problem is that my dependecies maven-artifact a maven-core contain the > same classes. This causes the java9 compiler to fail. It also seems that > those libraries haven't been upgraded to use module-info.java or at least > automatic module name in META-INF. > Expected solution: > restructure the libraries to conform to the java module system. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (MDEP-657) Maven - Failing when two modules have same dependency and both trying to download the dependency at the same time when Parallel flag is enabled.
[
https://issues.apache.org/jira/browse/MDEP-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Padma G updated MDEP-657:
-
Description:
Maven Version 3.6.1
command : mvn -U -T 2C -DskipTests=true clean install -s settings.xml
We have several modules with same dependency and it is failing when two are
downloading same dependency at the same time with below error.
if we remove parallel flag it will go through. But the build will be very long.
Ideally it should wait and not fail?
{noformat}
[ERROR] Failed to execute goal on project content-model: Could not resolve
dependencies for project com.gehc.ei.zfp:content-model:jar:6011.0.1.8270:
Failed to collect dependencies at
com.gehc.ei.zfp:ei-logging-service:jar:6011.0.1.8109 ->
com.gehc.ei.zfp:atna-log-appender:jar:6011.0.1.8109: Failed to read artifact
descriptor for com.gehc.ei.zfp:atna-log-appender:jar:6011.0.1.8109: Could not
transfer artifact com.gehc.ei.zfp:atna-log-appender:pom:6011.0.1.8109 from/to
central ([/artifactory/maven-zfp-all|:
C:\Users\user\.m2\repository\com\gehc\ei\zfp\atna-log-appender\6011.0.1.8109\atna-log-appender-6011.0.1.8109.pom.part.lock
(The process cannot access the file because it is being used by another
process) -> [Help 1]
{noformat}
Any idea why it is behaving this way?
Regards,
Padma
was:
Maven Version 3.6.1
command : mvn -U -T 2C -DskipTests=true clean install -s settings.xml
We have several modules with same dependency and it is failing when two are
downloading same dependency at the same time with below error.
if we remove parallel flag it will go through. But the build will be very long.
Ideally it should wait and not fail?
{noformat}
[ERROR] Failed to execute goal on project content-model: Could not resolve
dependencies for project com.gehc.ei.zfp:content-model:jar:6011.0.1.8270:
Failed to collect dependencies at
com.gehc.ei.zfp:ei-logging-service:jar:6011.0.1.8109 ->
com.gehc.ei.zfp:atna-log-appender:jar:6011.0.1.8109: Failed to read artifact
descriptor for com.gehc.ei.zfp:atna-log-appender:jar:6011.0.1.8109: Could not
transfer artifact com.gehc.ei.zfp:atna-log-appender:pom:6011.0.1.8109 from/to
central ([/artifactory/maven-zfp-all|:
C:\Users\ecagent\.m2\repository\com\gehc\ei\zfp\atna-log-appender\6011.0.1.8109\atna-log-appender-6011.0.1.8109.pom.part.lock
(The process cannot access the file because it is being used by another
process) -> [Help 1]
{noformat}
Any idea why it is behaving this way?
Regards,
Padma
> Maven - Failing when two modules have same dependency and both trying to
> download the dependency at the same time when Parallel flag is enabled.
>
>
> Key: MDEP-657
> URL: https://issues.apache.org/jira/browse/MDEP-657
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Environment: Maven 3.6.1
>Reporter: Padma G
>Priority: Major
>
> Maven Version 3.6.1
> command : mvn -U -T 2C -DskipTests=true clean install -s settings.xml
> We have several modules with same dependency and it is failing when two are
> downloading same dependency at the same time with below error.
> if we remove parallel flag it will go through. But the build will be very
> long.
> Ideally it should wait and not fail?
> {noformat}
> [ERROR] Failed to execute goal on project content-model: Could not resolve
> dependencies for project com.gehc.ei.zfp:content-model:jar:6011.0.1.8270:
> Failed to collect dependencies at
> com.gehc.ei.zfp:ei-logging-service:jar:6011.0.1.8109 ->
> com.gehc.ei.zfp:atna-log-appender:jar:6011.0.1.8109: Failed to read artifact
> descriptor for com.gehc.ei.zfp:atna-log-appender:jar:6011.0.1.8109: Could not
> transfer artifact com.gehc.ei.zfp:atna-log-appender:pom:6011.0.1.8109 from/to
> central ([/artifactory/maven-zfp-all|:
> C:\Users\user\.m2\repository\com\gehc\ei\zfp\atna-log-appender\6011.0.1.8109\atna-log-appender-6011.0.1.8109.pom.part.lock
> (The process cannot access the file because it is being used by another
> process) -> [Help 1]
> {noformat}
> Any idea why it is behaving this way?
> Regards,
> Padma
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (MNG-6733) Package accessible from more than one module
[
https://issues.apache.org/jira/browse/MNG-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-6733.
---
Resolution: Duplicate
Assignee: Robert Scholte
MNG-6516 contains the answer why we can't simply fix that
> Package accessible from more than one module
>
>
> Key: MNG-6733
> URL: https://issues.apache.org/jira/browse/MNG-6733
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.1
> Environment: OpenJDK 12.0.2
>Reporter: Giovanni Lovato
>Assignee: Robert Scholte
>Priority: Major
>
> Importing {{org.apache.maven.plugin.AbstractMojo}} in a project using JPMS,
> the compiler gives this error:
> {code:java}
> The package org.apache.maven.plugin is accessible from more than one module:
> maven.core, maven.plugin.api{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [maven-wagon] michael-o commented on issue #49: [MNG-2802] Concurrent-safe access to local Maven repository
michael-o commented on issue #49: [MNG-2802] Concurrent-safe access to local Maven repository URL: https://github.com/apache/maven-wagon/pull/49#issuecomment-520931855 @Tibor17 Sure, pick up if you can. I can't, unfortunately. 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 With regards, Apache Git Services
[GitHub] [maven-wagon] Tibor17 commented on issue #49: [MNG-2802] Concurrent-safe access to local Maven repository
Tibor17 commented on issue #49: [MNG-2802] Concurrent-safe access to local Maven repository URL: https://github.com/apache/maven-wagon/pull/49#issuecomment-520925365 @michael-o > @Tibor17 would you review if @erikhakansson would provide a new PR for Resolver? Your concurrency skills are better than mine. No prolem. I will try, feel free to ask me whenever it is necessary. @erikhakansson Maybe one advice. Pls keep it still open since it is important issue for the Maven and we can include more developers. We can continue on development of this PR even if you wouldn't participate. @michael-o @olamy Would you mind if we discuss this topic on our mailing list? We in commercial companies usually write a chart of technical alternatives with Pros/Cons. This sounds to me like a step which we have not used yet and here it would be a good approach. WDYT? 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 With regards, Apache Git Services
[GitHub] [maven-wagon] Tibor17 commented on issue #49: [MNG-2802] Concurrent-safe access to local Maven repository
Tibor17 commented on issue #49: [MNG-2802] Concurrent-safe access to local Maven repository URL: https://github.com/apache/maven-wagon/pull/49#issuecomment-520912312 @erikhakansson @michael-o I have recived the announcement in the email right now. Give me some time to dive into this again. 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 With regards, Apache Git Services
[GitHub] [maven-wagon] erikhakansson commented on issue #49: [MNG-2802] Concurrent-safe access to local Maven repository
erikhakansson commented on issue #49: [MNG-2802] Concurrent-safe access to local Maven repository URL: https://github.com/apache/maven-wagon/pull/49#issuecomment-520903968 @michael-o sorry for not replying earlier. But yeah we can close this. Unfortunately I probably won't have time anytime soon to look at a new implementation in the Resolver. 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 With regards, Apache Git Services
[jira] [Updated] (MNG-6733) Package accessible from more than one module
[
https://issues.apache.org/jira/browse/MNG-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Giovanni Lovato updated MNG-6733:
-
Environment: OpenJDK 12.0.2
> Package accessible from more than one module
>
>
> Key: MNG-6733
> URL: https://issues.apache.org/jira/browse/MNG-6733
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.1
> Environment: OpenJDK 12.0.2
>Reporter: Giovanni Lovato
>Priority: Major
>
> Importing {{org.apache.maven.plugin.AbstractMojo}} in a project using JPMS,
> the compiler gives this error:
> {code:java}
> The package org.apache.maven.plugin is accessible from more than one module:
> maven.core, maven.plugin.api{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MSHADE-322) Provide a transformer for properties files
[ https://issues.apache.org/jira/browse/MSHADE-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906102#comment-16906102 ] Hudson commented on MSHADE-322: --- Build unstable in Jenkins: Maven TLP » maven-shade-plugin » master #16 See https://builds.apache.org/job/maven-box/job/maven-shade-plugin/job/master/16/ > Provide a transformer for properties files > -- > > Key: MSHADE-322 > URL: https://issues.apache.org/jira/browse/MSHADE-322 > Project: Maven Shade Plugin > Issue Type: Task >Affects Versions: 3.2.1 >Reporter: Romain Manni-Bucau >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The goal is to be able to merge properties deterministicly and respecting > ordinal common practise. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MDEP-579) Regression: get goal does not pass server credentials to BasicRepositoryConnector
[
https://issues.apache.org/jira/browse/MDEP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906092#comment-16906092
]
Kent Granström commented on MDEP-579:
-
Hi [~pmoerenhout].
We're actually using a usertoken and pwtoken generated by our Nexus instance
but that basically equals to username and pw. I'm not allowed to hand out
anything from our environment but for the sake of this issue I have written a
somewhat equivalent configuration of what I'm doing to get this behaviour.
Obviously the path, user and pw doesn't map to the real world but perhaps its
enough for you to be able to reproduce the issue.
Running a bat-file from the commandline in Windows:
{code:java}
In get.bat (toggling 3.1.1 and 3.1.2-SNAPSHOT):
mvn clean -X
org.apache.maven.plugins:maven-dependency-plugin:3.1.2-SNAPSHOT:get ^
-Dartifact= com.test.note:note-docker:4.1:zip ^
-DremoteRepositories=internal-repo-id::default::https://example.com/nexus/repository/internal-repo
^
-Dtransitive=false
This is settings.xml:
nexus
SomeUser
APassword
internal-repo-id
SomeUSer
APAssword
nexus
Our Public repo group
https://example.com/nexus/repository/public-repo
*,!internal-repo
internal-repo
Our internal artifact group
https://example.com/nexus/repository/internal-repo
internal-repo
{code}
Hope this helps.
> Regression: get goal does not pass server credentials to
> BasicRepositoryConnector
> -
>
> Key: MDEP-579
> URL: https://issues.apache.org/jira/browse/MDEP-579
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: get
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Richard W. Eggert II
>Priority: Critical
> Labels: credentials
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{get}} goal does not pass the server credentials from {{settings.xml}}
> to the {{BasicRepositoryConnector}} in version 3.0.1 (and, presumably 3.0.0),
> resulting in {{NotAuthorized}} errors when resolving artifacts against
> repositories that require authentication. It works correctly in version 2.9.
> Background: I discovered this in the course of debugging a Jenkins job in
> which I'm using the {{get}} and {{copy}} goals from the command line (with no
> POM) to download artifacts to deploy. After spending several hours thinking
> that Jenkins was not properly configuring {{settings.xml}}, I noticed from
> the Maven debug output that the credentials were being passed when resolving
> the maven-dependency-plugin and its dependencies, but not being passed when
> resolving the artifact I requested. On a hunch I downgraded from
> maven-dependency-plugin version 3.0.1 to 2.9, and suddenly everything
> magically worked.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6733) Package accessible from more than one module
[
https://issues.apache.org/jira/browse/MNG-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906063#comment-16906063
]
Michael Osipov commented on MNG-6733:
-
[~rfscholte], this one is for you.
> Package accessible from more than one module
>
>
> Key: MNG-6733
> URL: https://issues.apache.org/jira/browse/MNG-6733
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.1
>Reporter: Giovanni Lovato
>Priority: Major
>
> Importing {{org.apache.maven.plugin.AbstractMojo}} in a project using JPMS,
> the compiler gives this error:
> {code:java}
> The package org.apache.maven.plugin is accessible from more than one module:
> maven.core, maven.plugin.api{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (MNG-6733) Package accessible from more than one module
[
https://issues.apache.org/jira/browse/MNG-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Giovanni Lovato updated MNG-6733:
-
Description:
Importing {{org.apache.maven.plugin.AbstractMojo}} in a project using JPMS, the
compiler gives this error:
{code:java}
The package org.apache.maven.plugin is accessible from more than one module:
maven.core, maven.plugin.api{code}
was:
Importing `org.apache.maven.plugin.AbstractMojo` in a project using JPMS, the
compiler gives this error:
{code:java}
The package org.apache.maven.plugin is accessible from more than one module:
maven.core, maven.plugin.api{code}
> Package accessible from more than one module
>
>
> Key: MNG-6733
> URL: https://issues.apache.org/jira/browse/MNG-6733
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.1
>Reporter: Giovanni Lovato
>Priority: Major
>
> Importing {{org.apache.maven.plugin.AbstractMojo}} in a project using JPMS,
> the compiler gives this error:
> {code:java}
> The package org.apache.maven.plugin is accessible from more than one module:
> maven.core, maven.plugin.api{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (MNG-6733) Package accessible from more than one module
Giovanni Lovato created MNG-6733:
Summary: Package accessible from more than one module
Key: MNG-6733
URL: https://issues.apache.org/jira/browse/MNG-6733
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 3.6.1
Reporter: Giovanni Lovato
Importing `org.apache.maven.plugin.AbstractMojo` in a project using JPMS, the
compiler gives this error:
{code:java}
The package org.apache.maven.plugin is accessible from more than one module:
maven.core, maven.plugin.api{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MDEP-579) Regression: get goal does not pass server credentials to BasicRepositoryConnector
[
https://issues.apache.org/jira/browse/MDEP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905925#comment-16905925
]
Pim Moerenhout commented on MDEP-579:
-
Hi [~kentgran], can you share the (part of the ) POM, and the maven command, so
I try to reproduce your issue ?
How is your repository secured, with username/password ?
I tested it, with getting an artifact from the command line.
> Regression: get goal does not pass server credentials to
> BasicRepositoryConnector
> -
>
> Key: MDEP-579
> URL: https://issues.apache.org/jira/browse/MDEP-579
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: get
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Richard W. Eggert II
>Priority: Critical
> Labels: credentials
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{get}} goal does not pass the server credentials from {{settings.xml}}
> to the {{BasicRepositoryConnector}} in version 3.0.1 (and, presumably 3.0.0),
> resulting in {{NotAuthorized}} errors when resolving artifacts against
> repositories that require authentication. It works correctly in version 2.9.
> Background: I discovered this in the course of debugging a Jenkins job in
> which I'm using the {{get}} and {{copy}} goals from the command line (with no
> POM) to download artifacts to deploy. After spending several hours thinking
> that Jenkins was not properly configuring {{settings.xml}}, I noticed from
> the Maven debug output that the credentials were being passed when resolving
> the maven-dependency-plugin and its dependencies, but not being passed when
> resolving the artifact I requested. On a hunch I downgraded from
> maven-dependency-plugin version 3.0.1 to 2.9, and suddenly everything
> magically worked.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
