[jira] [Commented] (SUREFIRE-2072) Surefire retains too much heap in some case, leading to OutOfMemory
[
https://issues.apache.org/jira/browse/SUREFIRE-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522507#comment-17522507
]
Mickael Istria commented on SUREFIRE-2072:
--
Unfortunately, I don't think there is a one-size-fits-all for this cache. I
would suggest to make it configurable in the `StartupReportConfiguration` to
let consumers (eg Tycho) optimize it according to their cases. For end-users of
maven-surefire-plugin, maybe it could as well be a mojo parameter.
I don't think 64kB is a bad value and I even trust it's a good one as you
demonstrated, so I do not advocate in favor of changing it by default. I'm more
looking for a solution to control this cache. However, if some other solution
(like discarding the stdout/stderr buffers whenever they're not necessary
anymore) is implemented, that's fine as well.
> The object of {{TestSetRunListener}} is not in fork. It is in Maven process.
As a reminder, the case here is tycho-surefire-plugin, that does run JUnit test
inside an Eclipse Platform/OSGi environment. In that story, the
TestSetRunListener is actually part of the test process, because it's what
seems to work best so far. Mayve it could be done differently/better, but it's
hard to change code that has been functioning without issues for a decade...
The tests do run sequentially, so the memory is freed between executions, the
tests used in the example used by
[https://github.com/eclipse/tycho/issues/879] don't seem to leave "leaks" after
execution. The memory consumed by the fork after a GC remains constants
(~130MB) after each test; while the TestSetRunListener does grow greedily.
> Surefire retains too much heap in some case, leading to OutOfMemory
> ---
>
> Key: SUREFIRE-2072
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2072
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Mickael Istria
>Priority: Major
>
> Most likely since SuREFIRE-1845, every test execution can retain 64kB of RAM
> (as cache). Which caching is welcome, this cannot scale with some big test
> suites of several thousands of tests and cause OutOfMemoryError.
> This is the case when running Eclipse JDT dom test suite, since
> tycho-surefire-plugin started to adopt surefire 3.0.0.M6, as described in
> https://github.com/eclipse/tycho/issues/879#issuecomment-1096454637
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2072) Surefire retains too much heap in some case, leading to OutOfMemory
[ https://issues.apache.org/jira/browse/SUREFIRE-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521928#comment-17521928 ] Mickael Istria commented on SUREFIRE-2072: -- In general, caching some kB here and there can be a good idea, however I have the impression that with patch for SUREFIRE-1845, each test will consume 64kB of extra memory even if it actually only has a dozen of characters to cache (as it's the case for JDT tests). So most of the extra memory consumeption causing the OOM isn't even used at all. > Surefire retains too much heap in some case, leading to OutOfMemory > --- > > Key: SUREFIRE-2072 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2072 > Project: Maven Surefire > Issue Type: Bug >Reporter: Mickael Istria >Priority: Major > > Most likely since SuREFIRE-1845, every test execution can retain 64kB of RAM > (as cache). Which caching is welcome, this cannot scale with some big test > suites of several thousands of tests and cause OutOfMemoryError. > This is the case when running Eclipse JDT dom test suite, since > tycho-surefire-plugin started to adopt surefire 3.0.0.M6, as described in > https://github.com/eclipse/tycho/issues/879#issuecomment-1096454637 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SUREFIRE-2072) Surefire retains too much heap in some case, leading to OutOfMemory
Mickael Istria created SUREFIRE-2072: Summary: Surefire retains too much heap in some case, leading to OutOfMemory Key: SUREFIRE-2072 URL: https://issues.apache.org/jira/browse/SUREFIRE-2072 Project: Maven Surefire Issue Type: Bug Reporter: Mickael Istria Most likely since SuREFIRE-1845, every test execution can retain 64kB of RAM (as cache). Which caching is welcome, this cannot scale with some big test suites of several thousands of tests and cause OutOfMemoryError. This is the case when running Eclipse JDT dom test suite, since tycho-surefire-plugin started to adopt surefire 3.0.0.M6, as described in https://github.com/eclipse/tycho/issues/879#issuecomment-1096454637 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1845) Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck for the tests with logs
[ https://issues.apache.org/jira/browse/SUREFIRE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521916#comment-17521916 ] Mickael Istria commented on SUREFIRE-1845: -- This change can too easily cause OutOfMemory for some cases, I'm going to open a separate ticket with details > Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck > for the tests with logs > - > > Key: SUREFIRE-1845 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1845 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > > The fix would speed up the cache 8 times. > After we have applied fast TCP/IP encoder and decoder along with the fix for > this issue we have got fast Test3 in the integration test > ConsoleOutputIT#largerSoutThanMemory(), i.e. 0.44 seconds of the test exec > time from previous 8.8 seconds. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MNG-7426) Allow condition (like ) on mojo executions
Mickael Istria created MNG-7426: --- Summary: Allow condition (like ) on mojo executions Key: MNG-7426 URL: https://issues.apache.org/jira/browse/MNG-7426 Project: Maven Issue Type: Improvement Components: Core Reporter: Mickael Istria There are some goals that are only expected to run under some circumstances (eg a file exists, we're running on a particular OS...). The current solution to implement that is to create profiles and profiles are great particularly when multiple invocations or other configurations are involved as they allow to group things into a meaningful block; however in many cases, one can want to just decide to enable/disable 1 particular mojo execution. For those cases where only 1 execution is conditional, profiles seem like a lot of boilerplate and complexity. Instead, we could imagine to add to `` element some `` (or whatever other meaningful name) child that would allow similar evaluations as what's possible with profile execution. When the activation condition is set and returns false, then the execution would be simply skipped. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7285) [Regression] MavenProject.getArtifacts() not returning correct value across multiple threads
[ https://issues.apache.org/jira/browse/MNG-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17427228#comment-17427228 ] Mickael Istria commented on MNG-7285: - > I guess this issue applies to master as well? I guess so; but we didn't try for m2e as there are other issues with Maven 4 that prevents us to go far enough to notice this bug. > [Regression] MavenProject.getArtifacts() not returning correct value across > multiple threads > > > Key: MNG-7285 > URL: https://issues.apache.org/jira/browse/MNG-7285 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.2, 4.0.0-alpha-1, 3.8.3 >Reporter: Mickael Istria >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.x-candidate, 3.8.x-candidate > > > Patch for MNG-6843 seems to cause that when trying to use > MavenProject.getArtifacts() across different threads, some of them get an > incorrect result. > This cause an issue in m2e where we schedule a lot of work and don't have > much control over which thread will do the work (there is a thread pool); > we've faced several regressions because of this issue when trying to adopt > 3.8.3 from 3.8.1. More details at > [https://github.com/eclipse-m2e/m2e-core/pull/346|https://github.com/eclipse-m2e/m2e-core/pull/350] > , > [https://github.com/eclipse-m2e/m2e-core/pull/347|https://github.com/eclipse-m2e/m2e-core/pull/350] > and [https://github.com/eclipse-m2e/m2e-core/pull/350] . > I'll try to capture it in a test case for maven repo in the next days. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7285) [Regression] MavenProject.getArtifacts() not returning correct value across multiple threads
[ https://issues.apache.org/jira/browse/MNG-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425779#comment-17425779 ] Mickael Istria commented on MNG-7285: - PR at [https://github.com/apache/maven/pull/570] shows the regression. This same test is working with maven 3.8.1 and starts failing since 3.8.3. I think any mojo that uses project.getArtifacts() can get faulty result if using parallel build. > [Regression] MavenProject.getArtifacts() not returning correct value across > multiple threads > > > Key: MNG-7285 > URL: https://issues.apache.org/jira/browse/MNG-7285 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.2, 3.8.3 >Reporter: Mickael Istria >Priority: Critical > > Patch for MNG-6843 seems to cause that when trying to use > MavenProject.getArtifacts() across different threads, some of them get an > incorrect result. > This cause an issue in m2e where we schedule a lot of work and don't have > much control over which thread will do the work (there is a thread pool); > we've faced several regressions because of this issue when trying to adopt > 3.8.3 from 3.8.1. More details at > [https://github.com/eclipse-m2e/m2e-core/pull/346|https://github.com/eclipse-m2e/m2e-core/pull/350] > , > [https://github.com/eclipse-m2e/m2e-core/pull/347|https://github.com/eclipse-m2e/m2e-core/pull/350] > and [https://github.com/eclipse-m2e/m2e-core/pull/350] . > I'll try to capture it in a test case for maven repo in the next days. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7285) [Regression] MavenProject.getArtifacts() not returning correct value across multiple threads
[ https://issues.apache.org/jira/browse/MNG-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mickael Istria updated MNG-7285: Affects Version/s: 3.8.2 > [Regression] MavenProject.getArtifacts() not returning correct value across > multiple threads > > > Key: MNG-7285 > URL: https://issues.apache.org/jira/browse/MNG-7285 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.2, 3.8.3 >Reporter: Mickael Istria >Priority: Critical > > Patch for MNG-6843 seems to cause that when trying to use > MavenProject.getArtifacts() across different threads, some of them get an > incorrect result. > This cause an issue in m2e where we schedule a lot of work and don't have > much control over which thread will do the work (there is a thread pool); > we've faced several regressions because of this issue when trying to adopt > 3.8.3 from 3.8.1. More details at > [https://github.com/eclipse-m2e/m2e-core/pull/346|https://github.com/eclipse-m2e/m2e-core/pull/350] > , > [https://github.com/eclipse-m2e/m2e-core/pull/347|https://github.com/eclipse-m2e/m2e-core/pull/350] > and [https://github.com/eclipse-m2e/m2e-core/pull/350] . > I'll try to capture it in a test case for maven repo in the next days. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7285) [Regression] MavenProject.getArtifacts() not returning correct value across multiple threads
[ https://issues.apache.org/jira/browse/MNG-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425377#comment-17425377 ] Mickael Istria commented on MNG-7285: - I also believe that some mojos, or even Maven core, running with a -T option can reach this issue. > [Regression] MavenProject.getArtifacts() not returning correct value across > multiple threads > > > Key: MNG-7285 > URL: https://issues.apache.org/jira/browse/MNG-7285 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.3 >Reporter: Mickael Istria >Priority: Critical > > Patch for MNG-6843 seems to cause that when trying to use > MavenProject.getArtifacts() across different threads, some of them get an > incorrect result. > This cause an issue in m2e where we schedule a lot of work and don't have > much control over which thread will do the work (there is a thread pool); > we've faced several regressions because of this issue when trying to adopt > 3.8.3 from 3.8.1. More details at > [https://github.com/eclipse-m2e/m2e-core/pull/346|https://github.com/eclipse-m2e/m2e-core/pull/350] > , > [https://github.com/eclipse-m2e/m2e-core/pull/347|https://github.com/eclipse-m2e/m2e-core/pull/350] > and [https://github.com/eclipse-m2e/m2e-core/pull/350] . > I'll try to capture it in a test case for maven repo in the next days. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6843) Parallel build fails due to missing JAR artifacts in compilePath
[
https://issues.apache.org/jira/browse/MNG-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425192#comment-17425192
]
Mickael Istria commented on MNG-6843:
-
> please spawn a new issue
Done with MNG-7285
> Parallel build fails due to missing JAR artifacts in compilePath
>
>
> Key: MNG-6843
> URL: https://issues.apache.org/jira/browse/MNG-6843
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.6.3
> Environment: - Linux (tested Docker using maven:3-jdk-8 tag): happens
> most times.
> - Windows 10: happens sometimes.
>Reporter: Stepan Hrbacek
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Build of our multi module (57) Java maven project is failing phase when
> running it as parallel in 4 threads (mvn -T 4 clean install). The failure
> happens during compilation because packages/classes from compile dependencies
> cannot be found:
> {noformat}
> [main] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Compilation failure: Compilation
> failure:
> [main] [ERROR]
> /home/common/src/main/java/com/foo/ZonedDateTimeParser.java:[6,32] package
> org.apache.commons.lang3 does not exist{noformat}
> After enabling debug logging (with thread names) I have found out that a
> compile path of the failing module is empty (besides target/classes):
> When running in 4 threads (-T 4):
> {noformat}
> [BuilderThread 2] [DEBUG] (f) compilePath = [/home/common/target/classes]
> ...
> [BuilderThread 2] [DEBUG] Command line options:
> [BuilderThread 2] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes: -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> When running in a single thread (-T 1):
> {noformat}
> [BuilderThread 0] [DEBUG] (f) compilePath = [/home/common/target/classes,
> /root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar,
>
> /root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar,
>
> /root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar,
>
> /root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar,
> /root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar,
> /root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar,
> /root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar]
> ...
> [BuilderThread 0] [DEBUG] Command line options:
> [BuilderThread 0] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes:/root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar:/root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar:/root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar:/root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar:/root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar:/root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar:/root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar:
> -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> After adding custom log messages I have found out that the root cause is that
> org.apache.maven.project.MavenProject.setArtifactFilter() is called with null
> artifactFilter parameter. The call happens for the failing module from a
> thread that is building another module. The call stack is:
> {code:java}
> "BuilderThread 0@2513" prio=5 tid=0xe nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.maven.project.MavenProject.setArtifactFilter(MavenProject.java:1437)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java
[jira] [Created] (MNG-7285) [Regression] MavenProject.getArtifacts() not returning correct value across multiple threads
Mickael Istria created MNG-7285: --- Summary: [Regression] MavenProject.getArtifacts() not returning correct value across multiple threads Key: MNG-7285 URL: https://issues.apache.org/jira/browse/MNG-7285 Project: Maven Issue Type: Bug Components: Core Affects Versions: 3.8.3 Reporter: Mickael Istria Patch for MNG-6843 seems to cause that when trying to use MavenProject.getArtifacts() across different threads, some of them get an incorrect result. This cause an issue in m2e where we schedule a lot of work and don't have much control over which thread will do the work (there is a thread pool); we've faced several regressions because of this issue when trying to adopt 3.8.3 from 3.8.1. More details at [https://github.com/eclipse-m2e/m2e-core/pull/346|https://github.com/eclipse-m2e/m2e-core/pull/350] , [https://github.com/eclipse-m2e/m2e-core/pull/347|https://github.com/eclipse-m2e/m2e-core/pull/350] and [https://github.com/eclipse-m2e/m2e-core/pull/350] . I'll try to capture it in a test case for maven repo in the next days. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6843) Parallel build fails due to missing JAR artifacts in compilePath
[
https://issues.apache.org/jira/browse/MNG-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425010#comment-17425010
]
Mickael Istria commented on MNG-6843:
-
This does unfortunately cause a regression in m2e when moving from 3.8.1 to
3.8.3: [https://github.com/eclipse-m2e/m2e-core/issues/346] and
[https://github.com/eclipse-m2e/m2e-core/issues/347] . Apparently, because of
this change, using MavenProject across different threads makes that some
classpath references are missing in some cases.
> Parallel build fails due to missing JAR artifacts in compilePath
>
>
> Key: MNG-6843
> URL: https://issues.apache.org/jira/browse/MNG-6843
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.6.3
> Environment: - Linux (tested Docker using maven:3-jdk-8 tag): happens
> most times.
> - Windows 10: happens sometimes.
>Reporter: Stepan Hrbacek
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Build of our multi module (57) Java maven project is failing phase when
> running it as parallel in 4 threads (mvn -T 4 clean install). The failure
> happens during compilation because packages/classes from compile dependencies
> cannot be found:
> {noformat}
> [main] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Compilation failure: Compilation
> failure:
> [main] [ERROR]
> /home/common/src/main/java/com/foo/ZonedDateTimeParser.java:[6,32] package
> org.apache.commons.lang3 does not exist{noformat}
> After enabling debug logging (with thread names) I have found out that a
> compile path of the failing module is empty (besides target/classes):
> When running in 4 threads (-T 4):
> {noformat}
> [BuilderThread 2] [DEBUG] (f) compilePath = [/home/common/target/classes]
> ...
> [BuilderThread 2] [DEBUG] Command line options:
> [BuilderThread 2] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes: -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> When running in a single thread (-T 1):
> {noformat}
> [BuilderThread 0] [DEBUG] (f) compilePath = [/home/common/target/classes,
> /root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar,
>
> /root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar,
>
> /root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar,
>
> /root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar,
> /root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar,
> /root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar,
> /root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar]
> ...
> [BuilderThread 0] [DEBUG] Command line options:
> [BuilderThread 0] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes:/root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar:/root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar:/root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar:/root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar:/root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar:/root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar:/root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar:
> -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> After adding custom log messages I have found out that the root cause is that
> org.apache.maven.project.MavenProject.setArtifactFilter() is called with null
> artifactFilter parameter. The call happens for the failing module from a
> thread that is building another module. The call stack is:
> {c
[jira] [Commented] (MNG-7226) DefaultModelBuilder.buildRawModel fails as it ignores pom file
[ https://issues.apache.org/jira/browse/MNG-7226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17409355#comment-17409355 ] Mickael Istria commented on MNG-7226: - Thanks for the review & merge! > DefaultModelBuilder.buildRawModel fails as it ignores pom file > -- > > Key: MNG-7226 > URL: https://issues.apache.org/jira/browse/MNG-7226 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 4.0.0-alpha-1 >Reporter: Mickael Istria >Assignee: Guillaume Nodet >Priority: Blocker > Fix For: 4.0.0-alpha-1 > > > LemMinX-Maven uses DefaultModelBuilder.buildRawModel() to retrieve some > informations about some models (in case loading the whole project is not > necessary). > Since MNG-6957, this method is broken as it ignores the input pom file. I > imagine the request would simply have to set the FileModelSource instead. > This issue has happened because it looks like this method as no user in the > other parts of Maven, nor has a test case covering it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7226) DefaultModelBuilder.buildRawModel fails as it ignores pom file
[ https://issues.apache.org/jira/browse/MNG-7226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17407374#comment-17407374 ] Mickael Istria commented on MNG-7226: - See [https://github.com/apache/maven/pull/528] for a proposed solution. > DefaultModelBuilder.buildRawModel fails as it ignores pom file > -- > > Key: MNG-7226 > URL: https://issues.apache.org/jira/browse/MNG-7226 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 4.0.0-alpha-1 >Reporter: Mickael Istria >Priority: Blocker > > LemMinX-Maven uses DefaultModelBuilder.buildRawModel() to retrieve some > informations about some models (in case loading the whole project is not > necessary). > Since MNG-6957, this method is broken as it ignores the input pom file. I > imagine the request would simply have to set the FileModelSource instead. > This issue has happened because it looks like this method as no user in the > other parts of Maven, nor has a test case covering it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-7226) DefaultModelBuilder.buildRawModel fails as it ignores pom file
Mickael Istria created MNG-7226: --- Summary: DefaultModelBuilder.buildRawModel fails as it ignores pom file Key: MNG-7226 URL: https://issues.apache.org/jira/browse/MNG-7226 Project: Maven Issue Type: Bug Components: Core Affects Versions: 4.0.0-alpha-1 Reporter: Mickael Istria LemMinX-Maven uses DefaultModelBuilder.buildRawModel() to retrieve some informations about some models (in case loading the whole project is not necessary). Since MNG-6957, this method is broken as it ignores the input pom file. I imagine the request would simply have to set the FileModelSource instead. This issue has happened because it looks like this method as no user in the other parts of Maven, nor has a test case covering it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6616) Create public API for Projects Artifacts Cache where one project can be invalidated
[ https://issues.apache.org/jira/browse/MNG-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17407201#comment-17407201 ] Mickael Istria commented on MNG-6616: - Do I get it right that with the change in [https://github.com/apache/maven/pull/402] , then the cache is basically disabled by default except when using MavenCLI ? That would actually be perfect for cases embedding Maven API to use it for a long session. > Create public API for Projects Artifacts Cache where one project can be > invalidated > --- > > Key: MNG-6616 > URL: https://issues.apache.org/jira/browse/MNG-6616 > Project: Maven > Issue Type: Wish > Components: Bootstrap & Build >Affects Versions: 3.6.0 >Reporter: Balazs Zsoldos >Priority: Major > > By introducing the Projects Artifact Cache, single builds became faster. > However, there are tools that embed Maven and do not restart the complete JVM > process between builds: M2E, mvnsh, etc. > These tools cannot force the refresh of project artifacts currently based on > a stable public API of Maven. It would be nice if there was a public stable > API, where projects could be invalidated in the cache even one-by-one, so the > recompilation of a project would be the fastest possible. > In case of designing such an API, it should not be only about project > artifacts cache, so if new caches introduced later by maven internally, the > API should invalidate the project-specific records in all of them. > I mean that the API interface should not be called ProjectArtifactCache, but > more like ProjectCache, where the first current implementation would > invalidate records in ProjectArtifactCache, but later if new caches are > introduced, the same API call would manage those caches, too. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7027) Invalidate project cache upon changes
[
https://issues.apache.org/jira/browse/MNG-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1740#comment-1740
]
Mickael Istria commented on MNG-7027:
-
Actually, both from m2e and lemminx-maven perspective, having a good solution
for MNG-6616 would be best; m2e and lemminx-maven would only invalidate the
modified project when it's changed and that would still allow to leverage other
parts of the cache.
However, the requirement here would be helpful too; some parts of m2e only
reacts for files modification on disk (to not cascade to recomputation of all
dependency tree on every keystroke), so having cache invalidation on save
without need to call any API would still make those parts functioning without
modification.
> Invalidate project cache upon changes
> -
>
> Key: MNG-7027
> URL: https://issues.apache.org/jira/browse/MNG-7027
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Major
>
> To keep some kind of long-living cache (mvnd does this and I suppose m2e is
> doing it too), the project cache needs to be invalidated (or disabled in the
> case of m2e).
> It would be nice if the cached entries could be invalidated upon changes.
> This could be done only for snapshots maybe (as non snapshots are kind
> supposed to be immutable and that would save quite some processing).
> In order to be non disruptive, I propose the introduction of a new component
> that would monitor files and that could be used by the {{ProjectBuilder}} to
> manage the {{ModelCache}} and also the {{MavenPluginManager}} to manage the
> {{PluginRealmCache}}.
> For the background: {{mvnd}} needs to redefine the {{ProjectBuilder}} and the
> {{PluginRealmCache}} component to work around those problems, but the
> {{DefaultProjectBuilder}} in particular is not really extensible and the
> {{org.apache.maven.project}} package has a lot of package private classes
> that makes defining a replacement class outside of the package quite
> impossible. This intermediate component would offer a pluggable way to solve
> both {{ProjectBuilder}} and {{MavenPluginManager}} problems.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7027) Invalidate project cache upon changes
[
https://issues.apache.org/jira/browse/MNG-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17403317#comment-17403317
]
Mickael Istria commented on MNG-7027:
-
> I'm not sure mutable POM files for non snapshots versions are supported by
> maven. AFAIK, a released pom has always been supposed to be immutable. That's
> the basic assumption when dealing with a maven repository which is cached in
> the local maven repository.
They actually were very well supported when disabling cache fully. This is a
requirement for devtools that would build a model/project on edit/save.
> Invalidate project cache upon changes
> -
>
> Key: MNG-7027
> URL: https://issues.apache.org/jira/browse/MNG-7027
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Major
>
> To keep some kind of long-living cache (mvnd does this and I suppose m2e is
> doing it too), the project cache needs to be invalidated (or disabled in the
> case of m2e).
> It would be nice if the cached entries could be invalidated upon changes.
> This could be done only for snapshots maybe (as non snapshots are kind
> supposed to be immutable and that would save quite some processing).
> In order to be non disruptive, I propose the introduction of a new component
> that would monitor files and that could be used by the {{ProjectBuilder}} to
> manage the {{ModelCache}} and also the {{MavenPluginManager}} to manage the
> {{PluginRealmCache}}.
> For the background: {{mvnd}} needs to redefine the {{ProjectBuilder}} and the
> {{PluginRealmCache}} component to work around those problems, but the
> {{DefaultProjectBuilder}} in particular is not really extensible and the
> {{org.apache.maven.project}} package has a lot of package private classes
> that makes defining a replacement class outside of the package quite
> impossible. This intermediate component would offer a pluggable way to solve
> both {{ProjectBuilder}} and {{MavenPluginManager}} problems.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7027) Invalidate project cache upon changes
[
https://issues.apache.org/jira/browse/MNG-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400215#comment-17400215
]
Mickael Istria commented on MNG-7027:
-
> It would be nice if the cached entries could be invalidated upon changes.
> This could be done only for snapshots maybe (as non snapshots are kind
> supposed to be immutable and that would save quite some processing).
In the lifecycle of an IDE, that is not true: even non-SNAPSHOTs pom files can
be mutable.
> Invalidate project cache upon changes
> -
>
> Key: MNG-7027
> URL: https://issues.apache.org/jira/browse/MNG-7027
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Major
>
> To keep some kind of long-living cache (mvnd does this and I suppose m2e is
> doing it too), the project cache needs to be invalidated (or disabled in the
> case of m2e).
> It would be nice if the cached entries could be invalidated upon changes.
> This could be done only for snapshots maybe (as non snapshots are kind
> supposed to be immutable and that would save quite some processing).
> In order to be non disruptive, I propose the introduction of a new component
> that would monitor files and that could be used by the {{ProjectBuilder}} to
> manage the {{ModelCache}} and also the {{MavenPluginManager}} to manage the
> {{PluginRealmCache}}.
> For the background: {{mvnd}} needs to redefine the {{ProjectBuilder}} and the
> {{PluginRealmCache}} component to work around those problems, but the
> {{DefaultProjectBuilder}} in particular is not really extensible and the
> {{org.apache.maven.project}} package has a lot of package private classes
> that makes defining a replacement class outside of the package quite
> impossible. This intermediate component would offer a pluggable way to solve
> both {{ProjectBuilder}} and {{MavenPluginManager}} problems.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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&focusedCommentId=17400211#comment-17400211 ] Mickael Istria commented on MNG-6530: - I can see the related system property that was introduced to remove cache strategies (and allow pom files to mutate in the lifecycle of the ProjectBuilde) was removed in master/Maven 4, or maybe was it never added? What is the recommendation to disable any form of caching that expects file content is immutable? Or was Maven 4 cache fixed to properly invalidate content (but this wasn't reflected in MNG-7027).-- Note that without a way to disable or invalidate cache, Maven API becomes unusable for m2e and lemminx-maven Language Servers. > 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 >Assignee: Michael Osipov >Priority: Critical > Fix For: 3.6.1 > > Time Spent: 10m > Remaining Estimate: 0h > > 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 (v8.3.4#803005)
[jira] [Commented] (MNG-7215) Maven Site Plugin cannot resolve parent site descriptor without locale
[
https://issues.apache.org/jira/browse/MNG-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400170#comment-17400170
]
Mickael Istria commented on MNG-7215:
-
OK, thanks. I looked at
[https://github.com/apache/maven/pull/321/commits/d478e2a91dc18f8881a7351ed9947cf5a00f5921]
and I think the reason why Maven 4 is both setting the making the test pass
and not setting basedir on repository pom files is because it's using a
different ModelSource (not a FileModelSource nor a pom file) for poms that come
from local repository. That's a good thing.
However, it still seems to me that any plugin that assumes that
project.getBasedir() is enough to decide whether a project is part of the
reactor or not is relying on a very fragile assumption and should improve its
code to rely on mavenSession.getProjects() instead which seems more reliable.
> Maven Site Plugin cannot resolve parent site descriptor without locale
> --
>
> Key: MNG-7215
> URL: https://issues.apache.org/jira/browse/MNG-7215
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2
>Reporter: Slawomir Jaranowski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.8.3
>
>
> Maven site parent descriptor is not resolved by maven 3.8.2.
> Without changing in project, build on maven 3.8.1, I have in logs:
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../src/site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId...
> [DEBUG] No site descriptor found for parentGroupId:artifactId... for locale
> en, trying without locale...
> [DEBUG] Reading parent level 1 site descriptor from .../parent-x.x.x-site.xml
> [INFO] Rendering content with
> org.apache.maven.skins:maven-fluido-skin:jar:1.9 skin.
> {code}
> And with maven 3.8.2
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId
> [DEBUG] No parent level 1 site descriptor.
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> {code}
> Only one difference I see in logs is that in maven 3.8.2 I don't have:
> [DEBUG] No site descriptor found for parentGroupId:artifactId for locale en,
> trying without locale...
> The problem is introduced by commit:
> https://github.com/apache/maven/commit/5a8997312680a4b9c69a129801524691bc546c08
> Similar problem https://github.com/eclipse-ee4j/eclipselink/issues/1242
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7215) Maven Site Plugin cannot resolve parent site descriptor without locale
[
https://issues.apache.org/jira/browse/MNG-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1747#comment-1747
]
Mickael Istria commented on MNG-7215:
-
This test
[https://github.com/apache/maven/commit/5a8997312680a4b9c69a129801524691bc546c08#diff-07febfae60761fe55c18956d192eb8c1f5a6609c02cb4b22e5c686f54c3edd10R88]
covers what I think can be expected from the ModelBuilding API. It apparently
wasn't integrated in Maven 4 (I focused on 3.8.2, so don't know how things have
been ported or not to Maven 4).
> Maven Site Plugin cannot resolve parent site descriptor without locale
> --
>
> Key: MNG-7215
> URL: https://issues.apache.org/jira/browse/MNG-7215
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2
>Reporter: Slawomir Jaranowski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.8.3
>
>
> Maven site parent descriptor is not resolved by maven 3.8.2.
> Without changing in project, build on maven 3.8.1, I have in logs:
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../src/site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId...
> [DEBUG] No site descriptor found for parentGroupId:artifactId... for locale
> en, trying without locale...
> [DEBUG] Reading parent level 1 site descriptor from .../parent-x.x.x-site.xml
> [INFO] Rendering content with
> org.apache.maven.skins:maven-fluido-skin:jar:1.9 skin.
> {code}
> And with maven 3.8.2
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId
> [DEBUG] No parent level 1 site descriptor.
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> {code}
> Only one difference I see in logs is that in maven 3.8.2 I don't have:
> [DEBUG] No site descriptor found for parentGroupId:artifactId for locale en,
> trying without locale...
> The problem is introduced by commit:
> https://github.com/apache/maven/commit/5a8997312680a4b9c69a129801524691bc546c08
> Similar problem https://github.com/eclipse-ee4j/eclipselink/issues/1242
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7215) Maven Site Plugin cannot resolve parent site descriptor without locale
[
https://issues.apache.org/jira/browse/MNG-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1736#comment-1736
]
Mickael Istria commented on MNG-7215:
-
The intention of MNG-7170 is to set the pomFile when passing a FileModelSource,
because it's the only entry point in the API that allow to build a "dirty" (not
saved) content toreport error without saving file. Setting the pomFile makes
further steps (eg computation of basedir and other properties) work as expected.
So if Maven 4 doesn't do that, then Maven 4 is, quite similarly to Maven 3.8.1,
not able to be used efficiently for as-you-type validation and not suitable for
usage in a language server or IDE that would want to provde reliable fast
feedback.
The change I introduced is IMO not a bug; the fact that DefaultSiteTool uses a
not explicit nor documented nor specified ssumption to verify a project is in
the reactor or not when there is some API that's almost inteded to verify that
is IMO the real bug here. My former change unveils that some plugins have
relied on something they shouldn't rely, and has increased usability of Maven
API to build pom.xml edition tool while also improving the API. IMO, it's not
really what needs to be reverted or fixed.
> Maven Site Plugin cannot resolve parent site descriptor without locale
> --
>
> Key: MNG-7215
> URL: https://issues.apache.org/jira/browse/MNG-7215
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2
>Reporter: Slawomir Jaranowski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.8.3
>
>
> Maven site parent descriptor is not resolved by maven 3.8.2.
> Without changing in project, build on maven 3.8.1, I have in logs:
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../src/site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId...
> [DEBUG] No site descriptor found for parentGroupId:artifactId... for locale
> en, trying without locale...
> [DEBUG] Reading parent level 1 site descriptor from .../parent-x.x.x-site.xml
> [INFO] Rendering content with
> org.apache.maven.skins:maven-fluido-skin:jar:1.9 skin.
> {code}
> And with maven 3.8.2
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId
> [DEBUG] No parent level 1 site descriptor.
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> {code}
> Only one difference I see in logs is that in maven 3.8.2 I don't have:
> [DEBUG] No site descriptor found for parentGroupId:artifactId for locale en,
> trying without locale...
> The problem is introduced by commit:
> https://github.com/apache/maven/commit/5a8997312680a4b9c69a129801524691bc546c08
> Similar problem https://github.com/eclipse-ee4j/eclipselink/issues/1242
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7215) Maven Site Plugin cannot resolve parent site descriptor without locale
[
https://issues.apache.org/jira/browse/MNG-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1731#comment-1731
]
Mickael Istria commented on MNG-7215:
-
>I have checked Maven 4 (debugged): the POM isn't set so isn't basedir.
So Maven 4 will also suffer from MNG-7170 ?
> I know and I fully agree, unfortunately I don't see a reasonable solution for
> this now, do you see one?
IMO, plugins that have assumed that project.getBasedir() == null has a semantic
about the reactor have just written erroneous code and relied on a side-effect;
without investing in covering it with a test or some documentation. Consumers
using bad code is not a reason for a platform to reduce its quality; on the
contrary.
So concretely, I'd just let the code as it and let plugins that have used this
bad code fix their code to use what seems to be the intended API
(session.getProjects().contains(...)).
> Maven Site Plugin cannot resolve parent site descriptor without locale
> --
>
> Key: MNG-7215
> URL: https://issues.apache.org/jira/browse/MNG-7215
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2
>Reporter: Slawomir Jaranowski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.8.3
>
>
> Maven site parent descriptor is not resolved by maven 3.8.2.
> Without changing in project, build on maven 3.8.1, I have in logs:
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../src/site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId...
> [DEBUG] No site descriptor found for parentGroupId:artifactId... for locale
> en, trying without locale...
> [DEBUG] Reading parent level 1 site descriptor from .../parent-x.x.x-site.xml
> [INFO] Rendering content with
> org.apache.maven.skins:maven-fluido-skin:jar:1.9 skin.
> {code}
> And with maven 3.8.2
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId
> [DEBUG] No parent level 1 site descriptor.
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> {code}
> Only one difference I see in logs is that in maven 3.8.2 I don't have:
> [DEBUG] No site descriptor found for parentGroupId:artifactId for locale en,
> trying without locale...
> The problem is introduced by commit:
> https://github.com/apache/maven/commit/5a8997312680a4b9c69a129801524691bc546c08
> Similar problem https://github.com/eclipse-ee4j/eclipselink/issues/1242
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7215) Maven Site Plugin cannot resolve parent site descriptor without locale
[
https://issues.apache.org/jira/browse/MNG-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17399983#comment-17399983
]
Mickael Istria commented on MNG-7215:
-
> lack of documentation
and tests.
Note that reverting will actually be another form of regression, as the API to
build project models will then send errors in some cases when it shouldn't; and
some model would have pomFile set to null when the modelSource actually has all
pom infos.
IMO, reverting is not the right approach, and the current state of Maven is
more correct from API POV. Reverting reduces quality of the library.
> Maven Site Plugin cannot resolve parent site descriptor without locale
> --
>
> Key: MNG-7215
> URL: https://issues.apache.org/jira/browse/MNG-7215
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2
>Reporter: Slawomir Jaranowski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.8.3
>
>
> Maven site parent descriptor is not resolved by maven 3.8.2.
> Without changing in project, build on maven 3.8.1, I have in logs:
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../src/site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId...
> [DEBUG] No site descriptor found for parentGroupId:artifactId... for locale
> en, trying without locale...
> [DEBUG] Reading parent level 1 site descriptor from .../parent-x.x.x-site.xml
> [INFO] Rendering content with
> org.apache.maven.skins:maven-fluido-skin:jar:1.9 skin.
> {code}
> And with maven 3.8.2
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId
> [DEBUG] No parent level 1 site descriptor.
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> {code}
> Only one difference I see in logs is that in maven 3.8.2 I don't have:
> [DEBUG] No site descriptor found for parentGroupId:artifactId for locale en,
> trying without locale...
> The problem is introduced by commit:
> https://github.com/apache/maven/commit/5a8997312680a4b9c69a129801524691bc546c08
> Similar problem https://github.com/eclipse-ee4j/eclipselink/issues/1242
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7215) maven site - parent descriptor without locale is not resolved
[
https://issues.apache.org/jira/browse/MNG-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17399965#comment-17399965
]
Mickael Istria commented on MNG-7215:
-
Apparently the change cause that all projects now have the basedir set while it
used to be only the case for reactor projects. So the result of
`project.getBasedine()` is now different for non-reactor projects. I don't know
whether this is breaking some API contract of Maven. At least, no test was
covering that and no Javadoc declares that, so one can assume it's not a
reliable assumption to use for plugins.
If the goal is to know whether a project is in the reactor, one could use
`session.getProjects().contains(project)` instead, which seems more reliable.
> maven site - parent descriptor without locale is not resolved
> -
>
> Key: MNG-7215
> URL: https://issues.apache.org/jira/browse/MNG-7215
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2
>Reporter: Slawomir Jaranowski
>Priority: Critical
>
> Maven site parent descriptor is not resolved by maven 3.8.2.
> Without changing in project, build on maven 3.8.1, I have in logs:
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../src/site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId...
> [DEBUG] No site descriptor found for parentGroupId:artifactId... for locale
> en, trying without locale...
> [DEBUG] Reading parent level 1 site descriptor from .../parent-x.x.x-site.xml
> [INFO] Rendering content with
> org.apache.maven.skins:maven-fluido-skin:jar:1.9 skin.
> {code}
> And with maven 3.8.2
> {code}
> [INFO] Rendering site with default locale English (en)
> [DEBUG] Computing decoration model of groupId:artifactId for locale en
> [DEBUG] Reading site descriptor from .../site/site.xml
> [DEBUG] Looking for site descriptor of level 1 parent project:
> parentGroupId:artifactId
> [DEBUG] No parent level 1 site descriptor.
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> {code}
> Only one difference I see in logs is that in maven 3.8.2 I don't have:
> [DEBUG] No site descriptor found for parentGroupId:artifactId for locale en,
> trying without locale...
> The problem is introduced by commit:
> https://github.com/apache/maven/commit/5a8997312680a4b9c69a129801524691bc546c08
> Similar problem https://github.com/eclipse-ee4j/eclipselink/issues/1242
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7170) Allow to associate pomFile/${basedir} with DefaultProjectBuilder.build(ModelSource, ...)
[
https://issues.apache.org/jira/browse/MNG-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17370437#comment-17370437
]
Mickael Istria commented on MNG-7170:
-
Thanks a lot for the review and merge [~michael-o] !
> Allow to associate pomFile/${basedir} with
> DefaultProjectBuilder.build(ModelSource, ...)
>
>
> Key: MNG-7170
> URL: https://issues.apache.org/jira/browse/MNG-7170
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.8.1
>Reporter: Mickael Istria
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2
>
>
> In LemMinX-Maven Language Server for pom.xml files, we're building models
> from "working copy" (unsaved) pom files. We do so by invoking
> {code}DefaultProjectBuilder.build( ModelSource modelSource,
> ProjectBuildingRequest request ){code}
> One pitfall is that this cascades to pomFile being null for the Model, and as
> a result {code}${basedir}{code} is not resolved.
> One could expect that the {code}ModelSource2.getLocationURI(){code} could be
> used to derive the pomFile when possible. LemMinX-Maven happens to properly
> set this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7170) Allow to associate pomFile/${basedir} with DefaultProjectBuilder.build(ModelSource, ...)
[
https://issues.apache.org/jira/browse/MNG-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361756#comment-17361756
]
Mickael Istria commented on MNG-7170:
-
I've implemented a workaround:
[https://github.com/eclipse/lemminx-maven/commit/2e553da35bcc2495887f9d72209c84085ab433eb]
Feel free to close as won't fix if 3.8.2 will never happen
> Allow to associate pomFile/${basedir} with
> DefaultProjectBuilder.build(ModelSource, ...)
>
>
> Key: MNG-7170
> URL: https://issues.apache.org/jira/browse/MNG-7170
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.8.1
>Reporter: Mickael Istria
>Priority: Major
>
> In LemMinX-Maven Language Server for pom.xml files, we're building models
> from "working copy" (unsaved) pom files. We do so by invoking
> {code}DefaultProjectBuilder.build( ModelSource modelSource,
> ProjectBuildingRequest request ){code}
> One pitfall is that this cascades to pomFile being null for the Model, and as
> a result {code}${basedir}{code} is not resolved.
> One could expect that the {code}ModelSource2.getLocationURI(){code} could be
> used to derive the pomFile when possible. LemMinX-Maven happens to properly
> set this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7170) Allow to associate pomFile/${basedir} with DefaultProjectBuilder.build(ModelSource, ...)
[
https://issues.apache.org/jira/browse/MNG-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361669#comment-17361669
]
Mickael Istria commented on MNG-7170:
-
> The model itself shouldn't need this information. The Reader of the Model
> already says {{read ModelSource X}} so it knows the location.
I agree it would be best. A setter here is probably the cause why the getter
returns null in some cases: the issue with getters is that it's never clear
who's supposed to call them.
So do I understand it right that there will be no Maven 3.8.2? When is Maven
4.0 expected to be released?
> Allow to associate pomFile/${basedir} with
> DefaultProjectBuilder.build(ModelSource, ...)
>
>
> Key: MNG-7170
> URL: https://issues.apache.org/jira/browse/MNG-7170
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.8.1
>Reporter: Mickael Istria
>Priority: Major
>
> In LemMinX-Maven Language Server for pom.xml files, we're building models
> from "working copy" (unsaved) pom files. We do so by invoking
> {code}DefaultProjectBuilder.build( ModelSource modelSource,
> ProjectBuildingRequest request ){code}
> One pitfall is that this cascades to pomFile being null for the Model, and as
> a result {code}${basedir}{code} is not resolved.
> One could expect that the {code}ModelSource2.getLocationURI(){code} could be
> used to derive the pomFile when possible. LemMinX-Maven happens to properly
> set this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7170) Allow to associate pomFile/${basedir} with DefaultProjectBuilder.build(ModelSource, ...)
[
https://issues.apache.org/jira/browse/MNG-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361585#comment-17361585
]
Mickael Istria commented on MNG-7170:
-
Patch
[https://github.com/apache/maven/commit/5cdb8332f99a36e5a1da202da43e3c7dfbb49322]
for MNG-5669 has fixed that for master/Maven 4.
I tried to apply it to maven-3.8.1 but it seems to have important dependencies
on some major Maven 4 commits; so it seems tricky to backport it fully. So I've
just reincorporate the related changes, added a test and submitted a PR for the
maven-3.8.x branch: https://github.com/apache/maven/pull/478
> Allow to associate pomFile/${basedir} with
> DefaultProjectBuilder.build(ModelSource, ...)
>
>
> Key: MNG-7170
> URL: https://issues.apache.org/jira/browse/MNG-7170
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.8.1
>Reporter: Mickael Istria
>Priority: Major
>
> In LemMinX-Maven Language Server for pom.xml files, we're building models
> from "working copy" (unsaved) pom files. We do so by invoking
> {code}DefaultProjectBuilder.build( ModelSource modelSource,
> ProjectBuildingRequest request ){code}
> One pitfall is that this cascades to pomFile being null for the Model, and as
> a result {code}${basedir}{code} is not resolved.
> One could expect that the {code}ModelSource2.getLocationURI(){code} could be
> used to derive the pomFile when possible. LemMinX-Maven happens to properly
> set this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7170) Allow to associate pomFile/${basedir} with DefaultProjectBuilder.build(ModelSource, ...)
[
https://issues.apache.org/jira/browse/MNG-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17359826#comment-17359826
]
Mickael Istria commented on MNG-7170:
-
I wrote a test that reproduces the issues for 3.8.1:
[https://github.com/mickaelistria/maven/tree/test-MNG-7170-3.8.1
]Same test against master seems to pass:
[https://github.com/mickaelistria/maven/tree/test-MNG-7170-4.0|https://github.com/mickaelistria/maven/tree/test-MNG-7170-3.8.1]
I'll keep investigating sort out which commit does introduce the probable fix
to find out whether this cna be leveraged downstream easily, or whether a 3.8.2
seems to be a requirement.
> Allow to associate pomFile/${basedir} with
> DefaultProjectBuilder.build(ModelSource, ...)
>
>
> Key: MNG-7170
> URL: https://issues.apache.org/jira/browse/MNG-7170
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.8.1
>Reporter: Mickael Istria
>Priority: Major
>
> In LemMinX-Maven Language Server for pom.xml files, we're building models
> from "working copy" (unsaved) pom files. We do so by invoking
> {code}DefaultProjectBuilder.build( ModelSource modelSource,
> ProjectBuildingRequest request ){code}
> One pitfall is that this cascades to pomFile being null for the Model, and as
> a result {code}${basedir}{code} is not resolved.
> One could expect that the {code}ModelSource2.getLocationURI(){code} could be
> used to derive the pomFile when possible. LemMinX-Maven happens to properly
> set this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-7170) Allow to associate pomFile/${basedir} with DefaultProjectBuilder.build(ModelSource, ...)
Mickael Istria created MNG-7170:
---
Summary: Allow to associate pomFile/${basedir} with
DefaultProjectBuilder.build(ModelSource, ...)
Key: MNG-7170
URL: https://issues.apache.org/jira/browse/MNG-7170
Project: Maven
Issue Type: Improvement
Components: core
Affects Versions: 3.8.1
Reporter: Mickael Istria
In LemMinX-Maven Language Server for pom.xml files, we're building models from
"working copy" (unsaved) pom files. We do so by invoking
{code}DefaultProjectBuilder.build( ModelSource modelSource,
ProjectBuildingRequest request ){code}
One pitfall is that this cascades to pomFile being null for the Model, and as a
result {code}${basedir}{code} is not resolved.
One could expect that the {code}ModelSource2.getLocationURI(){code} could be
used to derive the pomFile when possible. LemMinX-Maven happens to properly set
this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MPLUGIN-366) Make maven-plugin-plugin:descriptor m2e friendly by using BuildContext and declaring metadata
Mickael Istria created MPLUGIN-366: -- Summary: Make maven-plugin-plugin:descriptor m2e friendly by using BuildContext and declaring metadata Key: MPLUGIN-366 URL: https://issues.apache.org/jira/browse/MPLUGIN-366 Project: Maven Plugin Tools Issue Type: Improvement Reporter: Mickael Istria The maven-plugin-plugin should implement the patterns described in [https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html] to improve compatibility with incremental project builders (eg Eclipse m2e). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MASSEMBLY-942) Make "single" goal m2e-friendly by using BuildContext
Mickael Istria created MASSEMBLY-942: Summary: Make "single" goal m2e-friendly by using BuildContext Key: MASSEMBLY-942 URL: https://issues.apache.org/jira/browse/MASSEMBLY-942 Project: Maven Assembly Plugin Issue Type: Improvement Components: maven-archiver Reporter: Mickael Istria When using the maven-assembly-plugin "single" goal in Eclipse m2e, it shows the usual errors regarding unsupported goals. For best results in m2e (and all consumers, and for non-CLI builds in general), the maven-assembly-plugin should leverage BuildContext and declare m2e capabilities, as described in https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6911) Allow the Maven model cache tto recache a maven model on request
[
https://issues.apache.org/jira/browse/MNG-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17113498#comment-17113498
]
Mickael Istria commented on MNG-6911:
-
I think one possible strategy is for the global cache to keep the reference to
pom file and its "lastModifiedTimestamp" of the pom file when parsing it, and
verify that the actual underlying file didn't change before returning it, or
just discard the if some change happened..
> Allow the Maven model cache tto recache a maven model on request
>
>
> Key: MNG-6911
> URL: https://issues.apache.org/jira/browse/MNG-6911
> Project: Maven
> Issue Type: Bug
> Components: IDEs, POM
>Affects Versions: 3.6.3
> Environment: Linux (Fedora 30-32)
>Reporter: Andrew Obuchowicz
>Priority: Major
>
> Hi, I'm one of the developers of
> [LemMinX-Maven|[https://github.com/eclipse/lemminx-maven]|https://github.com/eclipse/lemminx-maven],]
> which is a project that implements the Language Server Protocol for editing
> Maven pom.xml files (any LSP client editor can easily gain pom.xml editing
> features with this project).
>
> We've encountered an
> [issue|[https://github.com/eclipse/lemminx-maven/pull/67]] where
> modifications to a parent pom (such as adding a new property) are not
> reflected in the child pom, as the global model cache has an outdated version
> of the parent pom (before the modification was made).
>
> Disabling the global model cache works as a temporary workaround, eg.
>
> {code:java}
> System.setProperty(DefaultProjectBuilder.DISABLE_GLOBAL_MODEL_CACHE_SYSTEM_PROPERTY,
> Boolean.toString(true));
> {code}
>
> However, we'd still like to use the model cache and not have to disable it
> entirely.
>
> Thus, it would be beneficial if the model cache could "uncache" (or refresh)
> a pom that has been modified. From our project, we can easily detect when a
> pom.xml has been modified, thus tracking pom modifications does not need to
> be implemented. *What is required on the Maven API side* is to be able to
> signal that a pom.xml has been modified, and should be recached with the new
> modifications.
>
> Also, I apologize in advance if this was reported under the wrong project or
> component. Feel free to place it where it should be.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1776) DefaultReportFactory doesn't report errors when engine fails
[ https://issues.apache.org/jira/browse/SUREFIRE-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17085504#comment-17085504 ] Mickael Istria commented on SUREFIRE-1776: -- So I managed to identify the root cause of the issue (which is not requiring OSGi per se): JUnit5 throws a lot of NoClassDefFound when mixing a 5.x engine with a 5.y API. This mix is what causes the error to happen before the test starts. The failure itself is fine and to be handled better in Tycho, nothing Surefire should/can do about it. But still, DefaultReportFactory shouldn't ignore unrooted errors. However it seems like this class is gone in surefire 3.x so hopefully this issue vanished as well. I don't have the opportunity to try the surefire-snapshots soon especially since we use it as API in Tycho, changing it requires to adapt some consumer code and it's not currently something we can afford in the Tycho project at the moment. Maybe later. > DefaultReportFactory doesn't report errors when engine fails > > > Key: SUREFIRE-1776 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1776 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.22.0 >Reporter: Mickael Istria >Priority: Major > > We face an issue with tycho-surefire-plugin reporting "No tests found" when a > test is actually found but the engine fails (for a tycho-specific reason) > when preparing the test. > tycho-surefire-plugin basically builds an OSGi container as defined in the > usual Tycho way and uses Surefire API to run the tests inside that container > and report it as a plain surefire does regularly. > To do so, it does mainly uses `RunResult result = > ProviderFactory.invokeProvider(...)`. However, it can happen that an error > happen in the engine, before any test method starts (although the test method > is scanned and detected and an executionRequest is emitted for it). The cases > for it are relatively probable with Tycho/OSGi. > In such case, even if the engine faced an error, we get a RunResult > mentioning no error, actually reporting no test execution, but no error, > usually making the test report say everything is fine or telling "No tests > found" (which is also incorrect because test is found, it could not just be > started). > I could dig a bit more and I think the > DefaultTestReporter.mergeTestHistoryResult() method just fails at handling > the cases of errors when the error do not happen on the test method, because > it wrongly assumes that `listener.getTestMethodStats()` is exhaustive. > More specifically, when debugging this method, I do see in debugger that > `this.listeners[0].detailsForThis` has `completedCount==1` and `errors==1` > but the return value says completedCount==0 and errors=0; its reportEntries > show one error entry, which has for source `` so they're not > returned by `listener.getTestMethodStats()`. > I believe the DefaultReportFactory should handle the case to verify before > returning whether such unrooted error wasn't missed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1776) DefaultReportFactory doesn't report errors when engine fails
Mickael Istria created SUREFIRE-1776: Summary: DefaultReportFactory doesn't report errors when engine fails Key: SUREFIRE-1776 URL: https://issues.apache.org/jira/browse/SUREFIRE-1776 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.22.0 Reporter: Mickael Istria We face an issue with tycho-surefire-plugin reporting "No tests found" when a test is actually found but the engine fails (for a tycho-specific reason) when preparing the test. tycho-surefire-plugin basically builds an OSGi container as defined in the usual Tycho way and uses Surefire API to run the tests inside that container and report it as a plain surefire does regularly. To do so, it does mainly uses `RunResult result = ProviderFactory.invokeProvider(...)`. However, it can happen that an error happen in the engine, before any test method starts (although the test method is scanned and detected and an executionRequest is emitted for it). The cases for it are relatively probable with Tycho/OSGi. In such case, even if the engine faced an error, we get a RunResult mentioning no error, actually reporting no test execution, but no error, usually making the test report say everything is fine or telling "No tests found" (which is also incorrect because test is found, it could not just be started). I could dig a bit more and I think the DefaultTestReporter.mergeTestHistoryResult() method just fails at handling the cases of errors when the error do not happen on the test method, because it wrongly assumes that `listener.getTestMethodStats()` is exhaustive. More specifically, when debugging this method, I do see in debugger that `this.listeners[0].detailsForThis` has `completedCount==1` and `errors==1` but the return value says completedCount==0 and errors=0; its reportEntries show one error entry, which has for source `` so they're not returned by `listener.getTestMethodStats()`. I believe the DefaultReportFactory should handle the case to verify before returning whether such unrooted error wasn't missed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-6849) maven-dependency-plugin:copy goal should define m2e metadata
Mickael Istria created MNG-6849: --- Summary: maven-dependency-plugin:copy goal should define m2e metadata Key: MNG-6849 URL: https://issues.apache.org/jira/browse/MNG-6849 Project: Maven Issue Type: Improvement Components: Dependencies Reporter: Mickael Istria I often use the maven-dependency-plugon:copy goal for packaging purpose. However, Eclipse m2e complains that "plugin execution isn't covered...". This could be improved by adding just m2e lifecycle mapping metadata and leveraging the BuildContext API: https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6765) [Regression] tycho pom-less builds fails with 3.6.2
[
https://issues.apache.org/jira/browse/MNG-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954985#comment-16954985
]
Mickael Istria commented on MNG-6765:
-
https://ci.eclipse.org/tycho/job/tycho-build-with-maven-snapshots/43/ confirms
that Eclipse Tycho, which had failing test for pom-less with 3.6.3-SNAPSHOT
last week, seems to work fine with
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6765/2/artifact/org/apache/maven/apache-maven/3.6.3-SNAPSHOT/apache-maven-3.6.3-SNAPSHOT-bin.tar.gz
> [Regression] tycho pom-less builds fails with 3.6.2
> ---
>
> Key: MNG-6765
> URL: https://issues.apache.org/jira/browse/MNG-6765
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Jonathan Chen
>Assignee: Robert Scholte
>Priority: Critical
>
> Projects using tycho pom-less builds fail with maven-3.6.2.
> One such example would be using maven-3.6.2 to build Eclipse-4.13, which
> fails pretty early in the build with:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation10/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation11/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.feature/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se12/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se13/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se14/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se15/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase16/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase17/.polyglot.build.properties:
> input contained no data @
> ...
> {noformat}
> These errors do not arise with maven-3.6.0 or maven-3.6.1
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6765) [Regression] tycho pom-less builds fails with 3.6.2
[
https://issues.apache.org/jira/browse/MNG-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941304#comment-16941304
]
Mickael Istria commented on MNG-6765:
-
This is now surfacing in Tycho tests against snapshot:
https://ci.eclipse.org/tycho/job/tycho-build-with-maven-snapshots/41/
When a patch is merged and snapshot is built, just running this job should
highlight whether it fixes the Tycho case or not.
> [Regression] tycho pom-less builds fails with 3.6.2
> ---
>
> Key: MNG-6765
> URL: https://issues.apache.org/jira/browse/MNG-6765
> Project: Maven
> Issue Type: Bug
>Reporter: Jonathan Chen
>Priority: Major
>
> Projects using tycho pom-less builds fail with maven-3.6.2.
> One such example would be using maven-3.6.2 to build Eclipse-4.13, which
> fails pretty early in the build with:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation10/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation11/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.feature/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se12/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se13/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se14/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se15/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase16/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase17/.polyglot.build.properties:
> input contained no data @
> ...
> {noformat}
> These errors do not arise with maven-3.6.0 or maven-3.6.1
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6740) Provide a way to override properties of a polyglot build
[ https://issues.apache.org/jira/browse/MNG-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911359#comment-16911359 ] Mickael Istria commented on MNG-6740: - Actually, it also looks like something that's not in Maven Core, but instead in polyglot-maven: https://github.com/takari/polyglot-maven/issues/new > Provide a way to override properties of a polyglot build > > > Key: MNG-6740 > URL: https://issues.apache.org/jira/browse/MNG-6740 > Project: Maven > Issue Type: New Feature >Reporter: Christoph Läubrich >Priority: Major > > polyglot allows to generate maven models out of other metadata that pom.xml > via extensions. > This is great and offers high flexibility for advanced use-cases but comes > with the cost that it is not as easy to modify certain settings or properties > if the data is derived from other sources. > For example [Eclipse Tycho|https://www.eclipse.org/tycho/] generates models > out of OSGi/PDE metadata but can often only guess what is the right thing to > use for example as artifactId, and it can't know of any custom properties a > user might wish to set. > While it is always possible to create custom crafted poms, this contradicts > the approach which goal is to reuse as many metadata as possible, and the > user only wants do configure a really small portion of it (e.g. the > description or a single poperty). > [A proposal was made to integrate support for this inside the tycho > extension|https://bugs.eclipse.org/bugs/show_bug.cgi?id=550239], but because > it might be of wider use I'd like to evaluate (as suggestes by Mickael > Istria) if it is possible to implement/add this as a more generic feature > directly into the maven project. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6742) org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files ending in.xml
[
https://issues.apache.org/jira/browse/MNG-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911308#comment-16911308
]
Mickael Istria commented on MNG-6742:
-
Shouldn't it be reported to https://github.com/takari/polyglot-maven/issues
instead?
> org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files
> ending in.xml
> ---
>
> Key: MNG-6742
> URL: https://issues.apache.org/jira/browse/MNG-6742
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Blocker
>
> in org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) there is
> the following code:
> {code:java}
> File pomFile = manager.locatePom(dir);
> if (pomFile != null && !pomFile.getName().endsWith(".pom") &&
> !pomFile.getName().endsWith(".xml")) {
> ...
> }
> {code}
> This makes it impossible to return any file with xml ending as alternative to
> pom.xml, in my case data is stored in a file named category.xml and i can't
> use ist because then my Mapping is never called.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6742) org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files ending in.xml
[
https://issues.apache.org/jira/browse/MNG-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911283#comment-16911283
]
Mickael Istria commented on MNG-6742:
-
This is blocking https://bugs.eclipse.org/bugs/show_bug.cgi?id=490886.
Tycho hacked this for feature.xml by assuming there is always a
build.properties file with it, but it's a hack and cannot be relied upon for
some other types.
I suggest we just fix it in Maven by refining the condition.
> org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) ignores files
> ending in.xml
> ---
>
> Key: MNG-6742
> URL: https://issues.apache.org/jira/browse/MNG-6742
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Blocker
>
> in org.sonatype.maven.polyglot.TeslaModelProcessor.locatePom(File) there is
> the following code:
> {code:java}
> File pomFile = manager.locatePom(dir);
> if (pomFile != null && !pomFile.getName().endsWith(".pom") &&
> !pomFile.getName().endsWith(".xml")) {
> ...
> }
> {code}
> This makes it impossible to return any file with xml ending as alternative to
> pom.xml, in my case data is stored in a file named category.xml and i can't
> use ist because then my Mapping is never called.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6740) Provide a way to override properties of a polyglot build
[ https://issues.apache.org/jira/browse/MNG-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911209#comment-16911209 ] Mickael Istria commented on MNG-6740: - +1 for this feature in Maven. Most polyglot extensions will have such caveats as some missing Maven properties to infer, Maven should provide a generic way to fill the gap. In the proposal, it's about a properties file, but I imagine it could also (or maybe better) take the form of a partial pom file with only the few additional properties or elements to complete what the extension generates. > Provide a way to override properties of a polyglot build > > > Key: MNG-6740 > URL: https://issues.apache.org/jira/browse/MNG-6740 > Project: Maven > Issue Type: New Feature >Reporter: Christoph Läubrich >Priority: Major > > polyglot allows to generate maven models out of other metadata that pom.xml > via extensions. > This is great and offers high flexibility for advanced use-cases but comes > with the cost that it is not as easy to modify certain settings or properties > if the data is derived from other sources. > For example [Eclipse Tycho|https://www.eclipse.org/tycho/] generates models > out of OSGi/PDE metadata but can often only guess what is the right thing to > use for example as artifactId, and it can't know of any custom properties a > user might wish to set. > While it is always possible to create custom crafted poms, this contradicts > the approach which goal is to reuse as many metadata as possible, and the > user only wants do configure a really small portion of it (e.g. the > description or a single poperty). > [A proposal was made to integrate support for this inside the tycho > extension|https://bugs.eclipse.org/bugs/show_bug.cgi?id=550239], but because > it might be of wider use I'd like to evaluate (as suggestes by Mickael > Istria) if it is possible to implement/add this as a more generic feature > directly into the maven project. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6642) Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
[
https://issues.apache.org/jira/browse/MNG-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907288#comment-16907288
]
Mickael Istria commented on MNG-6642:
-
FWIW, I think maintenance branches really add a lot of complexity and cost to
the project maintenance.
As a consumer and user, I would rather see Maven project getting more into a
rolling 1-click release process, just answering the question "is the current
state any better than previous release" and be ready to release whenever there
is a request and state is not worth (ie all test pass). That would IMO provide
much more value to everyone and once setup, it wouldn't cost anything to run a
release. For example, although there are still known bugs on master, if those
are not regressions, I don't really get why they would be blocking a highly
requested release.
The Eclipse SDK (Platform, JDT, PDE) recently dropped intensive usage of
maintenance branch, and it was a huge relief for the contributors, maintainers,
users... as more effort were put in master and value was delivered much faster
and the project attracted new contributors thanks to that.
> Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
> --
>
> Key: MNG-6642
> URL: https://issues.apache.org/jira/browse/MNG-6642
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Francesco Chicchiriccò
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.2
>
>
> Build does not work with Maven 3.6.1 (works fine with Maven 3.6.0).
> How to reproduce:
> # git clone https://github.com/apache/syncope.git
> # git checkout 2_1_X
> # $M2_HOME/bin/mvn clean
> When {{M2_HOME}} points to 3.6.0, build goes fine.
> When {{M2_HOME}} points to 3.6.1, the following output is reported:
> {code}
> [INFO] Scanning for projects...
> [INFO] Computing target platform for MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] Resolving dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true,
> osgi.arch=x86}
> [ERROR] Cannot resolve project dependencies:
> [ERROR] Software being installed: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier
> [ERROR] Missing requirement: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not
> be found
> [ERROR]
> [ERROR] See
> http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
> [ERROR] Cannot resolve dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml:
> See log for details -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6642) Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
[
https://issues.apache.org/jira/browse/MNG-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903320#comment-16903320
]
Mickael Istria commented on MNG-6642:
-
There are discussions on the d...@maven.apache.org mailing-list. 2 bugs are to
be closed before a release happen, both have patches but some other issues
(test stability) are considered as blocker before merging the patches and doing
the release.
You can join the lobbying game on the mailing-list, it's where things seem to
work the most efficiently for Maven (as opposed to Eclipse world where
contributors usually get more influence on specific tickets).
> Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
> --
>
> Key: MNG-6642
> URL: https://issues.apache.org/jira/browse/MNG-6642
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Francesco Chicchiriccò
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.2
>
>
> Build does not work with Maven 3.6.1 (works fine with Maven 3.6.0).
> How to reproduce:
> # git clone https://github.com/apache/syncope.git
> # git checkout 2_1_X
> # $M2_HOME/bin/mvn clean
> When {{M2_HOME}} points to 3.6.0, build goes fine.
> When {{M2_HOME}} points to 3.6.1, the following output is reported:
> {code}
> [INFO] Scanning for projects...
> [INFO] Computing target platform for MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] Resolving dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true,
> osgi.arch=x86}
> [ERROR] Cannot resolve project dependencies:
> [ERROR] Software being installed: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier
> [ERROR] Missing requirement: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not
> be found
> [ERROR]
> [ERROR] See
> http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
> [ERROR] Cannot resolve dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml:
> See log for details -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6642) Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
[
https://issues.apache.org/jira/browse/MNG-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903301#comment-16903301
]
Mickael Istria commented on MNG-6642:
-
This Tycho CI job also checks compatibility with latest Maven snapshot:
https://ci.eclipse.org/tycho/job/tycho-build-with-maven-snapshots/
> Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
> --
>
> Key: MNG-6642
> URL: https://issues.apache.org/jira/browse/MNG-6642
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Francesco Chicchiriccò
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.2
>
>
> Build does not work with Maven 3.6.1 (works fine with Maven 3.6.0).
> How to reproduce:
> # git clone https://github.com/apache/syncope.git
> # git checkout 2_1_X
> # $M2_HOME/bin/mvn clean
> When {{M2_HOME}} points to 3.6.0, build goes fine.
> When {{M2_HOME}} points to 3.6.1, the following output is reported:
> {code}
> [INFO] Scanning for projects...
> [INFO] Computing target platform for MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] Resolving dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true,
> osgi.arch=x86}
> [ERROR] Cannot resolve project dependencies:
> [ERROR] Software being installed: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier
> [ERROR] Missing requirement: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not
> be found
> [ERROR]
> [ERROR] See
> http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
> [ERROR] Cannot resolve dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml:
> See log for details -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6642) Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
[
https://issues.apache.org/jira/browse/MNG-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903134#comment-16903134
]
Mickael Istria commented on MNG-6642:
-
Snapshot repo for Maven 3.6.2-SNAPSHOT:
https://repository.apache.org/content/groups/public/
Binary build for Maven 3.6.2-SNAPSHOT:
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/master/lastSuccessfulBuild/artifact/org/apache/maven/apache-maven/3.6.2-SNAPSHOT/apache-maven-3.6.2-SNAPSHOT-bin.tar.gz
> Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
> --
>
> Key: MNG-6642
> URL: https://issues.apache.org/jira/browse/MNG-6642
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Francesco Chicchiriccò
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.2
>
>
> Build does not work with Maven 3.6.1 (works fine with Maven 3.6.0).
> How to reproduce:
> # git clone https://github.com/apache/syncope.git
> # git checkout 2_1_X
> # $M2_HOME/bin/mvn clean
> When {{M2_HOME}} points to 3.6.0, build goes fine.
> When {{M2_HOME}} points to 3.6.1, the following output is reported:
> {code}
> [INFO] Scanning for projects...
> [INFO] Computing target platform for MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] Resolving dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true,
> osgi.arch=x86}
> [ERROR] Cannot resolve project dependencies:
> [ERROR] Software being installed: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier
> [ERROR] Missing requirement: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not
> be found
> [ERROR]
> [ERROR] See
> http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
> [ERROR] Cannot resolve dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml:
> See log for details -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MNG-6642) Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
[
https://issues.apache.org/jira/browse/MNG-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903134#comment-16903134
]
Mickael Istria edited comment on MNG-6642 at 8/8/19 4:44 PM:
-
Snapshot repo for Maven 3.6.2-SNAPSHOT:
https://repository.apache.org/content/groups/public/
Binary build for Maven 3.6.2-SNAPSHOT:
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/master/lastSuccessfulBuild/artifact/org/apache/maven/apache-maven/3.6.2-SNAPSHOT/
was (Author: mickael.istria):
Snapshot repo for Maven 3.6.2-SNAPSHOT:
https://repository.apache.org/content/groups/public/
Binary build for Maven 3.6.2-SNAPSHOT:
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/master/lastSuccessfulBuild/artifact/org/apache/maven/apache-maven/3.6.2-SNAPSHOT/apache-maven-3.6.2-SNAPSHOT-bin.tar.gz
> Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
> --
>
> Key: MNG-6642
> URL: https://issues.apache.org/jira/browse/MNG-6642
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Francesco Chicchiriccò
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.2
>
>
> Build does not work with Maven 3.6.1 (works fine with Maven 3.6.0).
> How to reproduce:
> # git clone https://github.com/apache/syncope.git
> # git checkout 2_1_X
> # $M2_HOME/bin/mvn clean
> When {{M2_HOME}} points to 3.6.0, build goes fine.
> When {{M2_HOME}} points to 3.6.1, the following output is reported:
> {code}
> [INFO] Scanning for projects...
> [INFO] Computing target platform for MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] Resolving dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true,
> osgi.arch=x86}
> [ERROR] Cannot resolve project dependencies:
> [ERROR] Software being installed: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier
> [ERROR] Missing requirement: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not
> be found
> [ERROR]
> [ERROR] See
> http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
> [ERROR] Cannot resolve dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml:
> See log for details -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6716) relative testSourceDirectory on macos throw duplicate class error
[
https://issues.apache.org/jira/browse/MNG-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16898175#comment-16898175
]
Mickael Istria commented on MNG-6716:
-
See proposal at https://github.com/apache/maven/pull/274/
> relative testSourceDirectory on macos throw duplicate class error
> -
>
> Key: MNG-6716
> URL: https://issues.apache.org/jira/browse/MNG-6716
> Project: Maven
> Issue Type: Bug
> Components: core, POM
>Affects Versions: 3.6.1
> Environment: MacOS Sierra 10.12.6
> mvn 3.6.1
>Reporter: Thibaud Lepretre
>Priority: Minor
> Fix For: 3.6.x-candidate, waiting-for-feedback
>
> Attachments: image-2019-07-30-12-26-50-201.png,
> image-2019-07-30-12-27-38-526.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With custom folder structure where test source folder is not sharing the same
> parent folder as source folder, for example (is just a sample structure
> itself is not the key point):
> {code:java}
> ws/bug-macos-tstsrc-relative-path-src/src/main/java
> ws/bug-macos-tstsrc-relative-path-tst/src
> {code}
> With following pom.xml customization
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src
> {code}
> On {{<= 3.6.0}} *everything works* but until 3.6.1 MacOS (I'm not able to
> reproduce on Docker container maven:3.6.1), I have the following error:
> {code:java}
> AppTest.java:[10,8] duplicate class: dev.thibaud.AppTest{code}
> And if I check with {{-X}} I saw 2 paths added instead of 1
> {code:java}
> [DEBUG] Source roots:
> [DEBUG]
> /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-src/../bug-macos-tstsrc-relative-path-tst/src
> [DEBUG] /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-tst/src{code}
> h2. *How to reproduce:*
> {code:java}
> #!/usr/bin/env bash
> readonly SRC_FOLDER="bug-macos-tstsrc-relative-path-src"
> readonly TST_FOLDER="bug-macos-tstsrc-relative-path-tst"
> mkdir -p ws
> cd ws/
> mvn archetype:generate -DgroupId=dev.thibaud -DartifactId=${SRC_FOLDER}
> -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
> mkdir -p ${TST_FOLDER}/src/
> mv ${SRC_FOLDER}/src/test/java/* ${TST_FOLDER}/src/
> rm -fr ${SRC_FOLDER}/src/test
> cat < ${SRC_FOLDER}/pom.xml
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> dev.thibaud
> bug-macos-tstsrcrelative-path
> jar
> 1.0-SNAPSHOT
> bug-macos-tstsrcrelative-path
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> ../${TST_FOLDER}/src
>
>
> EOT{code}
> Then simply run
> {code:java}
> mvn -f bug-macos-tstsrc-relative-path-src/pom.xml clean test -X{code}
> h2. *Workaround:*
> is not using relative path by editing
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src{code}
> to
> {code:java}
> ${project.basedir}/../bug-macos-tstsrc-relative-path-tst/src{code}
>
> PS: maybe affect {{sourceDirectory}} but no tested
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6716) relative testSourceDirectory on macos throw duplicate class error
[
https://issues.apache.org/jira/browse/MNG-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16898134#comment-16898134
]
Mickael Istria commented on MNG-6716:
-
Ok, I've got a test case showing the issue. Now it's just a matter of fixing it.
> relative testSourceDirectory on macos throw duplicate class error
> -
>
> Key: MNG-6716
> URL: https://issues.apache.org/jira/browse/MNG-6716
> Project: Maven
> Issue Type: Bug
> Components: core, POM
>Affects Versions: 3.6.1
> Environment: MacOS Sierra 10.12.6
> mvn 3.6.1
>Reporter: Thibaud Lepretre
>Priority: Minor
> Fix For: 3.6.x-candidate, waiting-for-feedback
>
> Attachments: image-2019-07-30-12-26-50-201.png,
> image-2019-07-30-12-27-38-526.png
>
>
> With custom folder structure where test source folder is not sharing the same
> parent folder as source folder, for example (is just a sample structure
> itself is not the key point):
> {code:java}
> ws/bug-macos-tstsrc-relative-path-src/src/main/java
> ws/bug-macos-tstsrc-relative-path-tst/src
> {code}
> With following pom.xml customization
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src
> {code}
> On {{<= 3.6.0}} *everything works* but until 3.6.1 MacOS (I'm not able to
> reproduce on Docker container maven:3.6.1), I have the following error:
> {code:java}
> AppTest.java:[10,8] duplicate class: dev.thibaud.AppTest{code}
> And if I check with {{-X}} I saw 2 paths added instead of 1
> {code:java}
> [DEBUG] Source roots:
> [DEBUG]
> /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-src/../bug-macos-tstsrc-relative-path-tst/src
> [DEBUG] /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-tst/src{code}
> h2. *How to reproduce:*
> {code:java}
> #!/usr/bin/env bash
> readonly SRC_FOLDER="bug-macos-tstsrc-relative-path-src"
> readonly TST_FOLDER="bug-macos-tstsrc-relative-path-tst"
> mkdir -p ws
> cd ws/
> mvn archetype:generate -DgroupId=dev.thibaud -DartifactId=${SRC_FOLDER}
> -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
> mkdir -p ${TST_FOLDER}/src/
> mv ${SRC_FOLDER}/src/test/java/* ${TST_FOLDER}/src/
> rm -fr ${SRC_FOLDER}/src/test
> cat < ${SRC_FOLDER}/pom.xml
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> dev.thibaud
> bug-macos-tstsrcrelative-path
> jar
> 1.0-SNAPSHOT
> bug-macos-tstsrcrelative-path
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> ../${TST_FOLDER}/src
>
>
> EOT{code}
> Then simply run
> {code:java}
> mvn -f bug-macos-tstsrc-relative-path-src/pom.xml clean test -X{code}
> h2. *Workaround:*
> is not using relative path by editing
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src{code}
> to
> {code:java}
> ${project.basedir}/../bug-macos-tstsrc-relative-path-tst/src{code}
>
> PS: maybe affect {{sourceDirectory}} but no tested
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6716) relative testSourceDirectory on macos throw duplicate class error
[
https://issues.apache.org/jira/browse/MNG-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16898127#comment-16898127
]
Mickael Istria commented on MNG-6716:
-
I don't think it's user's fault if it used to work fine.
However, I find this issue hard to reproduce in a unit test programatically
(spent several hours on it unsuccessfully). If I use the
Project.getTestCompileSourceRoots API I do not see this issue, how can I ask
for resolution of the property programatically ?
> relative testSourceDirectory on macos throw duplicate class error
> -
>
> Key: MNG-6716
> URL: https://issues.apache.org/jira/browse/MNG-6716
> Project: Maven
> Issue Type: Bug
> Components: core, POM
>Affects Versions: 3.6.1
> Environment: MacOS Sierra 10.12.6
> mvn 3.6.1
>Reporter: Thibaud Lepretre
>Priority: Minor
> Fix For: 3.6.x-candidate, waiting-for-feedback
>
> Attachments: image-2019-07-30-12-26-50-201.png,
> image-2019-07-30-12-27-38-526.png
>
>
> With custom folder structure where test source folder is not sharing the same
> parent folder as source folder, for example (is just a sample structure
> itself is not the key point):
> {code:java}
> ws/bug-macos-tstsrc-relative-path-src/src/main/java
> ws/bug-macos-tstsrc-relative-path-tst/src
> {code}
> With following pom.xml customization
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src
> {code}
> On {{<= 3.6.0}} *everything works* but until 3.6.1 MacOS (I'm not able to
> reproduce on Docker container maven:3.6.1), I have the following error:
> {code:java}
> AppTest.java:[10,8] duplicate class: dev.thibaud.AppTest{code}
> And if I check with {{-X}} I saw 2 paths added instead of 1
> {code:java}
> [DEBUG] Source roots:
> [DEBUG]
> /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-src/../bug-macos-tstsrc-relative-path-tst/src
> [DEBUG] /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-tst/src{code}
> h2. *How to reproduce:*
> {code:java}
> #!/usr/bin/env bash
> readonly SRC_FOLDER="bug-macos-tstsrc-relative-path-src"
> readonly TST_FOLDER="bug-macos-tstsrc-relative-path-tst"
> mkdir -p ws
> cd ws/
> mvn archetype:generate -DgroupId=dev.thibaud -DartifactId=${SRC_FOLDER}
> -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
> mkdir -p ${TST_FOLDER}/src/
> mv ${SRC_FOLDER}/src/test/java/* ${TST_FOLDER}/src/
> rm -fr ${SRC_FOLDER}/src/test
> cat < ${SRC_FOLDER}/pom.xml
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> dev.thibaud
> bug-macos-tstsrcrelative-path
> jar
> 1.0-SNAPSHOT
> bug-macos-tstsrcrelative-path
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> ../${TST_FOLDER}/src
>
>
> EOT{code}
> Then simply run
> {code:java}
> mvn -f bug-macos-tstsrc-relative-path-src/pom.xml clean test -X{code}
> h2. *Workaround:*
> is not using relative path by editing
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src{code}
> to
> {code:java}
> ${project.basedir}/../bug-macos-tstsrc-relative-path-tst/src{code}
>
> PS: maybe affect {{sourceDirectory}} but no tested
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6716) relative testSourceDirectory on macos throw duplicate class error
[
https://issues.apache.org/jira/browse/MNG-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897933#comment-16897933
]
Mickael Istria commented on MNG-6716:
-
The variable `${project.testCompileSourceRoots}` contains the faulty value.
> relative testSourceDirectory on macos throw duplicate class error
> -
>
> Key: MNG-6716
> URL: https://issues.apache.org/jira/browse/MNG-6716
> Project: Maven
> Issue Type: Bug
> Components: core, POM
>Affects Versions: 3.6.1
> Environment: MacOS Sierra 10.12.6
> mvn 3.6.1
>Reporter: Thibaud Lepretre
>Priority: Minor
> Fix For: 3.6.x-candidate, waiting-for-feedback
>
> Attachments: image-2019-07-30-12-26-50-201.png,
> image-2019-07-30-12-27-38-526.png
>
>
> With custom folder structure where test source folder is not sharing the same
> parent folder as source folder, for example (is just a sample structure
> itself is not the key point):
> {code:java}
> ws/bug-macos-tstsrc-relative-path-src/src/main/java
> ws/bug-macos-tstsrc-relative-path-tst/src
> {code}
> With following pom.xml customization
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src
> {code}
> On {{<= 3.6.0}} *everything works* but until 3.6.1 MacOS (I'm not able to
> reproduce on Docker container maven:3.6.1), I have the following error:
> {code:java}
> AppTest.java:[10,8] duplicate class: dev.thibaud.AppTest{code}
> And if I check with {{-X}} I saw 2 paths added instead of 1
> {code:java}
> [DEBUG] Source roots:
> [DEBUG]
> /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-src/../bug-macos-tstsrc-relative-path-tst/src
> [DEBUG] /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-tst/src{code}
> h2. *How to reproduce:*
> {code:java}
> #!/usr/bin/env bash
> readonly SRC_FOLDER="bug-macos-tstsrc-relative-path-src"
> readonly TST_FOLDER="bug-macos-tstsrc-relative-path-tst"
> mkdir -p ws
> cd ws/
> mvn archetype:generate -DgroupId=dev.thibaud -DartifactId=${SRC_FOLDER}
> -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
> mkdir -p ${TST_FOLDER}/src/
> mv ${SRC_FOLDER}/src/test/java/* ${TST_FOLDER}/src/
> rm -fr ${SRC_FOLDER}/src/test
> cat < ${SRC_FOLDER}/pom.xml
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> dev.thibaud
> bug-macos-tstsrcrelative-path
> jar
> 1.0-SNAPSHOT
> bug-macos-tstsrcrelative-path
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> ../${TST_FOLDER}/src
>
>
> EOT{code}
> Then simply run
> {code:java}
> mvn -f bug-macos-tstsrc-relative-path-src/pom.xml clean test -X{code}
> h2. *Workaround:*
> is not using relative path by editing
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src{code}
> to
> {code:java}
> ${project.basedir}/../bug-macos-tstsrc-relative-path-tst/src{code}
>
> PS: maybe affect {{sourceDirectory}} but no tested
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6716) relative testSourceDirectory on macos throw duplicate class error
[
https://issues.apache.org/jira/browse/MNG-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897245#comment-16897245
]
Mickael Istria commented on MNG-6716:
-
While it works on Linux in next steps, I also see in the debug log
{code}
[DEBUG] Source roots:
[DEBUG]
/home/mistria/sandbox/testMaven/ws/bug-macos-tstsrc-relative-path-src/../bug-macos-tstsrc-relative-path-tst/src
[DEBUG]
/home/mistria/sandbox/testMaven/ws/bug-macos-tstsrc-relative-path-tst/src
{code}
while I just see
"/home/mistria/sandbox/testMaven/ws/bug-macos-tstsrc-relative-path-tst/src"
with 3.5.4
> relative testSourceDirectory on macos throw duplicate class error
> -
>
> Key: MNG-6716
> URL: https://issues.apache.org/jira/browse/MNG-6716
> Project: Maven
> Issue Type: Bug
> Components: core, POM
>Affects Versions: 3.6.1
> Environment: MacOS Sierra 10.12.6
> mvn 3.6.1
>Reporter: Thibaud Lepretre
>Priority: Minor
> Fix For: 3.6.x-candidate, waiting-for-feedback
>
> Attachments: image-2019-07-30-12-26-50-201.png,
> image-2019-07-30-12-27-38-526.png
>
>
> With custom folder structure where test source folder is not sharing the same
> parent folder as source folder, for example (is just a sample structure
> itself is not the key point):
> {code:java}
> ws/bug-macos-tstsrc-relative-path-src/src/main/java
> ws/bug-macos-tstsrc-relative-path-tst/src
> {code}
> With following pom.xml customization
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src
> {code}
> On {{<= 3.6.0}} *everything works* but until 3.6.1 MacOS (I'm not able to
> reproduce on Docker container maven:3.6.1), I have the following error:
> {code:java}
> AppTest.java:[10,8] duplicate class: dev.thibaud.AppTest{code}
> And if I check with {{-X}} I saw 2 paths added instead of 1
> {code:java}
> [DEBUG] Source roots:
> [DEBUG]
> /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-src/../bug-macos-tstsrc-relative-path-tst/src
> [DEBUG] /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-tst/src{code}
> h2. *How to reproduce:*
> {code:java}
> #!/usr/bin/env bash
> readonly SRC_FOLDER="bug-macos-tstsrc-relative-path-src"
> readonly TST_FOLDER="bug-macos-tstsrc-relative-path-tst"
> mkdir -p ws
> cd ws/
> mvn archetype:generate -DgroupId=dev.thibaud -DartifactId=${SRC_FOLDER}
> -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
> mkdir -p ${TST_FOLDER}/src/
> mv ${SRC_FOLDER}/src/test/java/* ${TST_FOLDER}/src/
> rm -fr ${SRC_FOLDER}/src/test
> cat < ${SRC_FOLDER}/pom.xml
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> dev.thibaud
> bug-macos-tstsrcrelative-path
> jar
> 1.0-SNAPSHOT
> bug-macos-tstsrcrelative-path
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> ../${TST_FOLDER}/src
>
>
> EOT{code}
> Then simply run
> {code:java}
> mvn -f bug-macos-tstsrc-relative-path-src/pom.xml clean test -X{code}
> h2. *Workaround:*
> is not using relative path by editing
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src{code}
> to
> {code:java}
> ${project.basedir}/../bug-macos-tstsrc-relative-path-tst/src{code}
>
> PS: maybe affect {{sourceDirectory}} but no tested
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6716) relative testSourceDirectory on macos throw duplicate class error
[
https://issues.apache.org/jira/browse/MNG-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896200#comment-16896200
]
Mickael Istria commented on MNG-6716:
-
[~kakawait] By the way, is it a macos specific issue? I don't think so. Can you
please share the most basic project you can imagine to reproduce this issue? I
could give it a try on Linux, and we could also include it in a test case for
ProjectBuilderTest.
> relative testSourceDirectory on macos throw duplicate class error
> -
>
> Key: MNG-6716
> URL: https://issues.apache.org/jira/browse/MNG-6716
> Project: Maven
> Issue Type: Bug
> Components: core, POM
>Affects Versions: 3.6.1
> Environment: MacOS Sierra 10.12.6
> mvn 3.6.1
>Reporter: Thibaud Lepretre
>Priority: Minor
> Fix For: 3.6.x-candidate, waiting-for-feedback
>
> Attachments: image-2019-07-30-12-26-50-201.png,
> image-2019-07-30-12-27-38-526.png
>
>
> With custom folder structure where test source folder is not sharing the same
> parent folder as source folder, for example (is just a sample structure
> itself is not the key point):
> {code:java}
> ws/bug-macos-tstsrc-relative-path-src/src/main/java
> ws/bug-macos-tstsrc-relative-path-tst/src
> {code}
> With following pom.xml customization
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src
> {code}
> On {{<= 3.6.0}} *everything works* but until 3.6.1 MacOS (I'm not able to
> reproduce on Docker container maven:3.6.1), I have the following error:
> {code:java}
> AppTest.java:[10,8] duplicate class: dev.thibaud.AppTest{code}
> And if I check with {{-X}} I saw 2 paths added instead of 1
> {code:java}
> [DEBUG] Source roots:
> [DEBUG]
> /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-src/../bug-macos-tstsrc-relative-path-tst/src
> [DEBUG] /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-tst/src{code}
> h2. *How to reproduce:*
> {code:java}
> #!/usr/bin/env bash
> readonly SRC_FOLDER="bug-macos-tstsrc-relative-path-src"
> readonly TST_FOLDER="bug-macos-tstsrc-relative-path-tst"
> mkdir -p ws
> cd ws/
> mvn archetype:generate -DgroupId=dev.thibaud -DartifactId=${SRC_FOLDER}
> -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
> mkdir -p ${TST_FOLDER}/src/
> mv ${SRC_FOLDER}/src/test/java/* ${TST_FOLDER}/src/
> rm -fr ${SRC_FOLDER}/src/test
> cat < ${SRC_FOLDER}/pom.xml
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> dev.thibaud
> bug-macos-tstsrcrelative-path
> jar
> 1.0-SNAPSHOT
> bug-macos-tstsrcrelative-path
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> ../${TST_FOLDER}/src
>
>
> EOT{code}
> Then simply run
> {code:java}
> mvn -f bug-macos-tstsrc-relative-path-src/pom.xml clean test -X{code}
> h2. *Workaround:*
> is not using relative path by editing
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src{code}
> to
> {code:java}
> ${project.basedir}/../bug-macos-tstsrc-relative-path-tst/src{code}
>
> PS: maybe affect {{sourceDirectory}} but no tested
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6716) relative testSourceDirectory on macos throw duplicate class error
[
https://issues.apache.org/jira/browse/MNG-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896196#comment-16896196
]
Mickael Istria commented on MNG-6716:
-
I don't have much to say here. The bug is definitely not something intended and
is more a side-effect of some other change.
I don't really mind this to be changed, as long as the test cases I added still
pass, it shouldn't be an issue for m2e.
Putting a breakpoint on testCompileSourceRoots.add() would allow to find out
why this is now invoked twice, and probably where to tweak the path so they
become absolute.
> relative testSourceDirectory on macos throw duplicate class error
> -
>
> Key: MNG-6716
> URL: https://issues.apache.org/jira/browse/MNG-6716
> Project: Maven
> Issue Type: Bug
> Components: core, POM
>Affects Versions: 3.6.1
> Environment: MacOS Sierra 10.12.6
> mvn 3.6.1
>Reporter: Thibaud Lepretre
>Priority: Minor
> Fix For: 3.6.x-candidate, waiting-for-feedback
>
> Attachments: image-2019-07-30-12-26-50-201.png,
> image-2019-07-30-12-27-38-526.png
>
>
> With custom folder structure where test source folder is not sharing the same
> parent folder as source folder, for example (is just a sample structure
> itself is not the key point):
> {code:java}
> ws/bug-macos-tstsrc-relative-path-src/src/main/java
> ws/bug-macos-tstsrc-relative-path-tst/src
> {code}
> With following pom.xml customization
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src
> {code}
> On {{<= 3.6.0}} *everything works* but until 3.6.1 MacOS (I'm not able to
> reproduce on Docker container maven:3.6.1), I have the following error:
> {code:java}
> AppTest.java:[10,8] duplicate class: dev.thibaud.AppTest{code}
> And if I check with {{-X}} I saw 2 paths added instead of 1
> {code:java}
> [DEBUG] Source roots:
> [DEBUG]
> /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-src/../bug-macos-tstsrc-relative-path-tst/src
> [DEBUG] /private/tmp/mvntest/ws/bug-macos-tstsrc-relative-path-tst/src{code}
> h2. *How to reproduce:*
> {code:java}
> #!/usr/bin/env bash
> readonly SRC_FOLDER="bug-macos-tstsrc-relative-path-src"
> readonly TST_FOLDER="bug-macos-tstsrc-relative-path-tst"
> mkdir -p ws
> cd ws/
> mvn archetype:generate -DgroupId=dev.thibaud -DartifactId=${SRC_FOLDER}
> -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
> mkdir -p ${TST_FOLDER}/src/
> mv ${SRC_FOLDER}/src/test/java/* ${TST_FOLDER}/src/
> rm -fr ${SRC_FOLDER}/src/test
> cat < ${SRC_FOLDER}/pom.xml
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> dev.thibaud
> bug-macos-tstsrcrelative-path
> jar
> 1.0-SNAPSHOT
> bug-macos-tstsrcrelative-path
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> ../${TST_FOLDER}/src
>
>
> EOT{code}
> Then simply run
> {code:java}
> mvn -f bug-macos-tstsrc-relative-path-src/pom.xml clean test -X{code}
> h2. *Workaround:*
> is not using relative path by editing
> {code:java}
> ../bug-macos-tstsrc-relative-path-tst/src{code}
> to
> {code:java}
> ${project.basedir}/../bug-macos-tstsrc-relative-path-tst/src{code}
>
> PS: maybe affect {{sourceDirectory}} but no tested
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6723) MavenProject.getParentFile() not set when using ProjectBuilder.build(List, ...)
[ https://issues.apache.org/jira/browse/MNG-6723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892647#comment-16892647 ] Mickael Istria commented on MNG-6723: - PR now contains a fix and is ready for review. > MavenProject.getParentFile() not set when using > ProjectBuilder.build(List, ...) > - > > Key: MNG-6723 > URL: https://issues.apache.org/jira/browse/MNG-6723 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.1 >Reporter: Mickael Istria >Priority: Major > Fix For: 3.6.x-candidate > > Time Spent: 10m > Remaining Estimate: 0h > > This is the root cause for > https://bugs.eclipse.org/bugs/show_bug.cgi?id=548652 and was found while > analyzing this m2e bug. > Using Maven 3.6.1, > If I have 2 files: 1 parent pom and 1 child pom (referencing parent). > I invoke `ProjectBuilder.build(child)` and the resulting MavenProject gives > me a correct value for `MavenProject.getParentFile()`. > I invoke `ProjectBuilder.build(List.of(parent, child), )` and invoking > `MavenProject.getParentFile()` on the child MavenProject returns `null` > (which `child.getParent().getFile()` returns the right value. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (MNG-6723) MavenProject.getParentFile() not set when using ProjectBuilder.build(List, ...)
[ https://issues.apache.org/jira/browse/MNG-6723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mickael Istria updated MNG-6723: Description: This is the root cause for https://bugs.eclipse.org/bugs/show_bug.cgi?id=548652 and was found while analyzing this m2e bug. Using Maven 3.6.1, If I have 2 files: 1 parent pom and 1 child pom (referencing parent). I invoke `ProjectBuilder.build(child)` and the resulting MavenProject gives me a correct value for `MavenProject.getParentFile()`. I invoke `ProjectBuilder.build(List.of(parent, child), )` and invoking `MavenProject.getParentFile()` on the child MavenProject returns `null` (which `child.getParent().getFile()` returns the right value. was: Using Maven 3.6.1, If I have 2 files: 1 parent pom and 1 child pom (referencing parent). I invoke `ProjectBuilder.build(child)` and the resulting MavenProject gives me a correct value for `MavenProject.getParentFile()`. I invoke `ProjectBuilder.build(List.of(parent, child), )` and invoking `MavenProject.getParentFile()` on the child MavenProject returns `null` (which `child.getParent().getFile()` returns the right value. > MavenProject.getParentFile() not set when using > ProjectBuilder.build(List, ...) > - > > Key: MNG-6723 > URL: https://issues.apache.org/jira/browse/MNG-6723 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.1 >Reporter: Mickael Istria >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This is the root cause for > https://bugs.eclipse.org/bugs/show_bug.cgi?id=548652 and was found while > analyzing this m2e bug. > Using Maven 3.6.1, > If I have 2 files: 1 parent pom and 1 child pom (referencing parent). > I invoke `ProjectBuilder.build(child)` and the resulting MavenProject gives > me a correct value for `MavenProject.getParentFile()`. > I invoke `ProjectBuilder.build(List.of(parent, child), )` and invoking > `MavenProject.getParentFile()` on the child MavenProject returns `null` > (which `child.getParent().getFile()` returns the right value. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MNG-6723) MavenProject.getParentFile() not set when using ProjectBuilder.build(List, ...)
[ https://issues.apache.org/jira/browse/MNG-6723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891980#comment-16891980 ] Mickael Istria commented on MNG-6723: - I've created https://github.com/apache/maven/pull/273 with a reproducer. I'll try to enrich the pull request with a fix soon. > MavenProject.getParentFile() not set when using > ProjectBuilder.build(List, ...) > - > > Key: MNG-6723 > URL: https://issues.apache.org/jira/browse/MNG-6723 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.1 >Reporter: Mickael Istria >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Using Maven 3.6.1, > If I have 2 files: 1 parent pom and 1 child pom (referencing parent). > I invoke `ProjectBuilder.build(child)` and the resulting MavenProject gives > me a correct value for `MavenProject.getParentFile()`. > I invoke `ProjectBuilder.build(List.of(parent, child), )` and invoking > `MavenProject.getParentFile()` on the child MavenProject returns `null` > (which `child.getParent().getFile()` returns the right value. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (MNG-6723) MavenProject.getParentFile() not set when using ProjectBuilder.build(List, ...)
Mickael Istria created MNG-6723: --- Summary: MavenProject.getParentFile() not set when using ProjectBuilder.build(List, ...) Key: MNG-6723 URL: https://issues.apache.org/jira/browse/MNG-6723 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.1 Reporter: Mickael Istria Using Maven 3.6.1, If I have 2 files: 1 parent pom and 1 child pom (referencing parent). I invoke `ProjectBuilder.build(child)` and the resulting MavenProject gives me a correct value for `MavenProject.getParentFile()`. I invoke `ProjectBuilder.build(List.of(parent, child), )` and invoking `MavenProject.getParentFile()` on the child MavenProject returns `null` (which `child.getParent().getFile()` returns the right value. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MNG-6642) Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
[
https://issues.apache.org/jira/browse/MNG-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16831917#comment-16831917
]
Mickael Istria commented on MNG-6642:
-
Is there something that should be done in Tycho to improve that and let Maven
remove the maven-compat dep without causing any issue?
Or is it affecting all forms of non m2 repo layouts?
> Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
> --
>
> Key: MNG-6642
> URL: https://issues.apache.org/jira/browse/MNG-6642
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Francesco Chicchiriccò
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.2
>
>
> Build does not work with Maven 3.6.1 (works fine with Maven 3.6.0).
> How to reproduce:
> # git clone https://github.com/apache/syncope.git
> # git checkout 2_1_X
> # $M2_HOME/bin/mvn clean
> When {{M2_HOME}} points to 3.6.0, build goes fine.
> When {{M2_HOME}} points to 3.6.1, the following output is reported:
> {code}
> [INFO] Scanning for projects...
> [INFO] Computing target platform for MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] Resolving dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml
> [INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true,
> osgi.arch=x86}
> [ERROR] Cannot resolve project dependencies:
> [ERROR] Software being installed: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier
> [ERROR] Missing requirement: org.apache.syncope.ide.eclipse.plugin
> 2.1.4.qualifier requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not
> be found
> [ERROR]
> [ERROR] See
> http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
> [ERROR] Cannot resolve dependencies of MavenProject:
> org.apache.syncope.ide.eclipse:org.apache.syncope.ide.eclipse.plugin:2.1.4-SNAPSHOT
> @
> /home/ilgrosso/work/syncope/syncope/ide/eclipse/bundles/org.apache.syncope.ide.eclipse.plugin/pom.xml:
> See log for details -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6563) StackOverflowError when reading deep (1000) project hierarchy
[ https://issues.apache.org/jira/browse/MNG-6563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16764112#comment-16764112 ] Mickael Istria commented on MNG-6563: - I imagine it's «just» a typical case where recursion should be replaced by a Stack of requests to populate and then process sequentially from root to leaf. > StackOverflowError when reading deep (1000) project hierarchy > - > > Key: MNG-6563 > URL: https://issues.apache.org/jira/browse/MNG-6563 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Mickael Istria >Priority: Major > > I'm trying to write tests loading huge extreme Maven projects in m2e to check > how it likes it or not and how to improve it. > One of the tests creates 1000 projects, each one being a parent of the other. > When trying to read it, Maven (and thus m2e) crashes with a > StackOverflowError because it deeply recurses on build/initParent methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6563) StackOverflowError when reading deep (1000) project hierarchy
[ https://issues.apache.org/jira/browse/MNG-6563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16760196#comment-16760196 ] Mickael Istria commented on MNG-6563: - m2e doesn't scale (at the moment) with "deep" projects. By deep, I mean deep in the sense of Maven parenthood, not necessarily deep on file-system. I wrote this test as an extreme case to cover MNG-6530 in the IDE; but it's indeed not a realistic one. But the deep recursion and the StackOverflowError here hughlught some areas where improvement is possible. Not high priority though. > StackOverflowError when reading deep (1000) project hierarchy > - > > Key: MNG-6563 > URL: https://issues.apache.org/jira/browse/MNG-6563 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Mickael Istria >Priority: Major > > I'm trying to write tests loading huge extreme Maven projects in m2e to check > how it likes it or not and how to improve it. > One of the tests creates 1000 projects, each one being a parent of the other. > When trying to read it, Maven (and thus m2e) crashes with a > StackOverflowError because it deeply recurses on build/initParent methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6571) Maven memory consumption issue
[ https://issues.apache.org/jira/browse/MNG-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16749969#comment-16749969 ] Mickael Istria commented on MNG-6571: - Great job Herve! I agree with [~YannLeCorse] that the BigInteger thing isn't worth chasing at the moment since you found an "upstream" optimization that makes the BigInteger almost invisible in overall memory consumption. However, although it's not retained, we need to keep in mind that instantiating a BigInteger takes more time than storing a long or a int, so f we want to get into deep perf improvement, we must also take into account not only the number of instances retained, but the overall number of object instantiated. But that's another topic where a profiler will help prioritization more than a heap dump. > Maven memory consumption issue > -- > > Key: MNG-6571 > URL: https://issues.apache.org/jira/browse/MNG-6571 > Project: Maven > Issue Type: Wish >Affects Versions: 3.6.0 >Reporter: Hervé Boutemy >Priority: Major > Attachments: Maven-Reactor-Dump-Patched.png, Maven-Reactor-Dump.png > > > as reported on Users list: > https://lists.apache.org/thread.html/7d75142448b3c234742bdfd3c743e2f62065fe8e0a313905cbbb2523@%3Cusers.maven.apache.org%3E > then with details on Dev list: > https://lists.apache.org/thread.html/34b64295238594e554f1f2f119848bce3b60d4e1e22e09f26aa64166@%3Cdev.maven.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6571) Maven memory consumption issue
[ https://issues.apache.org/jira/browse/MNG-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16749910#comment-16749910 ] Mickael Istria commented on MNG-6571: - [~hboutemy]'s comment about trying to cache VersionRange to avoid multiple instantiations seems promising. It reminds me that story with Date told by Martin Fowler to introduce the "create factory" in the "Refactoring" book IIRC ;) Another smell I see is usage bigInteger: there are 16M instances that retain ~1GB. Is this BigInteger really necessary? Isn't long or even int enough in the use-case case (IntegerItem in ComparableVersion)? If we go for a long instead, this 1GB would turn to 16M * 8B = 104MB, saving 900MB. > Maven memory consumption issue > -- > > Key: MNG-6571 > URL: https://issues.apache.org/jira/browse/MNG-6571 > Project: Maven > Issue Type: Wish >Affects Versions: 3.6.0 >Reporter: Hervé Boutemy >Priority: Major > Attachments: Maven-Reactor-Dump.png > > > as reported on Users list: > https://lists.apache.org/thread.html/7d75142448b3c234742bdfd3c743e2f62065fe8e0a313905cbbb2523@%3Cusers.maven.apache.org%3E > then with details on Dev list: > https://lists.apache.org/thread.html/34b64295238594e554f1f2f119848bce3b60d4e1e22e09f26aa64166@%3Cdev.maven.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6569) ProjectBuilder.build(List projects...) should resolve parency between specified projects
Mickael Istria created MNG-6569: --- Summary: ProjectBuilder.build(List projects...) should resolve parency between specified projects Key: MNG-6569 URL: https://issues.apache.org/jira/browse/MNG-6569 Project: Maven Issue Type: Improvement Components: core Reporter: Mickael Istria In Eclipse m2e, we're using ProjectBuilder.build(List projects...). If we specify a list of projects that contain a parent pom and another pom referencing it as parent, and parent.relativePath is not set and doesn't refernece the parent file, then the result of the method would only contain the proper parent, but not the module (that would report an error because of parent not fount). Instead, it would be more convenient that ProjectBuilder tries to find the parent inside the given set of files too and would allow to resolve both parent and child simultaneously, just like if the relativePath were properly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6563) StackOverflowError when reading deep (1000) project hierarchy
[
https://issues.apache.org/jira/browse/MNG-6563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741886#comment-16741886
]
Mickael Istria commented on MNG-6563:
-
Here is the code I use to generate the project
{code:java}
private Set buildLinearHierarchy(int depth, File tempDirectory) throws
FileNotFoundException {
Set poms = new HashSet<>(depth, 1.f);
for(int i = 0; i < depth; i++ ) {
File projectDir = new File(tempDirectory, "p" + i);
projectDir.mkdirs();
File pom = new File(projectDir, "pom.xml");
poms.add(pom);
try (PrintStream content = new PrintStream(pom);) {
content.println("");
content.println(" 4.0.0");
content.println("
org.eclipse.m2e.core.tests.hierarchy");
content.println(" pNUMBER".replace("NUMBER",
Integer.toString(i)));
content.println(" 1");
content.println(" pom");
if(i > 1) {
content.println(" ");
content.println("
org.eclipse.m2e.core.tests.hierarchy");
content.println("
pNUMBER".replace("NUMBER", Integer.toString(i - 1)));
content.println("1");
content.println("
../pNUMBER".replace("NUMBER", Integer.toString(i -
1)));
content.println(" ");
}
content.println("");
}
}
return poms;
}
{code}
then, invoking "DefaultProjectBuilder.build(new File("p999"))" should crash
with a StackOverflowError.
I don't have the opportunity to automate such test right now.
One approach could be to reorganize the builder to first resolve the dependency
chain as a Queue of Files and then build them from parents to leaves, caching
each result in the meantime so it's processed only once.
> StackOverflowError when reading deep (1000) project hierarchy
> -
>
> Key: MNG-6563
> URL: https://issues.apache.org/jira/browse/MNG-6563
> Project: Maven
> Issue Type: Bug
> Components: core
>Reporter: Mickael Istria
>Priority: Major
>
> I'm trying to write tests loading huge extreme Maven projects in m2e to check
> how it likes it or not and how to improve it.
> One of the tests creates 1000 projects, each one being a parent of the other.
> When trying to read it, Maven (and thus m2e) crashes with a
> StackOverflowError because it deeply recurses on build/initParent methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6563) StackOverflowError when reading deep (1000) project hierarchy
Mickael Istria created MNG-6563: --- Summary: StackOverflowError when reading deep (1000) project hierarchy Key: MNG-6563 URL: https://issues.apache.org/jira/browse/MNG-6563 Project: Maven Issue Type: Bug Components: core Reporter: Mickael Istria I'm trying to write tests loading huge extreme Maven projects in m2e to check how it likes it or not and how to improve it. One of the tests creates 1000 projects, each one being a parent of the other. When trying to read it, Maven (and thus m2e) crashes with a StackOverflowError because it deeply recurses on build/initParent methods. -- 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&focusedCommentId=16711132#comment-16711132 ] Mickael Istria commented on MNG-6530: - I've given another round of thought about it, and I believe that in the general case, a system property is better. Indeed, with m2e (and others) we can have the ProjectBuilder used by some mojos invoked in the same JVM (so using this cache) and relying on ProjectBuilder.build(...) to get some MavenProject. Those mojos would return erroneous results if some parent pom change because those change would be ignored. I think in the context of m2e or any application where lifetime of ProjectBuilder can see pom changing, we really need a way to fully disable the cache in any case, and not only for a given ProjectBuildRequest (as Maven plugin providers shouldn't care about whether they're in mvn CLI or in m2e or whatever to decide whether to change their ProjectBuilderRequest or not). So the system property seems to be a better solution than an explicit API to invoke for each consumer, basically because consumers cannot know whether to change the default behavior or not, it's up to the Plexus container "owner" (mvn CLI or m2e or ...) to decide that. > 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&focusedCommentId=16708537#comment-16708537
]
Mickael Istria commented on MNG-6530:
-
{quote}Regarding release notes, they are written at the end. I suggest to add a
paragraph in the description of this issue which could be added to the release
notes.{quote}
I was more talking about the 3.6.0 release note to have a note about this bug,
so people who upgrade from a Maven version to another (who should read the
release notes of all versions before doing so) would receive a warning and not
adopt 3.6.x if they are using ProjectBuilder in a context where files can
change.
Also, I'd like some confirmation here: If I add a field in
ProjectBuildingRequest instead of the system property, would this be merged? I
can spend time to work on those things, but I need some guidance to not waste
time in undesired changes.
> 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&focusedCommentId=16704514#comment-16704514 ] Mickael Istria commented on MNG-6530: - Before MNG-6311 , there was already a cache, which just happens to be attached to the current operation; MNG-6311 made it static and global for the application. I think it's worth being explicit there. > 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&focusedCommentId=16704488#comment-16704488 ] Mickael Istria commented on MNG-6530: - We could introduce ProjectBuildingRequest.useGlobalModelCache() method? > 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&focusedCommentId=16704049#comment-16704049 ] Mickael Istria commented on MNG-6530: - Is it possible to add a comment about this issue in the release notes for 3.6.0 ? If yes, what's the procedure to contribute to this document? > 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-6533) ProjectBuilder.build(list_of_projects,...) does not contain MavenProject in exception report
[ https://issues.apache.org/jira/browse/MNG-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16703830#comment-16703830 ] Mickael Istria commented on MNG-6533: - The pull request contains one unit test that showcase the issue, and a patch that seems to fix it. > ProjectBuilder.build(list_of_projects,...) does not contain MavenProject in > exception report > > > Key: MNG-6533 > URL: https://issues.apache.org/jira/browse/MNG-6533 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.0 >Reporter: Mickael Istria >Priority: Major > > To save a lot of CPU and RAM in Eclipse m2e, we're trying to use > ProjectBuilder.build(List projects ...) instead of sequencing multiple > Projectbuilder.build(File singleProject...). This has a big positive impact > on m2e. > However, we noticed that when the operation is failing in some case because > pom is incomplete (which is a pretty usual state in the IDE), the > multi-projects methods does not retrn the MavenProject in the > ProjectBuildingException.getResults() while the single-project method does. > Adding MavenProject for the multi-project ProjectBuilder.build(...) would > allow m2e to use this method and save ~75% RAM and CPU in many operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6533) ProjectBuilder.build(list_of_projects,...) does not contain MavenProject in exception report
Mickael Istria created MNG-6533: --- Summary: ProjectBuilder.build(list_of_projects,...) does not contain MavenProject in exception report Key: MNG-6533 URL: https://issues.apache.org/jira/browse/MNG-6533 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.6.0, 3.5.4 Reporter: Mickael Istria To save a lot of CPU and RAM in Eclipse m2e, we're trying to use ProjectBuilder.build(List projects ...) instead of sequencing multiple Projectbuilder.build(File singleProject...). This has a big positive impact on m2e. However, we noticed that when the operation is failing in some case because pom is incomplete (which is a pretty usual state in the IDE), the multi-projects methods does not retrn the MavenProject in the ProjectBuildingException.getResults() while the single-project method does. Adding MavenProject for the multi-project ProjectBuilder.build(...) would allow m2e to use this method and save ~75% RAM and CPU in many operations. -- 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&focusedCommentId=16702961#comment-16702961 ] Mickael Istria commented on MNG-6530: - I've added to my PR https://github.com/apache/maven/pull/194 a system property that can be used to disable the global model cache and restore previous behavior, honoring file changes. > 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&focusedCommentId=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] [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&focusedCommentId=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-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&focusedCommentId=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] (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&focusedCommentId=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)
[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&focusedCommentId=16701138#comment-16701138 ] Mickael Istria commented on MNG-6311: - I'm also quite surprised that despite the concerns raised by [~fbricon] in October, no further verification nor investigation has happened on this patch and it was released 13 days later in 3.6.0, basically ignoring adopter's concerns. It seems to me that this is a major failure in term of QE. The fact that the issue was missed can happen, but ignoring feedback from an adopter project that is delivered to 6 million users obviously leads to bad results, such as 3.6.0 containing a regression over 3.5.3 and not being usable for downstream projects. > 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] [Commented] (MNG-6529) ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies()
[ https://issues.apache.org/jira/browse/MNG-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16701127#comment-16701127 ] Mickael Istria commented on MNG-6529: - Pull request https://github.com/apache/maven/pull/193 now contains something that looks like a fix. > ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) > doesn't honor ProjectBuildingRequest.isResolveDependencies() > --- > > Key: MNG-6529 > URL: https://issues.apache.org/jira/browse/MNG-6529 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Mickael Istria >Priority: Critical > > I'm willing to upfate Eclipse m2e to take advantage of the > `ProjectBuilder.build(List project, boolean, ProjectBuildingRequest)` > in Eclipse m2e to avoid duplication of MavenProject in the IDE in place of > `ProjectBuilder.build(File singleFile, ProjectBuildingRequest)`. It's already > measured to have drastically good impact on the IDE, as explained in > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c20] and > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c38]. > However, using this cause regressions because the multi-projects entry-point > method seems to totally ignore the > `ProjectBuildRequest.isResolveDependencies()` flag and never returns a valid > list of `MavenProject.getArtifacts()`. -- 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&focusedCommentId=16701106#comment-16701106 ] Mickael Istria commented on MNG-6311: - Please have a look at this test case: https://github.com/apache/maven/pull/194 . It fails with current master. If you `git revert 8bc3c207d0aa7cef72171af23d9c4667b2d46c5d`, it succeeds, as expected. In the current form, the contract of `ProjectBuilder.build(...)` is broken as it doesn't resolve the MavenProject correctly. This is a severe regression, and I think it should really be avoided in Maven before it cascade to m2e or other projects that use the ProjectBuilder API to do some validation or any other form of analysis. I suggest this gets reverted, we merge my unit-test that guarantees a good functioning state for `ProjectBuilder.build(...)` and the patch gets reworked to not introduce a regression. This is the only safe path. Note that while I may seem very opposed to this change, I am actually not at all. I just want to make the API still work as expected. I think there are way to rework the suggested patch so it doesn't introduce that regression. > 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] [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&focusedCommentId=16700807#comment-16700807 ] Mickael Istria commented on MNG-6311: - I think this change should be reverted as it's not backward compatible. Unless I'm mistaken, this caching makes that 2 distinct calls to ProjectBuilder.build(pomFile) would always return the same result even if the content of pomFile did change. It's almost certain that m2e will face a bug and other clients of ProjectBuilder may face bugs too. This case of changing pom content being modified and ProjectBuilder.build(...) returning the same result should be covered by a unit test (I may try write one). Caching is a good idea, but it also need to take into account the modification date to not cause bug in dynamic world. > 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] [Commented] (MNG-6529) ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies()
[ https://issues.apache.org/jira/browse/MNG-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700542#comment-16700542 ] Mickael Istria commented on MNG-6529: - https://github.com/apache/maven/pull/193 showcases the bug in a JUnit Test > ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) > doesn't honor ProjectBuildingRequest.isResolveDependencies() > --- > > Key: MNG-6529 > URL: https://issues.apache.org/jira/browse/MNG-6529 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.3 >Reporter: Mickael Istria >Priority: Critical > > I'm willing to upfate Eclipse m2e to take advantage of the > `ProjectBuilder.build(List project, boolean, ProjectBuildingRequest)` > in Eclipse m2e to avoid duplication of MavenProject in the IDE in place of > `ProjectBuilder.build(File singleFile, ProjectBuildingRequest)`. It's already > measured to have drastically good impact on the IDE, as explained in > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c20] and > [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c38]. > However, using this cause regressions because the multi-projects entry-point > method seems to totally ignore the > `ProjectBuildRequest.isResolveDependencies()` flag and never returns a valid > list of `MavenProject.getArtifacts()`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6529) ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies()
Mickael Istria created MNG-6529: --- Summary: ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies() Key: MNG-6529 URL: https://issues.apache.org/jira/browse/MNG-6529 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.5.3 Reporter: Mickael Istria I'm willing to upfate Eclipse m2e to take advantage of the `ProjectBuilder.build(List project, boolean, ProjectBuildingRequest)` in Eclipse m2e to avoid duplication of MavenProject in the IDE in place of `ProjectBuilder.build(File singleFile, ProjectBuildingRequest)`. It's already measured to have drastically good impact on the IDE, as explained in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c20] and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c38]. However, using this cause regressions because the multi-projects entry-point method seems to totally ignore the `ProjectBuildRequest.isResolveDependencies()` flag and never returns a valid list of `MavenProject.getArtifacts()`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] (SUREFIRE-773) surefire forked processes not always killed after timeout
[
https://jira.codehaus.org/browse/SUREFIRE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340782#comment-340782
]
Mickael Istria commented on SUREFIRE-773:
-
Seems like MSHARED-295 could be the cause.
> surefire forked processes not always killed after timeout
> -
>
> Key: SUREFIRE-773
> URL: https://jira.codehaus.org/browse/SUREFIRE-773
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.8
> Environment: 64 bit RHEL 5.5 , 64-bit Java 1.6.0_23
>Reporter: David Biesack
>
> Our forked JUnit/surefire processes are not always stopping correctly when
> timing out within a Maven build
> (running inside our Jenkins CI server, ver 1.425).
> The maven build finishes and Jenkins shows a failed/unstable build.
> These running processes cause problems later, because the tests may be
> holding a resource like a port, and subsequent rebuilds fail because the
> tests fail.
> For example, even though no Maven builds are currently running, ps shows
> about a dozen Java processes running,
> with commands such as:
> {noformat}
> /usr/local/java-1.6_23/jre/bin/java -Xms1g -Xmx5g
> -Djava.library.path=/u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/lib
> \
>-jar
> /u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/surefire/surefirebooter1374560535780866887.jar
> \
>
> /u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/surefire/surefire65313...
> /usr/local/java-1.6_23/jre/bin/java -Xmx2g -Xms1g
> -Djava.library.path=/u/jenkinsci/.hudson/jobs/rtolap/workspace/target/lib \
>-jar
> /u/jenkinsci/.hudson/jobs/rtolap/workspace/target/surefire/surefirebooter6814971258434039335.jar
> \
>
> /u/jenkinsci/.hudson/jobs/rtolap/workspace/target/surefire/surefire5806103969370259371tmp
> /u/jenkinsci/...
> ...
> {noformat}
> We have our Maven surefire preferences set to fork the tests (via a parent
> pom)
> {code:xml|title=pom.xml excerpt}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.8
>
> once
>
> 720
>
>
> {code}
> I suspect the timeout is the problem - i.e. perhaps the test is timing out
> and the attempt to kill the forked process
> fails, leaving it running.
> Has anyone seen something similar and/or know how to fix this so that
> surefire *really* kills the process?
> When this happens, doing
> kill
> (logged in as the process owner) usually does not work, but
> kill -9
> does.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-773) surefire forked processes not always killed after timeout
[
https://jira.codehaus.org/browse/SUREFIRE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340781#comment-340781
]
Mickael Istria commented on SUREFIRE-773:
-
Tycho-surefire-plugin has a similar issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427556
> surefire forked processes not always killed after timeout
> -
>
> Key: SUREFIRE-773
> URL: https://jira.codehaus.org/browse/SUREFIRE-773
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.8
> Environment: 64 bit RHEL 5.5 , 64-bit Java 1.6.0_23
>Reporter: David Biesack
>
> Our forked JUnit/surefire processes are not always stopping correctly when
> timing out within a Maven build
> (running inside our Jenkins CI server, ver 1.425).
> The maven build finishes and Jenkins shows a failed/unstable build.
> These running processes cause problems later, because the tests may be
> holding a resource like a port, and subsequent rebuilds fail because the
> tests fail.
> For example, even though no Maven builds are currently running, ps shows
> about a dozen Java processes running,
> with commands such as:
> {noformat}
> /usr/local/java-1.6_23/jre/bin/java -Xms1g -Xmx5g
> -Djava.library.path=/u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/lib
> \
>-jar
> /u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/surefire/surefirebooter1374560535780866887.jar
> \
>
> /u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/surefire/surefire65313...
> /usr/local/java-1.6_23/jre/bin/java -Xmx2g -Xms1g
> -Djava.library.path=/u/jenkinsci/.hudson/jobs/rtolap/workspace/target/lib \
>-jar
> /u/jenkinsci/.hudson/jobs/rtolap/workspace/target/surefire/surefirebooter6814971258434039335.jar
> \
>
> /u/jenkinsci/.hudson/jobs/rtolap/workspace/target/surefire/surefire5806103969370259371tmp
> /u/jenkinsci/...
> ...
> {noformat}
> We have our Maven surefire preferences set to fork the tests (via a parent
> pom)
> {code:xml|title=pom.xml excerpt}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.8
>
> once
>
> 720
>
>
> {code}
> I suspect the timeout is the problem - i.e. perhaps the test is timing out
> and the attempt to kill the forked process
> fails, leaving it running.
> Has anyone seen something similar and/or know how to fix this so that
> surefire *really* kills the process?
> When this happens, doing
> kill
> (logged in as the process owner) usually does not work, but
> kill -9
> does.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5347) Support expression language in ${...}
[
https://jira.codehaus.org/browse/MNG-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334466#comment-334466
]
Mickael Istria commented on MNG-5347:
-
> Mickael, are you about to try something in this direction?
I don't have immediate plans to work on a patch to integrate Groovy because I
have many things in my TODO-list for now and can't put a big priority on this
request. If someone has some time to spend on this soon, let they do it, I'd be
glad to leech it later ;)
> Support expression language in ${...}
> -
>
> Key: MNG-5347
> URL: https://jira.codehaus.org/browse/MNG-5347
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: General
>Affects Versions: 3.0.4
> Environment: mistria@mistria--rh:~$ mvn -version
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: /home/mistria/apps/apache-maven-3.0.4
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.2.0-30-generic", arch: "amd64", family: "unix"
>Reporter: Mickael Istria
>
> Use-case:
> I want to give as input of my surefire-plugin
> {code}
>
> ${skipTests} || ${skipDownloadRuntimes}
>
> {code}
> This won't work because the expressions are not evaluated. Boolean arguments
> in plugin are set to something like Boolean.parseBoolean, which is quite
> limited.
> Instead, we could think of introducing an expression language, such as
> Groovy, that would allow expressions as parameters for plugins.
> Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would
> first replace "${skipTests} || ${skipDownloadRuntimes}" by "false
> || true" and then this evaluator would evaluate that to "false", and skip
> will receive the value "false".
> This would for sure make maven less verbose in some cases.
> *EDIT* (thanks Ondrej for inspiring commnent)
> Actually, this syntax would make more sense, and allow an expression language:
> {code}
>
> ${skipTests|| skipDownloadRuntimes}
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-406) Support of velocity expressions for user-defined properties
[
https://jira.codehaus.org/browse/ARCHETYPE-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334096#comment-334096
]
Mickael Istria edited comment on ARCHETYPE-406 at 10/14/13 2:31 AM:
MNG-5347 suggest allowing an expression language for user properties in
${...}
was (Author: mickael.istria):
MNG-5347 suggest allowing an expression language for user properties in
${...}
> Support of velocity expressions for user-defined properties
> ---
>
> Key: ARCHETYPE-406
> URL: https://jira.codehaus.org/browse/ARCHETYPE-406
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.x
>Reporter: Bue Pierre-Christophe
> Attachments: sample-archetype406.tar.gz
>
>
> Standard properties (artifactId, groupId, ...) are supported in Velocity
> expressiosn, but still does not work with user defined properties. For
> example:
>
> ${artifactId}.substring(0,1).toUpperCase()
>
> with artifactId=toto will give a=T, but
>
>
> ${b}.substring(0,1).toUpperCase()
>
> with b=toto will give a=${b}.substring(0,1).toUpperCase()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5347) Support expression language in ${...}
[
https://jira.codehaus.org/browse/MNG-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mickael Istria updated MNG-5347:
Description:
Use-case:
I want to give as input of my surefire-plugin
{code}
${skipTests} || ${skipDownloadRuntimes}
{code}
This won't work because the expressions are not evaluated. Boolean arguments in
plugin are set to something like Boolean.parseBoolean, which is quite limited.
Instead, we could think of introducing an expression language, such as Groovy,
that would allow expressions as parameters for plugins.
Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would first
replace "${skipTests} || ${skipDownloadRuntimes}" by "false || true"
and then this evaluator would evaluate that to "false", and skip will receive
the value "false".
This would for sure make maven less verbose in some cases.
*EDIT* (thanks Ondrej for inspiring commnent)
Actually, this syntax would make more sense, and allow an expression language:
{code}
${skipTests|| skipDownloadRuntimes}
{code}
was:
Use-case:
I want to give as input of my surefire-plugin
{code}
${skipTests} || ${skipDownloadRuntimes}
{code}
This won't work because the expressions are not evaluated. Boolean arguments in
plugin are set to something like Boolean.parseBoolean, which is quite limited.
Instead, we could think of introducing an expression language, such as Groovy,
that would allow expressions as parameters for plugins.
Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would first
replace "${skipTests} || ${skipDownloadRuntimes}" by "false || true" and then
this evaluator would evaluate that to "false", and skip will receive the value
"false".
This would for sure make maven less verbose in some cases.
> Support expression language in ${...}
> -
>
> Key: MNG-5347
> URL: https://jira.codehaus.org/browse/MNG-5347
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: General
>Affects Versions: 3.0.4
> Environment: mistria@mistria--rh:~$ mvn -version
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: /home/mistria/apps/apache-maven-3.0.4
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.2.0-30-generic", arch: "amd64", family: "unix"
>Reporter: Mickael Istria
>
> Use-case:
> I want to give as input of my surefire-plugin
> {code}
>
> ${skipTests} || ${skipDownloadRuntimes}
>
> {code}
> This won't work because the expressions are not evaluated. Boolean arguments
> in plugin are set to something like Boolean.parseBoolean, which is quite
> limited.
> Instead, we could think of introducing an expression language, such as
> Groovy, that would allow expressions as parameters for plugins.
> Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would
> first replace "${skipTests} || ${skipDownloadRuntimes}" by "false
> || true" and then this evaluator would evaluate that to "false", and skip
> will receive the value "false".
> This would for sure make maven less verbose in some cases.
> *EDIT* (thanks Ondrej for inspiring commnent)
> Actually, this syntax would make more sense, and allow an expression language:
> {code}
>
> ${skipTests|| skipDownloadRuntimes}
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5347) Support expressions for plugin parameters
[
https://jira.codehaus.org/browse/MNG-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334095#comment-334095
]
Mickael Istria commented on MNG-5347:
-
You're right, this is much more about supporting expression languages (ideally
Groovy) in ${...} blocks.
It was discussed some time ago:
http://maven.40175.n5.nabble.com/Discuss-Using-Expression-Language-in-POM-td3228668.html
and the conclusion was that introducing script would be against the current
descriptive & XML only approach. Despite of the output of this discussion, it
is clear the allowing expression language in ${...} blocks would be a pragmatic
and helpful improvement.
> Support expressions for plugin parameters
> -
>
> Key: MNG-5347
> URL: https://jira.codehaus.org/browse/MNG-5347
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: General
>Affects Versions: 3.0.4
> Environment: mistria@mistria--rh:~$ mvn -version
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: /home/mistria/apps/apache-maven-3.0.4
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.2.0-30-generic", arch: "amd64", family: "unix"
>Reporter: Mickael Istria
>
> Use-case:
> I want to give as input of my surefire-plugin
> {code}
>
> ${skipTests} || ${skipDownloadRuntimes}
>
> {code}
> This won't work because the expressions are not evaluated. Boolean arguments
> in plugin are set to something like Boolean.parseBoolean, which is quite
> limited.
> Instead, we could think of introducing an expression language, such as
> Groovy, that would allow expressions as parameters for plugins.
> Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would
> first replace "${skipTests} || ${skipDownloadRuntimes}" by "false || true"
> and then this evaluator would evaluate that to "false", and skip will receive
> the value "false".
> This would for sure make maven less verbose in some cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5347) Support expression language in ${...}
[
https://jira.codehaus.org/browse/MNG-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mickael Istria updated MNG-5347:
Summary: Support expression language in ${...} (was: Support expressions
for plugin parameters)
> Support expression language in ${...}
> -
>
> Key: MNG-5347
> URL: https://jira.codehaus.org/browse/MNG-5347
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: General
>Affects Versions: 3.0.4
> Environment: mistria@mistria--rh:~$ mvn -version
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: /home/mistria/apps/apache-maven-3.0.4
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.2.0-30-generic", arch: "amd64", family: "unix"
>Reporter: Mickael Istria
>
> Use-case:
> I want to give as input of my surefire-plugin
> {code}
>
> ${skipTests} || ${skipDownloadRuntimes}
>
> {code}
> This won't work because the expressions are not evaluated. Boolean arguments
> in plugin are set to something like Boolean.parseBoolean, which is quite
> limited.
> Instead, we could think of introducing an expression language, such as
> Groovy, that would allow expressions as parameters for plugins.
> Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would
> first replace "${skipTests} || ${skipDownloadRuntimes}" by "false || true"
> and then this evaluator would evaluate that to "false", and skip will receive
> the value "false".
> This would for sure make maven less verbose in some cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1026) Allow SurefireBooter framework to use alternative resolve for test classes
Mickael Istria created SUREFIRE-1026: Summary: Allow SurefireBooter framework to use alternative resolve for test classes Key: SUREFIRE-1026 URL: https://jira.codehaus.org/browse/SUREFIRE-1026 Project: Maven Surefire Issue Type: Wish Affects Versions: 2.15 Reporter: Mickael Istria For Tycho, there is a use-case that makes that we want to resolve includes/excludes for Surefire against either: * multiple directories (Tycho, as PDE, allows multiple directories for the classes depending on project-specific configuration; and all these directories can contain tests) * a bundle, which might contain some nested jars (nested jars are allowed by OSGi and can contain some jars, which can contain some tests to execute). I had a look at the surefire-booter framework, and it appears that the DirectoryScannerParameters allows only a single folder, and is propagated directly in all the surefire-booter framework. It would be interesting to introduce an abstract class to resolve the TestClasses, where Tycho could hook a resolver against an OSGi bundle instead of a resolver against a single directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-390) org.apache.maven.plugins:maven-dependency-plugin:get to support "unpack"
[ https://jira.codehaus.org/browse/MDEP-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314279#comment-314279 ] Mickael Istria commented on MDEP-390: - Sorry for the dupe. It seems to me that commit in r1397671 still does not allow to use alternative repositories from command-line when using unpack mojo. Was this use-case described in an earlier bug, or should I create a new ticket to request this? > org.apache.maven.plugins:maven-dependency-plugin:get to support "unpack" > > > Key: MDEP-390 > URL: https://jira.codehaus.org/browse/MDEP-390 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: get >Affects Versions: 2.5.1 >Reporter: Mickael Istria >Assignee: Robert Scholte > > As a user, I'd like to download a Maven artifact from command-line and get it > unzipped. > In order to use the maven-depdenceny-plugin:goal as the ultimate command-line > client to download a maven artifact (not necessarly in the context of a > project), it would be useful to add to it an "unpack" parameter that would > allow to unpack the just-downloaded stuff. > When in comes to automating download+unzip of an artifact in CI: > Currently, one has to add a Shell or Ant or Groovy script to unzip, after > using "mvn org.apache.maven.plugins:maven-dependency-plugin:2.5.1:get > -Dartifact=blah:blah:1.0 -DremoteRepositories=http://somewhere";. It's not > very convenient as this requires usage of another Ant or Groovy file, or > usage of a platform-specific interpreter. > Also note that the unpack-mojo can't fit this use-case since it's not > configurable via command-line (can't set artifactItems nor > remoteRepositories). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-390) org.apache.maven.plugins:maven-dependency-plugin:get to support "unpack"
Mickael Istria created MDEP-390: --- Summary: org.apache.maven.plugins:maven-dependency-plugin:get to support "unpack" Key: MDEP-390 URL: https://jira.codehaus.org/browse/MDEP-390 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: get Affects Versions: 2.5.1 Reporter: Mickael Istria As a user, I'd like to download a Maven artifact from command-line and get it unzipped. In order to use the maven-depdenceny-plugin:goal as the ultimate command-line client to download a maven artifact (not necessarly in the context of a project), it would be useful to add to it an "unpack" parameter that would allow to unpack the just-downloaded stuff. When in comes to automating download+unzip of an artifact in CI: Currently, one has to add a Shell or Ant or Groovy script to unzip, after using "mvn org.apache.maven.plugins:maven-dependency-plugin:2.5.1:get -Dartifact=blah:blah:1.0 -DremoteRepositories=http://somewhere";. It's not very convenient as this requires usage of another Ant or Groovy file, or usage of a platform-specific interpreter. Also note that the unpack-mojo can't fit this use-case since it's not configurable via command-line (can't set artifactItems nor remoteRepositories). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5347) Support expressions for plugin parameters
Mickael Istria created MNG-5347:
---
Summary: Support expressions for plugin parameters
Key: MNG-5347
URL: https://jira.codehaus.org/browse/MNG-5347
Project: Maven 2 & 3
Issue Type: Wish
Components: General
Affects Versions: 3.0.4
Environment: mistria@mistria--rh:~$ mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /home/mistria/apps/apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.2.0-30-generic", arch: "amd64", family: "unix"
Reporter: Mickael Istria
Use-case:
I want to give as input of my surefire-plugin
{code}
${skipTests} || ${skipDownloadRuntimes}
{code}
This won't work because the expressions are not evaluated. Boolean arguments in
plugin are set to something like Boolean.parseBoolean, which is quite limited.
Instead, we could think of introducing an expression language, such as Groovy,
that would allow expressions as parameters for plugins.
Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would first
replace "${skipTests} || ${skipDownloadRuntimes}" by "false || true" and then
this evaluator would evaluate that to "false", and skip will receive the value
"false".
This would for sure make maven less verbose in some cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5333) Support expressions for plugin parameters
Mickael Istria created MNG-5333:
---
Summary: Support expressions for plugin parameters
Key: MNG-5333
URL: https://jira.codehaus.org/browse/MNG-5333
Project: Maven 2 & 3
Issue Type: Wish
Environment: mistria@mistria--rh:~$ mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /home/mistria/apps/apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.2.0-29-generic", arch: "amd64", family: "unix"
Reporter: Mickael Istria
Use-case:
I want to give as input of my surefire-plugin
${skipTests} || ${skipDownloadRuntimes}
This won't work because the expressions are not evaluated. Boolean arguments in
plugin are set to something like Boolean.parseBoolean, which is quite limited.
Instead, we could think of introducing an expression language, such as Groovy,
that would allow expressions as parameters for plugins.
Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would first
replace "${skipTests} || ${skipDownloadRuntimes}" by "false || true" and then
this evaluator would evaluate that to "false", and skip will receive the value
"false".
This would for sure make maven less verbose in some cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
