[jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569572#comment-16569572
]
Dawid Weiss commented on MNG-6261:
--
Thanks Robert.
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Assignee: Robert Scholte
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1457) trimStackTrace should be disabled by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569570#comment-16569570
]
Tibor Digana commented on SUREFIRE-1457:
[~reda-alaoui]
but similar issue is in a plan: SUREFIRE-1432
> trimStackTrace should be disabled by default
>
>
> Key: SUREFIRE-1457
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1457
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.21.2
>Reporter: Réda Housni Alaoui
>Assignee: Tibor Digana
>Priority: Critical
>
> We are using Jenkins at work.
> Each time we had test failures, stack trace were incomplete and therefore
> totally useless.
> I just discovered {{trimStackTrace}} option.
> IMO, the fact that this option is currently enabled by default is a total non
> sense.
> Now we have to change the pom.xml of every projects of the company to have a
> correct default.
> IMO, and I think I am not the only one here, trimStackTrace should be
> disabled by default.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-109) Upgrade plexus-utils from 3.0.24 to 3.1.0
[ https://issues.apache.org/jira/browse/MRRESOURCES-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569565#comment-16569565 ] Hudson commented on MRRESOURCES-109: Build succeeded in Jenkins: Maven TLP » maven-remote-resources-plugin » master #18 See https://builds.apache.org/job/maven-box/job/maven-remote-resources-plugin/job/master/18/ > Upgrade plexus-utils from 3.0.24 to 3.1.0 > - > > Key: MRRESOURCES-109 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-109 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.6.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MRRESOURCES-109) Upgrade plexus-utils from 3.0.24 to 3.1.0
[ https://issues.apache.org/jira/browse/MRRESOURCES-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MRRESOURCES-109. --- Resolution: Done > Upgrade plexus-utils from 3.0.24 to 3.1.0 > - > > Key: MRRESOURCES-109 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-109 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.6.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-109) Upgrade plexus-utils from 3.0.24 to 3.1.0
[ https://issues.apache.org/jira/browse/MRRESOURCES-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569563#comment-16569563 ] Karl Heinz Marbaise commented on MRRESOURCES-109: - Done in [2882d5d6c013fce0b4bd92814db7376263c7a0f2|https://gitbox.apache.org/repos/asf?p=maven-remote-resources-plugin.git;a=commitdiff;h=2882d5d6c013fce0b4bd92814db7376263c7a0f2] > Upgrade plexus-utils from 3.0.24 to 3.1.0 > - > > Key: MRRESOURCES-109 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-109 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.6.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MRRESOURCES-109) Upgrade plexus-utils from 3.0.24 to 3.1.0
Karl Heinz Marbaise created MRRESOURCES-109: --- Summary: Upgrade plexus-utils from 3.0.24 to 3.1.0 Key: MRRESOURCES-109 URL: https://issues.apache.org/jira/browse/MRRESOURCES-109 Project: Maven Remote Resources Plugin Issue Type: Dependency upgrade Affects Versions: 1.6.0 Reporter: Karl Heinz Marbaise Fix For: 1.6.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-108) Upgrade plexus-interpolation to 1.25
[ https://issues.apache.org/jira/browse/MRRESOURCES-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569561#comment-16569561 ] Hudson commented on MRRESOURCES-108: Build succeeded in Jenkins: Maven TLP » maven-remote-resources-plugin » master #17 See https://builds.apache.org/job/maven-box/job/maven-remote-resources-plugin/job/master/17/ > Upgrade plexus-interpolation to 1.25 > > > Key: MRRESOURCES-108 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-108 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.6.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MRRESOURCES-108) Upgrade plexus-interpolation to 1.25
[ https://issues.apache.org/jira/browse/MRRESOURCES-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MRRESOURCES-108. --- Resolution: Done > Upgrade plexus-interpolation to 1.25 > > > Key: MRRESOURCES-108 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-108 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.6.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-108) Upgrade plexus-interpolation to 1.25
[ https://issues.apache.org/jira/browse/MRRESOURCES-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569560#comment-16569560 ] Karl Heinz Marbaise commented on MRRESOURCES-108: - Done in [997cb1abf320fb809a8a609c4e80b188e3cc1692|https://gitbox.apache.org/repos/asf?p=maven-remote-resources-plugin.git;a=commitdiff;h=997cb1abf320fb809a8a609c4e80b188e3cc1692] > Upgrade plexus-interpolation to 1.25 > > > Key: MRRESOURCES-108 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-108 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.6.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MRRESOURCES-108) Upgrade plexus-interpolation to 1.25
Karl Heinz Marbaise created MRRESOURCES-108: --- Summary: Upgrade plexus-interpolation to 1.25 Key: MRRESOURCES-108 URL: https://issues.apache.org/jira/browse/MRRESOURCES-108 Project: Maven Remote Resources Plugin Issue Type: Dependency upgrade Affects Versions: 1.6.0 Reporter: Karl Heinz Marbaise Fix For: 1.6.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-107) Upgrade JUnit from 4.11 to 4.12
[ https://issues.apache.org/jira/browse/MRRESOURCES-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569558#comment-16569558 ] Hudson commented on MRRESOURCES-107: Build succeeded in Jenkins: Maven TLP » maven-remote-resources-plugin » master #16 See https://builds.apache.org/job/maven-box/job/maven-remote-resources-plugin/job/master/16/ > Upgrade JUnit from 4.11 to 4.12 > --- > > Key: MRRESOURCES-107 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-107 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.6.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MRRESOURCES-107) Upgrade JUnit from 4.11 to 4.12
[ https://issues.apache.org/jira/browse/MRRESOURCES-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MRRESOURCES-107. --- Resolution: Done > Upgrade JUnit from 4.11 to 4.12 > --- > > Key: MRRESOURCES-107 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-107 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.6.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-107) Upgrade JUnit from 4.11 to 4.12
[ https://issues.apache.org/jira/browse/MRRESOURCES-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569557#comment-16569557 ] Karl Heinz Marbaise commented on MRRESOURCES-107: - Done in [65e90d310e4bcdf4960d6763d1032381f29a352e|https://gitbox.apache.org/repos/asf?p=maven-remote-resources-plugin.git;a=commitdiff;h=65e90d310e4bcdf4960d6763d1032381f29a352e] > Upgrade JUnit from 4.11 to 4.12 > --- > > Key: MRRESOURCES-107 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-107 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.6.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MRRESOURCES-107) Upgrade JUnit from 4.11 to 4.12
Karl Heinz Marbaise created MRRESOURCES-107: --- Summary: Upgrade JUnit from 4.11 to 4.12 Key: MRRESOURCES-107 URL: https://issues.apache.org/jira/browse/MRRESOURCES-107 Project: Maven Remote Resources Plugin Issue Type: Dependency upgrade Affects Versions: 1.6.0 Reporter: Karl Heinz Marbaise Fix For: 1.6.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MRRESOURCES-105) Currently Master build is failing
[ https://issues.apache.org/jira/browse/MRRESOURCES-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MRRESOURCES-105. --- Resolution: Resolved Fix Version/s: (was: 1.6) > Currently Master build is failing > - > > Key: MRRESOURCES-105 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-105 > Project: Maven Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCOMPILER-354) Module patching fails: case of simple single-module project
[
https://issues.apache.org/jira/browse/MCOMPILER-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569499#comment-16569499
]
Christian Stein commented on MCOMPILER-354:
---
I'm still trying to wrap my head around your example project and will come back
later with a direct answer...
But, in the meantime, perhaps it helps, when you look at the slides at
[https://gitpitch.com/sormuras/testing-in-the-modular-world/master?grs=github=beige#/7]
and the underlying sample project here
[https://github.com/junit-team/junit5-samples/tree/master/junit5-modular-world]
Also, take a look at the three integration tests added for
maven-compiler-plugin 3.8.0 in
[https://github.com/apache/maven-compiler-plugin/tree/master/src/it]
# jpms_compile-main-empty-test-bar (No Box ... just showing that test modules
are first-class modules too)
# jpms_compile-main-foo-test-bar (Black Box)
# jpms_compile-main-foo-test-foo (White Box)
> Module patching fails: case of simple single-module project
> ---
>
> Key: MCOMPILER-354
> URL: https://issues.apache.org/jira/browse/MCOMPILER-354
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: $ mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T20:33:14+02:00)
> Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
> Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk-10.0.2
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: foo bar
>Priority: Major
> Labels: Jigsaw
> Attachments: mvn-X-clean-install-FAILURE.log, project.png, wires.zip
>
>
> Sometimes it can be difficult to setup maven test-scoped dependencies in a
> Maven multi-module project. But I think I managed to find a simple 1-module
> case where module patching doesn't work.
> I have a single-module Java 10 project where the testCompile goal complains
> that Test Class A doesn't read Test Class B, which is in the same project!
> (but in a different package)
> Of course, a class shouldn't need to be exported to a class of the same
> module. So maybe there is a confusion somewhere between the unnamed module,
> automatic modules, and explicit modules.
> I think that's because of a bug in the module-patching flags passed by
> testCompile to javac.
> My project source tree, in its simplified branch to reproduce the issue,
> looks shown in the project.png attachment.
> Full log is attached as well as a zip of the issue reproduction branch. It
> can also be cloned from:
> {code:java}
> git clone https://github.com/vandekeiser/wires.git
> git checkout REPORT-MCOMPILER-2
> mvn clean install
> {code}
> The flags testCompile pass to javac.
> {code:java}
> [INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @
> wires-support ---
> [DEBUG] Command line options:
> -d G:\projets\wires\wires\wires\wires-support\target\test-classes
> -classpath G:\projets\wires\wires\wires\wires-support\target\test-classes;
> --module-path G:\projets\wires\wires\wires\wires-support\target\classes;
> -sourcepath G:\projets\wires\wires\wires\wires-support\src\test\java;
>
> G:\projets\wires\wires\wires\wires-support\target\generated-test-sources\test-annotations;
> -s
> G:\projets\wires\wires\wires\wires-support\target\generated-test-sources\test-annotations
> -g -deprecation -target 10 -source 10 -encoding UTF-8 -Werror
> -Xlint:all,-serial
> --patch-module fr.cla.wires.support=
> G:\projets\wires\wires\wires\wires-support\target\classes;
> G:\projets\wires\wires\wires\wires-support\src\test\java;
>
> G:\projets\wires\wires\wires\wires-support\target\generated-test-sources\test-annotations;
> --add-reads fr.cla.wires.support=ALL-UNNAMED
> {code}
> The warning I get (which for me is an error):
> {code:java}
> [WARNING]
> /G:/projets/wires/wires/wires/wires-support/src/test/java/fr/cla/wires/support/DoesntCompile.java:[14,20]
> class
> fr.cla.wires.support.javac_complains_this_is_not_exported.JavacComplainsThisIsNotExported
> in module fr.cla.wires.support
> is not exported
> [ERROR] COMPILATION ERROR :
> warnings found and -Werror specified
> [INFO] 1 error
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-103) Upgrade parent to 32
[ https://issues.apache.org/jira/browse/MRRESOURCES-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569498#comment-16569498 ] Hudson commented on MRRESOURCES-103: Build succeeded in Jenkins: Maven TLP » maven-remote-resources-plugin » master #14 See https://builds.apache.org/job/maven-box/job/maven-remote-resources-plugin/job/master/14/ > Upgrade parent to 32 > > > Key: MRRESOURCES-103 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-103 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6 >Reporter: Karl Heinz Marbaise >Assignee: Robert Scholte >Priority: Minor > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MRRESOURCES-103) Upgrade parent to 32
[ https://issues.apache.org/jira/browse/MRRESOURCES-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRRESOURCES-103. -- Resolution: Fixed Fixed in [ec3fbb182ac1da9adf78f1708158545c1b4ae848|https://gitbox.apache.org/repos/asf?p=maven-remote-resources-plugin.git;a=commit;h=ec3fbb182ac1da9adf78f1708158545c1b4ae848] > Upgrade parent to 32 > > > Key: MRRESOURCES-103 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-103 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6 >Reporter: Karl Heinz Marbaise >Assignee: Robert Scholte >Priority: Minor > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569494#comment-16569494
]
Hudson commented on MNG-6261:
-
Build succeeded in Jenkins: Maven TLP » maven-remote-resources-plugin »
MRRESOURCES-103 #23
See
https://builds.apache.org/job/maven-box/job/maven-remote-resources-plugin/job/MRRESOURCES-103/23/
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Assignee: Robert Scholte
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-103) Upgrade parent to 32
[ https://issues.apache.org/jira/browse/MRRESOURCES-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569493#comment-16569493 ] Hudson commented on MRRESOURCES-103: Build succeeded in Jenkins: Maven TLP » maven-remote-resources-plugin » MRRESOURCES-103 #23 See https://builds.apache.org/job/maven-box/job/maven-remote-resources-plugin/job/MRRESOURCES-103/23/ > Upgrade parent to 32 > > > Key: MRRESOURCES-103 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-103 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6 >Reporter: Karl Heinz Marbaise >Assignee: Robert Scholte >Priority: Minor > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINVOKER-190) build.log file location causes problems
[
https://issues.apache.org/jira/browse/MINVOKER-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MINVOKER-190:
Labels: up-for-grabs (was: )
> build.log file location causes problems
> ---
>
> Key: MINVOKER-190
> URL: https://issues.apache.org/jira/browse/MINVOKER-190
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Christopher Tubbs
>Priority: Major
> Labels: up-for-grabs
>
> The {{build.log}} file is quite annoying because it is placed in the invoked
> project's source tree by default. It is not configurable, except to disable
> it entirely with the {{noLog}} option.
> This causes issues, such as what is identified in RAT-160, where certain
> plugins behave in unexpectedly bad ways when it appears in the invoked
> project's root.
> Ideally, I'd love for the {{build.log}} file to be created outside of the
> invoked project's source tree entirely. The most sensible, I think, is in the
> invoking project's target/ directory, named uniquely for that invocation.
> Another option is in the invoked project's target directory (which may not
> otherwise exist, so this may not be suitable). A third option is to make the
> location completely configurable, and leave it up to the user to decide where
> it goes.
> The important thing to remember is that not every plugin on an executed
> project can be configured to ignore this file, so it definitely shouldn't be
> created in the invoked project's root by default when there isn't an option
> to put it elsewhere.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MENFORCER-194) Rule RequireSameVersions: dependency artifacts are not checked
[ https://issues.apache.org/jira/browse/MENFORCER-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MENFORCER-194: - Labels: up-for-grabs (was: ) > Rule RequireSameVersions: dependency artifacts are not checked > -- > > Key: MENFORCER-194 > URL: https://issues.apache.org/jira/browse/MENFORCER-194 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.3.1 >Reporter: Rod Woo >Priority: Major > Labels: up-for-grabs > Attachments: RequireSameVersions_setDependencies.patch > > > In RequireSameVersions.java you must prefer the method > project.getDependencyArtifacts() to project.getArtifacts(). > Testcase and patch are attached. > Furthermore, the official documentation of the rule should make clear that > transitive dependencies are not considered. This will make the rule for many > users meaningless. > Furthermore, the official documentation of the rule should make clear that > the test coverage of the rule implementation is small. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRELEASE-161) If there is more than one artifact with the same artifactId in dependencyManagement only the first one is updated
[
https://issues.apache.org/jira/browse/MRELEASE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-161:
Labels: up-for-grabs (was: )
> If there is more than one artifact with the same artifactId in
> dependencyManagement only the first one is updated
> -
>
> Key: MRELEASE-161
> URL: https://issues.apache.org/jira/browse/MRELEASE-161
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-4
> Environment: Maven 2.0.4 under windows
>Reporter: Sébastien Cesbron
>Priority: Major
> Labels: up-for-grabs
> Attachments: MRELEASE-161.patch, multipleArtifacts.patch,
> release-test.zip
>
>
> I have a multi module project. When I do release:prepare, the release plugin
> update the version tag of all my submodules in the dependencyManagement
> section.
> For the same module I have declared two artifacts like this :
> {code:xml}
>
> com.bla
> blabla
> 1.0-SNAPSHOT
> test-jar
> test
>
>
> com.bla
> blabla
> 1.0-SNAPSHOT
>
> {code}
> In this case, the release plugin only update the first dependency.
> This is due to element search in the "updateDomVersion" method of the
> AbstractRewritePomsPhase class. I've attached a patch to solve the problem. I
> don't know if this is the right way to do. I change all the artifacts in the
> same pass. I don't take car of different type/classifier
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MWAR-371) Overlays break first-win rule for web resource with target path ending with '/'
[
https://issues.apache.org/jira/browse/MWAR-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MWAR-371:
Labels: up-for-grabs (was: )
> Overlays break first-win rule for web resource with target path ending with
> '/'
> ---
>
> Key: MWAR-371
> URL: https://issues.apache.org/jira/browse/MWAR-371
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 2.6
>Reporter: Michal Domagala
>Priority: Minor
> Labels: up-for-grabs
>
> I have WAR 'generic' containing 2 files: x/a1.txt and x/a2.txt
> I have WAR 'custom' with two source files: src/main/custom/a1.txt and
> src/main/custom/a2.txt and settings:
> {code:xml}
> maven-war-plugin
>
>
>
> src/main/custom
> a1.txt
> x/
>
>
> src/main/custom
> a2.txt
> x
>
>
>
> {code}
> Note that *targetPath* is different: *x/* vs *x*
> When I build WAR 'custom'
> Actual: a1.txt is generic, a2.txt is custom
> Expected a1.txt and a2.txt are custom
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files
[
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MSHADE-291:
--
Labels: up-for-grabs (was: )
> shadedPattern applied multiples times when relocating the contents of
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Jan Luehe
>Priority: Major
> Labels: up-for-grabs
>
> Steps to reproduce:
> 1. Modified the test case for
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>
> org.apache.maven.plugins
> maven-shade-plugin
> -2.4
> +3.1.1
>
>
>
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>
>
>
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows:
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MDEP-586) Unpacking different resources into different location from the same artifact doesn't work
[
https://issues.apache.org/jira/browse/MDEP-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MDEP-586:
Description:
I have one artifact, in the simplest case only with two resources inside:
ResourceArtifact-1.0.jar
/resource1.dat
/resource2.dat
I want to unpack one resource into one location and the second in a different
location, all this with one pom.xml:
{code:xml}
org.apache.maven.plugins
maven-dependency-plugin
3.0.2
unpack-resource1
unpack-dependencies
ResourceArtifact
resource1.dat
resources1
unpack-resource2
unpack-dependencies
ResourceArtifact
resource2.dat
resources2
{code}
When I +*don't*+ use (which makes not so much sense, because in fact there's
nothing to overwrite):
{code:xml}
true
true
{code}
Then I get an info (even not a warning):
{noformat}
[INFO] --- maven-dependency-plugin:3.0.2:unpack-dependencies (unpack-resource2)
@ maven-unpack-same-artifact ---
[INFO] test:ResourceArtifact:jar:1.0 already exists in destination.
{noformat}
And the second resource is not unpacked.
was:
I have one artifact, in the simplest case only with two resources inside:
ResourceArtifact-1.0.jar
/resource1.dat
/resource2.dat
I want to unpack one resource into one location and the second in a different
location, all this with one pom.xml:
org.apache.maven.plugins
maven-dependency-plugin
3.0.2
unpack-resource1
unpack-dependencies
ResourceArtifact
resource1.dat
resources1
unpack-resource2
unpack-dependencies
ResourceArtifact
resource2.dat
resources2
When I +*don't*+ use (which makes not so much sense, because in fact there's
nothing to overwrite):
true
true
Then I get an info (even not a warning):
[INFO] --- maven-dependency-plugin:3.0.2:unpack-dependencies (unpack-resource2)
@ maven-unpack-same-artifact ---
[INFO] test:ResourceArtifact:jar:1.0 already exists in destination.
And the second resource is not unpacked.
> Unpacking different resources into different location from the same artifact
> doesn't work
> -
>
> Key: MDEP-586
> URL: https://issues.apache.org/jira/browse/MDEP-586
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack-dependencies
>Affects Versions: 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files (x86)\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_111\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Tomas Tulka
>Priority: Major
> Labels: up-for-grabs
> Attachments: pom.xml
>
>
> I have one artifact, in the simplest case only with two resources inside:
> ResourceArtifact-1.0.jar
> /resource1.dat
> /resource2.dat
> I want to unpack one resource into one location and the second in a different
> location, all this with one pom.xml:
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.0.2
>
>
> unpack-resource1
>
> unpack-dependencies
>
>
> ResourceArtifact
> resource1.dat
> resources1
>
>
>
> unpack-resource2
>
> unpack-dependencies
>
>
> ResourceArtifact
> resource2.dat
> resources2
>
>
>
>
> {code}
> When I +*don't*+ use (which makes not so much sense, because in fact there's
> nothing to overwrite):
> {code:xml}
> true
> true
> {code}
> Then I get an info (even not a warning):
> {noformat}
> [INFO] --- maven-dependency-plugin:3.0.2:unpack-dependencies
> (unpack-resource2) @ maven-unpack-same-artifact ---
> [INFO] test:ResourceArtifact:jar:1.0 already exists in destination.
> {noformat}
> And the second resource is not unpacked.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MDEP-586) Unpacking different resources into different location from the same artifact doesn't work
[
https://issues.apache.org/jira/browse/MDEP-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MDEP-586:
Labels: up-for-grabs (was: )
> Unpacking different resources into different location from the same artifact
> doesn't work
> -
>
> Key: MDEP-586
> URL: https://issues.apache.org/jira/browse/MDEP-586
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack-dependencies
>Affects Versions: 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files (x86)\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_111\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Tomas Tulka
>Priority: Major
> Labels: up-for-grabs
> Attachments: pom.xml
>
>
> I have one artifact, in the simplest case only with two resources inside:
> ResourceArtifact-1.0.jar
> /resource1.dat
> /resource2.dat
> I want to unpack one resource into one location and the second in a different
> location, all this with one pom.xml:
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.0.2
>
>
> unpack-resource1
>
> unpack-dependencies
>
>
> ResourceArtifact
> resource1.dat
> resources1
>
>
>
> unpack-resource2
>
> unpack-dependencies
>
>
> ResourceArtifact
> resource2.dat
> resources2
>
>
>
>
> {code}
> When I +*don't*+ use (which makes not so much sense, because in fact there's
> nothing to overwrite):
> {code:xml}
> true
> true
> {code}
> Then I get an info (even not a warning):
> {noformat}
> [INFO] --- maven-dependency-plugin:3.0.2:unpack-dependencies
> (unpack-resource2) @ maven-unpack-same-artifact ---
> [INFO] test:ResourceArtifact:jar:1.0 already exists in destination.
> {noformat}
> And the second resource is not unpacked.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6415) Project Artifacts Cache does not retain the order of classpath entries.
[ https://issues.apache.org/jira/browse/MNG-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6415: Labels: CLASSPATH up-for-grabs (was: CLASSPATH) > Project Artifacts Cache does not retain the order of classpath entries. > --- > > Key: MNG-6415 > URL: https://issues.apache.org/jira/browse/MNG-6415 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.2 > Environment: Windows 7, JDK8u144 >Reporter: Seckin Onur SELAMET >Priority: Major > Labels: CLASSPATH, up-for-grabs > Attachments: > [MNG-6415]_Fixes_Project_Artifact_Cache_classpath_order_retaining_issue_.patch > > > Project artifacts cache does not retain the order of classpath entries. > Wrong Object type used in implementation. HashSet can not guarantee the order > of elements. > In runtime ProjectArtifacts passed as LinkedHashSet already which is safe. > > Possible fix is provided in comments section. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MJAR-254) The fix for MJAR-198 is incomplete: filename conflict not detected
[ https://issues.apache.org/jira/browse/MJAR-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MJAR-254: Labels: up-for-grabs (was: ) > The fix for MJAR-198 is incomplete: filename conflict not detected > -- > > Key: MJAR-254 > URL: https://issues.apache.org/jira/browse/MJAR-254 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Archie Cobbs >Priority: Minor > Labels: up-for-grabs > > See this comment on MJAR-198. > In summary, the build should fail if the actual JAR file would get > overridden, not if the classifier happens to be the same. That is, the > conflict is at the actual filesystem level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569474#comment-16569474
]
Robert Scholte commented on MNG-6261:
-
Comparisson is done in
org.apache.maven.model.building.DefaultModelBuilder.readParent(), and the
following code now returns {{false}} when there's a difference between the
drive letter:
{code}
else
{
/*
* NOTE: This is a sanity check of the cache hit. If the cached
parent POM was locally resolved, the
* child's should point at that parent, too. If
it doesn't, we ignore the cache and
* resolve externally, to mimic the behavior if the cache
didn't exist in the first place. Otherwise,
* the cache would obscure a bad POM.
*/
File pomFile = parentData.getModel().getPomFile();
if ( pomFile != null )
{
ModelSource expectedParentSource = getParentPomFile(
childModel, childSource );
if ( expectedParentSource instanceof ModelSource2
&& !pomFile.toURI().equals( ( (ModelSource2)
expectedParentSource ).getLocationURI() ) )
{
parentData = readParentExternally( childModel, request,
problems );
}
}
}
{code}
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Assignee: Robert Scholte
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6261:
Fix Version/s: 3.6.x-candidate
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Assignee: Robert Scholte
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6261:
Labels: up-for-grabs (was: )
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Assignee: Robert Scholte
>Priority: Minor
> Labels: up-for-grabs
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MNG-6261:
---
Assignee: Robert Scholte
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJLINK-22) Upgrade maven-plugins parent to version 32.
[ https://issues.apache.org/jira/browse/MJLINK-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569433#comment-16569433 ] Hudson commented on MJLINK-22: -- Build succeeded in Jenkins: Maven TLP » maven-jlink-plugin » master #21 See https://builds.apache.org/job/maven-box/job/maven-jlink-plugin/job/master/21/ > Upgrade maven-plugins parent to version 32. > --- > > Key: MJLINK-22 > URL: https://issues.apache.org/jira/browse/MJLINK-22 > Project: Maven JLink Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJLINK-22) Upgrade maven-plugins parent to version 32.
[ https://issues.apache.org/jira/browse/MJLINK-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569431#comment-16569431 ] Karl Heinz Marbaise commented on MJLINK-22: --- Done in [e198f7e127b47efbd7b5882830d23fad19bec1dd|https://gitbox.apache.org/repos/asf?p=maven-jlink-plugin.git;a=commitdiff;h=e198f7e127b47efbd7b5882830d23fad19bec1dd] > Upgrade maven-plugins parent to version 32. > --- > > Key: MJLINK-22 > URL: https://issues.apache.org/jira/browse/MJLINK-22 > Project: Maven JLink Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MJLINK-22) Upgrade maven-plugins parent to version 32.
[ https://issues.apache.org/jira/browse/MJLINK-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MJLINK-22. - Resolution: Done > Upgrade maven-plugins parent to version 32. > --- > > Key: MJLINK-22 > URL: https://issues.apache.org/jira/browse/MJLINK-22 > Project: Maven JLink Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJLINK-22) Upgrade maven-plugins parent to version 32.
Karl Heinz Marbaise created MJLINK-22: - Summary: Upgrade maven-plugins parent to version 32. Key: MJLINK-22 URL: https://issues.apache.org/jira/browse/MJLINK-22 Project: Maven JLink Plugin Issue Type: Dependency upgrade Affects Versions: 3.0.0 Reporter: Karl Heinz Marbaise Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-751) Upgrade maven-shared-components parent to version 32
[ https://issues.apache.org/jira/browse/MSHARED-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569427#comment-16569427 ] Hudson commented on MSHARED-751: Build succeeded in Jenkins: Maven TLP » maven-verifier » master #17 See https://builds.apache.org/job/maven-box/job/maven-verifier/job/master/17/ > Upgrade maven-shared-components parent to version 32 > > > Key: MSHARED-751 > URL: https://issues.apache.org/jira/browse/MSHARED-751 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-verifier >Affects Versions: maven-verifier-3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-verifier-3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MSHARED-751) Upgrade maven-shared-components parent to version 32
[ https://issues.apache.org/jira/browse/MSHARED-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-751. --- Resolution: Done > Upgrade maven-shared-components parent to version 32 > > > Key: MSHARED-751 > URL: https://issues.apache.org/jira/browse/MSHARED-751 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-verifier >Affects Versions: maven-verifier-3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-verifier-3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-751) Upgrade maven-shared-components parent to version 32
[ https://issues.apache.org/jira/browse/MSHARED-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569426#comment-16569426 ] Karl Heinz Marbaise commented on MSHARED-751: - Done in [87996190391e6d9acb1d3df3b29f150d710e516d|https://gitbox.apache.org/repos/asf?p=maven-verifier.git;a=commitdiff;h=87996190391e6d9acb1d3df3b29f150d710e516d] > Upgrade maven-shared-components parent to version 32 > > > Key: MSHARED-751 > URL: https://issues.apache.org/jira/browse/MSHARED-751 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-verifier >Affects Versions: maven-verifier-3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-verifier-3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6454) Introduce option to allow non-pom packaging types to also support the modules-tag
Robert Scholte created MNG-6454:
---
Summary: Introduce option to allow non-pom packaging types to also
support the modules-tag
Key: MNG-6454
URL: https://issues.apache.org/jira/browse/MNG-6454
Project: Maven
Issue Type: New Feature
Reporter: Robert Scholte
While working on the multirelease jars I noticed we're missing a feature in
Maven. At JCrete after talking with [~sanne] he had a similar request for a
different reason. In his case it is about having a jar where all Drivers are
optional, so developers only have to add this jar. However, it would be great
it code could be isolated per Driver.
The idea is to allow packaging:jar to specify modules in the pom. These
submodules follow the normal lifecycle, but are never installed or deployed.
Instead the root-project will embed these files in the main jar.
To support this, Maven first of all recognize if modules are allowed for a
specific packaging type. The
{{org.apache.maven.artifact.handler.ArtifactHandler}} looks close, but that
should be about artifacts (dependencies). So most likely we need a new
ProjectHandler here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (MRELEASE-362) Support tagging nested projects
[
https://issues.apache.org/jira/browse/MRELEASE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reopened MRELEASE-362:
-
Discussed this with [~paranoiabla]
{quote}My current proposal:
the start situation is a folder containing several checked out projects.
the folder contains an aggregator pom, which is NOT under version control.
release:prepare should start as normal, but it should end with a
commit+tag+commit on every checked out folder.
release:perform uses target/checkout, where you copy the aggregator-pom.
And you also check out the projects by tag. Ensure they're using the same
directory-name.
That should be about it. The wording is probably easier compared to the
implementation.
Have a look at project-utils[1]. It should help with determining what kind of
project every pom is.
It hasn't been released yet, but it was written to help the
maven-release-plugin
{quote}
> Support tagging nested projects
> ---
>
> Key: MRELEASE-362
> URL: https://issues.apache.org/jira/browse/MRELEASE-362
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: scm
>Affects Versions: 2.0-beta-6
>Reporter: Michael Johns
>Priority: Minor
>
> We have a non-standard situation here. I can _almost_ get Maven to support
> it, but I can't cross the last hurdle of tagging and releasing the project.
> The business case is that we have a core product that is built with Maven and
> a customer implementation of that product that is also built with Maven.
> Each builds just fine on their own. They are both first-class projects. The
> second project depends on the first. Each project has multiple modules.
> The situation we want to support is parallel development of both projects.
> If a developer makes a change in the Core product, we don't want to have to
> go through a tag/release cycle in order to pull that change into the Customer
> project. (Yes, this is non-standard and not the best idea, but we have few
> options due to time and resources.) To accomplish this, we linked the second
> project into the first using svn:externals. We then created a new profile in
> our pom.xml that pulls in the "parent" pom.xml from the second project as a
> module. Let me see if I can visually represent it:
> Core Product
> - Core Product Module 1
> - Core Product Module 2
> - Core Product Module 3
> - Customer Project <== linked via svn:externals and included as a module
> in the "Core Product" pom.xml via a profile
> - Customer Project Module 1
> - Customer Project Module 2
> - Customer Project Module 3
> Note that the version numbers for the Customer projects are different than
> those in the Core Product.
> This works like a champ when running most plug-ins against it. For example,
> I can run the eclipse plug-in against it (using the special profile), and all
> project dependencies are resolved correctly between the two. The problem
> comes when I try to tag and release them together. This is the command I'm
> using:
> {code}
> mvn -P customer --batch-mode -Darguments="-P customer"
> -DpreparationGoals="jar:test-jar install" -Dresume=false -Dgoals="deploy
> site-deploy" clean install release:prepare release:perform release:clean
> {code}
> The "customer" profile is the one that pulls in the customer projects. This
> command (executed in Continuum) works like a champ to release our other
> projects. But when I run it against this project, here's what happens:
> # Updates versions on all projects (both Core and Customer) to drop SNAPSHOT
> # Installs all projects
> # Tags Core project
> #* Does *not* tag Customer project (*this is the problem*)
> #* Tagged Core project still points to external projects' trunk (this is a
> SVN issue, not a Maven issue)
> # Updates versions on all projects (both Core and Customer) to next SNAPSHOT
> # Checks out tagged project
> #* Project still points to Customer project's trunk (again, a SVN issue)
> # Builds projects
> #* Build fails on external projects because they point to the new SNAPSHOT
> version of main project (due to SVN issue)
> So ignoring the SVN issues, here's what I'd like to see supported by the
> release plug-in:
> * When tagging, also tag the Customer project that is included via a module.
> It is a stand-alone project, so it has all of the necessary information in
> the pom.
> I know this is a bit convoluted, so please let me know if you need
> clarification. I could potentially attach some of our pom files to show how
> our project is set up, but a big part of this is the directory structure
> (which we create using svn:externals, but it doesn't have to be done that
> way), so I'm not sure how useful it would be.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
