[jira] [Commented] (MNG-6130) Lost of profile information in workaround for MNG-4900
[
https://issues.apache.org/jira/browse/MNG-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005978#comment-16005978
]
Sebastian Pötzsch commented on MNG-6130:
The bug still exists in maven 3.5.0.
> Lost of profile information in workaround for MNG-4900
> --
>
> Key: MNG-6130
> URL: https://issues.apache.org/jira/browse/MNG-6130
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9
> Environment: Windows
>Reporter: Boris Brodski
> Labels: easyfix, patch
> Attachments: MNG-6130.patch
>
>
> Please, forgive me not providing example project reproducing the bug.
> It's very tricky and hopefully not necessary, since the 1-line fix is
> provided.
> Using profiles together with maven-javadoc-plugin results in the following
> problem:
> - Configuration from active profiles is not considered during dependency
> resolution started problematically from the maven-javadoc-plugin.
> This leads to unpredictable behavior, that is somewhat hard to reproduce.
> Here is the technical inside and the 1-line fix:
> In the DefaultMavenProjectBuilder.toRequest():
> {noformat}
> if ( profileManager != null ) {
>...
> } else {
> ...
> /*
>* MNG-4900: Hack to workaround deficiency of legacy API which makes it
> impossible for plugins to access the
>* global profile manager which is required to build a POM like a CLI
> invocation does. Failure to consider
>* the activated profiles can cause repo declarations to be lost which in
> turn will result in artifact
>* resolution failures, in particular when using the enhanced local repo
> which guards access to local files
>* based on the configured remote repos.
>*/
> request.setActiveProfileIds( req.getActiveProfiles() );
> request.setInactiveProfileIds( req.getInactiveProfiles() );
> }
> {noformat}
> Here we copy active and inactive profile ids, but we don't copy the list of
> all profile ids. Missing line:
> {noformat}
> request.setProfiles( req.getProfiles() );
> {noformat}
> As the result the method DefaultProfileManager.getActiveProfiles() always
> returns an empty list:
> {noformat}
> List activeProfiles = new ArrayList<>( profiles.size() );
> for ( Profile profile : profiles ) {
> ...
> }
> return activeProfiles;
> {noformat}
> "profiles" here is empty, since it wasn't copied together with
> "getActiveProfiles()" and "getInactiveProfiles()"
> Adding the missing line fixes the problem.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6205) Non-ascii chars in name element are displayed as question marks in Win CLI output (regression)
[
https://issues.apache.org/jira/browse/MNG-6205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005968#comment-16005968
]
Anders Hammar commented on MNG-6205:
[~hboutemy] I've tested jansi 1.16 and it still doesn't hande non-ascii chars
correctly with IBM JDK. :-( Tested by patching Maven 3.5.0 and with IBM JDK 1.7.
So, still a regression for us using IBM JDK.
> Non-ascii chars in name element are displayed as question marks in Win CLI
> output (regression)
> --
>
> Key: MNG-6205
> URL: https://issues.apache.org/jira/browse/MNG-6205
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.5.0
> Environment: Windows 7, IBM JDK 7.1, Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426)
>Reporter: Anders Hammar
>Assignee: Hervé Boutemy
> Fix For: 3.5.1
>
> Attachments: jansi-1.16-SNAPSHOT.jar, pom.xml
>
>
> If non-ascii characters (such as Swedish chars å, ä, ö) are used in the pom
> name element, they are displayed as question mark ('?') in the CLI output
> when building on Windows. This can been seen e.g. in the Reactor Summary in
> the end.
> See attached pom for an example.
> This was not an issue in Maven 3.3.9.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6218) Jansi 1.13 does not recognize MinGW bash
[ https://issues.apache.org/jira/browse/MNG-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005954#comment-16005954 ] Hervé Boutemy commented on MNG-6218: [~DannyNullZwo], I just proposed a pull request to make jansi.jar executable to easily test it in any conditions, without requiring integration in Maven or any other end-user tool: see https://github.com/fusesource/jansi/pull/88 For now, you'll need to import the PR and build the lib for yourself to test it in any conditions and report the results > Jansi 1.13 does not recognize MinGW bash > > > Key: MNG-6218 > URL: https://issues.apache.org/jira/browse/MNG-6218 > Project: Maven > Issue Type: Bug > Components: Command Line >Affects Versions: 3.5.0 > Environment: Windows Git Bash(MinGW) >Reporter: Daniel Heinrich >Priority: Minor > Original Estimate: 24h > Remaining Estimate: 24h > > Jansi checks if the platform is Windows to decide if coloring needs to be > handled differently. In the case that MinGW is detected it will handle > coloring as if it was running on Unix. > The test in Jansi 1.13 is if the enviroment variable TERM == "xterm", but > MinGW returns "xterm-256color". > Since Jansi 1.14 it checks if TERM starts with "xterm". > see: > https://github.com/fusesource/jansi/blob/jansi-project-1.14/jansi/src/main/java/org/fusesource/jansi/AnsiConsole.java#L123 > An upgrade to Jansi 1.14 or even 1.15 fixes this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARCHETYPE-397) Required property default value is not displayed correctly if a Velocity expression
[
https://issues.apache.org/jira/browse/ARCHETYPE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005599#comment-16005599
]
Mirko Raner commented on ARCHETYPE-397:
---
Not sure if this warrants re-opening this ticket, or filing a new one, but here
goes...
In my mind there are still a few things amiss in this area, for example, using
archetype plug-in version 3.0.1:
# the {{package}} property can be used in a Velocity expression to define a
{{}} but the default value is still displayed incorrectly during
interactive archetype instantiation (i.e., it shows the Velocity expression
instead of the resulting expanded value) -- it does however get properly
substituted during artifact generation
# the {{groupId}}, {{artifactId}} and {{version}} properties can be used in the
same way, and their effective default values are displayed correctly; however,
they resolve to the respective values for the archetype itself and are of
limited use
# the {{rootArtifactId}} does not seem to be available at all; during archetype
instantiation Maven displays the unexpanded expression, and the same expression
is also literally substituted in the generated artifacts
# similarly, {{archetypeGroupId}}, {{archetypeArtifactId}} are also not
available at all
With regards to ARCHETYPE-397, only item #1 seems directly related to this
ticket and might warrant re-opening it. Item #2, I believe, is the same problem
as described in ARCHETYPE-490. Items #3 and #4 seem to be covered by a comment
on ARCHETYPE-383:
https://issues.apache.org/jira/browse/ARCHETYPE-383?focusedCommentId=14423463&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14423463
Any opinions on which tickets should be re-opened or whether a new ticket
should be filed?
> Required property default value is not displayed correctly if a Velocity
> expression
> ---
>
> Key: ARCHETYPE-397
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-397
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 2.2
>Reporter: Nicolas Dupont
>Assignee: Olivier Lamy (*$^¨%`£)
> Fix For: 2.3
>
> Attachments: fix_archetype_397.patch
>
>
> If you use a Velocity expression to define a default value in your archetype
> descriptor, it is not displayed correctly when you generate a project.
> Let's say we have, in our descriptor :
> ${groupId}.${artifactId}
> When you generate a project from the archetype, you type com.company as a
> groupId and my-project as an artifactId. Then you'll be prompted for the
> package and default value will be displayed as "com.company.my-project".
> Now, if we have in our descriptor :
> {{ key="package">${groupId}.${artifactId.replace('-','')}}}
> When you generate a project in the same way, the default value for package
> will be displayed as ${groupId}.${artifactId.replace('-','')} instead of
> com.company.myproject.
> Note that if you leave the value as it is, the generation will do resolve the
> expression (package property will be resolve correctly). It's just confusing
> when the default value is showed at the prompt step.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005561#comment-16005561
]
M.P. Korstanje commented on SUREFIRE-1372:
--
Found a solution. Just gotta write the tests.
https://github.com/mpkorstanje/maven-surefire/commit/1ad7af080eb732adabfcec702f1b8f3743736316
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
M.P. Korstanje updated SUREFIRE-1372:
-
Description:
When using surefire to rerun failing tests created by a Runner that uses
{noformat}Description#createSuiteDescription{noformat} with a human readable
name rather then a class name the following stack trace occurs:
{code}
org.apache.maven.surefire.testset.TestSetFailedException: Unable to create test
class 'Scenario: Fail when running'
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
{code}
was:
Using surefire to rerun failing tests created by a Runner that uses
{noformat}Description#createSuiteDescription{noformat} with a human readable
name rather then a class name the following stack trace occurs:
{code}
org.apache.maven.surefire.testset.TestSetFailedException: Unable to create test
class 'Scenario: Fail when running'
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
{code}
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005492#comment-16005492
]
M.P. Korstanje edited comment on SUREFIRE-1372 at 5/10/17 9:38 PM:
---
It appears that JUnit4Provider#executeWithRerun uses a combination of class and
method names to rerun the tests. It could make use of the Filterable interface
of the Runner and use the Filter#matchMethodDescription to create a filter from
the descriptions of the failing tests to avoid the problems above.
was (Author: mpkorstanje):
It appears that JUnit4Provider#executeWithRerun uses a combination of class and
method names to rerun the tests. It could however make use of the Filterable
interface of the Runner and use the Filter#matchMethodDescription to create a
filter from the descriptions of the failing tests.
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>
> Using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005492#comment-16005492
]
M.P. Korstanje commented on SUREFIRE-1372:
--
It appears that JUnit4Provider#executeWithRerun uses a combination of class and
method names to rerun the tests. It could however make use of the Filterable
interface of the Runner and use the Filter#matchMethodDescription to create a
filter from the descriptions of the failing tests.
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>
> Using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
M.P. Korstanje updated SUREFIRE-1372:
-
Summary: Rerunning failing tests fails in combination with
Description#createSuiteDescription (was: Rerunning failing tests fails when
@RunWith is used)
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>
> Using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SUREFIRE-1372) Rerunning failing tests fails when @RunWith is used
M.P. Korstanje created SUREFIRE-1372:
Summary: Rerunning failing tests fails when @RunWith is used
Key: SUREFIRE-1372
URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.20
Reporter: M.P. Korstanje
Using surefire to rerun failing tests created by a Runner that uses
{noformat}Description#createSuiteDescription{noformat} with a human readable
name rather then a class name the following stack trace occurs:
{code}
org.apache.maven.surefire.testset.TestSetFailedException: Unable to create test
class 'Scenario: Fail when running'
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml
[
https://issues.apache.org/jira/browse/MDEPLOY-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005235#comment-16005235
]
Karl Heinz Marbaise commented on MDEPLOY-221:
-
So the only ones which I can identify which are not in the maven output:
{code:xml}
jar
31.0.0-20170510.070328-76
20170510070328
pom
31.0.0-20170510.070328-76
20170510070328
{code}
Some questions:
* Is this the whole output for uploading artifacts?
* Have you checked your build output if you have duplicated
maven-install-plugin calls?
** I saw an artifact obfuscated ? How does the log output look like there?
* Are you using parallelization? (mvn -T ...)
* Which version of Nexus do you use?
> deploy generates wrong timestamps in maven-metadata.xml
> ---
>
> Key: MDEPLOY-221
> URL: https://issues.apache.org/jira/browse/MDEPLOY-221
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2
>Reporter: Roland Illig
>
> When deploying an artifact to a Nexus server, the file {{maven-metadata.xml}}
> can end up with inconsistent timestamps.
> {noformat}
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 24 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 171 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> (18 kB at 591 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> (2.2 kB at 71 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 59 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 43 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 33 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 40 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> (12 kB at 386 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 59 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots
[jira] [Assigned] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-5227:
---
Assignee: Michael Osipov
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0-candidate
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-5) Update minimum Java version to 1.7
[ https://issues.apache.org/jira/browse/MRESOLVER-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MRESOLVER-5: > Update minimum Java version to 1.7 > -- > > Key: MRESOLVER-5 > URL: https://issues.apache.org/jira/browse/MRESOLVER-5 > Project: Maven Resolver > Issue Type: Task >Affects Versions: Maven Artifact Resolver 1.2.0 pre-reset >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: Maven Artifact Resolver 1.2.0 pre-reset > > > Maven Resolver is highly coupled in Maven 3. Since Maven now requires 1.7, > Resolver as a key component should require it too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-4) Use java.util.Objects#requireNonNull to intercept null input
[
https://issues.apache.org/jira/browse/MRESOLVER-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened MRESOLVER-4:
> Use java.util.Objects#requireNonNull to intercept null input
>
>
> Key: MRESOLVER-4
> URL: https://issues.apache.org/jira/browse/MRESOLVER-4
> Project: Maven Resolver
> Issue Type: Improvement
>Affects Versions: Maven Artifact Resolver 1.2.0 pre-reset
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.2.0 pre-reset
>
>
> In several spots of Maven Resolver IAE is thrown where an argument is null.
> This should be turned into NullPointerException since JDK adheres to is and
> the description of this exception indicates that and Effective Java does that
> too.
> Most likely to be misused:
> {noformat}
> $ grep -r "throw new IllegalArgumentException" .
> ./maven-resolver-api/src/main/java/org/eclipse/aether/artifact/DefaultArtifact.java:
> throw new IllegalArgumentException( "Bad artifact coordinates " +
> coords
> ./maven-resolver-api/src/main/java/org/eclipse/aether/artifact/DefaultArtifactType.java:
> throw new IllegalArgumentException( "no type id specified" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/artifact/DefaultArtifactType.java:
> throw new IllegalArgumentException( "no type id specified" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/collection/CollectResult.java:
> throw new IllegalArgumentException( "dependency collection
> request has not been specified" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/DefaultRepositorySystemSession.java:
> throw new IllegalArgumentException( "repository system session
> not specified" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/DefaultSessionData.java:
> throw new IllegalArgumentException( "key must not be null" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/DefaultSessionData.java:
> throw new IllegalArgumentException( "key must not be null" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/DefaultSessionData.java:
> throw new IllegalArgumentException( "key must not be null" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/deployment/DeployResult.java:
> throw new IllegalArgumentException( "deploy request has not been
> specified" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java:
> throw new IllegalArgumentException( "key must not be null" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/graph/Dependency.java:
> throw new IllegalArgumentException( "no artifact specified for
> dependency" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/installation/InstallResult.java:
> throw new IllegalArgumentException( "install request has not been
> specified" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/metadata/DefaultMetadata.java:
> throw new IllegalArgumentException( "metadata nature was not
> specified" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/repository/AuthenticationContext.java:
> throw new IllegalArgumentException( "repository system session
> missing" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/repository/AuthenticationContext.java:
> throw new IllegalArgumentException( "authentication data key
> missing" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/repository/AuthenticationContext.java:
> throw new IllegalArgumentException( "authentication data key
> missing" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/repository/LocalArtifactResult.java:
> throw new IllegalArgumentException( "local artifact request has
> not been specified" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/repository/LocalMetadataResult.java:
> throw new IllegalArgumentException( "local metadata request has
> not been specified" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/repository/RemoteRepository.java:
> throw new IllegalArgumentException( "repository prototype
> missing" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/RepositoryEvent.java:
> throw new IllegalArgumentException( "session not specified" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/RepositoryEvent.java:
> throw new IllegalArgumentException( "event type not specified" );
> ./maven-resolver-api/src/main/java/org/eclipse/aether/resolution/ArtifactDescriptorResult.java:
> throw new IllegalArgumentException( "artifact descriptor request
> has not been specifie
[jira] [Reopened] (MRESOLVER-3) Update dependencies
[ https://issues.apache.org/jira/browse/MRESOLVER-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MRESOLVER-3: > Update dependencies > --- > > Key: MRESOLVER-3 > URL: https://issues.apache.org/jira/browse/MRESOLVER-3 > Project: Maven Resolver > Issue Type: Task > Components: resolver >Affects Versions: Maven Artifact Resolver 1.2.0 pre-reset >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: Maven Artifact Resolver 1.2.0 pre-reset > > > All dependencies should be in line with Maven master in terms of versions. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MRESOLVER-6) Use java.nio.charset.StandardCharsets wherever possible
[
https://issues.apache.org/jira/browse/MRESOLVER-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened MRESOLVER-6:
> Use java.nio.charset.StandardCharsets wherever possible
> ---
>
> Key: MRESOLVER-6
> URL: https://issues.apache.org/jira/browse/MRESOLVER-6
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: Aether 1.0.2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: Maven Artifact Resolver 1.2.0 pre-reset
>
>
> In many spots an {{UnsupportedEncodingException}} has to be caught because
> {{UTF-8}} is passed as string, though this encoding must be supported by
> every JVM implementation. So we can use {{StandardCharsets.UTF_8}} and remove
> boilerplate code around it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MDEPLOY-222) Issue Tracking in pom.xml points to outdated Codehaus site
Roland Illig created MDEPLOY-222: Summary: Issue Tracking in pom.xml points to outdated Codehaus site Key: MDEPLOY-222 URL: https://issues.apache.org/jira/browse/MDEPLOY-222 Project: Maven Deploy Plugin Issue Type: Bug Affects Versions: 2.8.2 Reporter: Roland Illig https://maven.apache.org/plugins/maven-deploy-plugin/issue-tracking.html points to http://jira.codehaus.org/browse/MDEPLOY. This should be updated to https://issues.apache.org/jira/browse/MDEPLOY. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml
Roland Illig created MDEPLOY-221:
Summary: deploy generates wrong timestamps in maven-metadata.xml
Key: MDEPLOY-221
URL: https://issues.apache.org/jira/browse/MDEPLOY-221
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 2.8.2
Reporter: Roland Illig
When deploying an artifact to a Nexus server, the file {{maven-metadata.xml}}
can end up with inconsistent timestamps.
{noformat}
[INFO] Downloading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
[INFO] Downloaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
(1.9 kB at 24 kB/s)
[INFO] Downloading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
[INFO] Downloaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
(1.9 kB at 171 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
(18 kB at 591 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
(2.2 kB at 71 kB/s)
[INFO] Downloading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
[INFO] Downloaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
(1.2 kB at 92 kB/s)
[INFO] Downloading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
[INFO] Downloaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
(1.2 kB at 92 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
(1.9 kB at 59 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
(1.9 kB at 43 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
(1.2 kB at 33 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
(1.2 kB at 40 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
(12 kB at 386 kB/s)
[INFO] Downloading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
[INFO] Downloaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
(1.2 kB at 92 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
(1.9 kB at 59 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
(1.9 kB at 65 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
(1.2 kB at 37 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-test-sources.jar
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-test-sources.jar
(10 kB at 286 kB/s)
[INFO] Downloading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
[INFO] Downloaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-met
[jira] [Comment Edited] (MSHARED-437) maven-dependency-tree removes optional flag from managed dependencies
[ https://issues.apache.org/jira/browse/MSHARED-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15995166#comment-15995166 ] Michael Osipov edited comment on MSHARED-437 at 5/10/17 9:17 AM: - Issue fixed partially, remaining bits are in MNG-5935 and MNG-6228. was (Author: michael-o): Issue fixed partially, remaining bits are in MNG-5935. > maven-dependency-tree removes optional flag from managed dependencies > - > > Key: MSHARED-437 > URL: https://issues.apache.org/jira/browse/MSHARED-437 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-2.2 >Reporter: Arlo Louis O'Keeffe >Assignee: Michael Osipov >Priority: Minor > Fix For: maven-dependency-tree-3.0.1 > > > Given the following > [pom|https://github.com/evosec/export-dependencies-maven-plugin/blob/21d80e29bd2e3507e97556e65f2f962fb7b0/src/it/buck-bom-managed-optional-transitive-dependencies/pom.xml] > the dependency tree looks like this > - com.mysema.querydsl:querydsl-core:jar:3.4.3:compile > -- com.google.guava:guava:jar:17.0:compile > -- com.google.code.findbugs:jsr305:jar:2.0.3:compile > -- com.mysema.commons:mysema-commons-lang:jar:0.2.4:compile > -- com.infradna.tool:bridge-method-annotation:jar:1.13:compile > You expect the entire tree to have the optional flag set to true. But sadly > that's not the case. com.google.guava:guava and > com.google.code.findbugs:jsr305 are optional = false. > I found that this is because they are managed dependencies (no difference > whether imported or declared directly). When I use this > [pom|https://github.com/evosec/export-dependencies-maven-plugin/blob/a931ee09c0880097b73e2010d71b000ede3acbfe/src/it/buck-optional-transitive-dependencies/pom.xml] > it works. > There are some integration tests in this > [repository|https://github.com/evosec/export-dependencies-maven-plugin] that > demonstrate the issue. Checkout demonstrate-tree-bug branch and run "mvn > verify". Now compare these files in target/it > - buck-bom-managed-optional-transitive-dependencies/target/BUCK > - buck-managed-optional-transitive-dependencies/target/BUCK > - buck-optional-transitive-dependencies/target/BUCK > [The CI builds demonstrating the > failure|https://travis-ci.org/evosec/export-dependencies-maven-plugin/builds/81137480]. > Let me know if I can help you reproduce the problem. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MSHARED-437) maven-dependency-tree removes optional flag from managed dependencies
[ https://issues.apache.org/jira/browse/MSHARED-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16004354#comment-16004354 ] Michael Osipov commented on MSHARED-437: [~arlol], your issue has been fully resolved on Maven master. > maven-dependency-tree removes optional flag from managed dependencies > - > > Key: MSHARED-437 > URL: https://issues.apache.org/jira/browse/MSHARED-437 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-2.2 >Reporter: Arlo Louis O'Keeffe >Assignee: Michael Osipov >Priority: Minor > Fix For: maven-dependency-tree-3.0.1 > > > Given the following > [pom|https://github.com/evosec/export-dependencies-maven-plugin/blob/21d80e29bd2e3507e97556e65f2f962fb7b0/src/it/buck-bom-managed-optional-transitive-dependencies/pom.xml] > the dependency tree looks like this > - com.mysema.querydsl:querydsl-core:jar:3.4.3:compile > -- com.google.guava:guava:jar:17.0:compile > -- com.google.code.findbugs:jsr305:jar:2.0.3:compile > -- com.mysema.commons:mysema-commons-lang:jar:0.2.4:compile > -- com.infradna.tool:bridge-method-annotation:jar:1.13:compile > You expect the entire tree to have the optional flag set to true. But sadly > that's not the case. com.google.guava:guava and > com.google.code.findbugs:jsr305 are optional = false. > I found that this is because they are managed dependencies (no difference > whether imported or declared directly). When I use this > [pom|https://github.com/evosec/export-dependencies-maven-plugin/blob/a931ee09c0880097b73e2010d71b000ede3acbfe/src/it/buck-optional-transitive-dependencies/pom.xml] > it works. > There are some integration tests in this > [repository|https://github.com/evosec/export-dependencies-maven-plugin] that > demonstrate the issue. Checkout demonstrate-tree-bug branch and run "mvn > verify". Now compare these files in target/it > - buck-bom-managed-optional-transitive-dependencies/target/BUCK > - buck-managed-optional-transitive-dependencies/target/BUCK > - buck-optional-transitive-dependencies/target/BUCK > [The CI builds demonstrating the > failure|https://travis-ci.org/evosec/export-dependencies-maven-plugin/builds/81137480]. > Let me know if I can help you reproduce the problem. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6156) Resolving dependencies is not thread-safe
[
https://issues.apache.org/jira/browse/MNG-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16004348#comment-16004348
]
Roland Illig commented on MNG-6156:
---
Hello [~michael-o], did you find time to look into this issue?
> Resolving dependencies is not thread-safe
> -
>
> Key: MNG-6156
> URL: https://issues.apache.org/jira/browse/MNG-6156
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16004326#comment-16004326 ] Hudson commented on MNG-5935: - SUCCESS: Integrated in Jenkins build maven-3.x #1650 (See [https://builds.apache.org/job/maven-3.x/1650/]) [MNG-5935] Optional true getting lost in managed dependencies when (michaelo: [http://git-wip-us.apache.org/repos/asf/?p=maven.git&a=commit&h=f4ede96fd06c8d3e1e2b2fb679baec058cce30e1]) * (edit) maven-core/src/main/java/org/apache/maven/RepositoryUtils.java * (edit) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegate.java > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte >Assignee: Michael Osipov > Fix For: 3.5.1 > > Attachments: buildoutput.txt, Parent.zip > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-5935. --- Resolution: Fixed Fixed with [f4ede96fd06c8d3e1e2b2fb679baec058cce30e1|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=f4ede96fd06c8d3e1e2b2fb679baec058cce30e1] and IT with [4aeb411456ba9b0c5a3baadb552736ffbc57da51|https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=4aeb411456ba9b0c5a3baadb552736ffbc57da51]. > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte >Assignee: Michael Osipov > Fix For: 3.5.1 > > Attachments: buildoutput.txt, Parent.zip > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5935: Fix Version/s: (was: 3.6.0-candidate) (was: 3.5.1-candidate) 3.5.1 > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte >Assignee: Michael Osipov > Fix For: 3.5.1 > > Attachments: buildoutput.txt, Parent.zip > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6228) Optionality not displayed in dependency tree when run in debug mode
[
https://issues.apache.org/jira/browse/MNG-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16004214#comment-16004214
]
Hudson commented on MNG-6228:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1649 (See
[https://builds.apache.org/job/maven-3.x/1649/])
[MNG-6228] Optionality not displayed in dependency tree when run in (michaelo:
[http://git-wip-us.apache.org/repos/asf/?p=maven.git&a=commit&h=fd988e78e95a53c3a39ec944869ba62b0c7fc0f0])
* (edit)
maven-core/src/main/java/org/apache/maven/project/DefaultProjectDependenciesResolver.java
> Optionality not displayed in dependency tree when run in debug mode
> ---
>
> Key: MNG-6228
> URL: https://issues.apache.org/jira/browse/MNG-6228
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies, Logging
>Affects Versions: 3.5.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.1
>
>
> Consider you have optional dependencies in your POM and run Maven with
> {{-X}}, you'll see:
> {noformat}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0,
> ConflictMarker.markTime=1, ConflictMarker.nodeCount=6,
> ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=1,
> ConflictIdSorter.conflictIdCount=5, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=2, ConflictResolver.conflictItemCount=5,
> DefaultDependencyCollector.collectTime=26,
> DefaultDependencyCollector.transformTime=6}
> [DEBUG] org.apache.maven.its.mng5935:test:jar:0.1
> [DEBUG]com.mysema.querydsl:querydsl-core:jar:3.4.3:compile
> [DEBUG] com.google.guava:guava:jar:17.0:compile (version managed from
> 14.0)
> [DEBUG] com.google.code.findbugs:jsr305:jar:2.0.3:compile (version
> managed from 1.3.9)
> [DEBUG] com.mysema.commons:mysema-commons-lang:jar:0.2.4:compile
> [DEBUG] com.infradna.tool:bridge-method-annotation:jar:1.13:compile
> {noformat}
> The optional flag is never displayed. This leads to two issues:
> 1. It causes confusion with the user
> 2. The user thinks that the option flag does not work
> This required information shall be printed as same as MDEP does:
> {{...(optional)}}
> The expected result would be:
> {noformat}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0,
> ConflictMarker.markTime=1, ConflictMarker.nodeCount=6,
> ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=1,
> ConflictIdSorter.conflictIdCount=5, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=2, ConflictResolver.conflictItemCount=5,
> DefaultDependencyCollector.collectTime=26,
> DefaultDependencyCollector.transformTime=6}
> [DEBUG] org.apache.maven.its.mng5935:test:jar:0.1
> [DEBUG]com.mysema.querydsl:querydsl-core:jar:3.4.3:compile (optional)
> [DEBUG] com.google.guava:guava:jar:17.0:compile (version managed from
> 14.0) (optional)
> [DEBUG] com.google.code.findbugs:jsr305:jar:2.0.3:compile (version
> managed from 1.3.9) (optional)
> [DEBUG] com.mysema.commons:mysema-commons-lang:jar:0.2.4:compile
> (optional)
> [DEBUG] com.infradna.tool:bridge-method-annotation:jar:1.13:compile
> (optional)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6228) Optionality not displayed in dependency tree when run in debug mode
[
https://issues.apache.org/jira/browse/MNG-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6228.
---
Resolution: Fixed
Fixed with
[fd988e78e95a53c3a39ec944869ba62b0c7fc0f0|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=fd988e78e95a53c3a39ec944869ba62b0c7fc0f0].
> Optionality not displayed in dependency tree when run in debug mode
> ---
>
> Key: MNG-6228
> URL: https://issues.apache.org/jira/browse/MNG-6228
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies, Logging
>Affects Versions: 3.5.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.1
>
>
> Consider you have optional dependencies in your POM and run Maven with
> {{-X}}, you'll see:
> {noformat}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0,
> ConflictMarker.markTime=1, ConflictMarker.nodeCount=6,
> ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=1,
> ConflictIdSorter.conflictIdCount=5, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=2, ConflictResolver.conflictItemCount=5,
> DefaultDependencyCollector.collectTime=26,
> DefaultDependencyCollector.transformTime=6}
> [DEBUG] org.apache.maven.its.mng5935:test:jar:0.1
> [DEBUG]com.mysema.querydsl:querydsl-core:jar:3.4.3:compile
> [DEBUG] com.google.guava:guava:jar:17.0:compile (version managed from
> 14.0)
> [DEBUG] com.google.code.findbugs:jsr305:jar:2.0.3:compile (version
> managed from 1.3.9)
> [DEBUG] com.mysema.commons:mysema-commons-lang:jar:0.2.4:compile
> [DEBUG] com.infradna.tool:bridge-method-annotation:jar:1.13:compile
> {noformat}
> The optional flag is never displayed. This leads to two issues:
> 1. It causes confusion with the user
> 2. The user thinks that the option flag does not work
> This required information shall be printed as same as MDEP does:
> {{...(optional)}}
> The expected result would be:
> {noformat}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0,
> ConflictMarker.markTime=1, ConflictMarker.nodeCount=6,
> ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=1,
> ConflictIdSorter.conflictIdCount=5, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=2, ConflictResolver.conflictItemCount=5,
> DefaultDependencyCollector.collectTime=26,
> DefaultDependencyCollector.transformTime=6}
> [DEBUG] org.apache.maven.its.mng5935:test:jar:0.1
> [DEBUG]com.mysema.querydsl:querydsl-core:jar:3.4.3:compile (optional)
> [DEBUG] com.google.guava:guava:jar:17.0:compile (version managed from
> 14.0) (optional)
> [DEBUG] com.google.code.findbugs:jsr305:jar:2.0.3:compile (version
> managed from 1.3.9) (optional)
> [DEBUG] com.mysema.commons:mysema-commons-lang:jar:0.2.4:compile
> (optional)
> [DEBUG] com.infradna.tool:bridge-method-annotation:jar:1.13:compile
> (optional)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6228) Optionality not displayed in dependency tree when run in debug mode
[
https://issues.apache.org/jira/browse/MNG-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6228:
Fix Version/s: (was: 3.5.1-candidate)
3.5.1
> Optionality not displayed in dependency tree when run in debug mode
> ---
>
> Key: MNG-6228
> URL: https://issues.apache.org/jira/browse/MNG-6228
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies, Logging
>Affects Versions: 3.5.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.1
>
>
> Consider you have optional dependencies in your POM and run Maven with
> {{-X}}, you'll see:
> {noformat}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0,
> ConflictMarker.markTime=1, ConflictMarker.nodeCount=6,
> ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=1,
> ConflictIdSorter.conflictIdCount=5, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=2, ConflictResolver.conflictItemCount=5,
> DefaultDependencyCollector.collectTime=26,
> DefaultDependencyCollector.transformTime=6}
> [DEBUG] org.apache.maven.its.mng5935:test:jar:0.1
> [DEBUG]com.mysema.querydsl:querydsl-core:jar:3.4.3:compile
> [DEBUG] com.google.guava:guava:jar:17.0:compile (version managed from
> 14.0)
> [DEBUG] com.google.code.findbugs:jsr305:jar:2.0.3:compile (version
> managed from 1.3.9)
> [DEBUG] com.mysema.commons:mysema-commons-lang:jar:0.2.4:compile
> [DEBUG] com.infradna.tool:bridge-method-annotation:jar:1.13:compile
> {noformat}
> The optional flag is never displayed. This leads to two issues:
> 1. It causes confusion with the user
> 2. The user thinks that the option flag does not work
> This required information shall be printed as same as MDEP does:
> {{...(optional)}}
> The expected result would be:
> {noformat}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0,
> ConflictMarker.markTime=1, ConflictMarker.nodeCount=6,
> ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=1,
> ConflictIdSorter.conflictIdCount=5, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=2, ConflictResolver.conflictItemCount=5,
> DefaultDependencyCollector.collectTime=26,
> DefaultDependencyCollector.transformTime=6}
> [DEBUG] org.apache.maven.its.mng5935:test:jar:0.1
> [DEBUG]com.mysema.querydsl:querydsl-core:jar:3.4.3:compile (optional)
> [DEBUG] com.google.guava:guava:jar:17.0:compile (version managed from
> 14.0) (optional)
> [DEBUG] com.google.code.findbugs:jsr305:jar:2.0.3:compile (version
> managed from 1.3.9) (optional)
> [DEBUG] com.mysema.commons:mysema-commons-lang:jar:0.2.4:compile
> (optional)
> [DEBUG] com.infradna.tool:bridge-method-annotation:jar:1.13:compile
> (optional)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
