[jira] [Comment Edited] (MNG-5907) org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails starting at midnight
[ https://issues.apache.org/jira/browse/MNG-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951848#comment-14951848 ] Michael Osipov edited comment on MNG-5907 at 10/10/15 2:06 PM: --- Fixed with [316298e529c08936562d707ef136dc2756f0f084|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=316298e529c08936562d707ef136dc2756f0f084] and . was (Author: michael-o): Fixed with [316298e529c08936562d707ef136dc2756f0f084|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=316298e529c08936562d707ef136dc2756f0f084]. > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails > starting at midnight > -- > > Key: MNG-5907 > URL: https://issues.apache.org/jira/browse/MNG-5907 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Karl Heinz Marbaise >Assignee: Michael Osipov > Fix For: 3.3.7 > > > Currently this test fails (it seemed to be the reason having started the > build at midnight CET): > Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< > FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest) > Time elapsed: 0.011 sec <<< FAILURE! > java.lang.AssertionError: Expected 20151007 to be in [20151008] > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79) > Running org.apache.maven.repository.internal.RepositorySystemTest > Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec - > in org.apache.maven.repository.internal.RepositorySystemTest > I have run maven build several times over the day and had no problems..I have > to take a deeper look into this... > I have run the build at about 11:00 o'clock am (CET) and the build is > successfulwith the exact same code state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5907) org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails starting at midnight
[ https://issues.apache.org/jira/browse/MNG-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951862#comment-14951862 ] Hudson commented on MNG-5907: - SUCCESS: Integrated in maven-3.x #1132 (See [https://builds.apache.org/job/maven-3.x/1132/]) [MNG-5907] (michaelo: rev 2ec27257b4936762a92c2ac860ea5d633c633e77) * maven-model-builder/src/main/java/org/apache/maven/model/interpolation/MavenBuildTimestamp.java > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails > starting at midnight > -- > > Key: MNG-5907 > URL: https://issues.apache.org/jira/browse/MNG-5907 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Karl Heinz Marbaise >Assignee: Michael Osipov > Fix For: 3.3.7 > > > Currently this test fails (it seemed to be the reason having started the > build at midnight CET): > Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< > FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest) > Time elapsed: 0.011 sec <<< FAILURE! > java.lang.AssertionError: Expected 20151007 to be in [20151008] > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79) > Running org.apache.maven.repository.internal.RepositorySystemTest > Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec - > in org.apache.maven.repository.internal.RepositorySystemTest > I have run maven build several times over the day and had no problems..I have > to take a deeper look into this... > I have run the build at about 11:00 o'clock am (CET) and the build is > successfulwith the exact same code state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MNG-5907) org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails starting at midnight
[ https://issues.apache.org/jira/browse/MNG-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951848#comment-14951848 ] Michael Osipov edited comment on MNG-5907 at 10/10/15 2:36 PM: --- Fixed with [316298e529c08936562d707ef136dc2756f0f084|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=316298e529c08936562d707ef136dc2756f0f084] and [2ec27257b4936762a92c2ac860ea5d633c633e77|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=2ec27257b4936762a92c2ac860ea5d633c633e77]. was (Author: michael-o): Fixed with [316298e529c08936562d707ef136dc2756f0f084|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=316298e529c08936562d707ef136dc2756f0f084] and . > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails > starting at midnight > -- > > Key: MNG-5907 > URL: https://issues.apache.org/jira/browse/MNG-5907 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Karl Heinz Marbaise >Assignee: Michael Osipov > Fix For: 3.3.7 > > > Currently this test fails (it seemed to be the reason having started the > build at midnight CET): > Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< > FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest) > Time elapsed: 0.011 sec <<< FAILURE! > java.lang.AssertionError: Expected 20151007 to be in [20151008] > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79) > Running org.apache.maven.repository.internal.RepositorySystemTest > Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec - > in org.apache.maven.repository.internal.RepositorySystemTest > I have run maven build several times over the day and had no problems..I have > to take a deeper look into this... > I have run the build at about 11:00 o'clock am (CET) and the build is > successfulwith the exact same code state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5907) org.apache.maven.repository.internal.RemoteSnapshotMetadataTest fails to start at midnight
[ https://issues.apache.org/jira/browse/MNG-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5907: Summary: org.apache.maven.repository.internal.RemoteSnapshotMetadataTest fails to start at midnight (was: org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails starting at midnight) > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest fails to > start at midnight > -- > > Key: MNG-5907 > URL: https://issues.apache.org/jira/browse/MNG-5907 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Karl Heinz Marbaise >Assignee: Michael Osipov > Fix For: 3.3.7 > > > Currently this test fails (it seemed to be the reason having started the > build at midnight CET): > Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< > FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest) > Time elapsed: 0.011 sec <<< FAILURE! > java.lang.AssertionError: Expected 20151007 to be in [20151008] > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79) > Running org.apache.maven.repository.internal.RepositorySystemTest > Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec - > in org.apache.maven.repository.internal.RepositorySystemTest > I have run maven build several times over the day and had no problems..I have > to take a deeper look into this... > I have run the build at about 11:00 o'clock am (CET) and the build is > successfulwith the exact same code state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MNG-5907) org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails starting at midnight
[ https://issues.apache.org/jira/browse/MNG-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov resolved MNG-5907. - Resolution: Fixed Fixed with [316298e529c08936562d707ef136dc2756f0f084|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=316298e529c08936562d707ef136dc2756f0f084]. > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails > starting at midnight > -- > > Key: MNG-5907 > URL: https://issues.apache.org/jira/browse/MNG-5907 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Karl Heinz Marbaise >Assignee: Michael Osipov > Fix For: 3.3.7 > > > Currently this test fails (it seemed to be the reason having started the > build at midnight CET): > Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< > FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest) > Time elapsed: 0.011 sec <<< FAILURE! > java.lang.AssertionError: Expected 20151007 to be in [20151008] > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79) > Running org.apache.maven.repository.internal.RepositorySystemTest > Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec - > in org.apache.maven.repository.internal.RepositorySystemTest > I have run maven build several times over the day and had no problems..I have > to take a deeper look into this... > I have run the build at about 11:00 o'clock am (CET) and the build is > successfulwith the exact same code state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSHARED-442) Remove shading of artifact instead of using simple jar
[ https://issues.apache.org/jira/browse/MSHARED-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951851#comment-14951851 ] Karl Heinz Marbaise commented on MSHARED-442: - The question is why do we shade dependencies instead of using simple the dependency mechanism? Apart from that using shaded classes could produce class loading issues. So best would be to change the optional into a usual dependency which might be a better solution..? > Remove shading of artifact instead of using simple jar > -- > > Key: MSHARED-442 > URL: https://issues.apache.org/jira/browse/MSHARED-442 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Affects Versions: maven-shared-utils-0.9 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-shared-utils-3.0.0 > > > Currently the maven-shared-utils are being shaded during the build but why do > we need that? It would be simpler to use create a simple jar file instead. > The old build included commons-io into the shaded jar. commons-io dependency > is defined optional. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5877) maven-aether-provider/maven-compat does not always generate snapshot versions using Gregorian calendar year
[
https://issues.apache.org/jira/browse/MNG-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5877:
Summary: maven-aether-provider/maven-compat does not always generate
snapshot versions using Gregorian calendar year (was: maven-aether-provider
does not always generate snapshot versions using Gregorian calendar year )
> maven-aether-provider/maven-compat does not always generate snapshot versions
> using Gregorian calendar year
>
>
> Key: MNG-5877
> URL: https://issues.apache.org/jira/browse/MNG-5877
> Project: Maven
> Issue Type: Bug
>Reporter: Anders Forsell
>Assignee: Michael Osipov
> Fix For: 3.3.7
>
>
> I am using the maven-aether-provider in my software and have an issue when
> Thailand users are publishing their snapshot versions get the Buddhist
> calendar year (offset of 543 years).
> I have located the problem to be in the RemoteSnapShotMetaData class:
> {code:title=RemoteSnapShotMetaData.java|borderStyle=solid}
> DateFormat utcDateFormatter = new SimpleDateFormat(
> "MMdd.HHmmss" );
> utcDateFormatter.setTimeZone( TimeZone.getTimeZone( "UTC" ) );
> snapshot = new Snapshot();
> snapshot.setBuildNumber( getBuildNumber( recessive ) + 1 );
> snapshot.setTimestamp( utcDateFormatter.format( new Date() ) );
> {code}
> The fix should be to explicitly set the calendar to be Gregorian:
> {code:title=RemoteSnapShotMetaData.java|borderStyle=solid}
> DateFormat utcDateFormatter = new SimpleDateFormat(
> "MMdd.HHmmss" );
> utcDateFormatter.setTimeZone( TimeZone.getTimeZone( "UTC" ) );
> utcDateFormatter.setCalendar(new GregorianCalendar());
> snapshot = new Snapshot();
> snapshot.setBuildNumber( getBuildNumber( recessive ) + 1 );
> snapshot.setTimestamp( utcDateFormatter.format( new Date() ) );
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5698) Declare proxies and mirrors in profiles
[ https://issues.apache.org/jira/browse/MNG-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951987#comment-14951987 ] Michael Osipov commented on MNG-5698: - The best solution here would be rather use the default system proxy settings. When you access a VPN, you should set your system default proxy. Maven should pick this up. Are you expriencing this on Windows? > Declare proxies and mirrors in profiles > --- > > Key: MNG-5698 > URL: https://issues.apache.org/jira/browse/MNG-5698 > Project: Maven > Issue Type: Improvement > Components: Settings > Environment: All >Reporter: Edwin Wiles > > There appear to be 140 issues regarding proxy configuration. None of them > appear to have been adequately dealt with. > There should be a solution, internal to Maven, preferably in the settings.xml > file, that allows the user to either automatically, or at worst with a -P > profile argument, to switch between proxies and mirrors. > It seems the easiest way to achieve this is to allow proxies and mirrors into > profiles, the same as properties and repositories are now. > USE CASE: I am presently dealing with an environment where company A has a > mirror, proxy, and VPN access; company B has a mirror, proxy, and VPN access; > and the user may be working from either company's office, either company's > VPN, or from home without using either company's resources. > Just making proxies and mirrors acceptable in profiles would go a VERY long > way to solving this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5750) Sporadic failures in concurrent build
[
https://issues.apache.org/jira/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951984#comment-14951984
]
Michael Osipov commented on MNG-5750:
-
Has this issue been resolved actually?
> Sporadic failures in concurrent build
> -
>
> Key: MNG-5750
> URL: https://issues.apache.org/jira/browse/MNG-5750
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
> HotSpot JDK 7u25
> windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
>Reporter: Alexander Ashitkin
>Priority: Critical
>
> We have a large project of 300+ modules which regularly fails with different
> kind of errors in different places. The issue is reliably reproduced with
> parallel build and is not happens in single threaded. The optimal concurrency
> level for our project ~10 threads. At this level ~%20 of builds fail. To
> workaround the issue we reduced concurrency to 4 in development builds and
> reverted production build to 1 thread.
> Main point of failures:
> # Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
> to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
> # Compiler - unexpected failure because of incorrect classpath (literally all
> dependencies are not on the classpath), like: {code}
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
> org.joda.time does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
> import only from classes and interfaces
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
> import only from classes and interfaces
> {code}
> # Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
> plusgin seems to be also affected)
> At this point the issue looks like problem with MavenProject#getArtifacts in
> concurrent builds.
> To help with the issue im happy to implement or evaluate any custom assembly
> to trace this down. Unfortunately i cannot submit my project - it is
> proprietary.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5907) org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails starting at midnight
[ https://issues.apache.org/jira/browse/MNG-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951853#comment-14951853 ] Hudson commented on MNG-5907: - SUCCESS: Integrated in maven-3.x #1131 (See [https://builds.apache.org/job/maven-3.x/1131/]) [MNG-5907] (michaelo: rev 316298e529c08936562d707ef136dc2756f0f084) * maven-aether-provider/src/test/java/org/apache/maven/repository/internal/RemoteSnapshotMetadataTest.java * maven-aether-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails > starting at midnight > -- > > Key: MNG-5907 > URL: https://issues.apache.org/jira/browse/MNG-5907 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Karl Heinz Marbaise >Assignee: Michael Osipov > Fix For: 3.3.7 > > > Currently this test fails (it seemed to be the reason having started the > build at midnight CET): > Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< > FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest) > Time elapsed: 0.011 sec <<< FAILURE! > java.lang.AssertionError: Expected 20151007 to be in [20151008] > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79) > Running org.apache.maven.repository.internal.RepositorySystemTest > Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec - > in org.apache.maven.repository.internal.RepositorySystemTest > I have run maven build several times over the day and had no problems..I have > to take a deeper look into this... > I have run the build at about 11:00 o'clock am (CET) and the build is > successfulwith the exact same code state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5721) Possible NullPointerException in org.apache.maven.repository. MetadataResolutionResult
[
https://issues.apache.org/jira/browse/MNG-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5721:
Affects Version/s: 3.3.3
> Possible NullPointerException in org.apache.maven.repository.
> MetadataResolutionResult
>
>
> Key: MNG-5721
> URL: https://issues.apache.org/jira/browse/MNG-5721
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.3.3
>Reporter: Martin Schäf
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.7
>
> Attachments: MetadataResolutionResult.java
>
>
> In line 235 of org.apache.maven.repository.MetadataResolutionResult
> the function initList is used in the wrong way. Should be:
> public MetadataResolutionResult addError( Exception e )
> {
> exceptions = initList( exceptions );
> exceptions.add( e );
> return this;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5721) Possible NullPointerException in org.apache.maven.repository. MetadataResolutionResult
[
https://issues.apache.org/jira/browse/MNG-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952010#comment-14952010
]
Hudson commented on MNG-5721:
-
SUCCESS: Integrated in maven-3.x #1136 (See
[https://builds.apache.org/job/maven-3.x/1136/])
[MNG-5721] Possible NullPointerException in (michaelo: rev
d1dc63844f413ebce65162f1262c52d0bf15e06f)
*
maven-compat/src/main/java/org/apache/maven/repository/MetadataResolutionResult.java
> Possible NullPointerException in org.apache.maven.repository.
> MetadataResolutionResult
>
>
> Key: MNG-5721
> URL: https://issues.apache.org/jira/browse/MNG-5721
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.3.3
>Reporter: Martin Schäf
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.7
>
> Attachments: MetadataResolutionResult.java
>
>
> In line 235 of org.apache.maven.repository.MetadataResolutionResult
> the function initList is used in the wrong way. Should be:
> public MetadataResolutionResult addError( Exception e )
> {
> exceptions = initList( exceptions );
> exceptions.add( e );
> return this;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5693) Change logging of MojoExceptions to console
[
https://issues.apache.org/jira/browse/MNG-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952009#comment-14952009
]
Michael Osipov commented on MNG-5693:
-
Robert, I absolutely support that. The reference to the wiki is absolutely
useless. I would like to create a sub task and remove those messages as a first
step. What do you think?
> Change logging of MojoExceptions to console
> ---
>
> Key: MNG-5693
> URL: https://issues.apache.org/jira/browse/MNG-5693
> Project: Maven
> Issue Type: Improvement
> Components: FDPFC, Plugin API
>Reporter: Robert Scholte
>
> If a plugin fails for any reason, a general message is logged with a
> reference to a wiki page, which never contains the real reason why the plugin
> failed.
> For new users this is very confusing. Even when we teach them to read, and
> they finally see a link, it's quite frustrating for them that they still
> don't know what happened.
> {{MojoExecutionException}} and {{MojoFailureException}} should never refer to
> a wikipage anymore.
> Plugin writers should get more control over the message written to the
> console.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5428) Update documentation to make it clear released artifacts are *never* updated in the local cache
[ https://issues.apache.org/jira/browse/MNG-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952029#comment-14952029 ] Michael Osipov commented on MNG-5428: - Please provide a better wording for that option and I will apply it. > Update documentation to make it clear released artifacts are *never* updated > in the local cache > --- > > Key: MNG-5428 > URL: https://issues.apache.org/jira/browse/MNG-5428 > Project: Maven > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 3.0.4 >Reporter: Kent Moore >Priority: Minor > Labels: close-pending > > A literal reading of the "updatePolicy" section of > http://maven.apache.org/ref/3.0.4/maven-settings/settings.html, as well as > Maven help for the "-U" option, makes it seem as though Maven is capable of > updating release artifacts in the local cache. But that is not the case. > I believe the documentation in both areas should be updated to make it clear > released artifacts are *never* re-downloaded to the local Maven cache, even > if the repository manager contains a newer version of the release (which > shouldn't ever happen, but). > See > http://mail-archives.apache.org/mod_mbox/maven-users/201301.mbox/%3CCANdpH_0qHU5grD%3D%3DPRWDJiU7YFsoqw8T0Az0XTJRD7%3DOtwMjtw%40mail.gmail.com%3E. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5428) Update documentation to make it clear released artifacts are *never* updated in the local cache
[ https://issues.apache.org/jira/browse/MNG-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5428: Labels: close-pending (was: ) > Update documentation to make it clear released artifacts are *never* updated > in the local cache > --- > > Key: MNG-5428 > URL: https://issues.apache.org/jira/browse/MNG-5428 > Project: Maven > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 3.0.4 >Reporter: Kent Moore >Priority: Minor > Labels: close-pending > > A literal reading of the "updatePolicy" section of > http://maven.apache.org/ref/3.0.4/maven-settings/settings.html, as well as > Maven help for the "-U" option, makes it seem as though Maven is capable of > updating release artifacts in the local cache. But that is not the case. > I believe the documentation in both areas should be updated to make it clear > released artifacts are *never* re-downloaded to the local Maven cache, even > if the repository manager contains a newer version of the release (which > shouldn't ever happen, but). > See > http://mail-archives.apache.org/mod_mbox/maven-users/201301.mbox/%3CCANdpH_0qHU5grD%3D%3DPRWDJiU7YFsoqw8T0Az0XTJRD7%3DOtwMjtw%40mail.gmail.com%3E. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1182) Surefire 2.19 rc hangs when building maven core
[ https://issues.apache.org/jira/browse/SUREFIRE-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1182: --- Fix Version/s: 2.19 > Surefire 2.19 rc hangs when building maven core > --- > > Key: SUREFIRE-1182 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1182 > Project: Maven Surefire > Issue Type: Bug > Environment: Ubuntu linux >Reporter: Kristian Rosenvold >Assignee: Tibor Digana > Fix For: 2.19 > > > The 2.19 release candidate of 6 oct hangs when building maven core on linux. > Stack dumps; > Forked booter: > 2015-10-08 18:59:45 > Full thread dump OpenJDK 64-Bit Server VM (25.45-b02 mixed mode): > "Attach Listener" #23 daemon prio=9 os_prio=0 tid=0x7f6770001000 > nid=0x3f48 waiting on condition [0x] >java.lang.Thread.State: RUNNABLE > "DestroyJavaVM" #22 prio=5 os_prio=0 tid=0x7f67c000a000 nid=0x3e8d > waiting on condition [0x] >java.lang.Thread.State: RUNNABLE > "pool-1-thread-6" #20 prio=5 os_prio=0 tid=0x7f67c065e800 nid=0x3eab > waiting on condition [0x7f678847f000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "pool-1-thread-5" #19 prio=5 os_prio=0 tid=0x7f67c065d000 nid=0x3eaa > waiting on condition [0x7f678858] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "pool-1-thread-4" #18 prio=5 os_prio=0 tid=0x7f67c065b000 nid=0x3ea9 > waiting on condition [0x7f6788681000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "pool-1-thread-3" #17 prio=5 os_prio=0 tid=0x7f67c0659800 nid=0x3ea8 > waiting on condition [0x7f6788782000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >
[jira] [Assigned] (SUREFIRE-1182) Surefire 2.19 rc hangs when building maven core
[ https://issues.apache.org/jira/browse/SUREFIRE-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1182: -- Assignee: Tibor Digana > Surefire 2.19 rc hangs when building maven core > --- > > Key: SUREFIRE-1182 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1182 > Project: Maven Surefire > Issue Type: Bug > Environment: Ubuntu linux >Reporter: Kristian Rosenvold >Assignee: Tibor Digana > Fix For: 2.19 > > > The 2.19 release candidate of 6 oct hangs when building maven core on linux. > Stack dumps; > Forked booter: > 2015-10-08 18:59:45 > Full thread dump OpenJDK 64-Bit Server VM (25.45-b02 mixed mode): > "Attach Listener" #23 daemon prio=9 os_prio=0 tid=0x7f6770001000 > nid=0x3f48 waiting on condition [0x] >java.lang.Thread.State: RUNNABLE > "DestroyJavaVM" #22 prio=5 os_prio=0 tid=0x7f67c000a000 nid=0x3e8d > waiting on condition [0x] >java.lang.Thread.State: RUNNABLE > "pool-1-thread-6" #20 prio=5 os_prio=0 tid=0x7f67c065e800 nid=0x3eab > waiting on condition [0x7f678847f000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "pool-1-thread-5" #19 prio=5 os_prio=0 tid=0x7f67c065d000 nid=0x3eaa > waiting on condition [0x7f678858] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "pool-1-thread-4" #18 prio=5 os_prio=0 tid=0x7f67c065b000 nid=0x3ea9 > waiting on condition [0x7f6788681000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "pool-1-thread-3" #17 prio=5 os_prio=0 tid=0x7f67c0659800 nid=0x3ea8 > waiting on condition [0x7f6788782000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at >
[jira] [Commented] (MNG-5853) Can not set proxy port to 443
[
https://issues.apache.org/jira/browse/MNG-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951972#comment-14951972
]
Michael Osipov commented on MNG-5853:
-
Please provide output with {{-X}}. You do know that {{443}} is the default port
for {{HTTPS}} communcation? Other constellations are unsupported.
> Can not set proxy port to 443
> -
>
> Key: MNG-5853
> URL: https://issues.apache.org/jira/browse/MNG-5853
> Project: Maven
> Issue Type: Bug
> Components: General, Settings
>Affects Versions: 3.2.3
> Environment: mvn --version
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-12T03:58:10+07:00)
> Maven home: /opt/maven
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.7.0_67/jre
> Default locale: en_US, platform encoding: ANSI_X3.4-1968
> OS name: "linux", version: "2.6.32-431.el6.x86_64", arch: "amd64", family:
> "unix"
>
>
>
> true
> http
> x.x.x.x
> 443
>
>
> www.google.com|*.somewhere.com
>
>
>
>Reporter: Chuyen Vo
>
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec
> execute
> INFO: I/O exception (java.net.SocketException) caught when processing
> request: java.security.NoSuchAlgorithmException: Error constructing
> implementation (algorithm: Default, provider: SunJSSE, class:
> sun.security.ssl.SSLContextImpl$DefaultSSLContext)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5853) Can not set proxy port to 443
[ https://issues.apache.org/jira/browse/MNG-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5853: Labels: close-pending (was: ) > Can not set proxy port to 443 > - > > Key: MNG-5853 > URL: https://issues.apache.org/jira/browse/MNG-5853 > Project: Maven > Issue Type: Bug > Components: General, Settings >Affects Versions: 3.2.3 > Environment: mvn --version > Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; > 2014-08-12T03:58:10+07:00) > Maven home: /opt/maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/java/jdk1.7.0_67/jre > Default locale: en_US, platform encoding: ANSI_X3.4-1968 > OS name: "linux", version: "2.6.32-431.el6.x86_64", arch: "amd64", family: > "unix" > > > > true > http > x.x.x.x > 443 > > > www.google.com|*.somewhere.com > > > >Reporter: Chuyen Vo > Labels: close-pending > > org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec > execute > INFO: I/O exception (java.net.SocketException) caught when processing > request: java.security.NoSuchAlgorithmException: Error constructing > implementation (algorithm: Default, provider: SunJSSE, class: > sun.security.ssl.SSLContextImpl$DefaultSSLContext) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MNG-5721) Possible NullPointerException in org.apache.maven.repository. MetadataResolutionResult
[
https://issues.apache.org/jira/browse/MNG-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov resolved MNG-5721.
-
Resolution: Fixed
Fixed with
[d1dc63844f413ebce65162f1262c52d0bf15e06f|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=d1dc63844f413ebce65162f1262c52d0bf15e06f].
> Possible NullPointerException in org.apache.maven.repository.
> MetadataResolutionResult
>
>
> Key: MNG-5721
> URL: https://issues.apache.org/jira/browse/MNG-5721
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.3.3
>Reporter: Martin Schäf
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.7
>
> Attachments: MetadataResolutionResult.java
>
>
> In line 235 of org.apache.maven.repository.MetadataResolutionResult
> the function initList is used in the wrong way. Should be:
> public MetadataResolutionResult addError( Exception e )
> {
> exceptions = initList( exceptions );
> exceptions.add( e );
> return this;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5606) maven should use JDK_HOME env var if present
[
https://issues.apache.org/jira/browse/MNG-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952022#comment-14952022
]
Michael Osipov commented on MNG-5606:
-
That variable is not commonly used. {{JAVA_HOME}} is the defacto standard. If a
tool requires a JRE and you provide a JDK, it doesn't matter. It will run
anyway,
> maven should use JDK_HOME env var if present
>
>
> Key: MNG-5606
> URL: https://issues.apache.org/jira/browse/MNG-5606
> Project: Maven
> Issue Type: Wish
> Environment: windows 7
>Reporter: Gunchin Aleksey
>Priority: Trivial
> Labels: close-pending
>
> JAVA_HOME is for jre, but maven searches for javac there.
> One can add
> @if not "%JDK_HOME%" == "" set JAVA_HOME="%JDK_HOME%"
> to mvn.bat
> and the analogue string to .sh script
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5606) maven should use JDK_HOME env var if present
[ https://issues.apache.org/jira/browse/MNG-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5606: Labels: close-pending (was: ) > maven should use JDK_HOME env var if present > > > Key: MNG-5606 > URL: https://issues.apache.org/jira/browse/MNG-5606 > Project: Maven > Issue Type: Wish > Environment: windows 7 >Reporter: Gunchin Aleksey >Priority: Trivial > Labels: close-pending > > JAVA_HOME is for jre, but maven searches for javac there. > One can add > @if not "%JDK_HOME%" == "" set JAVA_HOME="%JDK_HOME%" > to mvn.bat > and the analogue string to .sh script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5877) maven-aether-provider/maven-compat does not always generate snapshot versions using Gregorian calendar year
[
https://issues.apache.org/jira/browse/MNG-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951874#comment-14951874
]
Michael Osipov commented on MNG-5877:
-
Just pushed [another
fix|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=2ec27257b4936762a92c2ac860ea5d633c633e77]
which might cause another problem.
> maven-aether-provider/maven-compat does not always generate snapshot versions
> using Gregorian calendar year
>
>
> Key: MNG-5877
> URL: https://issues.apache.org/jira/browse/MNG-5877
> Project: Maven
> Issue Type: Bug
>Reporter: Anders Forsell
>Assignee: Michael Osipov
> Fix For: 3.3.7
>
>
> I am using the maven-aether-provider in my software and have an issue when
> Thailand users are publishing their snapshot versions get the Buddhist
> calendar year (offset of 543 years).
> I have located the problem to be in the RemoteSnapShotMetaData class:
> {code:title=RemoteSnapShotMetaData.java|borderStyle=solid}
> DateFormat utcDateFormatter = new SimpleDateFormat(
> "MMdd.HHmmss" );
> utcDateFormatter.setTimeZone( TimeZone.getTimeZone( "UTC" ) );
> snapshot = new Snapshot();
> snapshot.setBuildNumber( getBuildNumber( recessive ) + 1 );
> snapshot.setTimestamp( utcDateFormatter.format( new Date() ) );
> {code}
> The fix should be to explicitly set the calendar to be Gregorian:
> {code:title=RemoteSnapShotMetaData.java|borderStyle=solid}
> DateFormat utcDateFormatter = new SimpleDateFormat(
> "MMdd.HHmmss" );
> utcDateFormatter.setTimeZone( TimeZone.getTimeZone( "UTC" ) );
> utcDateFormatter.setCalendar(new GregorianCalendar());
> snapshot = new Snapshot();
> snapshot.setBuildNumber( getBuildNumber( recessive ) + 1 );
> snapshot.setTimestamp( utcDateFormatter.format( new Date() ) );
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SUREFIRE-1182) Surefire 2.19 rc hangs when building maven core
[ https://issues.apache.org/jira/browse/SUREFIRE-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1182. -- Resolution: Fixed commit e817f4575aa2b15cdd22447b0662eee9eef9b198 > Surefire 2.19 rc hangs when building maven core > --- > > Key: SUREFIRE-1182 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1182 > Project: Maven Surefire > Issue Type: Bug > Environment: Ubuntu linux >Reporter: Kristian Rosenvold >Assignee: Tibor Digana > Fix For: 2.19 > > > The 2.19 release candidate of 6 oct hangs when building maven core on linux. > Stack dumps; > Forked booter: > 2015-10-08 18:59:45 > Full thread dump OpenJDK 64-Bit Server VM (25.45-b02 mixed mode): > "Attach Listener" #23 daemon prio=9 os_prio=0 tid=0x7f6770001000 > nid=0x3f48 waiting on condition [0x] >java.lang.Thread.State: RUNNABLE > "DestroyJavaVM" #22 prio=5 os_prio=0 tid=0x7f67c000a000 nid=0x3e8d > waiting on condition [0x] >java.lang.Thread.State: RUNNABLE > "pool-1-thread-6" #20 prio=5 os_prio=0 tid=0x7f67c065e800 nid=0x3eab > waiting on condition [0x7f678847f000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "pool-1-thread-5" #19 prio=5 os_prio=0 tid=0x7f67c065d000 nid=0x3eaa > waiting on condition [0x7f678858] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "pool-1-thread-4" #18 prio=5 os_prio=0 tid=0x7f67c065b000 nid=0x3ea9 > waiting on condition [0x7f6788681000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "pool-1-thread-3" #17 prio=5 os_prio=0 tid=0x7f67c0659800 nid=0x3ea8 > waiting on condition [0x7f6788782000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3001be0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) > at >
[jira] [Closed] (MNG-5792) mvn.bat renamed to mvn.cmd -> maven-invoker-plugin:run fails
[
https://issues.apache.org/jira/browse/MNG-5792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5792.
---
Resolution: Not A Problem
As Karl Heinz layed out, use a newer version of MINVOKER.
> mvn.bat renamed to mvn.cmd -> maven-invoker-plugin:run fails
>
>
> Key: MNG-5792
> URL: https://issues.apache.org/jira/browse/MNG-5792
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.3.1
> Environment: Windows 7 64 bit, Java 7
>Reporter: Jan Sievers
>
> steps to reproduce:
> # git clone https://github.com/takari/maven-polyglot.git
> # using maven 3.3.1 on WIndows, do a
> {code}
> mvn clean install
> {code}
> build fails with
> {code}
> [INFO] --- maven-invoker-plugin:1.5:run (integration-test) @ polyglot-ruby ---
> [INFO] Building: ruby_execute\pom.xml
> [INFO] ..FAILED (0.0 s)
> [INFO] Maven invocation failed. Error configuring command-line. Reason:
> Maven executable not found at: C:\tools\apache
> -maven-3.3.1\bin\mvn.bat
> [INFO] Building: use_jruby_installation\pom.xml
> [INFO] ..FAILED (0.0 s)
> [INFO] Maven invocation failed. Error configuring command-line. Reason:
> Maven executable not found at: C:\tools\apache
> -maven-3.3.1\bin\mvn.bat
> [INFO] -
> [INFO] Build Summary:
> [INFO] Passed: 0, Failed: 2, Errors: 0, Skipped: 0
> [INFO] -
> {code}
> it seems that mvn.bat was renamed to mvn.cmd with maven 3.3.1
> While maven-invoker-plugin could arguably be smarter to locate the mvn
> script, I think it's best to revert the rename unless there was a specific
> reason to rename from .bat to .cmd.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MASSEMBLY-784) Remove deprecated goals for 3.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MASSEMBLY-784. -- Resolution: Duplicate Someone else did this, but my search for a JIRA failed. > Remove deprecated goals for 3.0 > --- > > Key: MASSEMBLY-784 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-784 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Benson Margulies >Assignee: Benson Margulies > > The deprecated goals have been cluttering up the doc for years. > Kill! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5877) maven-aether-provider/maven-compat does not always generate snapshot versions using Gregorian calendar year
[
https://issues.apache.org/jira/browse/MNG-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951873#comment-14951873
]
Hudson commented on MNG-5877:
-
SUCCESS: Integrated in maven-3.x #1133 (See
[https://builds.apache.org/job/maven-3.x/1133/])
[MNG-5877] maven-aether-provider/maven-compat does not always generate
(michaelo: rev 4ba3b752d6cc7fb170911711fd9a8cbf5979e745)
*
maven-compat/src/main/java/org/apache/maven/repository/legacy/resolver/transform/SnapshotTransformation.java
> maven-aether-provider/maven-compat does not always generate snapshot versions
> using Gregorian calendar year
>
>
> Key: MNG-5877
> URL: https://issues.apache.org/jira/browse/MNG-5877
> Project: Maven
> Issue Type: Bug
>Reporter: Anders Forsell
>Assignee: Michael Osipov
> Fix For: 3.3.7
>
>
> I am using the maven-aether-provider in my software and have an issue when
> Thailand users are publishing their snapshot versions get the Buddhist
> calendar year (offset of 543 years).
> I have located the problem to be in the RemoteSnapShotMetaData class:
> {code:title=RemoteSnapShotMetaData.java|borderStyle=solid}
> DateFormat utcDateFormatter = new SimpleDateFormat(
> "MMdd.HHmmss" );
> utcDateFormatter.setTimeZone( TimeZone.getTimeZone( "UTC" ) );
> snapshot = new Snapshot();
> snapshot.setBuildNumber( getBuildNumber( recessive ) + 1 );
> snapshot.setTimestamp( utcDateFormatter.format( new Date() ) );
> {code}
> The fix should be to explicitly set the calendar to be Gregorian:
> {code:title=RemoteSnapShotMetaData.java|borderStyle=solid}
> DateFormat utcDateFormatter = new SimpleDateFormat(
> "MMdd.HHmmss" );
> utcDateFormatter.setTimeZone( TimeZone.getTimeZone( "UTC" ) );
> utcDateFormatter.setCalendar(new GregorianCalendar());
> snapshot = new Snapshot();
> snapshot.setBuildNumber( getBuildNumber( recessive ) + 1 );
> snapshot.setTimestamp( utcDateFormatter.format( new Date() ) );
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5721) Possible NullPointerException in org.apache.maven.repository. MetadataResolutionResult
[
https://issues.apache.org/jira/browse/MNG-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5721:
Fix Version/s: 3.3.7
> Possible NullPointerException in org.apache.maven.repository.
> MetadataResolutionResult
>
>
> Key: MNG-5721
> URL: https://issues.apache.org/jira/browse/MNG-5721
> Project: Maven
> Issue Type: Bug
> Components: General
>Reporter: Martin Schäf
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.7
>
> Attachments: MetadataResolutionResult.java
>
>
> In line 235 of org.apache.maven.repository.MetadataResolutionResult
> the function initList is used in the wrong way. Should be:
> public MetadataResolutionResult addError( Exception e )
> {
> exceptions = initList( exceptions );
> exceptions.add( e );
> return this;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MNG-5721) Possible NullPointerException in org.apache.maven.repository. MetadataResolutionResult
[
https://issues.apache.org/jira/browse/MNG-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-5721:
---
Assignee: Michael Osipov
> Possible NullPointerException in org.apache.maven.repository.
> MetadataResolutionResult
>
>
> Key: MNG-5721
> URL: https://issues.apache.org/jira/browse/MNG-5721
> Project: Maven
> Issue Type: Bug
> Components: General
>Reporter: Martin Schäf
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.7
>
> Attachments: MetadataResolutionResult.java
>
>
> In line 235 of org.apache.maven.repository.MetadataResolutionResult
> the function initList is used in the wrong way. Should be:
> public MetadataResolutionResult addError( Exception e )
> {
> exceptions = initList( exceptions );
> exceptions.add( e );
> return this;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MASSEMBLY-784) Remove deprecated goals for 3.0
Benson Margulies created MASSEMBLY-784: -- Summary: Remove deprecated goals for 3.0 Key: MASSEMBLY-784 URL: https://issues.apache.org/jira/browse/MASSEMBLY-784 Project: Maven Assembly Plugin Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Benson Margulies The deprecated goals have been cluttering up the doc for years. Kill! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5750) Sporadic failures in concurrent build
[
https://issues.apache.org/jira/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951997#comment-14951997
]
Kristian Rosenvold commented on MNG-5750:
-
I think so, this would appear to be the plexus-interpolation bug that was fixed
in 1.21
> Sporadic failures in concurrent build
> -
>
> Key: MNG-5750
> URL: https://issues.apache.org/jira/browse/MNG-5750
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
> HotSpot JDK 7u25
> windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
>Reporter: Alexander Ashitkin
>Priority: Critical
>
> We have a large project of 300+ modules which regularly fails with different
> kind of errors in different places. The issue is reliably reproduced with
> parallel build and is not happens in single threaded. The optimal concurrency
> level for our project ~10 threads. At this level ~%20 of builds fail. To
> workaround the issue we reduced concurrency to 4 in development builds and
> reverted production build to 1 thread.
> Main point of failures:
> # Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
> to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
> # Compiler - unexpected failure because of incorrect classpath (literally all
> dependencies are not on the classpath), like: {code}
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
> org.joda.time does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
> import only from classes and interfaces
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
> import only from classes and interfaces
> {code}
> # Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
> plusgin seems to be also affected)
> At this point the issue looks like problem with MavenProject#getArtifacts in
> concurrent builds.
> To help with the issue im happy to implement or evaluate any custom assembly
> to trace this down. Unfortunately i cannot submit my project - it is
> proprietary.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MASSEMBLY-784) Remove deprecated goals for 3.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned MASSEMBLY-784: -- Assignee: Benson Margulies > Remove deprecated goals for 3.0 > --- > > Key: MASSEMBLY-784 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-784 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Benson Margulies >Assignee: Benson Margulies > > The deprecated goals have been cluttering up the doc for years. > Kill! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-5556) Document org.jvnet.jax-ws-commons:jaxws-maven-plugin:2.3.1-b03 fails with AetherClassNotFound
[
https://issues.apache.org/jira/browse/MNG-5556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5556.
---
Resolution: Won't Fix
Unfortunately, that plugin is dead. New effort will be put in the Mojohaus fork.
> Document org.jvnet.jax-ws-commons:jaxws-maven-plugin:2.3.1-b03 fails with
> AetherClassNotFound
> -
>
> Key: MNG-5556
> URL: https://issues.apache.org/jira/browse/MNG-5556
> Project: Maven
> Issue Type: Task
> Components: Documentation: FAQ
>Reporter: Archimedes Trajano
>Priority: Minor
>
> The plugin
> {code:xml}
> org.jvnet.jax-ws-commons
> jaxws-maven-plugin
> 2.3.1-b03
> {code}
> Does not work on Maven 3.1.1
> Please add to
> https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound (I
> can't seem to comment or add to the list)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-945) Top of web page is pretty opaque
[ https://issues.apache.org/jira/browse/SUREFIRE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-945: -- Fix Version/s: 2.19 > Top of web page is pretty opaque > > > Key: SUREFIRE-945 > URL: https://issues.apache.org/jira/browse/SUREFIRE-945 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Benson Margulies >Assignee: Tibor Digana > Fix For: 2.19 > > > http://maven.apache.org/surefire/index.html is an about page with no > meaningful content and no navigation to other information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SUREFIRE-945) Top of web page is pretty opaque
[ https://issues.apache.org/jira/browse/SUREFIRE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-945: - Assignee: Tibor Digana > Top of web page is pretty opaque > > > Key: SUREFIRE-945 > URL: https://issues.apache.org/jira/browse/SUREFIRE-945 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Benson Margulies >Assignee: Tibor Digana > > http://maven.apache.org/surefire/index.html is an about page with no > meaningful content and no navigation to other information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5606) maven should use JDK_HOME env var if present
[ https://issues.apache.org/jira/browse/MNG-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952146#comment-14952146 ] Gunchin Aleksey commented on MNG-5606: -- If someone pointed JDK_HOME to jre than he is an idiot and you can require him to change it back. But if he pointed JAVA_HOME to whatever and your soft could not launch - it can be some other soft's requirement. > maven should use JDK_HOME env var if present > > > Key: MNG-5606 > URL: https://issues.apache.org/jira/browse/MNG-5606 > Project: Maven > Issue Type: Wish > Environment: windows 7 >Reporter: Gunchin Aleksey >Priority: Trivial > Labels: close-pending > > JAVA_HOME is for jre, but maven searches for javac there. > One can add > @if not "%JDK_HOME%" == "" set JAVA_HOME="%JDK_HOME%" > to mvn.bat > and the analogue string to .sh script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5750) Sporadic failures in concurrent build
[
https://issues.apache.org/jira/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952034#comment-14952034
]
Alexander Ashitkin commented on MNG-5750:
-
[~krosenvold] please confirm the fix version. i will evaluate it.
Thank you
> Sporadic failures in concurrent build
> -
>
> Key: MNG-5750
> URL: https://issues.apache.org/jira/browse/MNG-5750
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
> HotSpot JDK 7u25
> windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
>Reporter: Alexander Ashitkin
>Priority: Critical
>
> We have a large project of 300+ modules which regularly fails with different
> kind of errors in different places. The issue is reliably reproduced with
> parallel build and is not happens in single threaded. The optimal concurrency
> level for our project ~10 threads. At this level ~%20 of builds fail. To
> workaround the issue we reduced concurrency to 4 in development builds and
> reverted production build to 1 thread.
> Main point of failures:
> # Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
> to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
> # Compiler - unexpected failure because of incorrect classpath (literally all
> dependencies are not on the classpath), like: {code}
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
> org.joda.time does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
> import only from classes and interfaces
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
> import only from classes and interfaces
> {code}
> # Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
> plusgin seems to be also affected)
> At this point the issue looks like problem with MavenProject#getArtifacts in
> concurrent builds.
> To help with the issue im happy to implement or evaluate any custom assembly
> to trace this down. Unfortunately i cannot submit my project - it is
> proprietary.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5750) Sporadic failures in concurrent build
[
https://issues.apache.org/jira/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952034#comment-14952034
]
Alexander Ashitkin edited comment on MNG-5750 at 10/10/15 8:39 PM:
---
[~krosenvold] please confirm maven fix version. i will evaluate it.
Thank you
was (Author: alexander ashitkin):
[~krosenvold] please confirm the fix version. i will evaluate it.
Thank you
> Sporadic failures in concurrent build
> -
>
> Key: MNG-5750
> URL: https://issues.apache.org/jira/browse/MNG-5750
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
> HotSpot JDK 7u25
> windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
>Reporter: Alexander Ashitkin
>Priority: Critical
>
> We have a large project of 300+ modules which regularly fails with different
> kind of errors in different places. The issue is reliably reproduced with
> parallel build and is not happens in single threaded. The optimal concurrency
> level for our project ~10 threads. At this level ~%20 of builds fail. To
> workaround the issue we reduced concurrency to 4 in development builds and
> reverted production build to 1 thread.
> Main point of failures:
> # Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
> to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
> # Compiler - unexpected failure because of incorrect classpath (literally all
> dependencies are not on the classpath), like: {code}
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
> org.joda.time does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
> import only from classes and interfaces
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
> import only from classes and interfaces
> {code}
> # Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
> plusgin seems to be also affected)
> At this point the issue looks like problem with MavenProject#getArtifacts in
> concurrent builds.
> To help with the issue im happy to implement or evaluate any custom assembly
> to trace this down. Unfortunately i cannot submit my project - it is
> proprietary.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5773) Find duplicate properties
[
https://issues.apache.org/jira/browse/MNG-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952057#comment-14952057
]
Michael Osipov edited comment on MNG-5773 at 10/10/15 9:20 PM:
---
If you run {{mvn help:effective-pom}}, the duplicate property is eradicated
because they are backed by a {{Properties}} class. The problem with a possible
fix is that the reader is generated by Modello and I haven't found an option in
the Modello model to specify multiplicity duplicates. So no chance without a
Modello change.
was (Author: michael-o):
If you run {{mvn help:effective-pom}}, the duplicate property is eradicated.
The problem with the fix is that the reader is generated by Modello and I
haven't found and option in the Modello model to specify multiplicity
duplicates. So no chance without a Modello change.
> Find duplicate properties
> -
>
> Key: MNG-5773
> URL: https://issues.apache.org/jira/browse/MNG-5773
> Project: Maven
> Issue Type: Improvement
>Reporter: chibbe
> Attachments: pom.xml
>
>
> Would be good if a used property duplicated properties can be found as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5773) Find duplicate properties
[
https://issues.apache.org/jira/browse/MNG-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952057#comment-14952057
]
Michael Osipov commented on MNG-5773:
-
If you run {{mvn help:effective-pom}}, the duplicate property is eradicated.
The problem with the fix is that the reader is generated by Modello and I
haven't found and option in the Modello model to specify multiplicity
duplicates. So no chance without a Modello change.
> Find duplicate properties
> -
>
> Key: MNG-5773
> URL: https://issues.apache.org/jira/browse/MNG-5773
> Project: Maven
> Issue Type: Improvement
>Reporter: chibbe
> Attachments: pom.xml
>
>
> Would be good if a used property duplicated properties can be found as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MRELEASE-925) Old version of plexus utils forced here causes failures
[
https://issues.apache.org/jira/browse/MRELEASE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MRELEASE-925:
--
Description:
The maven-release pom calls for plexus utils 3.0.10. This is considerably older
than the version included with Maven 3.2.5; in any case, it seems to be the
cause of the following explosion in mvn release:prepare, where, somehow, that
old plexus utils beats out the newer one in the dependency graph, and a
required class goes missing. To repro this, pretend to repeat the release
process for maven-plugins version 28.
{noformat}
mvn release:prepare with 3.2.5
➜ maven-plugins mvn release:prepare
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Apache Maven Plugins 28-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.5.2:prepare (default-cli) @ maven-plugins ---
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: **/pom.xml.backup,
**/release.properties, **/pom.xml.branch, **/pom.xml.next,
**/pom.xml.releaseBackup, **/pom.xml.tag
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1.163 s
[INFO] Finished at: 2015-10-10T20:18:26-04:00
[INFO] Final Memory: 18M/310M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare
(default-cli) on project maven-plugins: Execution default-cli of goal
org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare failed: A
required class was missing while executing
org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare:
org/codehaus/plexus/util/xml/pull/EntityReplacementMap
[ERROR] -
[ERROR] realm =plugin>org.apache.maven.plugins:maven-release-plugin:2.5.2
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/Users/benson/.m2/repository/org/apache/maven/plugins/maven-release-plugin/2.5.2/maven-release-plugin-2.5.2.jar
[ERROR] urls[1] =
file:/Users/benson/.m2/repository/org/apache/maven/release/maven-release-manager/2.5.2/maven-release-manager-2.5.2.jar
[ERROR] urls[2] =
file:/Users/benson/.m2/repository/org/apache/maven/release/maven-release-api/2.5.2/maven-release-api-2.5.2.jar
[ERROR] urls[3] =
file:/Users/benson/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
[ERROR] urls[4] =
file:/Users/benson/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
[ERROR] urls[5] =
file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-6/plexus-interactivity-api-1.0-alpha-6.jar
[ERROR] urls[6] =
file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
[ERROR] urls[7] =
file:/Users/benson/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[8] =
file:/Users/benson/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
[ERROR] urls[9] =
file:/Users/benson/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[10] =
file:/Users/benson/.m2/repository/org/apache/maven/shared/maven-invoker/2.2/maven-invoker-2.2.jar
[ERROR] urls[11] =
file:/Users/benson/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
[ERROR] urls[12] =
file:/Users/benson/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
[ERROR] urls[13] =
file:/Users/benson/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
[ERROR] urls[14] =
file:/Users/benson/.m2/repository/commons-io/commons-io/2.2/commons-io-2.2.jar
[ERROR] urls[15] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-providers-standard/1.9.4/maven-scm-providers-standard-1.9.4.pom
[ERROR] urls[16] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-accurev/1.9.4/maven-scm-provider-accurev-1.9.4.jar
[ERROR] urls[17] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-bazaar/1.9.4/maven-scm-provider-bazaar-1.9.4.jar
[ERROR] urls[18] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-clearcase/1.9.4/maven-scm-provider-clearcase-1.9.4.jar
[ERROR] urls[19] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-cvsexe/1.9.4/maven-scm-provider-cvsexe-1.9.4.jar
[ERROR] urls[20] =
file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-cvs-commons/1.9.4/maven-scm-provider-cvs-commons-1.9.4.jar
[ERROR] urls[21] =
[jira] [Updated] (MNG-5842) java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter with jetty plugin
[
https://issues.apache.org/jira/browse/MNG-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5842:
Fix Version/s: (was: 3.3.7)
> java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter with jetty
> plugin
>
>
> Key: MNG-5842
> URL: https://issues.apache.org/jira/browse/MNG-5842
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3
>Reporter: Jean-Christophe Gay
>Assignee: Arnaud HERITIER
>
> When Maven is used with a different SLF4J implementation than slf4j-simple
> (in my case logback to have colored logs), running jetty-maven-plugin fails.
> {code}
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T13:57:37+02:00)
> Maven home: /usr/local/Cellar/maven/3.3.3/libexec
> Java version: 1.8.0_40, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre
> Default locale: fr_FR, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.3", arch: "x86_64", family: "mac"
> {code}
> {code}
> [WARNING] FAILED org.mortbay.jetty.plugin.JettyServer@66c4005:
> java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> java.lang.ClassNotFoundException: org.slf4j.helpers.MessageFormatter
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ~[plexus-classworlds-2.5.2.jar:na]
> ... 21 common frames omitted
> Wrapped by: java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> at
> org.eclipse.jetty.util.log.JettyAwareLogger.log(JettyAwareLogger.java:619)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.eclipse.jetty.util.log.JettyAwareLogger.info(JettyAwareLogger.java:314)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.eclipse.jetty.util.log.Slf4jLog.info(Slf4jLog.java:74)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.eclipse.jetty.server.Server.doStart(Server.java:271)
> ~[jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:65)
> ~[jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:520)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:365)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.mortbay.jetty.plugin.JettyRunMojo.execute(JettyRunMojo.java:521)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> [maven-core-3.3.1.jar:3.3.1]
> at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:275)
> [takari-smart-builder-0.4.0.jar:0.4.0]
> at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:101)
> [takari-smart-builder-0.4.0.jar:0.4.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_40]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40]
> java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> at
[jira] [Assigned] (SUREFIRE-1035) Use the same settings as the maven JVM when forking a JVM
[ https://issues.apache.org/jira/browse/SUREFIRE-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1035: -- Assignee: Tibor Digana > Use the same settings as the maven JVM when forking a JVM > - > > Key: SUREFIRE-1035 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1035 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin, process forking >Affects Versions: 2.16 >Reporter: Jifeng Zhang >Assignee: Tibor Digana > > When forking a JVM, JVM settings are not inherited from MAVEN_OPTS. And by > default, the forked JVM is a new instance of the same JVM used to start Maven. > Were there strong reasons for not using the same JVM settings as the > "parental" JVM, but using argLine explicitly? > I think for the users that are not aware of JVM forking, they would expect > the same JVM settings are used when running surefire plugin. Just like we > assumed it is the same JVM (new instance) forked as the one Maven runs on, > which was not true until version 2.3, and was fixed in > [SUREFIRE-135|https://jira.codehaus.org/browse/SUREFIRE-135] > So I propose when forking a JVM, the same settings from JVM that maven runs > on, is used; unless there is an argLine explicitly overwrites the settings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (SUREFIRE-945) Top of web page is pretty opaque
[ https://issues.apache.org/jira/browse/SUREFIRE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reopened SUREFIRE-945: --- > Top of web page is pretty opaque > > > Key: SUREFIRE-945 > URL: https://issues.apache.org/jira/browse/SUREFIRE-945 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Benson Margulies >Assignee: Tibor Digana > Fix For: 2.19 > > > http://maven.apache.org/surefire/index.html is an about page with no > meaningful content and no navigation to other information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SUREFIRE-1035) Use the same settings as the maven JVM when forking a JVM
[
https://issues.apache.org/jira/browse/SUREFIRE-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1035.
--
Resolution: Won't Fix
It is not surefire bug.
MAVEN_OPTS or JAVA_OPTS?
Instead of fixing this issue use simple syntax
{code}
${env.MAVEN_OPTS}
{code}
> Use the same settings as the maven JVM when forking a JVM
> -
>
> Key: SUREFIRE-1035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1035
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.16
>Reporter: Jifeng Zhang
>Assignee: Tibor Digana
>
> When forking a JVM, JVM settings are not inherited from MAVEN_OPTS. And by
> default, the forked JVM is a new instance of the same JVM used to start Maven.
> Were there strong reasons for not using the same JVM settings as the
> "parental" JVM, but using argLine explicitly?
> I think for the users that are not aware of JVM forking, they would expect
> the same JVM settings are used when running surefire plugin. Just like we
> assumed it is the same JVM (new instance) forked as the one Maven runs on,
> which was not true until version 2.3, and was fixed in
> [SUREFIRE-135|https://jira.codehaus.org/browse/SUREFIRE-135]
> So I propose when forking a JVM, the same settings from JVM that maven runs
> on, is used; unless there is an argLine explicitly overwrites the settings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5750) Sporadic failures in concurrent build
[
https://issues.apache.org/jira/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952046#comment-14952046
]
Alexander Ashitkin commented on MNG-5750:
-
Kristian, please notice the patch was applied to maven-core module. After that
the build is stable.
we've run it for a long time and no complaints so far
> Sporadic failures in concurrent build
> -
>
> Key: MNG-5750
> URL: https://issues.apache.org/jira/browse/MNG-5750
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
> HotSpot JDK 7u25
> windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
>Reporter: Alexander Ashitkin
>Priority: Critical
>
> We have a large project of 300+ modules which regularly fails with different
> kind of errors in different places. The issue is reliably reproduced with
> parallel build and is not happens in single threaded. The optimal concurrency
> level for our project ~10 threads. At this level ~%20 of builds fail. To
> workaround the issue we reduced concurrency to 4 in development builds and
> reverted production build to 1 thread.
> Main point of failures:
> # Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
> to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
> # Compiler - unexpected failure because of incorrect classpath (literally all
> dependencies are not on the classpath), like: {code}
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
> org.joda.time does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
> import only from classes and interfaces
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
> import only from classes and interfaces
> {code}
> # Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
> plusgin seems to be also affected)
> At this point the issue looks like problem with MavenProject#getArtifacts in
> concurrent builds.
> To help with the issue im happy to implement or evaluate any custom assembly
> to trace this down. Unfortunately i cannot submit my project - it is
> proprietary.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5415) Duplicate dependency with property causes the build to fail
[
https://issues.apache.org/jira/browse/MNG-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952053#comment-14952053
]
Michael Osipov commented on MNG-5415:
-
I have tested this with 3.3.7-SNAPSHOT and here are my results: During the
build, the POM is read, validator runs, interpolation is applied and
dependencies are merged. The actually problem is that if you have
{{$my.type}}, the validator operates on a static model. Passes this
through interpolation and models are merged. Now during that all dependencies
pass through a map where the key is {{groupId:artifactId:type:classifier}}
{{optional}} is not relevant. Since both deps have the same key, the last one
wins and the first has no version set. You lose. If you use literals, both
dependencies are merged because they have the same IDs ({{mergeDuplicates}}).
You lose too.
You have found a corner case. What do you expect to happen here? {{optional}}
does not qualify the dependency itself.
> Duplicate dependency with property causes the build to fail
> ---
>
> Key: MNG-5415
> URL: https://issues.apache.org/jira/browse/MNG-5415
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.3, 3.0.4
> Environment: $ mvn -version
> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /usr/share/maven
> Java version: 1.7.0_09, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.8.2", arch: "x86_64", family: "mac"
>Reporter: Tarje Killingberg
> Attachments: my-app.zip
>
>
> The following excerpt from a _pom.xml_ file causes just about any maven
> command (e.g. {{mvn package}}) to fail with the error
> _'dependencies.dependency.version' for junit:junit:jar is missing_:
> {code}
>
> jar
> jar
>
>
>
>
> junit
> junit
> 4.10
> ${my.type}
>
>
> junit
> junit
> 4.10
> ${my.other.type}
>
>
>
>
>
> junit
> junit
> ${my.type}
>
>
> junit
> junit
> ${my.other.type}
> true
>
>
> {code}
> If the string _jar_ is used instead of the properties, the build succeeds
> with warnings.
> A SSCCE is attached. Running the command {{mvn validate}} inside the
> _my-app_-folder should show the symptom.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5845) when in maven mojo, ClassNotFoundException slf4j-api `MessageFormatter` class
[
https://issues.apache.org/jira/browse/MNG-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5845:
Fix Version/s: (was: 3.3.7)
> when in maven mojo, ClassNotFoundException slf4j-api `MessageFormatter` class
> -
>
> Key: MNG-5845
> URL: https://issues.apache.org/jira/browse/MNG-5845
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.3
> Environment: window7;
> maven 3.3.3;
> my custom maven plugin dependencies
>
>
>
> org.apache.maven
> maven-core
> 3.3.3
>
>
> org.apache.maven
> maven-plugin-api
> 3.3.3
>
>
>
> org.apache.maven.plugin-tools
> maven-plugin-annotations
> 3.4
> provided
>
>
>
> org.codehaus.plexus
> plexus-component-annotations
> 1.6
> provided
>
>
> org.codehaus.plexus
> plexus-container-default
> 1.6
>
>
> org.codehaus.plexus
> plexus-interactivity-api
> 1.0-alpha-6
>
>
> plexus
> plexus-utils
>
>
>
>
> org.codehaus.plexus
> plexus-utils
> 3.0.22
>
>
> org.apache.maven.plugin-testing
> maven-plugin-testing-harness
> 3.3.0
> test
>
>
> org.slf4j
> slf4j-api
> 1.7.12
>
>
> org.slf4j
> slf4j-log4j12
> 1.7.12
>
>
>Reporter: feilong
>Assignee: Arnaud HERITIER
> Labels: maven
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> *my code is*
> {code}
> @Mojo(name = "hello",requiresProject = false)
> public class HelloWorldMojo extends AbstractMojo{
> @Override
> public void execute() throws MojoExecutionException,MojoFailureException{
> String[] argStrings = { "Hello world" };
> FormattingTuple formattingTuple = MessageFormatter.arrayFormat("{}",
> argStrings);
> getLog().info(formattingTuple.getMessage());
> }
> }
> {code}
> *when i run my plugins , show me result:*
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> at com.feilong.core.log.Slf4jUtil.formatMessage(Slf4jUtil.java:77)
> at
> com.feilong.project.train.mojo.BaseFlowMojo.getFolderPath(BaseFlowMojo.java:72)
> at
> com.feilong.project.train.mojo.InvitationMojo.handleExecute(InvitationMojo.java:89)
> at
> com.feilong.project.train.mojo.BaseFlowMojo.execute(BaseFlowMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.lang.ClassNotFoundException:
> org.slf4j.helpers.MessageFormatter
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 26 more
> {code}
> *And from the log (run with -X), i see that :*
> {code}
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T19:57:37+08:00)
> Maven home: D:\FeiLong Soft\Essential\Development\apache-maven-3.3.3\bin\..
> Java version: 1.8.0_11, vendor: Oracle Corporation
> Java home: D:\Program Files\Java\jdk1.8.0_11\jre
> Default locale: zh_CN, platform encoding: GBK
> OS name: "windows 7", version: "6.1", arch: "x86", family: "dos"
> [DEBUG] Created new class realm maven.api
> [DEBUG] Importing foreign packages into class realm maven.api
> [DEBUG] Imported: javax.enterprise.inject.* < plexus.core
> [DEBUG] Imported: javax.enterprise.util.* < plexus.core
> [DEBUG] Imported: javax.inject.* < plexus.core
> [DEBUG] Imported: org.apache.maven.* < plexus.core
>
[jira] [Closed] (SUREFIRE-945) Top of web page is pretty opaque
[ https://issues.apache.org/jira/browse/SUREFIRE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-945. - Resolution: Fixed commit 0d4ca4dec5955c95bfad8dd6f6353075897c028f > Top of web page is pretty opaque > > > Key: SUREFIRE-945 > URL: https://issues.apache.org/jira/browse/SUREFIRE-945 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Benson Margulies >Assignee: Tibor Digana > Fix For: 2.19 > > > http://maven.apache.org/surefire/index.html is an about page with no > meaningful content and no navigation to other information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5606) maven should use JDK_HOME env var if present
[ https://issues.apache.org/jira/browse/MNG-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952142#comment-14952142 ] Gunchin Aleksey commented on MNG-5606: -- People tend to interpret that "defacto standard" as they want. Maven have plugins, I have many other java soft on my workstation. Sometimes they require different things JAVA_HOME to point to. Javafx for example is in jre and not in jdk. Having two env vars allows to describe that precisely system-wide. Or else one have to give every program its own launch bat/sh script. > maven should use JDK_HOME env var if present > > > Key: MNG-5606 > URL: https://issues.apache.org/jira/browse/MNG-5606 > Project: Maven > Issue Type: Wish > Environment: windows 7 >Reporter: Gunchin Aleksey >Priority: Trivial > Labels: close-pending > > JAVA_HOME is for jre, but maven searches for javac there. > One can add > @if not "%JDK_HOME%" == "" set JAVA_HOME="%JDK_HOME%" > to mvn.bat > and the analogue string to .sh script -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5693) Change logging of MojoExceptions to console
[
https://issues.apache.org/jira/browse/MNG-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952059#comment-14952059
]
Robert Scholte commented on MNG-5693:
-
I don't know how this part of the code looks like, but these messages should be
removed. There are probably more wiki-references which can be removed, maybe
worth trying to track those too.
> Change logging of MojoExceptions to console
> ---
>
> Key: MNG-5693
> URL: https://issues.apache.org/jira/browse/MNG-5693
> Project: Maven
> Issue Type: Improvement
> Components: FDPFC, Plugin API
>Reporter: Robert Scholte
>
> If a plugin fails for any reason, a general message is logged with a
> reference to a wiki page, which never contains the real reason why the plugin
> failed.
> For new users this is very confusing. Even when we teach them to read, and
> they finally see a link, it's quite frustrating for them that they still
> don't know what happened.
> {{MojoExecutionException}} and {{MojoFailureException}} should never refer to
> a wikipage anymore.
> Plugin writers should get more control over the message written to the
> console.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MRELEASE-925) Old version of plexus utils forced here causes failures
Benson Margulies created MRELEASE-925: - Summary: Old version of plexus utils forced here causes failures Key: MRELEASE-925 URL: https://issues.apache.org/jira/browse/MRELEASE-925 Project: Maven Release Plugin Issue Type: Bug Reporter: Benson Margulies -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-5763) Incorrect resolution of ${project.groupId} for POM imports with different groupIds
[
https://issues.apache.org/jira/browse/MNG-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MNG-5763.
--
Resolution: Not A Problem
Assignee: Hervé Boutemy
> Incorrect resolution of ${project.groupId} for POM imports with different
> groupIds
> --
>
> Key: MNG-5763
> URL: https://issues.apache.org/jira/browse/MNG-5763
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build, Dependencies
>Affects Versions: 3.1.1
> Environment: Apache Maven 3.1.1
> (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 17:22:22+0200)
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Daniel Strassenburg
>Assignee: Hervé Boutemy
> Attachments: myproject.zip
>
>
> In the attached project find a sample which causes Maven to fail when
> resolving POM imports. The property {{$\{project.groupId\}}} is resolved
> incorrectly when
> # the imported modules have a different groupId
> # the imported POMs come from a submodule where one submodule containing a
> BOM POM has another groupId
> The groupIds of all other POM imports are changed to the groupId of the third
> BOM.
> Console output:
> {code}
> $ mvn install
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> com.mycompany.myproject.submodule:other-extension:1.0-SNAPSHOT
> (C:\dev\myproject\other-extension\pom.xml) has 2 errors
> [ERROR] Non-resolvable import POM: Failure to find
> com.mycompany.myproject.submodule:bom-1:pom:1.0-SNAPSHOT in
> http://repository-build.coremedia.com/nexus/content/repositories/snapshots.licenses/
> was cached in the local repository, resolution will not be reattempted until
> the update interval of coremedia.internal.licenses has elapsed or updates are
> forced @ com.mycompany.myproject:myroot:1.0-SNAPSHOT,
> C:\dev\myproject\pom.xml, line 19, column 19 -> [Help 2]
> [ERROR] Non-resolvable import POM: Failure to find
> com.mycompany.myproject.submodule:bom-2:pom:1.0-SNAPSHOT in
> http://repository-build.coremedia.com/nexus/content/repositories/snapshots.licenses/
> was cached in the local repository, resolution will not be reattempted until
> the update interval of coremedia.internal.licenses has elapsed or updates are
> forced @ com.mycompany.myproject:myroot:1.0-SNAPSHOT,
> C:\dev\myproject\pom.xml, line 26, column 19 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (MNG-5821) Documentation of the element parent.relativePath wrong in XSD
[
https://issues.apache.org/jira/browse/MNG-5821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy reopened MNG-5821:
reopening the issue
Arthur is right, maven-4.0.0.xsd in site is outdated: see
http://maven.apache.org/xsd/
{noformat} maven-4.0.0.xsd 2012-12-11 13:48{noformat}
current 3.3.3 documentation =
http://maven.apache.org/ref/3.3.3/maven-model/maven.html#class_parent
but xsd was put in the site in 2012, and seems to have been generated even
before
see https://svn.apache.org/viewvc/maven/site/trunk/content/resources/xsd/
I'll move this issue to MNGSITE (since this is a site issue) and update the xsd
with a recently generated one, taken from current source HEAD
(and in fact, perhaps we should publish the xsd sometimes, since we don't
update elements but we update documentation/comments in it)
> Documentation of the element parent.relativePath wrong in XSD
> -
>
> Key: MNG-5821
> URL: https://issues.apache.org/jira/browse/MNG-5821
> Project: Maven
> Issue Type: Documentation
>Reporter: Arthur Bauer
>Assignee: Karl Heinz Marbaise
> Attachments: mvn-3.0.5.log, mvn-3.1.1.log, mvn-3.2.5.log,
> mvn-3.3.3.log, test.zip
>
>
> The documentation of the element parent.relativePath in the XSD file seems to
> be wrong or outdated. It says:
> "Maven looks for the parent pom first in the reactor of currently building
> projects, then in this location on the filesystem, then the local repository,
> and lastly in the remote repo."
> (Source: http://maven.apache.org/xsd/maven-4.0.0.xsd)
> But the actual documentation of maven says
> "Maven looks for the parent POM first in this location on the filesystem,
> then the local repository, and lastly in the remote repo."
> (Source:
> http://maven.apache.org/ref/3.0.3/maven-model/apidocs/org/apache/maven/model/Parent.html#getRelativePath%28%29)
> I have tested it on my local and I have seen the behavior as described in the
> second source, i.e. maven does not look for the parent pom in the reactor of
> currently building projects first.
> So this is pretty misleading. It is even more misleading for us, as we are
> reading the documentation directly from eclipse, which loads it from the XSD
> file.
> Could you please correct the XSD documentation?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Moved] (MNGSITE-259) Documentation of the element parent.relativePath wrong in XSD
[ https://issues.apache.org/jira/browse/MNGSITE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy moved MNG-5821 to MNGSITE-259: Key: MNGSITE-259 (was: MNG-5821) Project: Maven Project Web Site (was: Maven) > Documentation of the element parent.relativePath wrong in XSD > - > > Key: MNGSITE-259 > URL: https://issues.apache.org/jira/browse/MNGSITE-259 > Project: Maven Project Web Site > Issue Type: Documentation >Reporter: Arthur Bauer >Assignee: Karl Heinz Marbaise > Attachments: mvn-3.0.5.log, mvn-3.1.1.log, mvn-3.2.5.log, > mvn-3.3.3.log, test.zip > > > The documentation of the element parent.relativePath in the XSD file seems to > be wrong or outdated. It says: > "Maven looks for the parent pom first in the reactor of currently building > projects, then in this location on the filesystem, then the local repository, > and lastly in the remote repo." > (Source: http://maven.apache.org/xsd/maven-4.0.0.xsd) > But the actual documentation of maven says > "Maven looks for the parent POM first in this location on the filesystem, > then the local repository, and lastly in the remote repo." > (Source: > http://maven.apache.org/ref/3.0.3/maven-model/apidocs/org/apache/maven/model/Parent.html#getRelativePath%28%29) > I have tested it on my local and I have seen the behavior as described in the > second source, i.e. maven does not look for the parent pom in the reactor of > currently building projects first. > So this is pretty misleading. It is even more misleading for us, as we are > reading the documentation directly from eclipse, which loads it from the XSD > file. > Could you please correct the XSD documentation? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5763) Incorrect resolution of ${project.groupId} for POM imports with different groupIds
[
https://issues.apache.org/jira/browse/MNG-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951757#comment-14951757
]
Hervé Boutemy commented on MNG-5763:
linking to MNG-5900 which tracks this $\{this.*} new feature
> Incorrect resolution of ${project.groupId} for POM imports with different
> groupIds
> --
>
> Key: MNG-5763
> URL: https://issues.apache.org/jira/browse/MNG-5763
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build, Dependencies
>Affects Versions: 3.1.1
> Environment: Apache Maven 3.1.1
> (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 17:22:22+0200)
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Daniel Strassenburg
>Assignee: Hervé Boutemy
> Attachments: myproject.zip
>
>
> In the attached project find a sample which causes Maven to fail when
> resolving POM imports. The property {{$\{project.groupId\}}} is resolved
> incorrectly when
> # the imported modules have a different groupId
> # the imported POMs come from a submodule where one submodule containing a
> BOM POM has another groupId
> The groupIds of all other POM imports are changed to the groupId of the third
> BOM.
> Console output:
> {code}
> $ mvn install
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> com.mycompany.myproject.submodule:other-extension:1.0-SNAPSHOT
> (C:\dev\myproject\other-extension\pom.xml) has 2 errors
> [ERROR] Non-resolvable import POM: Failure to find
> com.mycompany.myproject.submodule:bom-1:pom:1.0-SNAPSHOT in
> http://repository-build.coremedia.com/nexus/content/repositories/snapshots.licenses/
> was cached in the local repository, resolution will not be reattempted until
> the update interval of coremedia.internal.licenses has elapsed or updates are
> forced @ com.mycompany.myproject:myroot:1.0-SNAPSHOT,
> C:\dev\myproject\pom.xml, line 19, column 19 -> [Help 2]
> [ERROR] Non-resolvable import POM: Failure to find
> com.mycompany.myproject.submodule:bom-2:pom:1.0-SNAPSHOT in
> http://repository-build.coremedia.com/nexus/content/repositories/snapshots.licenses/
> was cached in the local repository, resolution will not be reattempted until
> the update interval of coremedia.internal.licenses has elapsed or updates are
> forced @ com.mycompany.myproject:myroot:1.0-SNAPSHOT,
> C:\dev\myproject\pom.xml, line 26, column 19 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5763) Incorrect resolution of ${project.groupId} for POM imports with different groupIds
[
https://issues.apache.org/jira/browse/MNG-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14950252#comment-14950252
]
Hervé Boutemy edited comment on MNG-5763 at 10/10/15 8:54 AM:
--
This also happens with $\{project.version}. When you import a pom in a parent
with $\{project.version}, the version of the child-pom is
used:
A (1.0) imports B ($\{project.version}, expected 1.0)
C (2.0) extends A, now imports B (2.0).
was (Author: papegaaij):
This also happens with ${project.version}. When you import a pom in a parent
with ${project.version}, the version of the child-pom is
used:
A (1.0) imports B (${project.version}, expected 1.0)
C (2.0) extends A, now imports B (2.0).
> Incorrect resolution of ${project.groupId} for POM imports with different
> groupIds
> --
>
> Key: MNG-5763
> URL: https://issues.apache.org/jira/browse/MNG-5763
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build, Dependencies
>Affects Versions: 3.1.1
> Environment: Apache Maven 3.1.1
> (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 17:22:22+0200)
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Daniel Strassenburg
> Attachments: myproject.zip
>
>
> In the attached project find a sample which causes Maven to fail when
> resolving POM imports. The property {{$\{project.groupId\}}} is resolved
> incorrectly when
> # the imported modules have a different groupId
> # the imported POMs come from a submodule where one submodule containing a
> BOM POM has another groupId
> The groupIds of all other POM imports are changed to the groupId of the third
> BOM.
> Console output:
> {code}
> $ mvn install
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> com.mycompany.myproject.submodule:other-extension:1.0-SNAPSHOT
> (C:\dev\myproject\other-extension\pom.xml) has 2 errors
> [ERROR] Non-resolvable import POM: Failure to find
> com.mycompany.myproject.submodule:bom-1:pom:1.0-SNAPSHOT in
> http://repository-build.coremedia.com/nexus/content/repositories/snapshots.licenses/
> was cached in the local repository, resolution will not be reattempted until
> the update interval of coremedia.internal.licenses has elapsed or updates are
> forced @ com.mycompany.myproject:myroot:1.0-SNAPSHOT,
> C:\dev\myproject\pom.xml, line 19, column 19 -> [Help 2]
> [ERROR] Non-resolvable import POM: Failure to find
> com.mycompany.myproject.submodule:bom-2:pom:1.0-SNAPSHOT in
> http://repository-build.coremedia.com/nexus/content/repositories/snapshots.licenses/
> was cached in the local repository, resolution will not be reattempted until
> the update interval of coremedia.internal.licenses has elapsed or updates are
> forced @ com.mycompany.myproject:myroot:1.0-SNAPSHOT,
> C:\dev\myproject\pom.xml, line 26, column 19 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5763) Incorrect resolution of ${project.groupId} for POM imports with different groupIds
[
https://issues.apache.org/jira/browse/MNG-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951734#comment-14951734
]
Hervé Boutemy commented on MNG-5763:
this is not a bug, this is a consequence of model interpolation (ie $\{..}
interpretation) happens after inheritance assembly
see reference documentation
http://maven.apache.org/ref/current/maven-model-builder/
during inheritance assembly, the unevaluated $\{...} is inherited, then
evaluation (= model interpolation) happens with current context, not context of
the parent pom
During ApacheCON, last week, Robert Scholte shared the idea of creating
$\{this.*} syntax to evaluate before inheritance (no MNG issue at the moment
AFAIK): this would give you the effect you're expecting currently
but such feature would not be backward compatible, then I suppose we'll need to
see when we can implement it without wrecking havoc in central...
I'll close the issue as "not a bug"
> Incorrect resolution of ${project.groupId} for POM imports with different
> groupIds
> --
>
> Key: MNG-5763
> URL: https://issues.apache.org/jira/browse/MNG-5763
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build, Dependencies
>Affects Versions: 3.1.1
> Environment: Apache Maven 3.1.1
> (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 17:22:22+0200)
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Daniel Strassenburg
> Attachments: myproject.zip
>
>
> In the attached project find a sample which causes Maven to fail when
> resolving POM imports. The property {{$\{project.groupId\}}} is resolved
> incorrectly when
> # the imported modules have a different groupId
> # the imported POMs come from a submodule where one submodule containing a
> BOM POM has another groupId
> The groupIds of all other POM imports are changed to the groupId of the third
> BOM.
> Console output:
> {code}
> $ mvn install
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> com.mycompany.myproject.submodule:other-extension:1.0-SNAPSHOT
> (C:\dev\myproject\other-extension\pom.xml) has 2 errors
> [ERROR] Non-resolvable import POM: Failure to find
> com.mycompany.myproject.submodule:bom-1:pom:1.0-SNAPSHOT in
> http://repository-build.coremedia.com/nexus/content/repositories/snapshots.licenses/
> was cached in the local repository, resolution will not be reattempted until
> the update interval of coremedia.internal.licenses has elapsed or updates are
> forced @ com.mycompany.myproject:myroot:1.0-SNAPSHOT,
> C:\dev\myproject\pom.xml, line 19, column 19 -> [Help 2]
> [ERROR] Non-resolvable import POM: Failure to find
> com.mycompany.myproject.submodule:bom-2:pom:1.0-SNAPSHOT in
> http://repository-build.coremedia.com/nexus/content/repositories/snapshots.licenses/
> was cached in the local repository, resolution will not be reattempted until
> the update interval of coremedia.internal.licenses has elapsed or updates are
> forced @ com.mycompany.myproject:myroot:1.0-SNAPSHOT,
> C:\dev\myproject\pom.xml, line 26, column 19 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNGSITE-259) Documentation of the element parent.relativePath wrong in XSD
[ https://issues.apache.org/jira/browse/MNGSITE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MNGSITE-259. - Resolution: Fixed update done in [r1707854|http://svn.apache.org/r1707854] > Documentation of the element parent.relativePath wrong in XSD > - > > Key: MNGSITE-259 > URL: https://issues.apache.org/jira/browse/MNGSITE-259 > Project: Maven Project Web Site > Issue Type: Documentation >Reporter: Arthur Bauer >Assignee: Karl Heinz Marbaise > Attachments: mvn-3.0.5.log, mvn-3.1.1.log, mvn-3.2.5.log, > mvn-3.3.3.log, test.zip > > > The documentation of the element parent.relativePath in the XSD file seems to > be wrong or outdated. It says: > "Maven looks for the parent pom first in the reactor of currently building > projects, then in this location on the filesystem, then the local repository, > and lastly in the remote repo." > (Source: http://maven.apache.org/xsd/maven-4.0.0.xsd) > But the actual documentation of maven says > "Maven looks for the parent POM first in this location on the filesystem, > then the local repository, and lastly in the remote repo." > (Source: > http://maven.apache.org/ref/3.0.3/maven-model/apidocs/org/apache/maven/model/Parent.html#getRelativePath%28%29) > I have tested it on my local and I have seen the behavior as described in the > second source, i.e. maven does not look for the parent pom in the reactor of > currently building projects first. > So this is pretty misleading. It is even more misleading for us, as we are > reading the documentation directly from eclipse, which loads it from the XSD > file. > Could you please correct the XSD documentation? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSHARED-442) Remove shading of artifact instead of using simple jar
[ https://issues.apache.org/jira/browse/MSHARED-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951749#comment-14951749 ] Hervé Boutemy commented on MSHARED-442: --- sorry, I did not hav time to look at this before I don't think this is a good idea either: commons-io as optional just will make the util blow up if someone uses the class(es) that was(were) previously shaded What is the problem you're trying to solve by removing shade? rat failure? > Remove shading of artifact instead of using simple jar > -- > > Key: MSHARED-442 > URL: https://issues.apache.org/jira/browse/MSHARED-442 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Affects Versions: maven-shared-utils-0.9 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-shared-utils-3.0.0 > > > Currently the maven-shared-utils are being shaded during the build but why do > we need that? It would be simpler to use create a simple jar file instead. > The old build included commons-io into the shaded jar. commons-io dependency > is defined optional. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5900) Support ${this.*} as expression
[
https://issues.apache.org/jira/browse/MNG-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951761#comment-14951761
]
Hervé Boutemy commented on MNG-5900:
I imagine it will require a new specific interpolation step before inheritance
assembly: http://maven.apache.org/ref/3.3.3/maven-model-builder/
and we'll need to take care of compatibility issues with other tools or old
Maven versions for POMs published to central
> Support ${this.*} as expression
> ---
>
> Key: MNG-5900
> URL: https://issues.apache.org/jira/browse/MNG-5900
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Right now we have $\{project.\*} which always interpolates values based on
> the final project. So it is not possible that parent poms can lock values. By
> adding $\{this} it will be possible to have intermediate interpolation.
> If a pomfile depends on a parent, that parent will first resolve all
> $\{this.\*} values for itself. Once the fully inherited pom is there, all
> $\{project.\*} will be resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-206) Make the sourceDirectories configurable
[
https://issues.apache.org/jira/browse/MPMD-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951767#comment-14951767
]
ASF GitHub Bot commented on MPMD-206:
-
Github user adangel closed the pull request at:
https://github.com/apache/maven-plugins/pull/47
> Make the sourceDirectories configurable
> ---
>
> Key: MPMD-206
> URL: https://issues.apache.org/jira/browse/MPMD-206
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: CPD, PMD
>Affects Versions: 3.4
>Reporter: Andreas Dangel
>Assignee: Dennis Lundberg
> Fix For: 3.5
>
>
> When analyzing a language other than Java, the sources currently have to be
> added by using the build-helper-maven-plugin to add additional source folders.
> This change adds the parameters {{sourceDirectories}} and
> {{testSourceDirectories}}, similarly as it is done in the checkstyle plugin.
> I'll provide a pull request for this:
> https://github.com/apache/maven-plugins/pull/47
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MDEP-509) dependency:tree and :list should reveal 'optional'
[ https://issues.apache.org/jira/browse/MDEP-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MDEP-509: -- Summary: dependency:tree and :list should reveal 'optional' (was: dependency:tree should reveal 'optional') > dependency:tree and :list should reveal 'optional' > -- > > Key: MDEP-509 > URL: https://issues.apache.org/jira/browse/MDEP-509 > Project: Maven Dependency Plugin > Issue Type: New Feature >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 3.0 > > > It would be helpful if dependency:tree would reveal the 'optional' status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MDEP-509) dependency:tree and :list should reveal 'optional'
[ https://issues.apache.org/jira/browse/MDEP-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MDEP-509. - > dependency:tree and :list should reveal 'optional' > -- > > Key: MDEP-509 > URL: https://issues.apache.org/jira/browse/MDEP-509 > Project: Maven Dependency Plugin > Issue Type: New Feature >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 3.0 > > > It would be helpful if dependency:tree would reveal the 'optional' status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MNG-5900) Support ${this.*} as expression
[
https://issues.apache.org/jira/browse/MNG-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951810#comment-14951810
]
Robert Scholte edited comment on MNG-5900 at 10/10/15 12:44 PM:
$\{this.\*} is mainly useful in pom packaging projects. To let all third party
tools work correctly, these values should be resolved before being
installed/deployed in case of current 4.0.0 modelVersion. Just an idea: maybe
we could use {{prerequisites/maven}} to decide if $\{this.\*} should be
resolved or not.
was (Author: rfscholte):
$\{this.*} is mainly useful in pom packaging projects. To let all third party
tools work correctly, these values should be resolved before being
installed/deployed in case of current 4.0.0 modelVersion. Just an idea: maybe
we could use {{prerequisites/maven}} to decide if $\{this.*} should be resolved
or not.
> Support ${this.*} as expression
> ---
>
> Key: MNG-5900
> URL: https://issues.apache.org/jira/browse/MNG-5900
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Right now we have $\{project.\*} which always interpolates values based on
> the final project. So it is not possible that parent poms can lock values. By
> adding $\{this} it will be possible to have intermediate interpolation.
> If a pomfile depends on a parent, that parent will first resolve all
> $\{this.\*} values for itself. Once the fully inherited pom is there, all
> $\{project.\*} will be resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5900) Support ${this.*} as expression
[
https://issues.apache.org/jira/browse/MNG-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951810#comment-14951810
]
Robert Scholte commented on MNG-5900:
-
$\{this.*} is mainly useful in pom packaging projects. To let all third party
tools work correctly, these values should be resolved before being
installed/deployed in case of current 4.0.0 modelVersion. Just an idea: maybe
we could use {{prerequisites/maven}} to decide if $\{this.*} should be resolved
or not.
> Support ${this.*} as expression
> ---
>
> Key: MNG-5900
> URL: https://issues.apache.org/jira/browse/MNG-5900
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Right now we have $\{project.\*} which always interpolates values based on
> the final project. So it is not possible that parent poms can lock values. By
> adding $\{this} it will be possible to have intermediate interpolation.
> If a pomfile depends on a parent, that parent will first resolve all
> $\{this.\*} values for itself. Once the fully inherited pom is there, all
> $\{project.\*} will be resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MNG-5906) Use canonical name for UTC timezone
[
https://issues.apache.org/jira/browse/MNG-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov resolved MNG-5906.
-
Resolution: Fixed
Fixed with
[b711de57dcd7d5db5b97ab4c9e1a618293e33a4d|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=b711de57dcd7d5db5b97ab4c9e1a618293e33a4d].
> Use canonical name for UTC timezone
> ---
>
> Key: MNG-5906
> URL: https://issues.apache.org/jira/browse/MNG-5906
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 3.3.7
>
>
> Throughout {{UTC}} is used. We shall use the canonical name {{Etc/UTC}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5906) Use canonical name for UTC timezone
[
https://issues.apache.org/jira/browse/MNG-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951816#comment-14951816
]
Hudson commented on MNG-5906:
-
SUCCESS: Integrated in maven-3.x #1130 (See
[https://builds.apache.org/job/maven-3.x/1130/])
[MNG-5906] Use canonical name for UTC timezone (michaelo: rev
b711de57dcd7d5db5b97ab4c9e1a618293e33a4d)
*
maven-aether-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java
*
maven-model-builder/src/main/java/org/apache/maven/model/interpolation/MavenBuildTimestamp.java
*
maven-compat/src/main/java/org/apache/maven/repository/legacy/resolver/transform/SnapshotTransformation.java
*
maven-model-builder/src/test/java/org/apache/maven/model/interpolation/AbstractModelInterpolatorTest.java
> Use canonical name for UTC timezone
> ---
>
> Key: MNG-5906
> URL: https://issues.apache.org/jira/browse/MNG-5906
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 3.3.7
>
>
> Throughout {{UTC}} is used. We shall use the canonical name {{Etc/UTC}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5900) Support ${this.*} as expression
[
https://issues.apache.org/jira/browse/MNG-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951820#comment-14951820
]
Hervé Boutemy commented on MNG-5900:
yes, some partially resolved POM could be installed/deployed instead of the
original pom
bq. maybe we could use prerequisites/maven to decide if ${this.*} should be
resolved or not.
this won't solve anything regarding POM already deployed to central: POM
deployed to central will require $\{this.*} empty poms
> Support ${this.*} as expression
> ---
>
> Key: MNG-5900
> URL: https://issues.apache.org/jira/browse/MNG-5900
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Right now we have $\{project.\*} which always interpolates values based on
> the final project. So it is not possible that parent poms can lock values. By
> adding $\{this} it will be possible to have intermediate interpolation.
> If a pomfile depends on a parent, that parent will first resolve all
> $\{this.\*} values for itself. Once the fully inherited pom is there, all
> $\{project.\*} will be resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MANTTASKS-249) download page linking to incorrect place?
[ https://issues.apache.org/jira/browse/MANTTASKS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951826#comment-14951826 ] Hervé Boutemy commented on MANTTASKS-249: - seems to be related to the new LUA script and the fact that Maven site has an internal redirect to /components/ see INFRA-10237 (I know this does not fix anything, but it is a start...) > download page linking to incorrect place? > - > > Key: MANTTASKS-249 > URL: https://issues.apache.org/jira/browse/MANTTASKS-249 > Project: Maven Ant Tasks > Issue Type: Bug > Components: documentation > Environment: website http://maven.apache.org/ant-tasks/ >Reporter: John Patrick > > From http://maven.apache.org/ant-tasks/ > Clicking "download page" > Takes you to this page http://maven.apache.org/ant-tasks/download.cgi > Unless you know how the mirrors are structure it might be difficult to > naviagte to say this subpath > http://www.mirrorservice.org/sites/ftp.apache.org/maven/ant-tasks/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5907) org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails starting at midnight
[
https://issues.apache.org/jira/browse/MNG-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951837#comment-14951837
]
Michael Osipov commented on MNG-5907:
-
Just reproduced it. Just like a set, a time zone issue. Fails here at 15:00
{{Europe/Berlin}} if I set time zone to {{Pacific/Auckland}}.
> org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails
> starting at midnight
> --
>
> Key: MNG-5907
> URL: https://issues.apache.org/jira/browse/MNG-5907
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.7
>Reporter: Karl Heinz Marbaise
>Assignee: Michael Osipov
>
> Currently this test fails (it seemed to be the reason having started the
> build at midnight CET):
> Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<<
> FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest
> gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest)
> Time elapsed: 0.011 sec <<< FAILURE!
> java.lang.AssertionError: Expected 20151007 to be in [20151008]
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79)
> Running org.apache.maven.repository.internal.RepositorySystemTest
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec -
> in org.apache.maven.repository.internal.RepositorySystemTest
> I have run maven build several times over the day and had no problems..I have
> to take a deeper look into this...
> I have run the build at about 11:00 o'clock am (CET) and the build is
> successfulwith the exact same code state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5907) org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails starting at midnight
[ https://issues.apache.org/jira/browse/MNG-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5907: Fix Version/s: 3.3.7 > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest Fails > starting at midnight > -- > > Key: MNG-5907 > URL: https://issues.apache.org/jira/browse/MNG-5907 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.7 >Reporter: Karl Heinz Marbaise >Assignee: Michael Osipov > Fix For: 3.3.7 > > > Currently this test fails (it seemed to be the reason having started the > build at midnight CET): > Running org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< > FAILURE! - in org.apache.maven.repository.internal.RemoteSnapshotMetadataTest > gregorianCalendarIsUsed(org.apache.maven.repository.internal.RemoteSnapshotMetadataTest) > Time elapsed: 0.011 sec <<< FAILURE! > java.lang.AssertionError: Expected 20151007 to be in [20151008] > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.gregorianCalendarIsUsed(RemoteSnapshotMetadataTest.java:79) > Running org.apache.maven.repository.internal.RepositorySystemTest > Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.832 sec - > in org.apache.maven.repository.internal.RepositorySystemTest > I have run maven build several times over the day and had no problems..I have > to take a deeper look into this... > I have run the build at about 11:00 o'clock am (CET) and the build is > successfulwith the exact same code state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
