[jira] [Commented] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702823#comment-16702823
]
Karl Heinz Marbaise commented on MINSTALL-151:
--
The problem is located in the izpack-maven-plugin which needs to be fixed...you
can configure your build to use an older version...
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6530) Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
[
https://issues.apache.org/jira/browse/MNG-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702814#comment-16702814
]
Mickael Istria commented on MNG-6530:
-
{quote}for all others these changes are improvements{quote}
Search for "maven ProjectBuilder" on GitHub, you'll see many entries. This
contains many plugins, all 3 main Java IDEs and a lot of other code that can
very easily suffer from this bug. As the steps to reproduce are not trivial and
it's in latest Maven, it can take some time before all those project 1. Adopt a
version of Maven containing this bug and 2. notice the impact of the bug.
{quote}Why not do what Fred Bricon suggested in MNG-6311 and make the cache
implementation injectable, then you could substitute a cache that evicts a POM
file from the cache when the workspace knows it has been modified? {quote}
This wouldn't fix what's bug in ProjectBuilder IMO, and it would still require
a big adoption effort for downstream components.
I'll let [~fbricon] comment more on that, but I think it would not fit m2e. The
cache itself seems to cache objects (like DependencyManagement) which seem to
have no link to the related pom file so there would be impossible for m2e to
sort out what to invalidate and when (especially since m2e doesn't necessarily
monitor the whole filesystem for changes in any pom file). The cache also comes
with a cost in term of RAM; and in IDEs where users can import a project a
delete it, it's totally possile that the cache contains thousands of elements
(Apache Camel is ~800 modules for instance) and that we don't need them because
related project are closed or removed from the IDE; so we can end up in
consuming a lot of heap for data that's not interesting any more.
I think the system property or a simple setting to control that cache "scope"
(is it a temporary cache for one invocation of ProjectBuilder.build(...) as it
used to or is it a static cache for the lifecycle of the application as
currently implemented?) is a better solution. At this point, the bug is so
critical for m2e and family that we don't really care about the potential value
of the new cache lifecycle in term of performance.
> Regression in ProjectBuilder when file change between invocations (introduced
> by MNG-6311)
> --
>
> Key: MNG-6530
> URL: https://issues.apache.org/jira/browse/MNG-6530
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.0
>Reporter: Mickael Istria
>Priority: Critical
> Fix For: 3.6.1
>
>
> The patch for MNG-6311 introduces a regression in ProjectBuilder due to
> missing cache invalidation when content change.
> It was identified as a potential issue by [~fbricon] on Oct 10, yet no
> further investigation happened and Maven 3.6.0 was released with this
> regression.
> This regression prevents Eclipse m2e (and probably most APIs using the
> ProjectBuilder for a longer session which allows pom.xml files to be
> modified) from adopting 3.6.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6531) custom maven plugin
zhubenle created MNG-6531: - Summary: custom maven plugin Key: MNG-6531 URL: https://issues.apache.org/jira/browse/MNG-6531 Project: Maven Issue Type: Bug Reporter: zhubenle org.apache.maven maven-plugin-api 3.6.0 plexus-utils org.codehaus.plexus org.apache.maven.plugin-tools maven-plugin-annotations 3.6.0 provided maven-artifact org.apache.maven org.apache.maven.plugins maven-plugin-plugin 3.6.0 com.t0mpi9 easy-jsch 1.0-SNAPSHOT junit junit 4.12 test jdk1.8 when I execute "clean package -X", The following exception information appears [ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor (default-descriptor) on project shell-pack-maven-plugin: Execution default-descriptor of goal org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed.: NullPointerException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor (default-descriptor) on project shell-pack-maven-plugin: Execution default-descriptor of goal org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) 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:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) 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 sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:498) 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) at org.codehaus.classworlds.Launcher.main (Launcher.java:47) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-descriptor of goal org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) 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:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) 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 sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:498) 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
[jira] [Commented] (MNG-6530) Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
[ https://issues.apache.org/jira/browse/MNG-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702643#comment-16702643 ] David Churcher commented on MNG-6530: - Why not do what [~fbricon] suggested in MNG-6311 and make the cache implementation injectable, then you could substitute a cache that evicts a POM file from the cache when the workspace knows it has been modified? > Regression in ProjectBuilder when file change between invocations (introduced > by MNG-6311) > -- > > Key: MNG-6530 > URL: https://issues.apache.org/jira/browse/MNG-6530 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.0 >Reporter: Mickael Istria >Priority: Critical > Fix For: 3.6.1 > > > The patch for MNG-6311 introduces a regression in ProjectBuilder due to > missing cache invalidation when content change. > It was identified as a potential issue by [~fbricon] on Oct 10, yet no > further investigation happened and Maven 3.6.0 was released with this > regression. > This regression prevents Eclipse m2e (and probably most APIs using the > ProjectBuilder for a longer session which allows pom.xml files to be > modified) from adopting 3.6.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702455#comment-16702455
]
Fabiano Cipriano de Oliveira commented on MNG-6261:
---
Thank you all for your support
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEP-628) Unpacking File Mappers
[
https://issues.apache.org/jira/browse/MDEP-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702376#comment-16702376
]
ASF GitHub Bot commented on MDEP-628:
-
rfscholte commented on issue #5: [MDEP-628] Parameter `fileMappers` for unpack
path rewriting
URL:
https://github.com/apache/maven-dependency-plugin/pull/5#issuecomment-442600267
Could you copy the unpack-dependencies instead of adjusting it? We need to
ensure that the default 1:1 extraction keeps working as expected.
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
> Unpacking File Mappers
> --
>
> Key: MDEP-628
> URL: https://issues.apache.org/jira/browse/MDEP-628
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Markus Karg
>Priority: Major
> Labels: FileMapper, Mapping, Path
>
> The new parameter {{fileMappers}} (default: {{null}}) can be set to an
> implementation of the
> {{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to
> rewrite the target path of each unpacked file.
> This is useful in case prefixes of target files names within the target
> directory shall be added (using {{PrefixFileMapper}}), changed or omitted
> (using {{RegExpFileMapper}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] rfscholte commented on issue #5: [MDEP-628] Parameter `fileMappers` for unpack path rewriting
rfscholte commented on issue #5: [MDEP-628] Parameter `fileMappers` for unpack path rewriting URL: https://github.com/apache/maven-dependency-plugin/pull/5#issuecomment-442600267 Could you copy the unpack-dependencies instead of adjusting it? We need to ensure that the default 1:1 extraction keeps working as expected. 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] [Closed] (MPIR-377) Profiles in POMs do not appear to be evaluated
[
https://issues.apache.org/jira/browse/MPIR-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPIR-377.
---
Resolution: Not A Problem
Assignee: Robert Scholte
Not sure which MNG issue fixed this, but the solution is: use at least Maven
3.6.0
> Profiles in POMs do not appear to be evaluated
> --
>
> Key: MPIR-377
> URL: https://issues.apache.org/jira/browse/MPIR-377
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.0.0
> Environment: Maven 3.5.4, Win 32_64, Java 10
>Reporter: Jason Faust
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: log.txt, pom.xml
>
>
> First of, I do not know if this is a bug, or if it's a result of OpenJFX
> being silly with how they setup their parent pom (
> [http://repo.maven.apache.org/maven2/org/openjfx/javafx/11.0.1/javafx-11.0.1.pom]
> and
> [http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1/javafx-base-11.0.1.pom]
> ), and the bug should be filed there, but:
> The dependencies report reports warnings of the OpenJFX poms (for example)
> referring to themselves, as they depend on {{${javafx.profile}}} having a
> value, which is derived from the parent POM. Net result is it appears that
> the dependencies report is unable to see the full tree, whereas Maven
> normally is able to include all of the jars required for a build.
> Error triggered by running 'site' against the attached [^pom.xml].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702364#comment-16702364
]
Hudson commented on MNG-6261:
-
Build succeeded in Jenkins: Maven TLP » maven » master #114
See https://builds.apache.org/job/maven-box/job/maven/job/master/114/
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6530) Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
[ https://issues.apache.org/jira/browse/MNG-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702361#comment-16702361 ] Robert Scholte commented on MNG-6530: - I've marked the Fix Version for 3.6.1, so once the release manager starts preparing that release he will notice this issue. However, that implies that the issue should be active or close to being fixed, otherwise he might decide to push it to a next release. > Regression in ProjectBuilder when file change between invocations (introduced > by MNG-6311) > -- > > Key: MNG-6530 > URL: https://issues.apache.org/jira/browse/MNG-6530 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.0 >Reporter: Mickael Istria >Priority: Critical > Fix For: 3.6.1 > > > The patch for MNG-6311 introduces a regression in ProjectBuilder due to > missing cache invalidation when content change. > It was identified as a potential issue by [~fbricon] on Oct 10, yet no > further investigation happened and Maven 3.6.0 was released with this > regression. > This regression prevents Eclipse m2e (and probably most APIs using the > ProjectBuilder for a longer session which allows pom.xml files to be > modified) from adopting 3.6.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6530) Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
[ https://issues.apache.org/jira/browse/MNG-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6530: Fix Version/s: 3.6.1 > Regression in ProjectBuilder when file change between invocations (introduced > by MNG-6311) > -- > > Key: MNG-6530 > URL: https://issues.apache.org/jira/browse/MNG-6530 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.0 >Reporter: Mickael Istria >Priority: Critical > Fix For: 3.6.1 > > > The patch for MNG-6311 introduces a regression in ProjectBuilder due to > missing cache invalidation when content change. > It was identified as a potential issue by [~fbricon] on Oct 10, yet no > further investigation happened and Maven 3.6.0 was released with this > regression. > This regression prevents Eclipse m2e (and probably most APIs using the > ProjectBuilder for a longer session which allows pom.xml files to be > modified) from adopting 3.6.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6530) Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
[ https://issues.apache.org/jira/browse/MNG-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6530: Affects Version/s: (was: 3.6.1) > Regression in ProjectBuilder when file change between invocations (introduced > by MNG-6311) > -- > > Key: MNG-6530 > URL: https://issues.apache.org/jira/browse/MNG-6530 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.0 >Reporter: Mickael Istria >Priority: Critical > Fix For: 3.6.1 > > > The patch for MNG-6311 introduces a regression in ProjectBuilder due to > missing cache invalidation when content change. > It was identified as a potential issue by [~fbricon] on Oct 10, yet no > further investigation happened and Maven 3.6.0 was released with this > regression. > This regression prevents Eclipse m2e (and probably most APIs using the > ProjectBuilder for a longer session which allows pom.xml files to be > modified) from adopting 3.6.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6530) Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
[
https://issues.apache.org/jira/browse/MNG-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702350#comment-16702350
]
Mickael Istria commented on MNG-6530:
-
{quote}Reverting
MNG-6311
would imply reverting
MNG-6030
too, and maybe even more. {quote}
I don't get why. MNG-6030 was fixed almost 2 years ago and no-one complained
about it. The change for MNG-6311 are downstream of this one,so they could be
reverted without affecting older patches.
{quote}This has become an Eclipse intregration issue, {quote}
Not only, it's an API regression. M2e noticed it, but there are chances that
any user of ProjectBuilder API could be affected.
I see you're trying to diminosh the criticity of the issue and try to put
responsibility of the regression on the users. I also do it too from time to
time, but deep inside me., I know I'm very wrong when I do that and that the
tolerated technical debt will come back to me even stronger in the future.
{quote} for all others these changes are improvements, so reverting just for
Eclipse doesn't sound good to me{quote}
Do you have an exhaustuve listing of «all others»? There are strong chances
that any tool providing Maven integration (read about all IDEs) do use this API
to generate info and assistance to edit the pom file.
{quote}Instead we (Maven team + Eclipse team) should cooperate and keep
improving Maven.{quote}
Sure, and that's what I'm doing with my former comment, I.just reached
my.technical limit in term of what I can develop here because of my lack of
knowledge in Maven. The ball is now on the side of Maven contributors.
{quote}Worst case we're going to introduce a system property to disable
caching{quote}
That'd be pretty good to me. If I submit a.patch with that,would it be accepted?
{quote}I would expect that caching would be interesting for Eclipse too,{quote}
Of course.
{quote}as long as it recognizes changes to the pomfile.{quote}
Basically,is there any chance it happens soon? My look at the code today made
me pissimistic, as explained in the previous comment.if you can send
optimisitic perspectives of this being fixed.soon, it may make me feel better
about.m2e and Maven.
> Regression in ProjectBuilder when file change between invocations (introduced
> by MNG-6311)
> --
>
> Key: MNG-6530
> URL: https://issues.apache.org/jira/browse/MNG-6530
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.0, 3.6.1
>Reporter: Mickael Istria
>Priority: Critical
>
> The patch for MNG-6311 introduces a regression in ProjectBuilder due to
> missing cache invalidation when content change.
> It was identified as a potential issue by [~fbricon] on Oct 10, yet no
> further investigation happened and Maven 3.6.0 was released with this
> regression.
> This regression prevents Eclipse m2e (and probably most APIs using the
> ProjectBuilder for a longer session which allows pom.xml files to be
> modified) from adopting 3.6.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702346#comment-16702346
]
Robert Scholte commented on MNG-6261:
-
Fixed in
[e4e33f73b8f089e443a3bcc678f509bf0daffb15|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=e4e33f73b8f089e443a3bcc678f509bf0daffb15]
Thanks for the patch!
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702339#comment-16702339
]
ASF GitHub Bot commented on MNG-6261:
-
rfscholte closed pull request #192: [MNG-6261] - using java File api to compare
URL: https://github.com/apache/maven/pull/192
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
b/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
index 0ac45ee459..87146116de 100644
---
a/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
+++
b/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
@@ -852,10 +852,11 @@ private ModelData readParent( Model childModel,
ModelSource childSource, ModelBu
File pomFile = parentData.getModel().getPomFile();
if ( pomFile != null )
{
+FileModelSource pomSource = new FileModelSource( pomFile );
ModelSource expectedParentSource = getParentPomFile(
childModel, childSource );
if ( expectedParentSource == null || (
expectedParentSource instanceof ModelSource2
-&& !pomFile.toURI().equals( ( (ModelSource2)
expectedParentSource ).getLocationURI() ) ) )
+&& !pomSource.equals( expectedParentSource ) ) )
{
parentData = readParentExternally( childModel,
request, problems );
}
diff --git
a/maven-model-builder/src/main/java/org/apache/maven/model/building/FileModelSource.java
b/maven-model-builder/src/main/java/org/apache/maven/model/building/FileModelSource.java
index a2e1141769..f329eb2a3e 100644
---
a/maven-model-builder/src/main/java/org/apache/maven/model/building/FileModelSource.java
+++
b/maven-model-builder/src/main/java/org/apache/maven/model/building/FileModelSource.java
@@ -80,4 +80,27 @@ public URI getLocationURI()
{
return getFile().toURI();
}
+
+@Override
+public boolean equals( Object obj )
+{
+if ( this == obj )
+{
+return true;
+}
+
+if ( !( obj instanceof FileModelSource ) )
+{
+return false;
+}
+FileModelSource other = ( FileModelSource ) obj;
+return getFile().equals( other.getFile() );
+}
+
+@Override
+public int hashCode()
+{
+return getFile().hashCode();
+}
+
}
diff --git
a/maven-model-builder/src/test/java/org/apache/maven/model/building/FileModelSourceTest.java
b/maven-model-builder/src/test/java/org/apache/maven/model/building/FileModelSourceTest.java
new file mode 100644
index 00..9b0ecd9ddf
--- /dev/null
+++
b/maven-model-builder/src/test/java/org/apache/maven/model/building/FileModelSourceTest.java
@@ -0,0 +1,75 @@
+package org.apache.maven.model.building;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+import java.io.File;
+import java.io.IOException;
+import static junit.framework.TestCase.assertFalse;
+import static junit.framework.TestCase.assertTrue;
+import org.apache.commons.lang3.SystemUtils;
+import static org.junit.Assume.assumeTrue;
+import org.junit.Test;
+
+/**
+ * Test that validate the solution of MNG-6261 issue
+ *
+ */
+public class FileModelSourceTest
+{
+
+/**
+ * Test of equals method, of class FileModelSource.
+ */
+@Test
+public void testEquals()
+throws Exception
+{
+File tempFile = createTempFile( "pomTest" );
+FileModelSource instance = new FileModelSource( tempFile );
+
+assertFalse( instance.equals( null ) );
+assertFalse( instance.equals( new Object() ) );
+assertTrue( instance.equals( instance ) );
+assertTrue(
[GitHub] rfscholte closed pull request #192: [MNG-6261] - using java File api to compare
rfscholte closed pull request #192: [MNG-6261] - using java File api to compare
URL: https://github.com/apache/maven/pull/192
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
b/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
index 0ac45ee459..87146116de 100644
---
a/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
+++
b/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
@@ -852,10 +852,11 @@ private ModelData readParent( Model childModel,
ModelSource childSource, ModelBu
File pomFile = parentData.getModel().getPomFile();
if ( pomFile != null )
{
+FileModelSource pomSource = new FileModelSource( pomFile );
ModelSource expectedParentSource = getParentPomFile(
childModel, childSource );
if ( expectedParentSource == null || (
expectedParentSource instanceof ModelSource2
-&& !pomFile.toURI().equals( ( (ModelSource2)
expectedParentSource ).getLocationURI() ) ) )
+&& !pomSource.equals( expectedParentSource ) ) )
{
parentData = readParentExternally( childModel,
request, problems );
}
diff --git
a/maven-model-builder/src/main/java/org/apache/maven/model/building/FileModelSource.java
b/maven-model-builder/src/main/java/org/apache/maven/model/building/FileModelSource.java
index a2e1141769..f329eb2a3e 100644
---
a/maven-model-builder/src/main/java/org/apache/maven/model/building/FileModelSource.java
+++
b/maven-model-builder/src/main/java/org/apache/maven/model/building/FileModelSource.java
@@ -80,4 +80,27 @@ public URI getLocationURI()
{
return getFile().toURI();
}
+
+@Override
+public boolean equals( Object obj )
+{
+if ( this == obj )
+{
+return true;
+}
+
+if ( !( obj instanceof FileModelSource ) )
+{
+return false;
+}
+FileModelSource other = ( FileModelSource ) obj;
+return getFile().equals( other.getFile() );
+}
+
+@Override
+public int hashCode()
+{
+return getFile().hashCode();
+}
+
}
diff --git
a/maven-model-builder/src/test/java/org/apache/maven/model/building/FileModelSourceTest.java
b/maven-model-builder/src/test/java/org/apache/maven/model/building/FileModelSourceTest.java
new file mode 100644
index 00..9b0ecd9ddf
--- /dev/null
+++
b/maven-model-builder/src/test/java/org/apache/maven/model/building/FileModelSourceTest.java
@@ -0,0 +1,75 @@
+package org.apache.maven.model.building;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+import java.io.File;
+import java.io.IOException;
+import static junit.framework.TestCase.assertFalse;
+import static junit.framework.TestCase.assertTrue;
+import org.apache.commons.lang3.SystemUtils;
+import static org.junit.Assume.assumeTrue;
+import org.junit.Test;
+
+/**
+ * Test that validate the solution of MNG-6261 issue
+ *
+ */
+public class FileModelSourceTest
+{
+
+/**
+ * Test of equals method, of class FileModelSource.
+ */
+@Test
+public void testEquals()
+throws Exception
+{
+File tempFile = createTempFile( "pomTest" );
+FileModelSource instance = new FileModelSource( tempFile );
+
+assertFalse( instance.equals( null ) );
+assertFalse( instance.equals( new Object() ) );
+assertTrue( instance.equals( instance ) );
+assertTrue( instance.equals( new FileModelSource( tempFile ) ) );
+}
+
+@Test
+public void testWindowsPaths()
+throws Exception
+{
+assumeTrue( SystemUtils.IS_OS_WINDOWS );
+
+File upperCaseFile =
[jira] [Commented] (MNG-6530) Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
[ https://issues.apache.org/jira/browse/MNG-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702325#comment-16702325 ] Robert Scholte commented on MNG-6530: - Reverting MNG-6311 would imply reverting MNG-6030 too, and maybe even more. This has become an Eclipse intregration issue, but for all others these changes are improvements, so reverting just for Eclipse doesn't sound good to me. Instead we (Maven team + Eclipse team) should cooperate and keep improving Maven. Worst case we're going to introduce a system property to disable caching, but I would expect that caching would be interesting for Eclipse too, as long as it recognizes changes to the pomfile. > Regression in ProjectBuilder when file change between invocations (introduced > by MNG-6311) > -- > > Key: MNG-6530 > URL: https://issues.apache.org/jira/browse/MNG-6530 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.0, 3.6.1 >Reporter: Mickael Istria >Priority: Critical > > The patch for MNG-6311 introduces a regression in ProjectBuilder due to > missing cache invalidation when content change. > It was identified as a potential issue by [~fbricon] on Oct 10, yet no > further investigation happened and Maven 3.6.0 was released with this > regression. > This regression prevents Eclipse m2e (and probably most APIs using the > ProjectBuilder for a longer session which allows pom.xml files to be > modified) from adopting 3.6.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPIR-377) Profiles in POMs do not appear to be evaluated
[
https://issues.apache.org/jira/browse/MPIR-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702242#comment-16702242
]
Jason Faust commented on MPIR-377:
--
Tried it with Maven 3.6.0, issue is gone in that version of Maven. Looks to be
resolved.
> Profiles in POMs do not appear to be evaluated
> --
>
> Key: MPIR-377
> URL: https://issues.apache.org/jira/browse/MPIR-377
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.0.0
> Environment: Maven 3.5.4, Win 32_64, Java 10
>Reporter: Jason Faust
>Priority: Minor
> Attachments: log.txt, pom.xml
>
>
> First of, I do not know if this is a bug, or if it's a result of OpenJFX
> being silly with how they setup their parent pom (
> [http://repo.maven.apache.org/maven2/org/openjfx/javafx/11.0.1/javafx-11.0.1.pom]
> and
> [http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1/javafx-base-11.0.1.pom]
> ), and the bug should be filed there, but:
> The dependencies report reports warnings of the OpenJFX poms (for example)
> referring to themselves, as they depend on {{${javafx.profile}}} having a
> value, which is derived from the parent POM. Net result is it appears that
> the dependencies report is unable to see the full tree, whereas Maven
> normally is able to include all of the jars required for a build.
> Error triggered by running 'site' against the attached [^pom.xml].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6530) Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
[ https://issues.apache.org/jira/browse/MNG-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702061#comment-16702061 ] Mickael Istria commented on MNG-6530: - I had a look at how feasible it would be to make the cache understand when pom files change. It seems impossible to do it in the cache itself as the cache doesn't have any understanding of the object it caches and where they come from. So it seems to only be achievable in DefaultModelBuilder that should ignore artifacts from the cache if they are outdated. The places that need to have a change are basically all consumers of DefaultModelBuilder.getCache(). For the readParent part, it seems achievable although not trivial: we'd need a way to have the ModelData store a creationTimestamp when created and to propagate it to clones. With this creationTimestamp, we can compare it to the lastModificationTimestamp of the underlying pom file and decide to ignore cache when lastModificationTimestamp > ModelData.creationTimestamp. For the dependency part, it's much harder since the DependencyManagement item that's stored in the cache doesn't contain any information regarding the actual pom.xml that generated it, so we cannot deduce a creationTimestamp nor the last modificationTimestamp of the supporting file. Note that the test I contributed only covers the parent part, not the depedency one. A test for dependencies should be added to ensure a fix is valid. At the moment, there is still no clear solution, and I think it'd still be best to consider reverting the changes from MNG-6311. > Regression in ProjectBuilder when file change between invocations (introduced > by MNG-6311) > -- > > Key: MNG-6530 > URL: https://issues.apache.org/jira/browse/MNG-6530 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.0, 3.6.1 >Reporter: Mickael Istria >Priority: Critical > > The patch for MNG-6311 introduces a regression in ProjectBuilder due to > missing cache invalidation when content change. > It was identified as a potential issue by [~fbricon] on Oct 10, yet no > further investigation happened and Maven 3.6.0 was released with this > regression. > This regression prevents Eclipse m2e (and probably most APIs using the > ProjectBuilder for a longer session which allows pom.xml files to be > modified) from adopting 3.6.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701943#comment-16701943
]
zosrothko commented on MINSTALL-151:
Hi
Got the same issue with the izpack-maven-plugin which is running fine with
maven-install-plugin:2.5.2 but fails with 3.0.0-M1 as
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project installer-izpack: NoFileAssignedException: The
packaging for this project did not assign a file to the build artifact -> [Help
1]
How can this be fixed otherwise to rollback to the maven-install-plugin:2.5.2 ?
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SUREFIRE-1604) "Surefire report directory" information is missing at the very beginning of execution for IDE integration
jmborer created SUREFIRE-1604:
-
Summary: "Surefire report directory" information is missing at the
very beginning of execution for IDE integration
Key: SUREFIRE-1604
URL: https://issues.apache.org/jira/browse/SUREFIRE-1604
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.22.1, 2.19.1
Reporter: jmborer
Since 2.18.1, Surefire no longer prints by default the line:
{noformat}
Surefire report directory: {noformat}
This information is really useful for IDE integration like in Netbeans, where
users want to click on links in the report that brings them to the build
directory. This line reappears if the "-e" option is used, but it brings with
it unecessary additional info as well.
Because the IDE is parsing the output, it must know the location of the reports
*before* the first results are displayed. Currently it is possible to guess the
reports directory by using the default location, but as soon as a user defines
a custom location, Netbeans for example won't be able to locate the new
directory early enough (see https://issues.apache.org/jira/browse/NETBEANS-635)
The code has changed in VerifyMojo,java line 171 (version 2.22.1)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1602) Surefire fails loading class ForkedBooter when using a sub-directory pom file and a local maven repo
[
https://issues.apache.org/jira/browse/SUREFIRE-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701777#comment-16701777
]
Daniel Kurzynski commented on SUREFIRE-1602:
[~tibor17]
Sure. Please use this repository:
[https://github.com/daniel-kurzynski/reproduce-surefire-issue]
It includes all the first steps. You just can execute the following steps:
{code:java}
mvn -Dmaven.repo.local=maven_local_repo -Dmaven.test.skip clean install{code}
Running the tests afterwards will fail
{code:java}
mvn test -Dmaven.repo.local=maven_local_repo --file
./integration-tests/pom.xml{code}
> Surefire fails loading class ForkedBooter when using a sub-directory pom file
> and a local maven repo
>
>
> Key: SUREFIRE-1602
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1602
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M1
> Environment: maven 3.6.0 open-jdk-8 (docker image
> maven:3.6.0-open-jdk-8)
>Reporter: Daniel Kurzynski
>Priority: Major
>
> Steps to reproduce:
> Use a docker image for maven:3.6 (docker run -it maven:3.6.0-jdk-8 bash)
> Inside generate a new project:
> {code:java}
> mvn archetype:generate \
> -DinteractiveMode=false \
> -DarchetypeGroupId=com.sap.cloud.s4hana.archetypes \
> -DarchetypeArtifactId=scp-cf-tomee \
> -DarchetypeVersion=2.7.0 \
> -DgroupId=com.sap.cloud.sdk.tutorial \
> -DartifactId=testapp\
> -Dversion=1.0-SNAPSHOT \
> -Dpackage=com.sap.cloud.s4hana.examples{code}
> In the folder testapp set surefire version to 3.0.0-M1 in unit-tests/pom.xml
> and integration-tests/pom.xml
> Build the project
> {code:java}
> mvn -Dmaven.repo.local=maven_local_repo -Dmaven.test.skip clean install{code}
> Running the tests afterwards will fail
> {code:java}
> mvn test -Dmaven.repo.local=maven_local_repo --file
> ./integration-tests/pom.xml{code}
> The error message in the logs is:
> Error: Could not find or load main class
> org.apache.maven.surefire.booter.ForkedBooter
> However, it only fails when using ./ in the beginning of the file parameter
> in combination with having a local maven repo.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6527) Add unit tests for org.apache.maven.repository.MavenArtifactMetadata
[ https://issues.apache.org/jira/browse/MNG-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701744#comment-16701744 ] ASF GitHub Bot commented on MNG-6527: - diffblue-assistant opened a new pull request #196: [MNG-6527] - Add unit tests for org.apache.maven.repository.MavenArtifactMetadata URL: https://github.com/apache/maven/pull/196 Hi, I've analysed your codebase and produced some unit tests for the following classes - org.apache.maven.repository.MavenArtifactMetadata. I've written the tests for these functions with the help of [Diffblue](https://www.diffblue.com/) [Cover](https://www.diffblue.com/datasheet). Hopefully, these tests should help you detect regressions caused by future code changes. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ 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 > Add unit tests for org.apache.maven.repository.MavenArtifactMetadata > > > Key: MNG-6527 > URL: https://issues.apache.org/jira/browse/MNG-6527 > Project: Maven > Issue Type: Test >Reporter: Louis Mills >Priority: Major > Labels: pull-request-available > > These tests were written by Diffblue Cover. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] diffblue-assistant opened a new pull request #196: [MNG-6527] - Add unit tests for org.apache.maven.repository.MavenArtifactMetadata
diffblue-assistant opened a new pull request #196: [MNG-6527] - Add unit tests for org.apache.maven.repository.MavenArtifactMetadata URL: https://github.com/apache/maven/pull/196 Hi, I've analysed your codebase and produced some unit tests for the following classes - org.apache.maven.repository.MavenArtifactMetadata. I've written the tests for these functions with the help of [Diffblue](https://www.diffblue.com/) [Cover](https://www.diffblue.com/datasheet). Hopefully, these tests should help you detect regressions caused by future code changes. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ 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] [Commented] (MNG-6528) Add unit tests for org.apache.maven.plugin.CacheUtils
[ https://issues.apache.org/jira/browse/MNG-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701740#comment-16701740 ] ASF GitHub Bot commented on MNG-6528: - diffblue-assistant opened a new pull request #195: [MNG-6528] - Add unit tests for org.apache.maven.plugin.CacheUtils URL: https://github.com/apache/maven/pull/195 Hi, I've analysed your codebase and produced some unit tests for the following classes - org.apache.maven.plugin.CacheUtils. I've written the tests for these functions with the help of [Diffblue](https://www.diffblue.com/) [Cover](https://www.diffblue.com/datasheet). Hopefully, these tests should help you detect regressions caused by future code changes. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ 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 > Add unit tests for org.apache.maven.plugin.CacheUtils > - > > Key: MNG-6528 > URL: https://issues.apache.org/jira/browse/MNG-6528 > Project: Maven > Issue Type: Test >Reporter: Louis Mills >Priority: Major > Labels: pull-request-available > > These tests were written by Diffblue Cover. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] diffblue-assistant opened a new pull request #195: [MNG-6528] - Add unit tests for org.apache.maven.plugin.CacheUtils
diffblue-assistant opened a new pull request #195: [MNG-6528] - Add unit tests for org.apache.maven.plugin.CacheUtils URL: https://github.com/apache/maven/pull/195 Hi, I've analysed your codebase and produced some unit tests for the following classes - org.apache.maven.plugin.CacheUtils. I've written the tests for these functions with the help of [Diffblue](https://www.diffblue.com/) [Cover](https://www.diffblue.com/datasheet). Hopefully, these tests should help you detect regressions caused by future code changes. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ 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] (MASSEMBLY-897) zipentry.getSize() returns -1 for regular files in a m-a-p created zip
Marcel created MASSEMBLY-897: Summary: zipentry.getSize() returns -1 for regular files in a m-a-p created zip Key: MASSEMBLY-897 URL: https://issues.apache.org/jira/browse/MASSEMBLY-897 Project: Maven Assembly Plugin Issue Type: Bug Components: maven-archiver Affects Versions: 3.1.0, 2.6, 2.5.5, 2.5.4, 2.5.3, 2.5.2, 2.5.1, 2.4.1, 2.5 Environment: Windows, oracle and ibm 1.8 jvm's Reporter: Marcel Attachments: ReadZip.java, pom.xml When you create a zip file using maven-assembly-plugin in one the 'affected versions' and later read it back using java.util.zip.ZipInputStream, the ZipEntry instances for files will return -1 from a call to zipentry.getSize(). Using version 2.4 this call will return the correct uncompressed size. It also works when I build and use the latest 3.1.1-SNAPSHOT. It was fixed in commit 5ccac88 which not surprisingly updated plexus-archiver. Please consider releasing 3.1.1 to make this publicly available and also to use the attached pom and java code to add a testcase guarding against a future regression. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6530) Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
[ https://issues.apache.org/jira/browse/MNG-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6530: -- Affects Version/s: 3.6.1 > Regression in ProjectBuilder when file change between invocations (introduced > by MNG-6311) > -- > > Key: MNG-6530 > URL: https://issues.apache.org/jira/browse/MNG-6530 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.0, 3.6.1 >Reporter: Mickael Istria >Priority: Critical > > The patch for MNG-6311 introduces a regression in ProjectBuilder due to > missing cache invalidation when content change. > It was identified as a potential issue by [~fbricon] on Oct 10, yet no > further investigation happened and Maven 3.6.0 was released with this > regression. > This regression prevents Eclipse m2e (and probably most APIs using the > ProjectBuilder for a longer session which allows pom.xml files to be > modified) from adopting 3.6.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEP-628) Unpacking File Mappers
[
https://issues.apache.org/jira/browse/MDEP-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701538#comment-16701538
]
ASF GitHub Bot commented on MDEP-628:
-
mkarg commented on issue #5: [MDEP-628] Parameter `fileMappers` for unpack path
rewriting
URL:
https://github.com/apache/maven-dependency-plugin/pull/5#issuecomment-442365984
@rfscholte Amended existing integration test to verify mapping works well,
see d47a4abbe0817cef27ea078ec7b35ca4e81b451b.
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
> Unpacking File Mappers
> --
>
> Key: MDEP-628
> URL: https://issues.apache.org/jira/browse/MDEP-628
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Markus Karg
>Priority: Major
> Labels: FileMapper, Mapping, Path
>
> The new parameter {{fileMappers}} (default: {{null}}) can be set to an
> implementation of the
> {{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to
> rewrite the target path of each unpacked file.
> This is useful in case prefixes of target files names within the target
> directory shall be added (using {{PrefixFileMapper}}), changed or omitted
> (using {{RegExpFileMapper}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] mkarg commented on issue #5: [MDEP-628] Parameter `fileMappers` for unpack path rewriting
mkarg commented on issue #5: [MDEP-628] Parameter `fileMappers` for unpack path rewriting URL: https://github.com/apache/maven-dependency-plugin/pull/5#issuecomment-442365984 @rfscholte Amended existing integration test to verify mapping works well, see d47a4abbe0817cef27ea078ec7b35ca4e81b451b. 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] [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=16701504#comment-16701504 ] Mickael Istria commented on MNG-6311: - I've opened MNG-6530 to track resolution of this one on a pure technical side; but again I think there is a process issue if those patches can get in even if some concerns are raised way before the release. The project leads should probably clarify some rules for applying patches and reverting them if they are probably causing issues downstream and no test covers this. > 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 >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > 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] (MNG-6530) Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
Mickael Istria created MNG-6530: --- Summary: Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311) Key: MNG-6530 URL: https://issues.apache.org/jira/browse/MNG-6530 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.0 Reporter: Mickael Istria The patch for MNG-6311 introduces a regression in ProjectBuilder due to missing cache invalidation when content change. It was identified as a potential issue by [~fbricon] on Oct 10, yet no further investigation happened and Maven 3.6.0 was released with this regression. This regression prevents Eclipse m2e (and probably most APIs using the ProjectBuilder for a longer session which allows pom.xml files to be modified) from adopting 3.6.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
