[jira] [Commented] (MNG-5987) Document the algorithm calculating the order of plugin executions.
[ https://issues.apache.org/jira/browse/MNG-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819658#comment-16819658 ] miowang commented on MNG-5987: -- I've encountered the same issue, I do believe it should be documented better. here is my understanding after went through several code in maven. When a maven build triggered, maven core will resolve all of the plugins from pom and parent poms, and put them in a list For plugins binding to same phase, the execution order is base on order in the list actually. Most of the time it is same with the order user declared in his/her pom because maven core append user's plugins to the bottom of parents' plugins, while sometimes it's not. take the case below for example # user declares A, B, C, D in parent pom, all of them are binding to the same phase. # now user declares E, C, F and B in sub pom, E and F are also binding to the same phase Then the order in resolved plugin list will be A, F, B, E, C, D. *F will be executed before E.* The reason is # user can redeclare the plugins in sub pom, while maven core keeps the order they were declared in parent pom. # for any plugins declared before the re-declared plugin, maven core will put them before the re-declared plugin in resolved list More details in [https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/inheritance/DefaultInheritanceAssembler.java#L241] > Document the algorithm calculating the order of plugin executions. > -- > > Key: MNG-5987 > URL: https://issues.apache.org/jira/browse/MNG-5987 > Project: Maven > Issue Type: Improvement >Reporter: Christian Schulte >Priority: Critical > > Users continuously report issues regarding the order of plugin executions: > repeating that this order is not expected to be guaranteed inside a phase is > not convincing for them. > The algorithm used to calculate the order of executions performed by Maven > needs to be documented: > - declaration order in the POM > - inheritance merging from parent POM, > - merging of profiles and other plugin containers, > - the order of executions of multiple executions in the same lifecycle phase, > etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-surefire] Tibor17 commented on issue #230: [SUREFIRE-1432] Add extension interface with two implementations for trimStackTrace
Tibor17 commented on issue #230: [SUREFIRE-1432] Add extension interface with two implementations for trimStackTrace URL: https://github.com/apache/maven-surefire/pull/230#issuecomment-483861798 @dfa1 Now it's pushed to https://github.com/apache/maven-surefire/tree/release/3.0.0-M6 Not sure why this PR was not automatically merged and closed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #227: defaulting trimStackTrace to false
Tibor17 commented on issue #227: defaulting trimStackTrace to false URL: https://github.com/apache/maven-surefire/pull/227#issuecomment-483832682 @dfa1 Thx, you can close this PR. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Assigned] (MANTRUN-218) Upgrade JUnit to 4.12
[ https://issues.apache.org/jira/browse/MANTRUN-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MANTRUN-218: Assignee: Sylwester Lachiewicz > Upgrade JUnit to 4.12 > - > > Key: MANTRUN-218 > URL: https://issues.apache.org/jira/browse/MANTRUN-218 > Project: Maven Antrun Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Trivial > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-surefire] dfa1 commented on issue #227: defaulting trimStackTrace to false
dfa1 commented on issue #227: defaulting trimStackTrace to false URL: https://github.com/apache/maven-surefire/pull/227#issuecomment-483817748 @Tibor17 created PR https://github.com/apache/maven-surefire/pull/230 for branch release/3.0.0-M6 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] dfa1 opened a new pull request #230: [SUREFIRE-1432] Add extension interface with two implementations for trimStackTrace
dfa1 opened a new pull request #230: [SUREFIRE-1432] Add extension interface with two implementations for trimStackTrace URL: https://github.com/apache/maven-surefire/pull/230 as requested by @Tibor17 in https://github.com/apache/maven-surefire/pull/227 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MANTRUN-218) Upgrade JUnit to 4.12
[ https://issues.apache.org/jira/browse/MANTRUN-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819437#comment-16819437 ] Hudson commented on MANTRUN-218: Build failed in Jenkins: Maven TLP » maven-antrun-plugin » master #8 See https://builds.apache.org/job/maven-box/job/maven-antrun-plugin/job/master/8/ > Upgrade JUnit to 4.12 > - > > Key: MANTRUN-218 > URL: https://issues.apache.org/jira/browse/MANTRUN-218 > Project: Maven Antrun Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Trivial > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6641) NPE from AttachedArtifact.getVersion rather than meaningful error
[
https://issues.apache.org/jira/browse/MNG-6641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819412#comment-16819412
]
Dale King commented on MNG-6641:
I don't have a project I can share to reproduce it but I can tell you what
caused the validation failure to begin with. We have our own plugin that tries
to override the version coming from the POM with one that it computes based on
a number of factors. And it had these lines:
{{
project.getArtifact().setVersionRange(VersionRange.createFromVersion(version));}}
{{ project.getArtifact().setVersion(version);}}
The code for DefaultArtifact.setVersion actually nulls out the version range
that we set on the line before. The source plugin uses AttachedArtifact and
AttachedArtifact basically will not work without a version range. The
validations
[here|https://github.com/apache/maven/blob/44826ab446d1115d464e73e7e308df36dcf7d39b/maven-artifact/src/main/java/org/apache/maven/artifact/DefaultArtifact.java#L147]
check to make sure that either versionRange or version is non-null, but
because this is called from the constructor version will ALWAYS be null so the
only way to pass the validations is to have a versionRange.
We were able to fix our problem by switching from calling setVersion to calling
selectVersion which does not null out the versionRange, but the problem with
the validations throwing an NPE instead of an intelligent message is still
there.
So to summarize a reproduction would be to simply call
{{ project.getArtifact().setVersion(project.getArtifact().getVersion());}}
in a plugin and also invoke the maven-source-plugin.
> NPE from AttachedArtifact.getVersion rather than meaningful error
> -
>
> Key: MNG-6641
> URL: https://issues.apache.org/jira/browse/MNG-6641
> Project: Maven
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.6.0
> Environment: any
>Reporter: Dale King
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> This issue is basically re-reporting issue
> https://issues.apache.org/jira/browse/MNG-4731, which was closed in the great
> Jira clean up of 2014. 5 years later I can report it is still an issue.
> The issue occurs when the information passed to AttachedArtifact violates any
> of the validations in DefaultArtifact.validateIdentity(). The call to
> getVersion() will throw an NPE because it is overridable in the
> DefaultArtifact and parent has not been initialized yet in AttachedArtifact.
> MNG-4731 explains this more clearly.
> A comment on that ticket suggests that the problem is that AttachedArtifact
> was called directly instead of using MavenProjectHelper.attachArtifact().
> That is not true as can be seen from my stack trace:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.project.artifact.AttachedArtifact.getVersion
> (AttachedArtifact.java:138)
> at org.apache.maven.artifact.DefaultArtifact.validateIdentity
> (DefaultArtifact.java:149)
> at org.apache.maven.artifact.DefaultArtifact.
> (DefaultArtifact.java:124)
> at org.apache.maven.project.artifact.AttachedArtifact.
> (AttachedArtifact.java:49)
> at org.apache.maven.project.DefaultMavenProjectHelper.attachArtifact
> (DefaultMavenProjectHelper.java:63)
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources
> (AbstractSourceJarMojo.java:324)
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources
> (AbstractSourceJarMojo.java:253)
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.execute
> (AbstractSourceJarMojo.java:216)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6641) NPE from AttachedArtifact.getVersion rather than meaningful error
[
https://issues.apache.org/jira/browse/MNG-6641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6641:
Fix Version/s: waiting-for-feedback
> NPE from AttachedArtifact.getVersion rather than meaningful error
> -
>
> Key: MNG-6641
> URL: https://issues.apache.org/jira/browse/MNG-6641
> Project: Maven
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.6.0
> Environment: any
>Reporter: Dale King
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> This issue is basically re-reporting issue
> https://issues.apache.org/jira/browse/MNG-4731, which was closed in the great
> Jira clean up of 2014. 5 years later I can report it is still an issue.
> The issue occurs when the information passed to AttachedArtifact violates any
> of the validations in DefaultArtifact.validateIdentity(). The call to
> getVersion() will throw an NPE because it is overridable in the
> DefaultArtifact and parent has not been initialized yet in AttachedArtifact.
> MNG-4731 explains this more clearly.
> A comment on that ticket suggests that the problem is that AttachedArtifact
> was called directly instead of using MavenProjectHelper.attachArtifact().
> That is not true as can be seen from my stack trace:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.project.artifact.AttachedArtifact.getVersion
> (AttachedArtifact.java:138)
> at org.apache.maven.artifact.DefaultArtifact.validateIdentity
> (DefaultArtifact.java:149)
> at org.apache.maven.artifact.DefaultArtifact.
> (DefaultArtifact.java:124)
> at org.apache.maven.project.artifact.AttachedArtifact.
> (AttachedArtifact.java:49)
> at org.apache.maven.project.DefaultMavenProjectHelper.attachArtifact
> (DefaultMavenProjectHelper.java:63)
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources
> (AbstractSourceJarMojo.java:324)
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources
> (AbstractSourceJarMojo.java:253)
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.execute
> (AbstractSourceJarMojo.java:216)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6641) NPE from AttachedArtifact.getVersion rather than meaningful error
[
https://issues.apache.org/jira/browse/MNG-6641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819375#comment-16819375
]
Michael Osipov commented on MNG-6641:
-
Please provide a reproducer.
> NPE from AttachedArtifact.getVersion rather than meaningful error
> -
>
> Key: MNG-6641
> URL: https://issues.apache.org/jira/browse/MNG-6641
> Project: Maven
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.6.0
> Environment: any
>Reporter: Dale King
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> This issue is basically re-reporting issue
> https://issues.apache.org/jira/browse/MNG-4731, which was closed in the great
> Jira clean up of 2014. 5 years later I can report it is still an issue.
> The issue occurs when the information passed to AttachedArtifact violates any
> of the validations in DefaultArtifact.validateIdentity(). The call to
> getVersion() will throw an NPE because it is overridable in the
> DefaultArtifact and parent has not been initialized yet in AttachedArtifact.
> MNG-4731 explains this more clearly.
> A comment on that ticket suggests that the problem is that AttachedArtifact
> was called directly instead of using MavenProjectHelper.attachArtifact().
> That is not true as can be seen from my stack trace:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.project.artifact.AttachedArtifact.getVersion
> (AttachedArtifact.java:138)
> at org.apache.maven.artifact.DefaultArtifact.validateIdentity
> (DefaultArtifact.java:149)
> at org.apache.maven.artifact.DefaultArtifact.
> (DefaultArtifact.java:124)
> at org.apache.maven.project.artifact.AttachedArtifact.
> (AttachedArtifact.java:49)
> at org.apache.maven.project.DefaultMavenProjectHelper.attachArtifact
> (DefaultMavenProjectHelper.java:63)
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources
> (AbstractSourceJarMojo.java:324)
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources
> (AbstractSourceJarMojo.java:253)
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.execute
> (AbstractSourceJarMojo.java:216)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6644) NPE in DefaultReportingConverter when reports has no InputLocation
[
https://issues.apache.org/jira/browse/MNG-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819374#comment-16819374
]
Robert Thornton commented on MNG-6644:
--
The exception is getting thrown in DefaultReportingConverter, line 243, most
likely because the `location` variable is null when the pom is generated by a
script rather than loaded from XML.
> NPE in DefaultReportingConverter when reports has no InputLocation
> --
>
> Key: MNG-6644
> URL: https://issues.apache.org/jira/browse/MNG-6644
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Robert Thornton
>Priority: Major
> Attachments: maven-3.6.1-reporting-bug.zip
>
>
> After upgrading from Maven 3.6.0 to Maven 3.6.1, the attached project fails
> with a NullPointerException. This project uses the extension
> `io.takari.polyglot:polyglot-kotlin` in order to build the Maven project
> model using a Kotlin script.
> {code:java}
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.apache.maven.wrapper.BootstrapMainStarter.start
> (BootstrapMainStarter.java:39)
> at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:122)
> at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:55)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:243)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:213)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
> (DefaultReportingConverter.java:140)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:479)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:432)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:616)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:385)
> at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
> at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
> at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:82)
> at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> at
[jira] [Created] (MNG-6644) NPE in DefaultReportingConverter when reports has no InputLocation
Robert Thornton created MNG-6644:
Summary: NPE in DefaultReportingConverter when reports has no
InputLocation
Key: MNG-6644
URL: https://issues.apache.org/jira/browse/MNG-6644
Project: Maven
Issue Type: Bug
Affects Versions: 3.6.1
Reporter: Robert Thornton
Attachments: maven-3.6.1-reporting-bug.zip
After upgrading from Maven 3.6.0 to Maven 3.6.1, the attached project fails
with a NullPointerException. This project uses the extension
`io.takari.polyglot:polyglot-kotlin` in order to build the Maven project model
using a Kotlin script.
{code:java}
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.apache.maven.wrapper.BootstrapMainStarter.start
(BootstrapMainStarter.java:39)
at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:122)
at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:55)
Caused by: java.lang.NullPointerException
at org.apache.maven.model.plugin.DefaultReportingConverter.convert
(DefaultReportingConverter.java:243)
at org.apache.maven.model.plugin.DefaultReportingConverter.convert
(DefaultReportingConverter.java:213)
at org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
(DefaultReportingConverter.java:140)
at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:479)
at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:432)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:616)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:385)
at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
(DefaultGraphBuilder.java:414)
at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
(DefaultGraphBuilder.java:405)
at org.apache.maven.graph.DefaultGraphBuilder.build
(DefaultGraphBuilder.java:82)
at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.apache.maven.wrapper.BootstrapMainStarter.start
(BootstrapMainStarter.java:39)
at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:122)
at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:55)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-shade-plugin] mkarg commented on issue #19: [MSHADE-316] - Configuration option
mkarg commented on issue #19: [MSHADE-316] - Configuration option URL: https://github.com/apache/maven-shade-plugin/pull/19#issuecomment-483778398 All requested changes done. Please continue review. :-) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MSHARED-815) Maven Archiver: MavenArchiver.addManifestAttribute does not escape empty lines in value
[
https://issues.apache.org/jira/browse/MSHARED-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819307#comment-16819307
]
Konrad Windszus commented on MSHARED-815:
-
This is now a confirmed bug (still not fixed even in Java 13 ea) tracked in
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8222547 therefore it
would be worth to implement a workaround.
> Maven Archiver: MavenArchiver.addManifestAttribute does not escape empty
> lines in value
> ---
>
> Key: MSHARED-815
> URL: https://issues.apache.org/jira/browse/MSHARED-815
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Konrad Windszus
>Priority: Major
>
> According to
> https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#name-value-pairs-and-sections
> {quote}
> Groups of name-value pairs are known as a "section". Sections are separated
> from other sections by empty lines.
> {quote}
> Therefore empty lines in attribute values lead to invalid manifests and must
> somehow be escaped.
> As this is not done by default in {{java.util.jar.Attributes.writeMain(...)}}
> the method {{MavenArchiver.addManifestAttribute(...)}} should either throw an
> exception in case of empty lines given to parameter {{value}} or escape those
> empty lines somehow
> (https://github.com/apache/maven-archiver/blob/d454ab3fcd147c0201a14f298cc8f9e1a25ba03e/src/main/java/org/apache/maven/archiver/MavenArchiver.java#L221).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-surefire] dfa1 commented on issue #227: defaulting trimStackTrace to false
dfa1 commented on issue #227: defaulting trimStackTrace to false URL: https://github.com/apache/maven-surefire/pull/227#issuecomment-483760206 @Tibor17 it looks like I don't have permissions to push directly: ``` dfa@aman:~/projects/maven-surefire [git:release/3.0.0-M6] $ git log -1 --oneline 8a6b3345 (HEAD -> release/3.0.0-M6) [SUREFIRE-1432] Add extension interface with two implementations for trimStackTrace dfa@aman:~/projects/maven-surefire [git:release/3.0.0-M6] $ git push -v Pushing to https://github.com/apache/maven-surefire remote: Permission to apache/maven-surefire.git denied to dfa1. fatal: unable to access 'https://github.com/apache/maven-surefire/': The requested URL returned error: 403 ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MANTRUN-218) Upgrade JUnit to 4.12
Sylwester Lachiewicz created MANTRUN-218: Summary: Upgrade JUnit to 4.12 Key: MANTRUN-218 URL: https://issues.apache.org/jira/browse/MANTRUN-218 Project: Maven Antrun Plugin Issue Type: Dependency upgrade Reporter: Sylwester Lachiewicz -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6642) Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
[
https://issues.apache.org/jira/browse/MNG-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819044#comment-16819044
]
Tobias Gruetzmacher commented on MNG-6642:
--
Bisecting yields:
{code:java}
bb3ec5da71d26d105972392f0a20bc61bc5d8c53 is the first bad commit
commit bb3ec5da71d26d105972392f0a20bc61bc5d8c53
Author: Sylwester Lachiewicz
Date: Sat Oct 13 04:16:44 2018 +0200
[MNG-5995] Remove dependency to maven-compat (#185)
No implementation for deprecated Maven 2.x RepositorySystem interface
{code}
(if I didn't do anything wrong)
> Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
> --
>
> Key: MNG-6642
> URL: https://issues.apache.org/jira/browse/MNG-6642
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Francesco Chicchiriccò
>Priority: Major
>
> Build does not work with Maven 3.6.1 (works fine with Maven 3.6.0).
> How to reproduce:
> # git clone https://github.com/apache/syncope.git
> # git checkout 2_1_X
> # $M2_HOME/bin/mvn clean
> When {{M2_HOME}} points to 3.6.0, build goes fine.
> When {{M2_HOME}} points to 3.6.1, the following output is reported:
> {code}
> [INFO] Scanning for projects...
> [INFO] Computing target platform for MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] Resolving dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true,
> osgi.arch=x86}
> [ERROR] Cannot resolve project dependencies:
> [ERROR] Software being installed: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier
> [ERROR] Missing requirement: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not
> be found
> [ERROR]
> [ERROR] See
> http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
> [ERROR] Cannot resolve dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml:
> See log for details -> [Help 1]
> [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/MavenExecutionException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819040#comment-16819040
]
Hudson commented on MNG-6405:
-
Build succeeded in Jenkins: Maven TLP » maven » master #196
See https://builds.apache.org/job/maven-box/job/maven/job/master/196/
> Incorrect basedir in forked executions when using flatten-maven-plugin with
> custom outputDirectory
> --
>
> Key: MNG-6405
> URL: https://issues.apache.org/jira/browse/MNG-6405
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Jesse Glick
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
> trying to use a variant of the tip shown
> [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
> using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
> directory. This works fine in almost all cases, since the plugin calls
> {{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
> Unfortunately it fails for mojos which rely on the basedir that are run
> inside a forked execution, as I found when accidentally using {{source:jar}}
> when {{source:jar-no-fork}} was what I wanted. (Ditto when using
> {{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
> {{setFile}}, so the basedir of a cloned project is not the same as the
> original—it is always the parent directory of the POM file.
> Fixing this should be trivial
> {code}
> diff --git
> a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> index 80a51935e..ee7a68635 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
> // disown the parent
>
> // copy fields
> -setFile( project.getFile() );
> +file = project.file;
> +basedir = project.basedir;
>
> // don't need a deep copy, they don't get modified or added/removed
> to/from - but make them unmodifiable to be
> // sure!
> {code}
> but I am unsure what the best approach is to validate the fix. A unit test in
> {{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
> {{source:jar}}, and some other mojo TBD which is sensitive to project
> basedir? Both?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[ https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819037#comment-16819037 ] Tibor Digana edited comment on SUREFIRE-1546 at 4/16/19 1:52 PM: - Feel free to write the test now, but it will fail as expected. My point is to find out on how much information needs to be wrapped, transfered and logically structured, and what information makes sense for the user in terms of HTML report. The test should explore this in the outcome. was (Author: tibor17): Feel free to write the test now, but it will fail as expected now. My point is to find out on how much information needs to be wrapped, transfered and logically structured, and what information makes sense for the user in terms of HTML report. The test should explore this in the outcome. > JUnit 5 runner does not honor JUnit 5 display names > --- > > Key: SUREFIRE-1546 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1546 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Affects Versions: 2.22.0 >Reporter: Romain Manni-Bucau >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Time Spent: 20m > Remaining Estimate: 0h > > JUnit 5 runner should respect the test @DisplayName instead of displaying the > classname if any is defined. Seems last release doesn't support that feature > of JUnit 5 making the console output and reports not the expected ones. > > Origin: https://github.com/junit-team/junit5/issues/990 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[ https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819037#comment-16819037 ] Tibor Digana commented on SUREFIRE-1546: Feel free to write the test now, but it will fail as expected now. My point is to find out on how much information needs to be wrapped, transfered and logically structured, and what information makes sense for the user in terms of HTML report. The test should explore this in the outcome. > JUnit 5 runner does not honor JUnit 5 display names > --- > > Key: SUREFIRE-1546 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1546 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Affects Versions: 2.22.0 >Reporter: Romain Manni-Bucau >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Time Spent: 20m > Remaining Estimate: 0h > > JUnit 5 runner should respect the test @DisplayName instead of displaying the > classname if any is defined. Seems last release doesn't support that feature > of JUnit 5 making the console output and reports not the expected ones. > > Origin: https://github.com/junit-team/junit5/issues/990 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[ https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819036#comment-16819036 ] Tibor Digana commented on SUREFIRE-1546: [~Srdo] The issue I see is the fact that you are joing the strings via " > " and you are constructing a text which should not be customized here in this class because it is not a report. It would be better to wait untill this issue is closed for normal tests, and then open a new ticket for parameterized tests staring with writing an integration test asserting extected behavior. Of course the test should be written and pushed to a pull request where we will better check it out practically. > JUnit 5 runner does not honor JUnit 5 display names > --- > > Key: SUREFIRE-1546 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1546 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Affects Versions: 2.22.0 >Reporter: Romain Manni-Bucau >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Time Spent: 20m > Remaining Estimate: 0h > > JUnit 5 runner should respect the test @DisplayName instead of displaying the > classname if any is defined. Seems last release doesn't support that feature > of JUnit 5 making the console output and reports not the expected ones. > > Origin: https://github.com/junit-team/junit5/issues/990 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6643) Version comparison CLI does not work anymore
Benoit GUERIN created MNG-6643:
--
Summary: Version comparison CLI does not work anymore
Key: MNG-6643
URL: https://issues.apache.org/jira/browse/MNG-6643
Project: Maven
Issue Type: Bug
Components: Command Line
Affects Versions: 3.6.1
Reporter: Benoit GUERIN
Since 3.6.1, comparison CLI does not work :
{code:java}
$ java -jar apache-maven-3.6.1/lib/maven-artifact-3.6.1.jar 5.32 5.27
Display parameters as parsed by Maven (in canonical form) and comparison result:
Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/commons/lang3/StringUtils
at
org.apache.maven.artifact.versioning.ComparableVersion.stripLeadingZeroes(ComparableVersion.java:612)
at
org.apache.maven.artifact.versioning.ComparableVersion.parseItem(ComparableVersion.java:594)
at
org.apache.maven.artifact.versioning.ComparableVersion.parseVersion(ComparableVersion.java:529)
at
org.apache.maven.artifact.versioning.ComparableVersion.(ComparableVersion.java:496)
at
org.apache.maven.artifact.versioning.ComparableVersion.main(ComparableVersion.java:679)
Caused by: java.lang.ClassNotFoundException:
org.apache.commons.lang3.StringUtils
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 5 more
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-surefire] Tibor17 commented on issue #227: defaulting trimStackTrace to false
Tibor17 commented on issue #227: defaulting trimStackTrace to false URL: https://github.com/apache/maven-surefire/pull/227#issuecomment-483636097 @dfa1 Pls rebase and push it to this branch https://github.com/apache/maven-surefire/tree/release/3.0.0-M6 Thx This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Assigned] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) reassigned MNG-6405:
---
Assignee: Olivier Lamy (*$^¨%`£)
> Incorrect basedir in forked executions when using flatten-maven-plugin with
> custom outputDirectory
> --
>
> Key: MNG-6405
> URL: https://issues.apache.org/jira/browse/MNG-6405
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Jesse Glick
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
> trying to use a variant of the tip shown
> [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
> using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
> directory. This works fine in almost all cases, since the plugin calls
> {{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
> Unfortunately it fails for mojos which rely on the basedir that are run
> inside a forked execution, as I found when accidentally using {{source:jar}}
> when {{source:jar-no-fork}} was what I wanted. (Ditto when using
> {{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
> {{setFile}}, so the basedir of a cloned project is not the same as the
> original—it is always the parent directory of the POM file.
> Fixing this should be trivial
> {code}
> diff --git
> a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> index 80a51935e..ee7a68635 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
> // disown the parent
>
> // copy fields
> -setFile( project.getFile() );
> +file = project.file;
> +basedir = project.basedir;
>
> // don't need a deep copy, they don't get modified or added/removed
> to/from - but make them unmodifiable to be
> // sure!
> {code}
> but I am unsure what the best approach is to validate the fix. A unit test in
> {{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
> {{source:jar}}, and some other mojo TBD which is sensitive to project
> basedir? Both?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) resolved MNG-6405.
-
Resolution: Fixed
pr merged
> Incorrect basedir in forked executions when using flatten-maven-plugin with
> custom outputDirectory
> --
>
> Key: MNG-6405
> URL: https://issues.apache.org/jira/browse/MNG-6405
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Jesse Glick
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
> trying to use a variant of the tip shown
> [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
> using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
> directory. This works fine in almost all cases, since the plugin calls
> {{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
> Unfortunately it fails for mojos which rely on the basedir that are run
> inside a forked execution, as I found when accidentally using {{source:jar}}
> when {{source:jar-no-fork}} was what I wanted. (Ditto when using
> {{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
> {{setFile}}, so the basedir of a cloned project is not the same as the
> original—it is always the parent directory of the POM file.
> Fixing this should be trivial
> {code}
> diff --git
> a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> index 80a51935e..ee7a68635 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
> // disown the parent
>
> // copy fields
> -setFile( project.getFile() );
> +file = project.file;
> +basedir = project.basedir;
>
> // don't need a deep copy, they don't get modified or added/removed
> to/from - but make them unmodifiable to be
> // sure!
> {code}
> but I am unsure what the best approach is to validate the fix. A unit test in
> {{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
> {{source:jar}}, and some other mojo TBD which is sensitive to project
> basedir? Both?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven] olamy merged pull request #225: [MNG-6405] Fix basedir in MavenProject.deepCopy
olamy merged pull request #225: [MNG-6405] Fix basedir in MavenProject.deepCopy URL: https://github.com/apache/maven/pull/225 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MRESOLVER-7) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818910#comment-16818910 ] Hudson commented on MRESOLVER-7: Build failed in Jenkins: Maven TLP » maven-resolver » master #12 See https://builds.apache.org/job/maven-box/job/maven-resolver/job/master/12/ > Download dependency POMs in parallel > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann >Assignee: Michael Osipov >Priority: Major > Fix For: 1.4.0 > > Time Spent: 40m > Remaining Estimate: 0h > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-surefire] Tibor17 commented on issue #222: [SUREFIRE-1647] Delay load testClass, but to use myown classLoader
Tibor17 commented on issue #222: [SUREFIRE-1647] Delay load testClass, but to use myown classLoader URL: https://github.com/apache/maven-surefire/pull/222#issuecomment-483616993 @cvictory Can you check it out with the latest version `3.0.0-M3`? The parameter `classpathDependencyExcludes` works only with test classpath and not with provider classpath. But I think this is a clear solution for you in `3.0.0-M3`: ``` maven-surefire-plugin 3.0.0-M3 org.apache.maven.surefire surefire-junit-platform 3.0.0-M3 org.junit.platform junit-platform-launcher ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (MCOMPILER-355) NPE in CompilerMojo.preparePaths on exception
[
https://issues.apache.org/jira/browse/MCOMPILER-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818800#comment-16818800
]
Gregor B. Rosenauer edited comment on MCOMPILER-355 at 4/16/19 9:27 AM:
With a Java 11 project and a dependency to Stardog triple store driver, I also
ran into this issue (project worked before), using maven 3.6.1 and
maven-compile-plugin 3.8.0:
{{}}
com.complexible.stardog
stardog-api
5.3.1
{{}}
Can confirm 3.8.1 fixed the issue for me, too.
was (Author: grexe):
With a Java 11 project and a dependency to Stardog triple store driver, I also
ran into this issue (project worked before), using maven 3.6.1 and
maven-compile-plugin 3.8.0:
{{}}
com.complexible.stardog
stardog-api
5.3.1
{{}}
> NPE in CompilerMojo.preparePaths on exception
> -
>
> Key: MCOMPILER-355
> URL: https://issues.apache.org/jira/browse/MCOMPILER-355
> Project: Maven Compiler Plugin
> Issue Type: Bug
> Environment: ubunutu 18.04.
>Reporter: Brett Sutton
>Assignee: Robert Scholte
>Priority: Major
> Attachments: testpom.zip
>
>
> I'm getting:
>
> {code:java}
>
> Caused by: java.lang.NullPointerException
> at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths
> (CompilerMojo.java:244)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:787)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:188)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> {code}
>
> Appears to be caused by the exception handling assuming the 'cause' will be
> non-null:
> line 244 is:
> {code:java}
> 243 Throwable cause = pathException.getValue().getCause();
> 244 while ( cause.getCause() != null )
> 245 {
> 246 cause = cause.getCause();
> 247 }{code}
>
> Clearly in some cases pathException.getValue().getCause() is returning null.
> This occurs when I try to build a java 10 project using:
> {code:java}
> mvn deploy{code}
>
> I've narrowed the problem down to this dependancy:
> {code:java}
>
> org.javamoney
> moneta
> 1.3
> pom
> {code}
> If you remove the above dependency then the problem goes away.
> So there is likely to be two problems here. The initial NPE which should be
> easy to fix and then possibly the root cause of the exception.
> Full pom is:
> {code:java}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> au.com.noojee
> noojeebilling.api
> 1.4-SNAPSHOT
>
>
>
> src/main/java
>
>
> maven-compiler-plugin
> 3.8.0
>
> 10
>
>
>
>
>
> io.packagecloud.maven.wagon
> maven-packagecloud-wagon
> 0.0.6
>
>
>
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
>
>
>
>
> com.google.code.gson
> gson
> 2.8.5
>
>
>
> org.apache.logging.log4j
> log4j-core
> 2.9.1
>
>
>
> org.javamoney
> moneta
> 1.3
> pom
>
>
>
> org.bouncycastle
> bcprov-jdk15on
> 1.59
>
>
> junit
> junit
> 4.11
> test
>
>
>
>
> {code}
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MCOMPILER-355) NPE in CompilerMojo.preparePaths on exception
[
https://issues.apache.org/jira/browse/MCOMPILER-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818800#comment-16818800
]
Gregor B. Rosenauer edited comment on MCOMPILER-355 at 4/16/19 9:07 AM:
With a Java 11 project and a dependency to Stardog triple store driver, I also
ran into this issue (project worked before), using maven 3.6.1 and
maven-compile-plugin 3.8.0:
{{}}
com.complexible.stardog
stardog-api
5.3.1
{{}}
was (Author: grexe):
With a Java 11 project and a dependency to Stardog triple store driver, I also
ran into this issue (project worked before), using maven 3.6.1 and
maven-compile-plugin 3.8.0:
{{}}
{{ com.complexible.stardog}}
{{ stardog-api}}
{{ 5.3.1}}
{{}}
> NPE in CompilerMojo.preparePaths on exception
> -
>
> Key: MCOMPILER-355
> URL: https://issues.apache.org/jira/browse/MCOMPILER-355
> Project: Maven Compiler Plugin
> Issue Type: Bug
> Environment: ubunutu 18.04.
>Reporter: Brett Sutton
>Assignee: Robert Scholte
>Priority: Major
> Attachments: testpom.zip
>
>
> I'm getting:
>
> {code:java}
>
> Caused by: java.lang.NullPointerException
> at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths
> (CompilerMojo.java:244)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:787)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:188)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> {code}
>
> Appears to be caused by the exception handling assuming the 'cause' will be
> non-null:
> line 244 is:
> {code:java}
> 243 Throwable cause = pathException.getValue().getCause();
> 244 while ( cause.getCause() != null )
> 245 {
> 246 cause = cause.getCause();
> 247 }{code}
>
> Clearly in some cases pathException.getValue().getCause() is returning null.
> This occurs when I try to build a java 10 project using:
> {code:java}
> mvn deploy{code}
>
> I've narrowed the problem down to this dependancy:
> {code:java}
>
> org.javamoney
> moneta
> 1.3
> pom
> {code}
> If you remove the above dependency then the problem goes away.
> So there is likely to be two problems here. The initial NPE which should be
> easy to fix and then possibly the root cause of the exception.
> Full pom is:
> {code:java}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> au.com.noojee
> noojeebilling.api
> 1.4-SNAPSHOT
>
>
>
> src/main/java
>
>
> maven-compiler-plugin
> 3.8.0
>
> 10
>
>
>
>
>
> io.packagecloud.maven.wagon
> maven-packagecloud-wagon
> 0.0.6
>
>
>
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
>
>
>
>
> com.google.code.gson
> gson
> 2.8.5
>
>
>
> org.apache.logging.log4j
> log4j-core
> 2.9.1
>
>
>
> org.javamoney
> moneta
> 1.3
> pom
>
>
>
> org.bouncycastle
> bcprov-jdk15on
> 1.59
>
>
> junit
> junit
> 4.11
> test
>
>
>
>
> {code}
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-355) NPE in CompilerMojo.preparePaths on exception
[
https://issues.apache.org/jira/browse/MCOMPILER-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818800#comment-16818800
]
Gregor B. Rosenauer commented on MCOMPILER-355:
---
With a Java 11 project and a dependency to Stardog triple store driver, I also
ran into this issue (project worked before), using maven 3.6.1 and
maven-compile-plugin 3.8.0:
{{}}
{{ com.complexible.stardog}}
{{ stardog-api}}
{{ 5.3.1}}
{{}}
> NPE in CompilerMojo.preparePaths on exception
> -
>
> Key: MCOMPILER-355
> URL: https://issues.apache.org/jira/browse/MCOMPILER-355
> Project: Maven Compiler Plugin
> Issue Type: Bug
> Environment: ubunutu 18.04.
>Reporter: Brett Sutton
>Assignee: Robert Scholte
>Priority: Major
> Attachments: testpom.zip
>
>
> I'm getting:
>
> {code:java}
>
> Caused by: java.lang.NullPointerException
> at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths
> (CompilerMojo.java:244)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:787)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:188)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> {code}
>
> Appears to be caused by the exception handling assuming the 'cause' will be
> non-null:
> line 244 is:
> {code:java}
> 243 Throwable cause = pathException.getValue().getCause();
> 244 while ( cause.getCause() != null )
> 245 {
> 246 cause = cause.getCause();
> 247 }{code}
>
> Clearly in some cases pathException.getValue().getCause() is returning null.
> This occurs when I try to build a java 10 project using:
> {code:java}
> mvn deploy{code}
>
> I've narrowed the problem down to this dependancy:
> {code:java}
>
> org.javamoney
> moneta
> 1.3
> pom
> {code}
> If you remove the above dependency then the problem goes away.
> So there is likely to be two problems here. The initial NPE which should be
> easy to fix and then possibly the root cause of the exception.
> Full pom is:
> {code:java}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> au.com.noojee
> noojeebilling.api
> 1.4-SNAPSHOT
>
>
>
> src/main/java
>
>
> maven-compiler-plugin
> 3.8.0
>
> 10
>
>
>
>
>
> io.packagecloud.maven.wagon
> maven-packagecloud-wagon
> 0.0.6
>
>
>
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
> noojee-internal
> packagecloud+https://packagecloud.io/noojee/internal
>
>
>
>
>
>
> com.google.code.gson
> gson
> 2.8.5
>
>
>
> org.apache.logging.log4j
> log4j-core
> 2.9.1
>
>
>
> org.javamoney
> moneta
> 1.3
> pom
>
>
>
> org.bouncycastle
> bcprov-jdk15on
> 1.59
>
>
> junit
> junit
> 4.11
> test
>
>
>
>
> {code}
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MCHECKSTYLE-373) Checkstyle version as properties
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Moittie updated MCHECKSTYLE-373:
Description:
Hi,
As we can see in your documentation, the only way to choose specific checkstyle
version is to modify the pom.xml.
So it will be nice to have a property to manage this in command line.
Example :
{code:java}
-Dcheckstyle-version=8.18{code}
So, from QA point of view, we can manage checkstyle version over all our java
projects, and there is no need to change project specific settings which are
still pom file.
was:
Hi,
As we can see in your documentation, the only way to choose specific checkstyle
version is to modify the pom.xml. So, from QA point of view, we can manage
checkstyle version over all our java projects, and there is no need to change
project specific settings which are still pom file.
So it will be nice to have a property to manage this in command line.
> Checkstyle version as properties
>
>
> Key: MCHECKSTYLE-373
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-373
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
> Components: checkstyle:checkstyle
>Affects Versions: 3.0.0
>Reporter: Vincent Moittie
>Priority: Major
>
> Hi,
>
> As we can see in your documentation, the only way to choose specific
> checkstyle version is to modify the pom.xml.
> So it will be nice to have a property to manage this in command line.
> Example :
> {code:java}
> -Dcheckstyle-version=8.18{code}
> So, from QA point of view, we can manage checkstyle version over all our java
> projects, and there is no need to change project specific settings which are
> still pom file.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MCHECKSTYLE-373) Checkstyle version as properties
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Moittie updated MCHECKSTYLE-373: Component/s: (was: predefined ruleset: Maven ) checkstyle:checkstyle > Checkstyle version as properties > > > Key: MCHECKSTYLE-373 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-373 > Project: Maven Checkstyle Plugin > Issue Type: Improvement > Components: checkstyle:checkstyle >Affects Versions: 3.0.0 >Reporter: Vincent Moittie >Priority: Major > > Hi, > > As we can see in your documentation, the only way to choose specific > checkstyle version is to modify the pom.xml. So, from QA point of view, we > can manage checkstyle version over all our java projects, and there is no > need to change project specific settings which are still pom file. > > So it will be nice to have a property to manage this in command line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MCHECKSTYLE-373) Checkstyle version as properties
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Moittie updated MCHECKSTYLE-373: Description: Hi, As we can see in your documentation, the only way to choose specific checkstyle version is to modify the pom.xml. So, from QA point of view, we can manage checkstyle version over all our java projects, and there is no need to change project specific settings which are still pom file. So it will be nice to have a property to manage this in command line. was: Hi, As we can see in your documentation, the only goals to choose specific checkstyle version is to modify the pom.xml. So, from QA point of view, we can manage checkstyle version over all our java projects, and there is no need to change project specific settings which are still pom file. So it will be nice to have a property to manage this in command line. > Checkstyle version as properties > > > Key: MCHECKSTYLE-373 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-373 > Project: Maven Checkstyle Plugin > Issue Type: Improvement > Components: predefined ruleset: Maven >Affects Versions: 3.0.0 >Reporter: Vincent Moittie >Priority: Major > > Hi, > > As we can see in your documentation, the only way to choose specific > checkstyle version is to modify the pom.xml. So, from QA point of view, we > can manage checkstyle version over all our java projects, and there is no > need to change project specific settings which are still pom file. > > So it will be nice to have a property to manage this in command line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MCHECKSTYLE-373) Checkstyle version as properties
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Moittie updated MCHECKSTYLE-373: Affects Version/s: 3.0.0 > Checkstyle version as properties > > > Key: MCHECKSTYLE-373 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-373 > Project: Maven Checkstyle Plugin > Issue Type: Improvement > Components: predefined ruleset: Maven >Affects Versions: 3.0.0 >Reporter: Vincent Moittie >Priority: Major > > Hi, > > As we can see in your documentation, the only goals to choose specific > checkstyle version is to modify the pom.xml. So, from QA point of view, we > can manage checkstyle version over all our java projects, and there is no > need to change project specific settings which are still pom file. > > So it will be nice to have a property to manage this in command line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MCHECKSTYLE-373) Checkstyle version as properties
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Moittie updated MCHECKSTYLE-373: Labels: a (was: ) > Checkstyle version as properties > > > Key: MCHECKSTYLE-373 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-373 > Project: Maven Checkstyle Plugin > Issue Type: Improvement > Components: predefined ruleset: Maven >Reporter: Vincent Moittie >Priority: Major > Labels: a > > Hi, > > As we can see in your documentation, the only goals to choose specific > checkstyle version is to modify the pom.xml. So, from QA point of view, we > can manage checkstyle version over all our java projects, and there is no > need to change project specific settings which are still pom file. > > So it will be nice to have a property to manage this in command line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MCHECKSTYLE-373) Checkstyle version as properties
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Moittie updated MCHECKSTYLE-373: Labels: (was: a) > Checkstyle version as properties > > > Key: MCHECKSTYLE-373 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-373 > Project: Maven Checkstyle Plugin > Issue Type: Improvement > Components: predefined ruleset: Maven >Reporter: Vincent Moittie >Priority: Major > > Hi, > > As we can see in your documentation, the only goals to choose specific > checkstyle version is to modify the pom.xml. So, from QA point of view, we > can manage checkstyle version over all our java projects, and there is no > need to change project specific settings which are still pom file. > > So it will be nice to have a property to manage this in command line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MCHECKSTYLE-373) Checkstyle version as properties
Vincent Moittie created MCHECKSTYLE-373: --- Summary: Checkstyle version as properties Key: MCHECKSTYLE-373 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-373 Project: Maven Checkstyle Plugin Issue Type: Improvement Components: predefined ruleset: Maven Reporter: Vincent Moittie Hi, As we can see in your documentation, the only goals to choose specific checkstyle version is to modify the pom.xml. So, from QA point of view, we can manage checkstyle version over all our java projects, and there is no need to change project specific settings which are still pom file. So it will be nice to have a property to manage this in command line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven] oehme edited a comment on issue #242: Speed up project discovery
oehme edited a comment on issue #242: Speed up project discovery URL: https://github.com/apache/maven/pull/242#issuecomment-481618896 Project discovery on the project took ~5min before, now down to ~2.5min. Still a long way to go, but a good improvement :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MNG-6642) Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
Francesco Chicchiriccò created MNG-6642:
---
Summary: Tycho-based modules do not build with 3.6.1 (works with
3.6.0)
Key: MNG-6642
URL: https://issues.apache.org/jira/browse/MNG-6642
Project: Maven
Issue Type: Bug
Affects Versions: 3.6.1
Reporter: Francesco Chicchiriccò
Build does not work with Maven 3.6.1 (works fine with Maven 3.6.0).
How to reproduce:
# git clone https://github.com/apache/syncope.git
# git checkout 2_1_X
# $M2_HOME/bin/mvn clean
When {{M2_HOME}} points to 3.6.0, build goes fine.
When {{M2_HOME}} points to 3.6.1, the following output is reported:
{code}
[INFO] Scanning for projects...
[INFO] Computing target platform for MavenProject:
org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
@
/home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
[INFO] Resolving dependencies of MavenProject:
org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
@
/home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
[INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true,
osgi.arch=x86}
[ERROR] Cannot resolve project dependencies:
[ERROR] Software being installed: org.apache.syncope.ide.eclipse.plugin
2.1.4.qualifier
[ERROR] Missing requirement: org.apache.syncope.ide.eclipse.plugin
2.1.4.qualifier requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not
be found
[ERROR]
[ERROR] See http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting
for help.
[ERROR] Cannot resolve dependencies of MavenProject:
org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
@
/home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml:
See log for details -> [Help 1]
[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/MavenExecutionException
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
