[jira] [Comment Edited] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329702#comment-16329702 ] David Churcher edited comment on MNG-6311 at 1/18/18 2:56 AM: -- It's a bit tricky to share more details as we don't own the source for most of it, and a lot of the project hierarchy is inside dependencies that we don't have any source for. I've attached some anonymised output of the hierarchy-maven-plugin – [https://github.com/ExampleDriven/hierarchy-maven-plugin] – which should give some idea of the scope of the parent POM problem. I will try to script the creation of a similar project. Interestingly when I build the whole project from top down I don't get the performance problem, it is only when I build the integration test project (as in the above hierarchy file) that has low-level dependencies and has to work its way up the dependency tree. I am running Maven from the command line, with -Xmx4000M. was (Author: dchr): It's a bit tricky to share more details as we don't own the source for most of it, and a lot of the project hierarchy is inside dependencies that we don't have any source for. I've attached some anonymised output of the hierarchy-maven-plugin – [https://github.com/ExampleDriven/hierarchy-maven-plugin] – which should give some idea of the scope of the parent POM problem. I will try to script the creation of a similar project. Interestingly when I build the whole project from top down I don't get the performance problem, it is only when I build the integration test project (as in the above hierarchy file) that has low-level dependencies and has to work its way up the dependency tree. I am running Maven from the command line, with -XmX4000M. > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Priority: Major > Labels: performance > Attachments: anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-4917) Profile not active even though it has activeByDefault set to true
[ https://issues.apache.org/jira/browse/MNG-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329800#comment-16329800 ] Joel Croteau commented on MNG-4917: --- This is an incredibly inane design choice. It makes `activeByDefault` very unpredictable, creating side effects in potentially totally unrelated areas of the POM, and has the potential to allow for some very hard to diagnose bugs in POM files. Please fix this or give us another option. > Profile not active even though it has activeByDefault set to true > - > > Key: MNG-4917 > URL: https://issues.apache.org/jira/browse/MNG-4917 > Project: Maven > Issue Type: Bug > Components: Profiles >Affects Versions: 3.0 >Reporter: Benson Margulies >Assignee: Benjamin Bentmann >Priority: Major > Attachments: pom.xml > > > I've got a parent pom with a profile with > true. > You can retrieve it for yourself via git clone > git://git.apache.org/webservices-xmlschema.git. > The problem is the sourcecheck profile in the parent pom. > running mvn -Psourcecheck works as expected, but running without the -P fails > to activate the profile. > the help plugin, I think, has separate problems in this area, or perhaps it's > not supposed to look at -P? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329702#comment-16329702 ] David Churcher edited comment on MNG-6311 at 1/17/18 11:47 PM: --- It's a bit tricky to share more details as we don't own the source for most of it, and a lot of the project hierarchy is inside dependencies that we don't have any source for. I've attached some anonymised output of the hierarchy-maven-plugin – [https://github.com/ExampleDriven/hierarchy-maven-plugin] – which should give some idea of the scope of the parent POM problem. I will try to script the creation of a similar project. Interestingly when I build the whole project from top down I don't get the performance problem, it is only when I build the integration test project (as in the above hierarchy file) that has low-level dependencies and has to work its way up the dependency tree. I am running Maven from the command line, with -XmX4000M. was (Author: dchr): It's a bit tricky to share more details as we don't own the source for most of it, and a lot of the project hierarchy is inside dependencies that we don't have any source for. I've attached some anonymised output of the hierarchy-maven-plugin – [https://github.com/ExampleDriven/hierarchy-maven-plugin] – which should give some idea of the scope of the parent POM problem. I will try to script the creation of a similar project. Interestingly when I build the whole project from top down I don't get the performance problem, it is only when I build the integration test project (as in the above hierarchy file) that has low-level dependencies and has to work its way up the dependency tree. > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Priority: Major > Labels: performance > Attachments: anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329702#comment-16329702 ] David Churcher edited comment on MNG-6311 at 1/17/18 11:45 PM: --- It's a bit tricky to share more details as we don't own the source for most of it, and a lot of the project hierarchy is inside dependencies that we don't have any source for. I've attached some anonymised output of the hierarchy-maven-plugin – [https://github.com/ExampleDriven/hierarchy-maven-plugin] – which should give some idea of the scope of the parent POM problem. I will try to script the creation of a similar project. Interestingly when I build the whole project from top down I don't get the performance problem, it is only when I build the integration test project (as in the above hierarchy file) that has low-level dependencies and has to work its way up the dependency tree. was (Author: dchr): It's a bit tricky to share more details as we don't own the source for most of it, and a lot of the project hierarchy is inside dependencies that we don't have any source for. I've attached some anonymised output of the hierarchy-maven-plugin - [https://github.com/ExampleDriven/hierarchy-maven-plugin|https://github.com/ExampleDriven/hierarchy-maven-plugin)] - which should give some idea of the scope of the parent POM problem. I will try to script the creation of a similar project. Interestingly when I build the whole project from top down I don't get the performance problem, it is only when I build the integration test project (as in the above hierarchy file) that has low-level dependencies and has to work its way up the dependency tree. > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Priority: Major > Labels: performance > Attachments: anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329702#comment-16329702 ] David Churcher commented on MNG-6311: - It's a bit tricky to share more details as we don't own the source for most of it, and a lot of the project hierarchy is inside dependencies that we don't have any source for. I've attached some anonymised output of the hierarchy-maven-plugin - [https://github.com/ExampleDriven/hierarchy-maven-plugin|https://github.com/ExampleDriven/hierarchy-maven-plugin)] - which should give some idea of the scope of the parent POM problem. I will try to script the creation of a similar project. Interestingly when I build the whole project from top down I don't get the performance problem, it is only when I build the integration test project (as in the above hierarchy file) that has low-level dependencies and has to work its way up the dependency tree. > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Priority: Major > Labels: performance > Attachments: anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Churcher updated MNG-6311: Attachment: anon-hierarchy-maven-output.zip > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Priority: Major > Labels: performance > Attachments: anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJLINK-9) Add support for multi module projects
Vladimir Tsanev created MJLINK-9:
Summary: Add support for multi module projects
Key: MJLINK-9
URL: https://issues.apache.org/jira/browse/MJLINK-9
Project: Maven JLink Plugin
Issue Type: New Feature
Affects Versions: 3.0.0-alpha-1
Reporter: Vladimir Tsanev
I would like to have a multi module project something like
{code:java}
parent
lib
pom.xml
app
pom.xml
dist
pom.xml{code}
where app is my application module that depends on a lib module and dist is a
jlink module that depends on app.
Currently I see a NPE because it cannot find app's jar. Seems like jars from
reactor are not resolved
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink (default-jlink)
on project dist: Execution default-jlink of goal
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.:
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink (default-jlink)
on project dist: Execution default-jlink of goal
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
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:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-jlink of goal
org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:145)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
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:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at
[jira] [Created] (MRESOLVER-40) Migrate examples to use java annotations
Sylwester Lachiewicz created MRESOLVER-40: - Summary: Migrate examples to use java annotations Key: MRESOLVER-40 URL: https://issues.apache.org/jira/browse/MRESOLVER-40 Project: Maven Resolver Issue Type: Improvement Reporter: Sylwester Lachiewicz Migrate examples from javadoc to java 5 annotations in _maven-resolver-demo-maven-plugin_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEP-578) Add message in case module name cannot be extracted from jar.
[ https://issues.apache.org/jira/browse/MDEP-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329560#comment-16329560 ] Hudson commented on MDEP-578: - Build succeeded in Jenkins: Maven TLP » maven-dependency-plugin » master #2 See https://builds.apache.org/job/maven-box/job/maven-dependency-plugin/job/master/2/ > Add message in case module name cannot be extracted from jar. > - > > Key: MDEP-578 > URL: https://issues.apache.org/jira/browse/MDEP-578 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: resolve >Affects Versions: 3.0.1 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.2 > > > The following jars are just some examples where Java 9 cannot give an > automatic module name: > || jar || root cause || > | geronimo-servlet_2.4_spec-1.1.1.jar | geronimo.servlet.2.4.spec: Invalid > module name: '2' is not a Java identifier | > | jdom-1.0.jar | JDOMAbout$Author.class found in top-level directory (unnamed > package not allowed in module) | > | geronimo-jta_1.1_spec-1.1.jar | geronimo.jta.1.1.spec: Invalid module name: > '1' is not a Java identifier | > Who would have expected that reason for jdom? A message would help a lot > (even though in the end it means you can still not refer to it) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329558#comment-16329558
]
David M. Lloyd commented on MCOMPILER-320:
--
Thanks for the feedback. A new "compile-only" scope would definitely be good
but it would not solve either of my two present immediate use cases.
Case 1 is that if you build a project in Java 9, and use {{--release=8}} (i.e.
{{8}}) then the sun.misc and sun.reflect packages are not
included in the class path. They must be stubbed, however you absolutely do
_not_ want to have the stubs appear in _any_ context other than the exact
compilation, otherwise severe problems will occur: the JVM could even crash. A
new scope _almost_ solves this, but not quite, because you might only want to
include the stub in one execution. What if you have more than one? Which
brings us to case 2.
Case 2 is that currently the best way of building an MR JAR can be done by way
of multiple executions. But in order to do this, the overlay executions must
include, on the class path, each earlier execution's output classes.
Here's an example of both cases being done at once; this is using a version of
the plugin which contains my proposed patch:
{code:xml}
maven-compiler-plugin
3.7.1-SNAPSHOT
default-compile
none
compile-java8
compile
compile
8
${project.build.directory}
${project.compileSourceRoots}
${project.build.outputDirectory}
${project.build.directory}/sun-misc.jar
compile-java9
compile
compile
9
${project.build.directory}
${project.basedir}/src/main/java9
${project.build.directory}/classes/META-INF/versions/9
${project.build.outputDirectory}
maven-dependency-plugin
fetch-misc
generate-sources
get
copy
org.jboss:sun-misc:1.Final-SNAPSHOT
${project.build.directory}
true
{code}
This makes use of several basic defining features of Maven: the ability to have
multiple executions, the usage of maven-dependency-plugin to fetch dependencies
by way of specific goals, etc.
The only missing piece is the ability to add class path entries.
I am enormously skeptical that a practical high-level solution to MR JARs will
appear in Maven _ever_. Even if I was wrong and it would happen, I am
extremely confident that it would be inadequate for any non-trivial case, and
furthermore, as a maintainer of many frameworks, I contend that most any case
where a framework _would_ require MR JARs would be a non-trivial case. This is
due to the fact that some of the key APIs that are motivating factors in
producing MR JARs - namely sun.misc.Unsafe and sun.reflect.ReflectionFactory -
have to be specially handled in the way that I have done above. It is unlikely
that a single compiler plugin pass, no matter how enhanced, would be able to
cope with this situation, nor would it be able to cope with any other situation
where different layers of the JAR would require different compiler parameters -
a situation that seems inevitable to me. I don't think there is a better
solution to MR JAR than the one I've worked up in this example.
We could maintain our own fork of this plugin, but that would be a bit
ridiculous: nothing in this proposed change opposes what I would call a
rational interpretation of the spirit of Maven's design, or of the design of
javac.
> Allow additional class path items to be
[jira] [Commented] (MRELEASE-973) Please keep the property performRelease or provide an alternativ for it
[
https://issues.apache.org/jira/browse/MRELEASE-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329453#comment-16329453
]
Robert Scholte commented on MRELEASE-973:
-
How about adding the parameter {{}}, where you can specify 1
or more profile ids used during the release?
> Please keep the property performRelease or provide an alternativ for it
> ---
>
> Key: MRELEASE-973
> URL: https://issues.apache.org/jira/browse/MRELEASE-973
> Project: Maven Release Plugin
> Issue Type: Wish
> Components: perform
>Affects Versions: 3.0.0
>Reporter: Oliver B. Fischer
>Priority: Critical
> Labels: compatibility, feature
> Fix For: 3.0.0
>
>
> MRELEASE-896 deprecates the {{useReleaseProfile}} and changed its default
> value from {{true}} to {{false}}.
> Unfortunately this disabled also the setting of the property
> {{performRelease}} which we use to enable multiple profiles during the
> release process.
> At least we need a possibility to enable multiple, sometimes different,
> profiles during a release and its preparation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSITE-709) relativizeDecorationLinks=false seems to be ignored
[ https://issues.apache.org/jira/browse/MSITE-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329442#comment-16329442 ] Mark Haseltine commented on MSITE-709: -- It seems the problem is in the fact that the parent link is coded to always relativize the link, regardless of the site plugin settings. We have a situation where this is problematic because we move the entire generated site folder around to maintain the "latest" site for a particular project. When we do that move, the relative links to the parent sites are broken. Would it be possible to make the parent link respect the relativize option? > relativizeDecorationLinks=false seems to be ignored > --- > > Key: MSITE-709 > URL: https://issues.apache.org/jira/browse/MSITE-709 > Project: Maven Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 3.3 >Reporter: Archimedes Trajano >Priority: Major > Attachments: MSITE-709.diff > > > I am trying to prevent the site plugin from using the "incorrectly > implemented" pathutils and use the links I have put in myself. However, > setting relativizeDecorationLinks=false seems to have no effect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329312#comment-16329312
]
Robert Scholte commented on MCOMPILER-320:
--
Hi David,
I think it would already help if there was an example attached to better
understand what you're trying to achieve (and which we can translate to an
integration test).
My first concern is that you will loose control over the order of the
classpath. I'd prefer to see a solution where the issue is solved with
dependencies, which might require a new scope.
In the end a dependency is just a reference to a file, like all entries on the
classpath, so I would expect there's a more elegant way to solve this.
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MPMD-251) Invalid report XML is generated with includeXmlInSite=true
Andreas Dangel created MPMD-251: --- Summary: Invalid report XML is generated with includeXmlInSite=true Key: MPMD-251 URL: https://issues.apache.org/jira/browse/MPMD-251 Project: Maven PMD Plugin Issue Type: Bug Components: CPD, PMD Reporter: Andreas Dangel Assignee: Andreas Dangel Fix For: 3.9.0 See: [https://github.com/apache/maven-plugins/pull/127] When the property [includeXmlInSite|https://maven.apache.org/plugins/maven-pmd-plugin/pmd-mojo.html#includeXmlInSite] is true, then the generated pmd.xml file in the site output directory is invalid (it's missing the closing tag). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNGSITE-312) "Using Your Own Manifest File" link is broken
[ https://issues.apache.org/jira/browse/MNGSITE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNGSITE-312. --- Resolution: Fixed Assignee: Karl Heinz Marbaise has been fixed in the meantime. > "Using Your Own Manifest File" link is broken > - > > Key: MNGSITE-312 > URL: https://issues.apache.org/jira/browse/MNGSITE-312 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Linmao Song >Assignee: Karl Heinz Marbaise >Priority: Major > > The link to "Using Your Own Manifest File" from page > https://maven.apache.org/plugins/maven-jar-plugin/index.html appears broken. > The link's URL is > https://maven.apache.org/plugins/maven-jar-plugin/shared/maven-archiver/examples/manifestFile.html > . Currently it redirects to "Not Found". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNGSITE-321) Replace "clean install" with "verify" as much as possible
[
https://issues.apache.org/jira/browse/MNGSITE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNGSITE-321.
---
Resolution: Fixed
Seemed to be fixed on the referenced page.
> Replace "clean install" with "verify" as much as possible
> --
>
> Key: MNGSITE-321
> URL: https://issues.apache.org/jira/browse/MNGSITE-321
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>
> I'm trying to learn everybody that they should run {{mvn verify}} instead of
> {{mvn clean install}} and why that is better. Kind of embarrassing I still
> see it on our pages, e.g.
> https://maven.apache.org/run-maven/index.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNGSITE-205) http://maven.apache.org/pom.html TOC is broken.
[ https://issues.apache.org/jira/browse/MNGSITE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNGSITE-205. --- Resolution: Fixed Assignee: Karl Heinz Marbaise > http://maven.apache.org/pom.html TOC is broken. > --- > > Key: MNGSITE-205 > URL: https://issues.apache.org/jira/browse/MNGSITE-205 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Critical > > The pom reference page's toc is currently broken. > Unfortunately the markdown currently seemed not to be working correctly. > I've made serveral tries to fix the issue but was not sucessful. > After seeking into it i found the following: > https://github.com/sirthias/pegdown/issues/123 > which looks we need to wait until it's fixed or we need switch back to apt > for the transition time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MDEP-596) Need ability to ignore test artifacts or named artifacts in analyze-dep-mgt mojo
[ https://issues.apache.org/jira/browse/MDEP-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MDEP-596: - Component/s: analyze-dep-mgt > Need ability to ignore test artifacts or named artifacts in analyze-dep-mgt > mojo > > > Key: MDEP-596 > URL: https://issues.apache.org/jira/browse/MDEP-596 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: analyze, analyze-dep-mgt >Reporter: Keshava Bhat >Priority: Major > > Today there is not way to configure to ignore non compile scoped artefacts > (*[ignoreNonCompile|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoreNonCompile])* > / certain ignored artifacts > (*[ignoredDependencies|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredDependencies] > )* out of analyze-dep-mgt mojo. > > it would be very sueful to ignore test scoped artifacts or certain enlisted > artifacts to be ignored out of analyze-dep-mgt mojo. > other mojos like analyze / analyze-olnly provide this support. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEP-596) Need ability to ignore test artifacts or named artifacts in analyze-dep-mgt mojo
[ https://issues.apache.org/jira/browse/MDEP-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329132#comment-16329132 ] Karl Heinz Marbaise commented on MDEP-596: -- I have move this issue to the correct location: maven-dependency-plugin area. > Need ability to ignore test artifacts or named artifacts in analyze-dep-mgt > mojo > > > Key: MDEP-596 > URL: https://issues.apache.org/jira/browse/MDEP-596 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: analyze, analyze-dep-mgt >Reporter: Keshava Bhat >Priority: Major > > Today there is not way to configure to ignore non compile scoped artefacts > (*[ignoreNonCompile|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoreNonCompile])* > / certain ignored artifacts > (*[ignoredDependencies|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredDependencies] > )* out of analyze-dep-mgt mojo. > > it would be very sueful to ignore test scoped artifacts or certain enlisted > artifacts to be ignored out of analyze-dep-mgt mojo. > other mojos like analyze / analyze-olnly provide this support. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Moved] (MDEP-596) Need ability to ignore test artifacts or named artifacts in analyze-dep-mgt mojo
[ https://issues.apache.org/jira/browse/MDEP-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise moved MNG-6341 to MDEP-596: --- Component/s: (was: Dependencies) analyze Key: MDEP-596 (was: MNG-6341) Project: Maven Dependency Plugin (was: Maven) > Need ability to ignore test artifacts or named artifacts in analyze-dep-mgt > mojo > > > Key: MDEP-596 > URL: https://issues.apache.org/jira/browse/MDEP-596 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: analyze >Reporter: Keshava Bhat >Priority: Major > > Today there is not way to configure to ignore non compile scoped artefacts > (*[ignoreNonCompile|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoreNonCompile])* > / certain ignored artifacts > (*[ignoredDependencies|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredDependencies] > )* out of analyze-dep-mgt mojo. > > it would be very sueful to ignore test scoped artifacts or certain enlisted > artifacts to be ignored out of analyze-dep-mgt mojo. > other mojos like analyze / analyze-olnly provide this support. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329124#comment-16329124
]
David M. Lloyd commented on MCOMPILER-320:
--
https://github.com/apache/maven-compiler-plugin/pull/1
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329120#comment-16329120
]
ASF GitHub Bot commented on MCOMPILER-320:
--
dmlloyd opened a new pull request #1: [MCOMPILER-320] Introduce
additionalCompilePathItems property
URL: https://github.com/apache/maven-compiler-plugin/pull/1
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] dmlloyd opened a new pull request #1: [MCOMPILER-320] Introduce additionalCompilePathItems property
dmlloyd opened a new pull request #1: [MCOMPILER-320] Introduce additionalCompilePathItems property URL: https://github.com/apache/maven-compiler-plugin/pull/1 This is an automated message from the Apache Git Service. To respond to the message, please log on 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] (MCOMPILER-320) Allow additional class path items to be given during compilation
David M. Lloyd created MCOMPILER-320:
Summary: Allow additional class path items to be given during
compilation
Key: MCOMPILER-320
URL: https://issues.apache.org/jira/browse/MCOMPILER-320
Project: Maven Compiler Plugin
Issue Type: New Feature
Reporter: David M. Lloyd
At present it is very difficult to include additional class path items during
compilation that are not dependencies. But this is a very useful capability,
especially when doing partial builds, MR JARs, JDK API stubbing, including
dependency items that cannot be included in any other build phase or execution,
etc.
This enhancement and pull request are to request the addition of a
{{additionalCompilePathItems}} property in CompilerMojo or AbstractCompilerMojo
which includes additional filesystem paths in the compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SUREFIRE-1465) Building with Maven 3.5.2 and Java 10 EA+38 gives an NPE
Gary Gregory created SUREFIRE-1465:
--
Summary: Building with Maven 3.5.2 and Java 10 EA+38 gives an NPE
Key: SUREFIRE-1465
URL: https://issues.apache.org/jira/browse/SUREFIRE-1465
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Surefire Plugin
Affects Versions: 2.20.1
Environment:
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
2017-10-18T01:58:13-06:00)
Maven home: C:\Java\apache-maven-3.5.2\bin\..
Java version: 10-ea, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk-10
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
java version "10-ea" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10-ea+38)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10-ea+38, mixed mode)
Reporter: Gary Gregory
Building with Maven 3.5.2 and Java 10 EA+38 gives an NPE:
This is the build for Apache HttpClient 5.0 BETA 1.
The problems is likely an old version of Apache Commons Lang being shaded in
the plugin. The POM shows version 3.5. The current version is 3.7.
{noformat}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache HttpComponents Client Parent SUCCESS [ 5.829 s]
[INFO] Apache HttpClient .. FAILURE [ 21.043 s]
[INFO] Apache HttpClient Fluent ... SKIPPED
[INFO] Apache HttpClient Cache SKIPPED
[INFO] Apache HttpClient Windows features . SKIPPED
[INFO] Apache HttpClient Integration Tests SKIPPED
[INFO] Apache HttpClient OSGi bundle .. SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 28.325 s
[INFO] Finished at: 2018-01-17T10:19:24-07:00
[INFO] Final Memory: 33M/117M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on
project httpclient5: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.:
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on
project httpclient5: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
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:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test
failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:145)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
[jira] [Created] (MASSEMBLY-874) maven-assembly plugin always downloads dependencies from net
Roland Schäuble created MASSEMBLY-874: - Summary: maven-assembly plugin always downloads dependencies from net Key: MASSEMBLY-874 URL: https://issues.apache.org/jira/browse/MASSEMBLY-874 Project: Maven Assembly Plugin Issue Type: Improvement Affects Versions: 3.1.0 Environment: Multi-Module build Reporter: Roland Schäuble Attachments: make.log The maven-assembly-plugin always loads it own dependencies from the internet, although the required dependencies are available in the local m2 repositiory. The local repository is updated with the dependencies but during the next build, the files are downloaded from the internet again instead of getting them from the local repo. In the attached log, near the end, the unnecessary downloads begin with "Downloading from central: [https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.;|https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.] The files are definitely available in my local repository under ~/.m2/repository/com/... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6341) Need ability to ignore test artifacts or named artifacts in analyze-dep-mgt mojo
Keshava Bhat created MNG-6341: - Summary: Need ability to ignore test artifacts or named artifacts in analyze-dep-mgt mojo Key: MNG-6341 URL: https://issues.apache.org/jira/browse/MNG-6341 Project: Maven Issue Type: Improvement Components: Dependencies Reporter: Keshava Bhat Today there is not way to configure to ignore non compile scoped artefacts (*[ignoreNonCompile|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoreNonCompile])* / certain ignored artifacts (*[ignoredDependencies|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredDependencies] )* out of analyze-dep-mgt mojo. it would be very sueful to ignore test scoped artifacts or certain enlisted artifacts to be ignored out of analyze-dep-mgt mojo. other mojos like analyze / analyze-olnly provide this support. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
