[jira] [Created] (MINSTALL-137) Upgrade maven-artifact-transfer to version 0.9.1
Karl Heinz Marbaise created MINSTALL-137: Summary: Upgrade maven-artifact-transfer to version 0.9.1 Key: MINSTALL-137 URL: https://issues.apache.org/jira/browse/MINSTALL-137 Project: Maven Install Plugin Issue Type: Task Affects Versions: 3.0.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MINSTALL-137) Upgrade maven-artifact-transfer to version 0.9.1
[ https://issues.apache.org/jira/browse/MINSTALL-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MINSTALL-137. Resolution: Fixed Done in [r1795355|https://svn.apache.org/r1795355] > Upgrade maven-artifact-transfer to version 0.9.1 > > > Key: MINSTALL-137 > URL: https://issues.apache.org/jira/browse/MINSTALL-137 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MDEPLOY-219) Upgrade maven-artifact-transfer to version 0.9.1
[ https://issues.apache.org/jira/browse/MDEPLOY-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MDEPLOY-219. --- Resolution: Fixed Done in [r1795356|https://svn.apache.org/r1795356] > Upgrade maven-artifact-transfer to version 0.9.1 > > > Key: MDEPLOY-219 > URL: https://issues.apache.org/jira/browse/MDEPLOY-219 > Project: Maven Deploy Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0 > > > The version 0.9.1 of the maven-artifact-transfer contains a [fix for Maven > 3.0|MSHARED-602] which should be part of this release. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6206) We should produce a WARNING by using RELEASE, LATEST as versions
[
https://issues.apache.org/jira/browse/MNG-6206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018383#comment-16018383
]
Karl Heinz Marbaise commented on MNG-6206:
--
Sure if you like go for it
> We should produce a WARNING by using RELEASE, LATEST as versions
>
>
> Key: MNG-6206
> URL: https://issues.apache.org/jira/browse/MNG-6206
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1-candidate, 3.6.0
>
>
> Currently we support the usage of {{LATEST}} and {{RELEASE}} as versions for
> dependencies. We should encourage users to use real versions or if they
> really like use version ranges...
> {code:java}
> public interface Artifact
> extends Comparable
> {
> String RELEASE_VERSION = "RELEASE";
> String LATEST_VERSION = "LATEST";
> {code}
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MNG-6206) We should produce a WARNING by using RELEASE, LATEST as versions
[
https://issues.apache.org/jira/browse/MNG-6206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018383#comment-16018383
]
Karl Heinz Marbaise edited comment on MNG-6206 at 5/20/17 9:33 AM:
---
Sure if you like go for itBut only a single issue which means here only
MNG-6206
was (Author: khmarbaise):
Sure if you like go for it
> We should produce a WARNING by using RELEASE, LATEST as versions
>
>
> Key: MNG-6206
> URL: https://issues.apache.org/jira/browse/MNG-6206
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1-candidate, 3.6.0
>
>
> Currently we support the usage of {{LATEST}} and {{RELEASE}} as versions for
> dependencies. We should encourage users to use real versions or if they
> really like use version ranges...
> {code:java}
> public interface Artifact
> extends Comparable
> {
> String RELEASE_VERSION = "RELEASE";
> String LATEST_VERSION = "LATEST";
> {code}
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6237) Property value during the same build should not change
[
https://issues.apache.org/jira/browse/MNG-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018434#comment-16018434
]
Karl Heinz Marbaise commented on MNG-6237:
--
The first thing which I see in your example project is that you are not using
the mechanisms which are in Maven itself to have a single location to maintain
versions of deps. This means you should use in your root pom:
{code:xml}
org.junit
junit
4.12
test
{code}
In all modules you can now use:
{code:xml}
org.junit
junit
{code}
So if you like to change the version of the junit dependency you only need to
change a single location in the root pom.
And yes it is at the moment not possible to overwrite a property via command
line like the example you have given. Apart from that the title of this issue
should be changed cause the value does not change during the build it is kept
without any modification.
> Property value during the same build should not change
> --
>
> Key: MNG-6237
> URL: https://issues.apache.org/jira/browse/MNG-6237
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.3
>Reporter: Zoltan Haindrich
>
> I've encountered this problem in HIVE-14289.
> But now I know more...and I think I probably understand what's going on.
> Long story short, I would like to override some project property to use a
> different version of a dependency...however using
> {code}
> mvn install -Dhadoop.version=2.8.0
> {code}
> is not enough...that's what I've found out in that ticket.
> The problem is:
> * root project defines a property {{junit.version}}
> * there is a lib project which pulls in a dependency with that property
> * there is an app module which tries to use the lib in some way
> in this setup even thru the developer would like to override the version of
> {{junit.version}}, he can't really do it; because maven references to it
> anyway.
> I've created a samle project in which the root project contains a malformed
> version number; and in case it tries to use it, will end up with an artifact
> resolution error.
> I'm not sure if the problem is within maven or in some of its plugins...
> sample project:
> https://github.com/kgyrtkirk/mng-6237
> sample output:
> https://api.travis-ci.org/jobs/234037973/log.txt?deansi=true
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6206) We should produce a WARNING by using RELEASE, LATEST as versions
[
https://issues.apache.org/jira/browse/MNG-6206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6206:
-
Fix Version/s: (was: 3.5.1-candidate)
(was: 3.6.0)
3.5.1
> We should produce a WARNING by using RELEASE, LATEST as versions
>
>
> Key: MNG-6206
> URL: https://issues.apache.org/jira/browse/MNG-6206
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1
>
>
> Currently we support the usage of {{LATEST}} and {{RELEASE}} as versions for
> dependencies. We should encourage users to use real versions or if they
> really like use version ranges...
> {code:java}
> public interface Artifact
> extends Comparable
> {
> String RELEASE_VERSION = "RELEASE";
> String LATEST_VERSION = "LATEST";
> {code}
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6206) We should produce a WARNING by using RELEASE, LATEST as versions
[
https://issues.apache.org/jira/browse/MNG-6206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MNG-6206:
Assignee: Karl Heinz Marbaise
> We should produce a WARNING by using RELEASE, LATEST as versions
>
>
> Key: MNG-6206
> URL: https://issues.apache.org/jira/browse/MNG-6206
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1
>
>
> Currently we support the usage of {{LATEST}} and {{RELEASE}} as versions for
> dependencies. We should encourage users to use real versions or if they
> really like use version ranges...
> {code:java}
> public interface Artifact
> extends Comparable
> {
> String RELEASE_VERSION = "RELEASE";
> String LATEST_VERSION = "LATEST";
> {code}
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6206) We should produce a WARNING by using RELEASE, LATEST as versions
[
https://issues.apache.org/jira/browse/MNG-6206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041247#comment-16041247
]
Karl Heinz Marbaise commented on MNG-6206:
--
Hi dejan2609, I have merged the change to Maven master.
> We should produce a WARNING by using RELEASE, LATEST as versions
>
>
> Key: MNG-6206
> URL: https://issues.apache.org/jira/browse/MNG-6206
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1
>
>
> Currently we support the usage of {{LATEST}} and {{RELEASE}} as versions for
> dependencies. We should encourage users to use real versions or if they
> really like use version ranges...
> {code:java}
> public interface Artifact
> extends Comparable
> {
> String RELEASE_VERSION = "RELEASE";
> String LATEST_VERSION = "LATEST";
> {code}
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6206) We should produce a WARNING by using RELEASE, LATEST as versions
[
https://issues.apache.org/jira/browse/MNG-6206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNG-6206.
Resolution: Fixed
> We should produce a WARNING by using RELEASE, LATEST as versions
>
>
> Key: MNG-6206
> URL: https://issues.apache.org/jira/browse/MNG-6206
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1
>
>
> Currently we support the usage of {{LATEST}} and {{RELEASE}} as versions for
> dependencies. We should encourage users to use real versions or if they
> really like use version ranges...
> {code:java}
> public interface Artifact
> extends Comparable
> {
> String RELEASE_VERSION = "RELEASE";
> String LATEST_VERSION = "LATEST";
> {code}
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6207) Create WARNINGs in case of using system scope
[
https://issues.apache.org/jira/browse/MNG-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6207:
-
Fix Version/s: (was: 3.5.1-candidate)
(was: 3.6.0)
3.5.1
> Create WARNINGs in case of using system scope
> -
>
> Key: MNG-6207
> URL: https://issues.apache.org/jira/browse/MNG-6207
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1
>
>
> Currently the documentation has already marked the usage of:
> {code:xml}
>
> javax.sql
> jdbc-stdext
> 2.0
> system
> ${java.home}/lib/rt.jar
>
> {code}
> as
> [deprecated|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies].
> So we should start to produce WARNING during a build if someone uses it...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6207) Create WARNINGs in case of using system scope
[
https://issues.apache.org/jira/browse/MNG-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MNG-6207:
Assignee: Karl Heinz Marbaise
> Create WARNINGs in case of using system scope
> -
>
> Key: MNG-6207
> URL: https://issues.apache.org/jira/browse/MNG-6207
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1
>
>
> Currently the documentation has already marked the usage of:
> {code:xml}
>
> javax.sql
> jdbc-stdext
> 2.0
> system
> ${java.home}/lib/rt.jar
>
> {code}
> as
> [deprecated|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies].
> So we should start to produce WARNING during a build if someone uses it...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6207) Create WARNINGs in case of using system scope
[
https://issues.apache.org/jira/browse/MNG-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16045909#comment-16045909
]
Karl Heinz Marbaise commented on MNG-6207:
--
I have get the pull request and had to change the log message to follow our
conventions...so now we need to wait for the integration test results..
> Create WARNINGs in case of using system scope
> -
>
> Key: MNG-6207
> URL: https://issues.apache.org/jira/browse/MNG-6207
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1
>
>
> Currently the documentation has already marked the usage of:
> {code:xml}
>
> javax.sql
> jdbc-stdext
> 2.0
> system
> ${java.home}/lib/rt.jar
>
> {code}
> as
> [deprecated|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies].
> So we should start to produce WARNING during a build if someone uses it...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6216) IndexArrayOutOfBounds when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16045910#comment-16045910 ] Karl Heinz Marbaise commented on MNG-6216: -- If I correctly analysed that via the commit [0e7e3eeb597b92f1394b24e33d5933e995ee8104|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0e7e3eeb597b92f1394b24e33d5933e995ee8104] where modello has been upgraded to 1.9.1 this issue should be fixed as well. > IndexArrayOutOfBounds when parsing POM > --- > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6216) IndexArrayOutOfBounds when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6216: - Fix Version/s: (was: 3.5.1-candidate) 3.5.1 > IndexArrayOutOfBounds when parsing POM > --- > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (MNG-6216) IndexArrayOutOfBounds when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16045910#comment-16045910 ] Karl Heinz Marbaise edited comment on MNG-6216 at 6/11/17 11:37 AM: If I correctly analysed that. This issue has been already fixed by the commit [0e7e3eeb597b92f1394b24e33d5933e995ee8104|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0e7e3eeb597b92f1394b24e33d5933e995ee8104] where modello has been upgraded to 1.9.1. was (Author: khmarbaise): If I correctly analysed that via the commit [0e7e3eeb597b92f1394b24e33d5933e995ee8104|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0e7e3eeb597b92f1394b24e33d5933e995ee8104] where modello has been upgraded to 1.9.1 this issue should be fixed as well. > IndexArrayOutOfBounds when parsing POM > --- > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MNG-6216) IndexArrayOutOfBounds when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise resolved MNG-6216. -- Resolution: Fixed > IndexArrayOutOfBounds when parsing POM > --- > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6216) IndexArrayOutOfBounds when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16045913#comment-16045913 ] Karl Heinz Marbaise commented on MNG-6216: -- Do we need to change plexus-utils for that? > IndexArrayOutOfBounds when parsing POM > --- > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MNG-6216) IndexArrayOutOfBounds when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reopened MNG-6216: -- > IndexArrayOutOfBounds when parsing POM > --- > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MNG-6207) Create WARNINGs in case of using system scope
[
https://issues.apache.org/jira/browse/MNG-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNG-6207.
Resolution: Fixed
Done with
[12d6471337c7ad067b7762d44050a079829ea26c|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=12d6471337c7ad067b7762d44050a079829ea26c]
> Create WARNINGs in case of using system scope
> -
>
> Key: MNG-6207
> URL: https://issues.apache.org/jira/browse/MNG-6207
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1
>
>
> Currently the documentation has already marked the usage of:
> {code:xml}
>
> javax.sql
> jdbc-stdext
> 2.0
> system
> ${java.home}/lib/rt.jar
>
> {code}
> as
> [deprecated|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies].
> So we should start to produce WARNING during a build if someone uses it...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5820) Allow extensions in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16046765#comment-16046765
]
Karl Heinz Marbaise commented on MNG-5820:
--
Having an extensions entry in your {{settings.xml}} can only being read by a
version which supports this. All earlier versions would fail with that This
means breaking backwards compatibility.
> Allow extensions in settings.xml
>
>
> Key: MNG-5820
> URL: https://issues.apache.org/jira/browse/MNG-5820
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.3.1
>Reporter: Yuri
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
>
> Since 3.3.1, we are now allowed to specify extensions in the
> projectBaseDir/.mvn/extensions.xml. This is great on it's own, but I have a
> case where repo urls are externalized to ~/.m2/settings.xml and these urls
> require an extension. Right now, the url and the extension that goes along
> with it are managed in two completely different places.
> Ideally, I would like to see the option to add an extension to our existing
> ~/.m2/settings.xml.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MSHARED-639) Removed prerequisites cause it is not a plugin
Karl Heinz Marbaise created MSHARED-639:
---
Summary: Removed prerequisites cause it is not a plugin
Key: MSHARED-639
URL: https://issues.apache.org/jira/browse/MSHARED-639
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-shared-utils
Affects Versions: maven-shared-utils-3.2.0
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
Priority: Trivial
Fix For: maven-shared-utils-3.2.0
Remove the entry:
{code:xml}
${mavenVersion}
{code}
cause this is no plugin. Maven 3.5.0 produces a warning.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MSHARED-639) Removed prerequisites cause it is not a plugin
[
https://issues.apache.org/jira/browse/MSHARED-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MSHARED-639.
---
Resolution: Fixed
Done in [r1798627|https://svn.apache.org/r1798627]
> Removed prerequisites cause it is not a plugin
> --
>
> Key: MSHARED-639
> URL: https://issues.apache.org/jira/browse/MSHARED-639
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-shared-utils
>Affects Versions: maven-shared-utils-3.2.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Trivial
> Fix For: maven-shared-utils-3.2.0
>
>
> Remove the entry:
> {code:xml}
>
> ${mavenVersion}
>
> {code}
> cause this is no plugin. Maven 3.5.0 produces a warning.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MDEP-571) JDK9: Issue with list goal fails with java.lang.NoSuchMethodException
Karl Heinz Marbaise created MDEP-571:
Summary: JDK9: Issue with list goal fails with
java.lang.NoSuchMethodException
Key: MDEP-571
URL: https://issues.apache.org/jira/browse/MDEP-571
Project: Maven Dependency Plugin
Issue Type: Bug
Environment: Apache Maven 3.5.0
(ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
Maven home: /usr/local/maven
Java version: 9-ea, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.9.0_ea+174.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
Reporter: Karl Heinz Marbaise
Priority: Blocker
Calling:
{{mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.1:list}}
Fails with the following:
{code}
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] parent
[INFO] domain
[INFO] service-client
[INFO] webgui
[INFO] service
[INFO] app
[INFO] appasm
[INFO] shade
[INFO] assembly
[INFO]
[INFO]
[INFO] Building parent 3.4.6-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:3.0.1:list (default-cli) @ parent ---
[INFO]
[INFO] The following files have been resolved:
[INFO]none
[INFO]
[INFO]
[INFO]
[INFO] Building domain 3.4.6-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:3.0.1:list (default-cli) @ domain ---
java.lang.NoSuchMethodException:
jdk.internal.module.ModuleReferenceImpl.descriptor()
at java.base/java.lang.Class.getDeclaredMethod(Class.java:2451)
at
org.apache.maven.plugins.dependency.utils.DependencyStatusSets.getModuleDescriptor(DependencyStatusSets.java:272)
at
org.apache.maven.plugins.dependency.utils.DependencyStatusSets.buildArtifactListOutput(DependencyStatusSets.java:227)
at
org.apache.maven.plugins.dependency.utils.DependencyStatusSets.getOutput(DependencyStatusSets.java:165)
at
org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute(ResolveDependenciesMojo.java:90)
at
org.apache.maven.plugins.dependency.AbstractDependencyMojo.execute(AbstractDependencyMojo.java:143)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[INFO]
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MDEP-571) JDK9: Issue with list goal fails with java.lang.NoSuchMethodException
[
https://issues.apache.org/jira/browse/MDEP-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MDEP-571:
-
Affects Version/s: 3.0.1
> JDK9: Issue with list goal fails with java.lang.NoSuchMethodException
> -
>
> Key: MDEP-571
> URL: https://issues.apache.org/jira/browse/MDEP-571
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /usr/local/maven
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.9.0_ea+174.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
>
> Calling:
> {{mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.1:list}}
> Fails with the following:
> {code}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] parent
> [INFO] domain
> [INFO] service-client
> [INFO] webgui
> [INFO] service
> [INFO] app
> [INFO] appasm
> [INFO] shade
> [INFO] assembly
> [INFO]
> [INFO]
>
> [INFO] Building parent 3.4.6-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:3.0.1:list (default-cli) @ parent ---
> [INFO]
> [INFO] The following files have been resolved:
> [INFO]none
> [INFO]
> [INFO]
> [INFO]
>
> [INFO] Building domain 3.4.6-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:3.0.1:list (default-cli) @ domain ---
> java.lang.NoSuchMethodException:
> jdk.internal.module.ModuleReferenceImpl.descriptor()
> at java.base/java.lang.Class.getDeclaredMethod(Class.java:2451)
> at
> org.apache.maven.plugins.dependency.utils.DependencyStatusSets.getModuleDescriptor(DependencyStatusSets.java:272)
> at
> org.apache.maven.plugins.dependency.utils.DependencyStatusSets.buildArtifactListOutput(DependencyStatusSets.java:227)
> at
> org.apache.maven.plugins.dependency.utils.DependencyStatusSets.getOutput(DependencyStatusSets.java:165)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute(ResolveDependenciesMojo.java:90)
> at
> org.apache.maven.plugins.dependency.AbstractDependencyMojo.execute(AbstractDependencyMojo.java:143)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launch
[jira] [Commented] (MASSEMBLY-855) Remote repositories ignored in a multi-module project
[
https://issues.apache.org/jira/browse/MASSEMBLY-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052292#comment-16052292
]
Karl Heinz Marbaise commented on MASSEMBLY-855:
---
I assume the jboss repository contains only releases so the configuration:
{code}
true
never
{code}
looks wrong to me?
> Remote repositories ignored in a multi-module project
> -
>
> Key: MASSEMBLY-855
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-855
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 3.0.0
>Reporter: John Farrelly
> Attachments: test-parent.tar.gz
>
>
> I have attached a small multi-module project to demonstrate the behaviour.
> I have a {{test-parent}} project with a child module, {{test-child}}.
> I have defined a repositories section in {{test-parent}}:
> {code:xml}
>
>
> jboss-public-repository-group
> JBoss Public Maven Repository Group
>
> https://repository.jboss.org/nexus/content/groups/public-jboss/
> default
>
> true
> never
>
>
> true
> never
>
>
>
> {code}
> I have defined the executing of {{maven-assembly-plugin}} in
> {{test-child/pom.xml}}:
> {code:xml}
>
> maven-assembly-plugin
> 3.0.0
>
>
> src/assembly/repository.xml
>
>
>
>
> create-repository
> package
>
> single
>
>
>
>
> {code}
> When I run {{mvn clean package}} from {{test-child}}, I can see that it is
> using {{repository.jboss.org}} to resolve dependencies:
> {noformat}
> [test-parent/test-child] $ mvn clean package
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building test-child 1.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-child ---
> [INFO]
> [INFO] --- maven-assembly-plugin:3.0.0:single (create-repository) @
> test-child ---
> [INFO] Reading assembly descriptor: src/assembly/repository.xml
> Downloading:
> https://repository.jboss.org/nexus/content/groups/public-jboss/org/jboss/spec/javax/servlet/jboss-servlet-api_3.0_spec/1.0.0.Beta2/jboss-servlet-api_3.0_spec-1.0.0.Beta2.pom
> {noformat}
> However, if I run {{mvn clean package}} from the parent project
> {{test-parent}}, it will only try to resolve dependencies from maven central,
> ignoring all repository settings:
> {noformat}
> [test-parent] $ mvn clean package
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] test-parent
> [INFO] test-child
> [INFO]
>
> [INFO]
>
> [INFO] Building test-parent 1.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-parent ---
> [INFO]
>
> [INFO]
>
> [INFO] Building test-child 1.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-child ---
> [INFO] Deleting /media/sf_SharedFolder/Temp/test-parent/test-child/target
> [INFO]
> [INFO] --- maven-assembly-plugin:3.0.0:single (create-repository) @
> test-child ---
> [INFO] Reading assembly descriptor: src/assembly/repository.xml
> Downloading:
> https://repo.maven.apache.org/maven2/org/jboss/spec/javax/servlet/jboss-servlet-api_3.0_spec/1.0.0.Beta2/jboss-servlet-api_3.0_spec-1.0.0.Beta2.pom
> {noformat}
> This causes issues for us when we reference dependencies that don't exist in
> maven central.
> {panel:title=Note|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> I am using maven version 3.3.3
> {panel}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-853) jar which are not transitive is not excluding.
[ https://issues.apache.org/jira/browse/MASSEMBLY-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052299#comment-16052299 ] Karl Heinz Marbaise commented on MASSEMBLY-853: --- Can you provide a full working example? > jar which are not transitive is not excluding. > -- > > Key: MASSEMBLY-853 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-853 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.4, 3.0.0 >Reporter: S Boot > > So here is the thing what I am trying is : > I have parent pom and I am using maven-assembly-plugin in that like below. > > maven-assembly-plugin > > > > > src/main/assembly/domainApi.xml > > > > > dist-assembly > package > > single > > > > > I also have assembley file which is listed below. > > domainApi > > jar > > > false > > > > target/classes/com/cac/customer/api > . > > *.class > > > > > > > > false > > false > false > false > > > > > Now while building assembley jar I am getting only .class file which I want > exactly and pushing this jar > to nexus. > While using this jar with below notation it also download some other jar > which is not detect by > Please suggest whats the way to exclude parent jar which are not > TransitiveDependencies. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[
https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052312#comment-16052312
]
Karl Heinz Marbaise commented on MASSEMBLY-848:
---
Using the following in your assembly descriptor should work:
{code:xml}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
distribution
${project.name}-${project.version}
zip
true
false
lib
false
false
false
{code}
> Version range dependencies not resolved from the reactor
>
>
> Key: MASSEMBLY-848
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-848
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.3.9
> (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 2015-11-23T10:17:27+00:00)
> Maven home: /opt/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.8.13-1-arch", arch: "amd64", family: "unix"
>Reporter: Mark Raynsford
> Attachments: mvn.log.gz
>
>
> When using modules that have independent version numbers (that is, modules in
> the same project may have different version numbers), it's commonplace to
> specify dependencies between modules with version ranges when using semantic
> versioning.
> For some reason, when version ranges are used on dependencies that refer to
> modules that are part of the project (and therefore should be in the
> reactor), the assembly plugin ignores them and tries to resolve them from the
> local repository instead.
> The following project reproduces this issue (just "mvn clean package"):
> https://github.com/io7m/independent-versioning-20170207
> Interestingly, this didn't happen with the same assembly plugin on older
> Maven versions. Here's a successful build on Travis CI:
> https://travis-ci.org/io7m/independent-versioning-20170207
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[
https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052312#comment-16052312
]
Karl Heinz Marbaise edited comment on MASSEMBLY-848 at 6/17/17 11:00 AM:
-
Using the following in your assembly descriptor works:
{code:xml}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
distribution
${project.name}-${project.version}
zip
true
false
lib
false
false
false
{code}
was (Author: khmarbaise):
Using the following in your assembly descriptor should work:
{code:xml}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
distribution
${project.name}-${project.version}
zip
true
false
lib
false
false
false
{code}
> Version range dependencies not resolved from the reactor
>
>
> Key: MASSEMBLY-848
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-848
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.3.9
> (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 2015-11-23T10:17:27+00:00)
> Maven home: /opt/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.8.13-1-arch", arch: "amd64", family: "unix"
>Reporter: Mark Raynsford
> Attachments: mvn.log.gz
>
>
> When using modules that have independent version numbers (that is, modules in
> the same project may have different version numbers), it's commonplace to
> specify dependencies between modules with version ranges when using semantic
> versioning.
> For some reason, when version ranges are used on dependencies that refer to
> modules that are part of the project (and therefore should be in the
> reactor), the assembly plugin ignores them and tries to resolve them from the
> local repository instead.
> The following project reproduces this issue (just "mvn clean package"):
> https://github.com/io7m/independent-versioning-20170207
> Interestingly, this didn't happen with the same assembly plugin on older
> Maven versions. Here's a successful build on Travis CI:
> https://travis-ci.org/io7m/independent-versioning-20170207
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-856) Ability to overwrite existing files
[
https://issues.apache.org/jira/browse/MASSEMBLY-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052800#comment-16052800
]
Karl Heinz Marbaise commented on MASSEMBLY-856:
---
Can you offer a full working example please...maybe put on Github or attached
to this JIRA ticket...
> Ability to overwrite existing files
> ---
>
> Key: MASSEMBLY-856
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-856
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.2-beta-5, 2.5.4, 3.0.0
>Reporter: Kamal Mettananda
> Labels: features
>
> This is a request to add element to in assembly file.
> Currently, it is not possible to overwrite the already existing files inside
> the expected archive with new files.
> e.g.:
> Expectation of below assembly file is to have the conf.properties file in
> dir2 after the zip file is generated.
> {code:xml}
>
> dist
>
> zip
>
> false
>
>
>
> dir1
> release
>
>
>
> dir2
> release
> true
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[
https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052312#comment-16052312
]
Karl Heinz Marbaise edited comment on MASSEMBLY-848 at 6/17/17 11:07 AM:
-
Using the following in your assembly descriptor works:
{code:xml}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
distribution
${project.name}-${project.version}
zip
true
false
lib
false
false
false
{code}
Added [working
example|https://github.com/khmarbaise/massembly/tree/master/massembly-848].
was (Author: khmarbaise):
Using the following in your assembly descriptor works:
{code:xml}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
distribution
${project.name}-${project.version}
zip
true
false
lib
false
false
false
{code}
> Version range dependencies not resolved from the reactor
>
>
> Key: MASSEMBLY-848
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-848
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.3.9
> (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 2015-11-23T10:17:27+00:00)
> Maven home: /opt/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.8.13-1-arch", arch: "amd64", family: "unix"
>Reporter: Mark Raynsford
> Attachments: mvn.log.gz
>
>
> When using modules that have independent version numbers (that is, modules in
> the same project may have different version numbers), it's commonplace to
> specify dependencies between modules with version ranges when using semantic
> versioning.
> For some reason, when version ranges are used on dependencies that refer to
> modules that are part of the project (and therefore should be in the
> reactor), the assembly plugin ignores them and tries to resolve them from the
> local repository instead.
> The following project reproduces this issue (just "mvn clean package"):
> https://github.com/io7m/independent-versioning-20170207
> Interestingly, this didn't happen with the same assembly plugin on older
> Maven versions. Here's a successful build on Travis CI:
> https://travis-ci.org/io7m/independent-versioning-20170207
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient
[
https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052801#comment-16052801
]
Karl Heinz Marbaise commented on MASSEMBLY-845:
---
It is not prevented to use:
{code:xml}
ToWhatEverYouLike
...
{code}
This only changes the name of the resulting artifact in the target folder
nothing more...
To be honest I don't see a real issue here?
> MASSEMBLY-817 makes some usecases very inconvenient
> ---
>
> Key: MASSEMBLY-845
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-845
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>
> The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient:
> We need to create an archive with one stable name (independent of e.g.
> version) so we don't have to propagate these information to a bunch of
> scripts.
> The general solution (i.e. Stack-overflow) refers exactly to the finalName:
> [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin]
> *Please change finalName back to a settable property.*
> It being settable does not hurt anyone satisfied with the default naming
> convention but makes some usecases vastly simpler (otherwise you have to
> rename the artifact using yet another plugin or propagate version info
> possibly through a chain of scripts)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated
[ https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MASSEMBLY-843: - Assignee: Karl Heinz Marbaise > finalName as readonly parameter makes common usecases very complicated > -- > > Key: MASSEMBLY-843 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-843 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer >Assignee: Karl Heinz Marbaise > > The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient: > We need to create an archive with one stable name (independent of e.g. > version) so we don't have to propagate these information to a bunch of > scripts. > The general solution (i.e. Stack-overflow) refers exactly to the finalName: > [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin] > *Please change finalName back to a settable property.* > It being settable does not hurt anyone satisfied with the default naming > convention but makes some usecases vastly simpler (otherwise you have to > rename the artifact using yet another plugin or propagate version info > possibly through a chain of scripts) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated
[ https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MASSEMBLY-843: - Assignee: (was: Karl Heinz Marbaise) > finalName as readonly parameter makes common usecases very complicated > -- > > Key: MASSEMBLY-843 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-843 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer > > The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient: > We need to create an archive with one stable name (independent of e.g. > version) so we don't have to propagate these information to a bunch of > scripts. > The general solution (i.e. Stack-overflow) refers exactly to the finalName: > [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin] > *Please change finalName back to a settable property.* > It being settable does not hurt anyone satisfied with the default naming > convention but makes some usecases vastly simpler (otherwise you have to > rename the artifact using yet another plugin or propagate version info > possibly through a chain of scripts) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052825#comment-16052825 ] Karl Heinz Marbaise commented on MASSEMBLY-848: --- The original example does not work on Maven 3.0.5, 3.1.1, 3.2.5, 3.3.9 and 3.5.0. It is independent of the Maven version. The same output on all Maven versions. The problem is related to a wrong assumption, cause a dependencySet is something different than a moduleSet. In this case it is related to the moduleSet. And at the moment I don't see that there is an issue... > Version range dependencies not resolved from the reactor > > > Key: MASSEMBLY-848 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-848 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 > Environment: Apache Maven 3.3.9 > (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 2015-11-23T10:17:27+00:00) > Maven home: /opt/maven > Java version: 1.8.0_121, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-8-openjdk/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux", version: "4.8.13-1-arch", arch: "amd64", family: "unix" >Reporter: Mark Raynsford > Attachments: mvn.log.gz > > > When using modules that have independent version numbers (that is, modules in > the same project may have different version numbers), it's commonplace to > specify dependencies between modules with version ranges when using semantic > versioning. > For some reason, when version ranges are used on dependencies that refer to > modules that are part of the project (and therefore should be in the > reactor), the assembly plugin ignores them and tries to resolve them from the > local repository instead. > The following project reproduces this issue (just "mvn clean package"): > https://github.com/io7m/independent-versioning-20170207 > Interestingly, this didn't happen with the same assembly plugin on older > Maven versions. Here's a successful build on Travis CI: > https://travis-ci.org/io7m/independent-versioning-20170207 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[
https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052859#comment-16052859
]
Karl Heinz Marbaise commented on MASSEMBLY-848:
---
I have taken the above link to github and cloned that and tested that with each
Maven version which failed (I used {{mvn clean package}})...The point here is
that you have used {{mvn install}} instead of {{mvn package}} which is
something different.
If you do a {{mvn install}} each module of that multi module build will be
iterated over. The first one will do the life cycle including installing the
artifact into local cache {{$HOME/.m2/repository}} the next module etc. and so
until the last module {{mod-c}} which has the maven-assembly-plugin
configuration which now resolves the dependencies from the local cache which
works. This will work with all Maven versions cause it's independent of the
Maven version.
If you like to do {{mvn clean package}} that will fail for all Maven versions
cause they are not solved from the reactor only if artifacts have the same
version this will work...
I never use {{mvn clean install}} on multi module builds. I always use {{mvn
clean package}}...and that's the issue here. The resolution will not work for
those dependencies from the reactor cause they have different version numbers
and they will be tried to resolve from remote repository in which they did not
exist...If you use the example I have shown this will work also with {{mvn
clean package}}...
> Version range dependencies not resolved from the reactor
>
>
> Key: MASSEMBLY-848
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-848
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.3.9
> (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 2015-11-23T10:17:27+00:00)
> Maven home: /opt/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.8.13-1-arch", arch: "amd64", family: "unix"
>Reporter: Mark Raynsford
> Attachments: mvn.log.gz
>
>
> When using modules that have independent version numbers (that is, modules in
> the same project may have different version numbers), it's commonplace to
> specify dependencies between modules with version ranges when using semantic
> versioning.
> For some reason, when version ranges are used on dependencies that refer to
> modules that are part of the project (and therefore should be in the
> reactor), the assembly plugin ignores them and tries to resolve them from the
> local repository instead.
> The following project reproduces this issue (just "mvn clean package"):
> https://github.com/io7m/independent-versioning-20170207
> Interestingly, this didn't happen with the same assembly plugin on older
> Maven versions. Here's a successful build on Travis CI:
> https://travis-ci.org/io7m/independent-versioning-20170207
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MSHARED-642) Upgrade to maven-shared-utils 3.2.0
Karl Heinz Marbaise created MSHARED-642: --- Summary: Upgrade to maven-shared-utils 3.2.0 Key: MSHARED-642 URL: https://issues.apache.org/jira/browse/MSHARED-642 Project: Maven Shared Components Issue Type: Improvement Components: maven-reporting-impl Affects Versions: maven-reporting-impl 3.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor Fix For: maven-reporting-impl 3.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MSHARED-642) Upgrade to maven-shared-utils 3.2.0
[ https://issues.apache.org/jira/browse/MSHARED-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-642. --- Resolution: Fixed Done in [r1799070|https://svn.apache.org/r1799070] > Upgrade to maven-shared-utils 3.2.0 > --- > > Key: MSHARED-642 > URL: https://issues.apache.org/jira/browse/MSHARED-642 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-impl >Affects Versions: maven-reporting-impl 3.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-reporting-impl 3.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSHARED-643) Upgrade to maven-shared-utils 3.2.0
Karl Heinz Marbaise created MSHARED-643: --- Summary: Upgrade to maven-shared-utils 3.2.0 Key: MSHARED-643 URL: https://issues.apache.org/jira/browse/MSHARED-643 Project: Maven Shared Components Issue Type: Improvement Components: maven-archiver Affects Versions: maven-archiver-3.1.2 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor Fix For: maven-archiver-3.1.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MSHARED-643) Upgrade to maven-shared-utils 3.2.0
[ https://issues.apache.org/jira/browse/MSHARED-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-643. --- Resolution: Fixed Done in [r1799071|https://svn.apache.org/r1799071] > Upgrade to maven-shared-utils 3.2.0 > --- > > Key: MSHARED-643 > URL: https://issues.apache.org/jira/browse/MSHARED-643 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-archiver >Affects Versions: maven-archiver-3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-archiver-3.1.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSHARED-644) Removed prerequisites from non maven-plugin project
Karl Heinz Marbaise created MSHARED-644: --- Summary: Removed prerequisites from non maven-plugin project Key: MSHARED-644 URL: https://issues.apache.org/jira/browse/MSHARED-644 Project: Maven Shared Components Issue Type: Improvement Components: maven-archiver Affects Versions: maven-archiver-3.1.2 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor Fix For: maven-archiver-3.1.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSHARED-644) Removed prerequisites for none maven-plugin project
[ https://issues.apache.org/jira/browse/MSHARED-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-644: Summary: Removed prerequisites for none maven-plugin project (was: Removed prerequisites from non maven-plugin project) > Removed prerequisites for none maven-plugin project > --- > > Key: MSHARED-644 > URL: https://issues.apache.org/jira/browse/MSHARED-644 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-archiver >Affects Versions: maven-archiver-3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-archiver-3.1.2 > > > Usage of prerequisites for non maven-plugin projects is deprecated MNG-5297, > MNG-6092 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSHARED-644) Removed prerequisites from non maven-plugin project
[ https://issues.apache.org/jira/browse/MSHARED-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-644: Description: Usage of prerequisites for non maven-plugin projects is deprecated MNG-5297, MNG-6092 > Removed prerequisites from non maven-plugin project > --- > > Key: MSHARED-644 > URL: https://issues.apache.org/jira/browse/MSHARED-644 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-archiver >Affects Versions: maven-archiver-3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-archiver-3.1.2 > > > Usage of prerequisites for non maven-plugin projects is deprecated MNG-5297, > MNG-6092 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MSHARED-644) Removed prerequisites for none maven-plugin project
[ https://issues.apache.org/jira/browse/MSHARED-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-644. --- Resolution: Fixed Done in [r1799072|https://svn.apache.org/r1799072] > Removed prerequisites for none maven-plugin project > --- > > Key: MSHARED-644 > URL: https://issues.apache.org/jira/browse/MSHARED-644 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-archiver >Affects Versions: maven-archiver-3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-archiver-3.1.2 > > > Usage of prerequisites for non maven-plugin projects is deprecated MNG-5297, > MNG-6092 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MSHARED-645) Upgrade to maven-shared-utils 3.2.0
[ https://issues.apache.org/jira/browse/MSHARED-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-645. --- Resolution: Fixed Done in [r1799073|https://svn.apache.org/r1799073] > Upgrade to maven-shared-utils 3.2.0 > --- > > Key: MSHARED-645 > URL: https://issues.apache.org/jira/browse/MSHARED-645 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-filtering-3.1.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSHARED-645) Upgrade to maven-shared-utils 3.2.0
Karl Heinz Marbaise created MSHARED-645: --- Summary: Upgrade to maven-shared-utils 3.2.0 Key: MSHARED-645 URL: https://issues.apache.org/jira/browse/MSHARED-645 Project: Maven Shared Components Issue Type: Improvement Components: maven-filtering Affects Versions: maven-filtering-3.1.2 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor Fix For: maven-filtering-3.1.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSHARED-646) Removed prerequisites for none maven-plugin project
Karl Heinz Marbaise created MSHARED-646: --- Summary: Removed prerequisites for none maven-plugin project Key: MSHARED-646 URL: https://issues.apache.org/jira/browse/MSHARED-646 Project: Maven Shared Components Issue Type: Improvement Components: maven-filtering Affects Versions: maven-filtering-3.1.2 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor Fix For: maven-filtering-3.1.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MSHARED-646) Removed prerequisites for none maven-plugin project
[ https://issues.apache.org/jira/browse/MSHARED-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-646. --- Resolution: Fixed Done in [r1799074|https://svn.apache.org/r1799074] > Removed prerequisites for none maven-plugin project > --- > > Key: MSHARED-646 > URL: https://issues.apache.org/jira/browse/MSHARED-646 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-filtering-3.1.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MNG-6244) Cannot build project sub-module when property is used for project version
[
https://issues.apache.org/jira/browse/MNG-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNG-6244.
Resolution: Not A Problem
Assignee: Karl Heinz Marbaise
It's good that you already found the solution. The documentation says
explicitly so https://maven.apache.org/maven-ci-friendly.html
The point is if you do an install without Flatten-Maven-Plugin of such pom's
which contain {{${revision}}} the installed pom in local repository
keep containing {{${revision}}} which means Maven can't solve them...
> Cannot build project sub-module when property is used for project version
> --
>
> Key: MNG-6244
> URL: https://issues.apache.org/jira/browse/MNG-6244
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Bogdan Ilchyshyn
>Assignee: Karl Heinz Marbaise
> Attachments: clean-install-root.log, clean-install-submodule.log,
> sources.tar.gz
>
>
> Consider simple multi-module project (see [^sources.tar.gz]):
> {noformat}
> parent/pom.xml
> parent/module-a
> parent/module-b
> {noformat}
> {{parent}} has defined project version via property {{revision}}:
> {code:xml}
> ${revision}
>
>
> 1.0.0-SNAPSHOT
>
> {code}
> Both sub-modules ({{module-a}} and {{module-b}}) define parent versions via
> this property:
> {code:xml}
>
> test
> parent
> ${revision}
>
> {code}
> Sub-module {{module-b}} has a dependency to {{module-a}}:
> {code:xml}
>
> test
> module-a
> ${project.version}
>
> {code}
> The project is built successfully from the root (see
> [^clean-install-root.log] for build log).
> Also there is no problem to build {{module-a}} independently (i.e. {{cd
> module-a && mvn clean install}}).
> But when trying to build {{module-b}} (i.e. {{cd module-b && mvn clean
> install}}), build fails (see [^clean-install-submodule.log]):
> {noformat}
> [ERROR] Failed to execute goal on project module-b: Could not resolve
> dependencies for project test:module-b:jar:1.0.0-SNAPSHOT: Failed to collect
> dependencies at test:module-a:jar:1.0.0-SNAPSHOT: Failed to read artifact
> descriptor for test:module-a:jar:1.0.0-SNAPSHOT: Could not find artifact
> test:parent:pom:${revision} in central (https://repo.maven.apache.org/maven2)
> -> [Help 1]
> {noformat}
> Changing {{$\{project.version\}}} directly to {{$\{revision\}}} produces the
> same output.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MNG-6249) Pluggin requires Maven version 3.0
[ https://issues.apache.org/jira/browse/MNG-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNG-6249. Resolution: Not A Problem > Pluggin requires Maven version 3.0 > -- > > Key: MNG-6249 > URL: https://issues.apache.org/jira/browse/MNG-6249 > Project: Maven > Issue Type: Question >Reporter: Justin Doh > > I am trying to write command line to install Maven version 3.0. > What do I need to type? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6249) Pluggin requires Maven version 3.0
[ https://issues.apache.org/jira/browse/MNG-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071565#comment-16071565 ] Karl Heinz Marbaise commented on MNG-6249: -- This is not a support forum. If you have question please ask on the users mailing list > Pluggin requires Maven version 3.0 > -- > > Key: MNG-6249 > URL: https://issues.apache.org/jira/browse/MNG-6249 > Project: Maven > Issue Type: Question >Reporter: Justin Doh > > I am trying to write command line to install Maven version 3.0. > What do I need to type? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6253) Replace CI friendly variables in pom.xml when installing/deploying
[
https://issues.apache.org/jira/browse/MNG-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080856#comment-16080856
]
Karl Heinz Marbaise commented on MNG-6253:
--
The [referenced documentation already contains the
necessary|https://maven.apache.org/maven-ci-friendly.html#Install__Deploy]
information how to do it correctly.
> Replace CI friendly variables in pom.xml when installing/deploying
> --
>
> Key: MNG-6253
> URL: https://issues.apache.org/jira/browse/MNG-6253
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Christoph Amshoff
>
> When using variables in pom.xml to get CI friendly version
> (https://maven.apache.org/maven-ci-friendly.html), these will not be replaced
> in installed or deployed pom files, which makes them unusable for other
> builds.
> Karl Heinz Marbaise suggested to use the flatten-maven-plugin to do the
> property replacement
> (http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/),
> and this was also suggested as a workaround in other tickets (MDEPLOY-223
> got closed with "Not A Problem" solution).
> That indeed works, but flatten-maven-plugin has to be manually configured in
> the base POM, and additionally it changes the pom files in many other areas
> which you would not want.
> I honestly think that property replacement for the three allowed properties
> ({{$\{revision\}}}, {{$\{sha1\}}}, {{$\{changelist\}}}) should be done by
> Maven internally without having the user configure other plugins. The feature
> is just not correctly working without, so closing such issues with "Not A
> Problem" is too little.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6253) Replace CI friendly variables in pom.xml when installing/deploying
[
https://issues.apache.org/jira/browse/MNG-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6253:
-
Issue Type: Improvement (was: Bug)
> Replace CI friendly variables in pom.xml when installing/deploying
> --
>
> Key: MNG-6253
> URL: https://issues.apache.org/jira/browse/MNG-6253
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Christoph Amshoff
>
> When using variables in pom.xml to get CI friendly version
> (https://maven.apache.org/maven-ci-friendly.html), these will not be replaced
> in installed or deployed pom files, which makes them unusable for other
> builds.
> Karl Heinz Marbaise suggested to use the flatten-maven-plugin to do the
> property replacement
> (http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/),
> and this was also suggested as a workaround in other tickets (MDEPLOY-223
> got closed with "Not A Problem" solution).
> That indeed works, but flatten-maven-plugin has to be manually configured in
> the base POM, and additionally it changes the pom files in many other areas
> which you would not want.
> I honestly think that property replacement for the three allowed properties
> ({{$\{revision\}}}, {{$\{sha1\}}}, {{$\{changelist\}}}) should be done by
> Maven internally without having the user configure other plugins. The feature
> is just not correctly working without, so closing such issues with "Not A
> Problem" is too little.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6265) Controlling reactor order of modules
[
https://issues.apache.org/jira/browse/MNG-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16105454#comment-16105454
]
Karl Heinz Marbaise commented on MNG-6265:
--
Tests are running on each module and not on a reactor base or do you mean the
tests in different modules? Furthermore what do you mean by {{mvn install
-DskipTests; mvn test}} ? Is the reactor order different from the {{mvn
install..}} than from {{mvn test}} after ? The order of running tests within
the modules can be controlled by use the option {{-Dsurefire.runOrder...}} as
you mentioned...
Do you have defined correct dependencies between your modules in your reactor ?
It sounds like you didn't? Cause the reactor order is defined by the
dependencies...?Can you give a concrete example ? What is the real problem you
are trying to solve?
> Controlling reactor order of modules
>
>
> Key: MNG-6265
> URL: https://issues.apache.org/jira/browse/MNG-6265
> Project: Maven
> Issue Type: New Feature
> Components: core
>Affects Versions: 3.5.0
>Reporter: August Shi
> Attachments: p.patch
>
>
> We have a use case for controlling the reactor order in Maven, specifically
> for running tests on Travis. The common pattern is to run "mvn install
> -DskipTests; mvn test". After modules are installed (in the default order),
> the modules can be run in any order during testing, e.g., running the failed
> modules first, as in -Dsurefire.runOrder=failedfirst for Surefire.
> Would this feature be useful for others? I am attaching a *draft* patch that
> implements this feature by modifying DefaultMaven.java. I see no clean way of
> implementing this feature through an extension, unless some new callback,
> e.g., afterProjectsOrdered, is implemented first. Would it be worthwhile to
> improve this draft?
> One can test the feature by applying the patch, building Maven, and running
> tests with the modules in a random order like this:
> $ mvn -DdistributionTargetDir=$(pwd)/apache-maven-3.5.x-SNAPSHOT clean
> install -DskipTests
> $ apache-maven-3.5.x-SNAPSHOT/bin/mvn test -Dmaven.project.order.file=<(ls -d
> maven* | shuf)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MPLUGINTESTING-48) Github repo not up-to-date
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MPLUGINTESTING-48. - Resolution: Fixed Assignee: Karl Heinz Marbaise INFRA fixed this INFRA-14716 > Github repo not up-to-date > -- > > Key: MPLUGINTESTING-48 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-48 > Project: Maven Plugin Testing > Issue Type: Task >Reporter: Anders Hammar >Assignee: Karl Heinz Marbaise > > The github repo is not up-to-date. It seems as it is mirroring the wrong repo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MNG-6143) MAVEN_CONFIG is not implemented on Windows (mvn.cmd)
[
https://issues.apache.org/jira/browse/MNG-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNG-6143.
Resolution: Implemented
Assignee: Karl Heinz Marbaise
This is already implemented in [Maven starting with Maven
3.3.1|http://maven.apache.org/docs/3.3.1/release-notes.html] using the
{{.mvn/maven.config}}
> MAVEN_CONFIG is not implemented on Windows (mvn.cmd)
>
>
> Key: MNG-6143
> URL: https://issues.apache.org/jira/browse/MNG-6143
> Project: Maven
> Issue Type: New Feature
>Affects Versions: 3.3.9
>Reporter: XUBO YAN
>Assignee: Karl Heinz Marbaise
>
> MAVEN_CONFIG is a way of supplying default command line arguments
> see: MNG-5824
> this feature is implemented on non-windows only.
> {code}
> # Provide a "standardized" way to retrieve the CLI args that will
> # work with both Windows and non-Windows executions.
> MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $@"
> export MAVEN_CMD_LINE_ARGS
> {code}
> but the mvn.cmd does not contain MAVEN_CONFIG
> need it on windows.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6123) detect self references in POM and fail fast
[
https://issues.apache.org/jira/browse/MNG-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16105578#comment-16105578
]
Karl Heinz Marbaise commented on MNG-6123:
--
The [change in the integration test
suite|https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=3a1f095ec845c94b8e21ea28e4ffe69a01c29f4b]
fixes the problem with the integration tests.
> detect self references in POM and fail fast
> ---
>
> Key: MNG-6123
> URL: https://issues.apache.org/jira/browse/MNG-6123
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build, Dependencies
>Affects Versions: 3.3.9
> Environment: Oracle JDK 1.8.0_111 on Linux 4.8 x64
>Reporter: Gregor B. Rosenauer
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Labels: build, easyfix
> Fix For: 3.5.1-candidate
>
>
> Maven does not detect self references in a POM and tries to download the
> artifact it is about to build, which makes no sense and should result in an
> early error and abort of the build.
> E.g. sample POM:
> {code}
> org.my.acme
> my-module
> 1.2.3
>
> ...
>
> ${project.groupId}
> my-module
> ${project.version}
>
>
> {code}
> Maven tries to download my-module.jar but obviously fails...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6123) detect self references in POM and fail fast
[
https://issues.apache.org/jira/browse/MNG-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6123:
-
Fix Version/s: (was: 3.5.1-candidate)
3.5.1
> detect self references in POM and fail fast
> ---
>
> Key: MNG-6123
> URL: https://issues.apache.org/jira/browse/MNG-6123
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build, Dependencies
>Affects Versions: 3.3.9
> Environment: Oracle JDK 1.8.0_111 on Linux 4.8 x64
>Reporter: Gregor B. Rosenauer
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Labels: build, easyfix
> Fix For: 3.5.1
>
>
> Maven does not detect self references in a POM and tries to download the
> artifact it is about to build, which makes no sense and should result in an
> early error and abort of the build.
> E.g. sample POM:
> {code}
> org.my.acme
> my-module
> 1.2.3
>
> ...
>
> ${project.groupId}
> my-module
> ${project.version}
>
>
> {code}
> Maven tries to download my-module.jar but obviously fails...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MENFORCER-278) Upgrade mockito to 2.X to prevent jDK 9 WARNINGs
Karl Heinz Marbaise created MENFORCER-278:
-
Summary: Upgrade mockito to 2.X to prevent jDK 9 WARNINGs
Key: MENFORCER-278
URL: https://issues.apache.org/jira/browse/MENFORCER-278
Project: Maven Enforcer Plugin
Issue Type: Improvement
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
Priority: Minor
Upgrade Mockito Version to 2.X to prevent WARNING in Tests:
{code}
Running org.apache.maven.plugins.enforcer.TestDefaultEnforcementRuleHelper
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.mockito.cglib.core.ReflectUtils$2
(file:/Users/kama/.m2/repository/org/mockito/mockito-core/1.9.5/mockito-core-1.9.5.jar)
to method
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of
org.mockito.cglib.core.ReflectUtils$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Second:
[INFO] --- maven-invoker-plugin:2.0.0:run (integration-t...
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-278) Upgrade mockito to 2.X to prevent JDK 9 WARNINGs
[
https://issues.apache.org/jira/browse/MENFORCER-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-278:
--
Summary: Upgrade mockito to 2.X to prevent JDK 9 WARNINGs (was: Upgrade
mockito to 2.X to prevent jDK 9 WARNINGs)
> Upgrade mockito to 2.X to prevent JDK 9 WARNINGs
>
>
> Key: MENFORCER-278
> URL: https://issues.apache.org/jira/browse/MENFORCER-278
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Upgrade Mockito Version to 2.X to prevent WARNING in Tests:
> {code}
> Running org.apache.maven.plugins.enforcer.TestDefaultEnforcementRuleHelper
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.mockito.cglib.core.ReflectUtils$2
> (file:/Users/kama/.m2/repository/org/mockito/mockito-core/1.9.5/mockito-core-1.9.5.jar)
> to method
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of
> org.mockito.cglib.core.ReflectUtils$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Second:
> [INFO] --- maven-invoker-plugin:2.0.0:run (integration-t...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MNG-6123) detect self references in POM and fail fast
[
https://issues.apache.org/jira/browse/MNG-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNG-6123.
Resolution: Fixed
Done in Maven
Core:[8f8c45c990193b04c1770997d446951c5185b164|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8f8c45c990193b04c1770997d446951c5185b164]
Done in Maven Integration Testing
[3a1f095ec845c94b8e21ea28e4ffe69a01c29f4b|https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=3a1f095ec845c94b8e21ea28e4ffe69a01c29f4b]
> detect self references in POM and fail fast
> ---
>
> Key: MNG-6123
> URL: https://issues.apache.org/jira/browse/MNG-6123
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build, Dependencies
>Affects Versions: 3.3.9
> Environment: Oracle JDK 1.8.0_111 on Linux 4.8 x64
>Reporter: Gregor B. Rosenauer
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Labels: build, easyfix
> Fix For: 3.5.1
>
>
> Maven does not detect self references in a POM and tries to download the
> artifact it is about to build, which makes no sense and should result in an
> early error and abort of the build.
> E.g. sample POM:
> {code}
> org.my.acme
> my-module
> 1.2.3
>
> ...
>
> ${project.groupId}
> my-module
> ${project.version}
>
>
> {code}
> Maven tries to download my-module.jar but obviously fails...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MNG-6174) Clean Up Maven Model
[ https://issues.apache.org/jira/browse/MNG-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNG-6174. Resolution: Fixed Done in [4f2a2dba89251d9045fe9944783509a397491da3|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=4f2a2dba89251d9045fe9944783509a397491da3] > Clean Up Maven Model > > > Key: MNG-6174 > URL: https://issues.apache.org/jira/browse/MNG-6174 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.3.9 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.5.1 > > > Remove all parts from the Maven Model which are only valid for ModelVersion > 3.0.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6148) Can't package and assemble with JDK9/Jigsaw
[ https://issues.apache.org/jira/browse/MNG-6148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113285#comment-16113285 ] Karl Heinz Marbaise commented on MNG-6148: -- Do you have more specific information what's not working with maven-jar-plugin ? any test project for this? > Can't package and assemble with JDK9/Jigsaw > --- > > Key: MNG-6148 > URL: https://issues.apache.org/jira/browse/MNG-6148 > Project: Maven > Issue Type: Bug >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.5.1-candidate > > > Rootcause is project verona: Here are the related plugins with their fixed > versions: > * maven-assembly-plugin:3.0.0 > * maven-jar-plugin:3.0.0 > * maven-javadoc-plugin:2.10.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSHARED-651) Upgrade plexus-utils to version 3.1.0
Karl Heinz Marbaise created MSHARED-651: --- Summary: Upgrade plexus-utils to version 3.1.0 Key: MSHARED-651 URL: https://issues.apache.org/jira/browse/MSHARED-651 Project: Maven Shared Components Issue Type: Improvement Components: maven-artifact-transfer Affects Versions: maven-artifact-transfer-1.0.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor Fix For: maven-artifact-transfer-1.0.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MSHARED-651) Upgrade plexus-utils to version 3.1.0
[ https://issues.apache.org/jira/browse/MSHARED-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-651. --- Resolution: Fixed Done in [r1804202|https://svn.apache.org/r1804202] > Upgrade plexus-utils to version 3.1.0 > - > > Key: MSHARED-651 > URL: https://issues.apache.org/jira/browse/MSHARED-651 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-artifact-transfer >Affects Versions: maven-artifact-transfer-1.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-artifact-transfer-1.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSHARED-652) Upgrade to maven-shade-plugin to version 3.0.0
Karl Heinz Marbaise created MSHARED-652: --- Summary: Upgrade to maven-shade-plugin to version 3.0.0 Key: MSHARED-652 URL: https://issues.apache.org/jira/browse/MSHARED-652 Project: Maven Shared Components Issue Type: Improvement Components: maven-artifact-transfer Affects Versions: maven-artifact-resolver-1.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor Fix For: maven-artifact-transfer-1.0.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MSHARED-652) Upgrade to maven-shade-plugin to version 3.0.0
[ https://issues.apache.org/jira/browse/MSHARED-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-652. --- Resolution: Fixed Done in [r1804203|https://svn.apache.org/r1804203] > Upgrade to maven-shade-plugin to version 3.0.0 > -- > > Key: MSHARED-652 > URL: https://issues.apache.org/jira/browse/MSHARED-652 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-artifact-transfer >Affects Versions: maven-artifact-resolver-1.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-artifact-transfer-1.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MPOM-168) JDK 9 required updated to plugins
Karl Heinz Marbaise created MPOM-168: Summary: JDK 9 required updated to plugins Key: MPOM-168 URL: https://issues.apache.org/jira/browse/MPOM-168 Project: Maven POMs Issue Type: Improvement Components: asf Affects Versions: ASF-19 Reporter: Karl Heinz Marbaise Priority: Minor Fix For: ASF-20 The following plugins needed to be updated to work with JDK 9: * The maven-enforcer-plugin should be updated to final 3.0.0 release to make the pom working with JDK 9... * maven-shade-plugin should be upgraded to 3.0.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MEAR-250) IT skinny-wars-javaee5 fails while running with JDK 9
[
https://issues.apache.org/jira/browse/MEAR-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MEAR-250:
Assignee: Karl Heinz Marbaise
> IT skinny-wars-javaee5 fails while running with JDK 9
> -
>
> Key: MEAR-250
> URL: https://issues.apache.org/jira/browse/MEAR-250
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Currently running the build of maven-ear-plugin via {{mvn -Prun-its clean
> verify}} by using JDK 9+181 will fail a single IT.
> * skinny-wars-javaee5
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MEAR-250) IT skinny-wars-javaee5 fails while running with JDK 9
Karl Heinz Marbaise created MEAR-250:
Summary: IT skinny-wars-javaee5 fails while running with JDK 9
Key: MEAR-250
URL: https://issues.apache.org/jira/browse/MEAR-250
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
Priority: Blocker
Fix For: 3.0.0
Currently running the build of maven-ear-plugin via {{mvn -Prun-its clean
verify}} by using JDK 9+181 will fail a single IT.
* skinny-wars-javaee5
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MEAR-250) IT skinny-wars-javaee5 fails while running with JDK 9
[
https://issues.apache.org/jira/browse/MEAR-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MEAR-250.
Resolution: Fixed
Fixed in [r1804460|https://svn.apache.org/r1804460]
> IT skinny-wars-javaee5 fails while running with JDK 9
> -
>
> Key: MEAR-250
> URL: https://issues.apache.org/jira/browse/MEAR-250
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.0
>
>
> Currently running the build of maven-ear-plugin via {{mvn -Prun-its clean
> verify}} by using JDK 9+181 will fail a single IT.
> * skinny-wars-javaee5
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MSHARED-653) Upgrade to plexus-archiver 3.5
Karl Heinz Marbaise created MSHARED-653: --- Summary: Upgrade to plexus-archiver 3.5 Key: MSHARED-653 URL: https://issues.apache.org/jira/browse/MSHARED-653 Project: Maven Shared Components Issue Type: Improvement Affects Versions: maven-archiver-3.1.2 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor Fix For: maven-archiver-3.1.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSHARED-653) Upgrade to plexus-archiver 3.5
[ https://issues.apache.org/jira/browse/MSHARED-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-653: Description: Upgrading to plexus-archiver 3.5 will require upgrade to JDK 7 minimum here. > Upgrade to plexus-archiver 3.5 > -- > > Key: MSHARED-653 > URL: https://issues.apache.org/jira/browse/MSHARED-653 > Project: Maven Shared Components > Issue Type: Improvement >Affects Versions: maven-archiver-3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-archiver-3.1.2 > > > Upgrading to plexus-archiver 3.5 will require upgrade to JDK 7 minimum here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSHARED-653) Upgrade to plexus-archiver 3.5
[ https://issues.apache.org/jira/browse/MSHARED-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-653: Description: Upgrading to plexus-archiver 3.5 will require upgrade to JDK 7 minimum here. See the [changelog|https://github.com/codehaus-plexus/plexus-archiver/milestone/10?closed=1] (was: Upgrading to plexus-archiver 3.5 will require upgrade to JDK 7 minimum here.) > Upgrade to plexus-archiver 3.5 > -- > > Key: MSHARED-653 > URL: https://issues.apache.org/jira/browse/MSHARED-653 > Project: Maven Shared Components > Issue Type: Improvement >Affects Versions: maven-archiver-3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-archiver-3.1.2 > > > Upgrading to plexus-archiver 3.5 will require upgrade to JDK 7 minimum here. > See the > [changelog|https://github.com/codehaus-plexus/plexus-archiver/milestone/10?closed=1] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MASSEMBLY-866) poor performance of jar-with-dependencies when run in same run as docbook
[
https://issues.apache.org/jira/browse/MASSEMBLY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119088#comment-16119088
]
Karl Heinz Marbaise edited comment on MASSEMBLY-866 at 8/8/17 10:00 PM:
You can simply force maven-assembly-plugin to use those different versions of
dependencies by doing the following:
{code:xml}
..
..
...
org.codehaus.plexus
plexus-archiver
3.5
...
{code}
BTW: Which Maven version do you use? On which JDK you are running? Are you
running Maven Job Type in Jenkins? Can you exactly reproduce this by
downgrading maven-assembly-plugin to for example to 2.6 ? How large is the
resulting jar-with-dependencies file? Can you attach a log file of the build?
Before and after the upgrade ?
was (Author: khmarbaise):
You can simply force maven-assembly-plugin to use those different versions of
dependencies by doing the following:
{code:xml}
..
..
...
org.codehaus.plexus
plexus-archiver
3.5
...
{code}
BTW: Which Maven version do you use? On which JDK you are running? Are you
running Maven Job Type in Jenkins? Can you exactly reproduce this by
downgrading maven-assembly-plugin to for example to 2.6 ? How large is the
resulting jar-with-dependencies file?
> poor performance of jar-with-dependencies when run in same run as docbook
> -
>
> Key: MASSEMBLY-866
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-866
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: John Vines
> Labels: performance
>
> I apologize for the lack of information, but we have a large build
> environment which I cannot share, but I'll try to explain things as best I
> can.
> In our full build path, we have 2 components that I've found have side
> effects. One is a doc build which uses the docbkx-maven-plugin
> (https://github.com/mimil/docbkx-tools) to generate documentation (and
> usually takes a while, ~27 minutes) and another which builds a
> jar-with-depends for our UI. Prior to upgrade the assembly plugin to 3.0.0
> from 2.3 or 2.5 (I cannot recall) everything ran fine. After upgrading we
> found our jenkins builds taking about 40 more minutes, most of this change
> was in maven-assembly-plugin for that UI jar-with-dependencies
> {code}assembly-plugin:3.0.0:single (make-assembly) @ sqrrl-web-dist-ui ---
> 16:17:37 [INFO] Reading assembly descriptor: src/main/assembly/dist-ui.xml
> 16:17:40 [INFO] Building jar:
> /var/lib/jenkins/workspace/sqrrl-master-build/web/dist-ui/target/sqrrl-web-dist-ui-2.8.0-SNAPSHOT-jar-with-dependencies.jar
> 17:01:54 [INFO] {code}
> Eventually I isolated to a case where just that doc and that jar-with-deps
> being built would cause the jar-with-deps to take ~40 minutes, but if I built
> it by itself (all other maven options being equal) it would take about 1.5
> minutes.
> I'm honestly not too familiar with the inner workings of this plugin, nor the
> maven docbook plugin, but my hunch was that the docbook plugin was
> 'corrupting' or otherwise altering the main maven jvm in such a way to cause
> this. It does use some really old plexus plugins, among others, afterall.
> However, I stumbled across MASSEMBLY-424 and tested forking
> maven-assembly-plugin:3.0.0 and updating plexus-archiver to 3.5, plexus-io to
> 3.0.0 and plexus-utils to 3.1.0 and ran my 2 module build with the custom
> plugin and it ran just as quick as being run standalone (1.5minutes). (To
> build it with those plugins I had to disable checkstyle and enforcer though
> since at least one of those plugins versions was java7)
> One last datapoint is that in our jar-with-deps we are including
> bouncycastle's bcpix and bcprov and explicitly excluding them from the
> jar-with-depends also made that 2 module build faster (but not as fast), so
> I'm not 100% sure it's the docbook plugin was the catalyst there.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-866) poor performance of jar-with-dependencies when run in same run as docbook
[
https://issues.apache.org/jira/browse/MASSEMBLY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119088#comment-16119088
]
Karl Heinz Marbaise commented on MASSEMBLY-866:
---
You can simply force maven-assembly-plugin to use those different versions of
dependencies by doing the following:
{code:xml}
..
..
...
org.codehaus.plexus
plexus-archiver
3.5
...
{code}
BTW: Which Maven version do you use? On which JDK you are running? Are you
running Maven Job Type in Jenkins? Can you exactly reproduce this by
downgrading maven-assembly-plugin to for example to 2.6 ? How large is the
resulting jar-with-dependencies file?
> poor performance of jar-with-dependencies when run in same run as docbook
> -
>
> Key: MASSEMBLY-866
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-866
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: John Vines
> Labels: performance
>
> I apologize for the lack of information, but we have a large build
> environment which I cannot share, but I'll try to explain things as best I
> can.
> In our full build path, we have 2 components that I've found have side
> effects. One is a doc build which uses the docbkx-maven-plugin
> (https://github.com/mimil/docbkx-tools) to generate documentation (and
> usually takes a while, ~27 minutes) and another which builds a
> jar-with-depends for our UI. Prior to upgrade the assembly plugin to 3.0.0
> from 2.3 or 2.5 (I cannot recall) everything ran fine. After upgrading we
> found our jenkins builds taking about 40 more minutes, most of this change
> was in maven-assembly-plugin for that UI jar-with-dependencies
> {code}assembly-plugin:3.0.0:single (make-assembly) @ sqrrl-web-dist-ui ---
> 16:17:37 [INFO] Reading assembly descriptor: src/main/assembly/dist-ui.xml
> 16:17:40 [INFO] Building jar:
> /var/lib/jenkins/workspace/sqrrl-master-build/web/dist-ui/target/sqrrl-web-dist-ui-2.8.0-SNAPSHOT-jar-with-dependencies.jar
> 17:01:54 [INFO] {code}
> Eventually I isolated to a case where just that doc and that jar-with-deps
> being built would cause the jar-with-deps to take ~40 minutes, but if I built
> it by itself (all other maven options being equal) it would take about 1.5
> minutes.
> I'm honestly not too familiar with the inner workings of this plugin, nor the
> maven docbook plugin, but my hunch was that the docbook plugin was
> 'corrupting' or otherwise altering the main maven jvm in such a way to cause
> this. It does use some really old plexus plugins, among others, afterall.
> However, I stumbled across MASSEMBLY-424 and tested forking
> maven-assembly-plugin:3.0.0 and updating plexus-archiver to 3.5, plexus-io to
> 3.0.0 and plexus-utils to 3.1.0 and ran my 2 module build with the custom
> plugin and it ran just as quick as being run standalone (1.5minutes). (To
> build it with those plugins I had to disable checkstyle and enforcer though
> since at least one of those plugins versions was java7)
> One last datapoint is that in our jar-with-deps we are including
> bouncycastle's bcpix and bcprov and explicitly excluding them from the
> jar-with-depends also made that 2 module build faster (but not as fast), so
> I'm not 100% sure it's the docbook plugin was the catalyst there.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-302) Project doesn't compile with jdk7 (does with jdk8)
[
https://issues.apache.org/jira/browse/MCOMPILER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120400#comment-16120400
]
Karl Heinz Marbaise commented on MCOMPILER-302:
---
After taken a deeper look into that...I think I can explain the problem..
The issue is based on the generation of two command line option sets in the
case for JDK 7 which looks in debug output like this:
{code}
[DEBUG]
/Users/kama/.m2/repository/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar
[DEBUG] /Users/kama/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar
[DEBUG] Source roots:
[DEBUG] /Users/kama/ws-git-maven-bugs/failingCompile/src/main/java
[DEBUG]
/Users/kama/ws-git-maven-bugs/failingCompile/target/generated-sources/annotations
[DEBUG] Command line options:
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] incrementalBuildHelper#beforeRebuildExecution
[INFO] Compiling 1 source file to
/Users/kama/ws-git-maven-bugs/failingCompile/target/classes
[DEBUG] incrementalBuildHelper#afterRebuildExecution
[INFO]
[INFO] --- maven-resources-pl
{code}
which in the end causes an error of javac on command line:
{code}
javac: no source files
Usage: javac
use -help for a list of possible options
{code}
The first thing is that shouldn't happen and of course the failure output of
javac should somehow catched up and produce a useful error message for the
user...and being silently ignored...
Using JDK 8 there is exactly a single line of command line options being
generated...
But the most important question is: Why does it produce two command line
options sets in JDK 7 whereas in JDK 8 it does not...
> Project doesn't compile with jdk7 (does with jdk8)
> --
>
> Key: MCOMPILER-302
> URL: https://issues.apache.org/jira/browse/MCOMPILER-302
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2
> Environment: Windows 7
>Reporter: Sander Theetaert
> Labels: maven
> Attachments: failingCompile.zip
>
>
> When building attached project there are no .class files generated in the
> target/classes
> folder,
> this is a trimmed down example project but we do face this issue and can't
> use jdk8 for other reasons.
> At least a workaround would be nice...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MCOMPILER-302) Project doesn't compile with jdk7 (does with jdk8)
[
https://issues.apache.org/jira/browse/MCOMPILER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120400#comment-16120400
]
Karl Heinz Marbaise edited comment on MCOMPILER-302 at 8/9/17 6:23 PM:
---
After taken a deeper look into that...I think I can explain the problem..
The issue is based on the generation of two command line option sets in the
case for JDK 7 which looks in debug output like this:
{code}
[DEBUG]
/Users/kama/.m2/repository/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar
[DEBUG] /Users/kama/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar
[DEBUG] Source roots:
[DEBUG] /Users/kama/ws-git-maven-bugs/failingCompile/src/main/java
[DEBUG]
/Users/kama/ws-git-maven-bugs/failingCompile/target/generated-sources/annotations
[DEBUG] Command line options:
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] incrementalBuildHelper#beforeRebuildExecution
[INFO] Compiling 1 source file to
/Users/kama/ws-git-maven-bugs/failingCompile/target/classes
[DEBUG] incrementalBuildHelper#afterRebuildExecution
[INFO]
[INFO] --- maven-resources-pl
{code}
which in the end causes an error of javac on command line:
{code}
javac: no source files
Usage: javac
use -help for a list of possible options
{code}
The first thing is that shouldn't happen and of course the failure output of
javac should somehow catched up and produce a useful error message for the
user...and not being silently ignored...
Using JDK 8 there is exactly a single line of command line options being
generated...
But the most important question is: Why does it produce two command line
options sets in JDK 7 whereas in JDK 8 it does not...
was (Author: khmarbaise):
After taken a deeper look into that...I think I can explain the problem..
The issue is based on the generation of two command line option sets in the
case for JDK 7 which looks in debug output like this:
{code}
[DEBUG]
/Users/kama/.m2/repository/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar
[DEBUG] /Users/kama/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar
[DEBUG] Source roots:
[DEBUG] /Users/kama/ws-git-maven-bugs/failingCompile/src/main/java
[DEBUG]
/Users/kama/ws-git-maven-bugs/failingCompile/target/generated-sources/annotations
[DEBUG] Command line options:
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] -d /Users/kama/ws-git-maven-bugs/failingCompile/target/classes
-classpath .
[DEBUG] incrementalBuildHelper#beforeRebuildExecution
[INFO] Compiling 1 source file to
/Users/kama/ws-git-maven-bugs/failingCompile/target/classes
[DEBUG] incrementalBuildHelper#afterRebuildExecution
[INFO]
[INFO] --- maven-resources-pl
{code}
which in the end causes an error of javac on command line:
{code}
javac: no source files
Usage: javac
use -help for a list of possible options
{code}
The first thing is that shouldn't happen and of course the failure output of
javac should somehow catched up and produce a useful error message for the
user...and being silently ignored...
Using JDK 8 there is exactly a single line of command line options being
generated...
But the most important question is: Why does it produce two command line
options sets in JDK 7 whereas in JDK 8 it does not...
> Project doesn't compile with jdk7 (does with jdk8)
> --
>
> Key: MCOMPILER-302
> URL: https://issues.apache.org/jira/browse/MCOMPILER-302
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2
> Environment: Windows 7
>Reporter: Sander Theetaert
> Labels: maven
> Attachments: failingCompile.zip
>
>
> When building attached project there are no .class files generated in the
> target/classes
> folder,
> this is a trimmed down example project but we do face this issue and can't
> use jdk8 for other reasons.
> At least a workaround would be nice...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MSHARED-653) Upgrade to plexus-archiver 3.5
[ https://issues.apache.org/jira/browse/MSHARED-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-653. --- Resolution: Fixed Done in [r1804594|https://svn.apache.org/r1804594] > Upgrade to plexus-archiver 3.5 > -- > > Key: MSHARED-653 > URL: https://issues.apache.org/jira/browse/MSHARED-653 > Project: Maven Shared Components > Issue Type: Improvement >Affects Versions: maven-archiver-3.2.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-archiver-3.2.0 > > > Upgrading to plexus-archiver 3.5 will require upgrade to JDK 7 minimum here. > See the > [changelog|https://github.com/codehaus-plexus/plexus-archiver/milestone/10?closed=1] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MEJB-97) Remove param properties that doesn't make sense for CLI usage
[
https://issues.apache.org/jira/browse/MEJB-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16121948#comment-16121948
]
Karl Heinz Marbaise commented on MEJB-97:
-
The {{maven.ejb.ejbJar}} should be removed as property.
> Remove param properties that doesn't make sense for CLI usage
> -
>
> Key: MEJB-97
> URL: https://issues.apache.org/jira/browse/MEJB-97
> Project: Maven EJB Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.1
> Environment: n/a
>Reporter: Anders Hammar
>Assignee: Karl Heinz Marbaise
> Fix For: 3.0.0
>
>
> Currently the plugin supports configuring several of the parameters via CLI
> properties. This doesn't make sense in many cases and encourages bad Maven
> usage (builds should be reproducible). Remove the properties for those
> parameters. The v3.0.0 release is a good time to do this.
> First of all we need to identify candidates for removal.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MEJB-97) Remove param properties that doesn't make sense for CLI usage
[
https://issues.apache.org/jira/browse/MEJB-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16121948#comment-16121948
]
Karl Heinz Marbaise edited comment on MEJB-97 at 8/10/17 5:28 PM:
--
The {{maven.ejb.ejbJar}}, {{maven.ejb.escapeBackslashesInFilePath}},
{{maven.ejb.escapeString}}, {{maven.ejb.filterDeploymentDescriptor}},
{{maven.ejb.ejbVersion}} should be removed as property cause this should be
configured in the {{pom.xml}}
was (Author: khmarbaise):
The {{maven.ejb.ejbJar}} should be removed as property.
> Remove param properties that doesn't make sense for CLI usage
> -
>
> Key: MEJB-97
> URL: https://issues.apache.org/jira/browse/MEJB-97
> Project: Maven EJB Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.1
> Environment: n/a
>Reporter: Anders Hammar
>Assignee: Karl Heinz Marbaise
> Fix For: 3.0.0
>
>
> Currently the plugin supports configuring several of the parameters via CLI
> properties. This doesn't make sense in many cases and encourages bad Maven
> usage (builds should be reproducible). Remove the properties for those
> parameters. The v3.0.0 release is a good time to do this.
> First of all we need to identify candidates for removal.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MEJB-97) Remove param properties that doesn't make sense for CLI usage
[
https://issues.apache.org/jira/browse/MEJB-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16121948#comment-16121948
]
Karl Heinz Marbaise edited comment on MEJB-97 at 8/10/17 5:35 PM:
--
The {{maven.ejb.ejbJar}}, {{maven.ejb.escapeBackslashesInFilePath}},
{{maven.ejb.escapeString}}, {{maven.ejb.filterDeploymentDescriptor}},
{{maven.ejb.ejbVersion}}, {{maven.ejb.classifier}} should be removed as
property cause this should be configured in the {{pom.xml}}
was (Author: khmarbaise):
The {{maven.ejb.ejbJar}}, {{maven.ejb.escapeBackslashesInFilePath}},
{{maven.ejb.escapeString}}, {{maven.ejb.filterDeploymentDescriptor}},
{{maven.ejb.ejbVersion}} should be removed as property cause this should be
configured in the {{pom.xml}}
> Remove param properties that doesn't make sense for CLI usage
> -
>
> Key: MEJB-97
> URL: https://issues.apache.org/jira/browse/MEJB-97
> Project: Maven EJB Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.1
> Environment: n/a
>Reporter: Anders Hammar
>Assignee: Karl Heinz Marbaise
> Fix For: 3.0.0
>
>
> Currently the plugin supports configuring several of the parameters via CLI
> properties. This doesn't make sense in many cases and encourages bad Maven
> usage (builds should be reproducible). Remove the properties for those
> parameters. The v3.0.0 release is a good time to do this.
> First of all we need to identify candidates for removal.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MEJB-97) Remove param properties that doesn't make sense for CLI usage
[ https://issues.apache.org/jira/browse/MEJB-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MEJB-97. --- Resolution: Fixed Fixed in [r1804689|https://svn.apache.org/r1804689] > Remove param properties that doesn't make sense for CLI usage > - > > Key: MEJB-97 > URL: https://issues.apache.org/jira/browse/MEJB-97 > Project: Maven EJB Plugin > Issue Type: Improvement >Affects Versions: 2.5.1 > Environment: n/a >Reporter: Anders Hammar >Assignee: Karl Heinz Marbaise > Fix For: 3.0.0 > > > Currently the plugin supports configuring several of the parameters via CLI > properties. This doesn't make sense in many cases and encourages bad Maven > usage (builds should be reproducible). Remove the properties for those > parameters. The v3.0.0 release is a good time to do this. > First of all we need to identify candidates for removal. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MEJB-110) Updated maven-archiver to 3.2.0
Karl Heinz Marbaise created MEJB-110: Summary: Updated maven-archiver to 3.2.0 Key: MEJB-110 URL: https://issues.apache.org/jira/browse/MEJB-110 Project: Maven EJB Plugin Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Blocker Fix For: 3.0.0 We need to update to maven-archiver 3.2.0 until the archiver 3.2.0 is released. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MCOMPILER-303) Failure of a build with JDK 9
Karl Heinz Marbaise created MCOMPILER-303:
-
Summary: Failure of a build with JDK 9
Key: MCOMPILER-303
URL: https://issues.apache.org/jira/browse/MCOMPILER-303
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.6.2
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
Priority: Blocker
Fix For: 3.6.3
{code}
DEBUG] CompilerReuseStrategy: reuseCreated
[DEBUG] useIncrementalCompilation enabled
[ERROR] Failed to parse module-info:
[ERROR] With reflect: null
[ERROR] With asm: null
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile
(default-testCompile) on project devday-workshop-service: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile failed: Failed
to parse module-info -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile
(default-testCompile) on project devday-workshop-service: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile failed: Failed
to parse module-info
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile failed: Failed
to parse module-info
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
Caused by: java.lang.RuntimeException: Failed to parse module-info
at
org.apache.maven.plugin.compiler.TestCompilerMojo.getModuleName(TestCompilerMojo.java:328)
at
org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths(TestCompilerMojo.java:265)
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:751)
at
org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:172)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 21 more
{code}
Currently testing the project:
https://github.com/khmarbaise/java9-modules-maven-junit-example which I have
adopted just to see how it works with Maven using modules etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-303) Failure of a build with JDK 9
[
https://issues.apache.org/jira/browse/MCOMPILER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124652#comment-16124652
]
Karl Heinz Marbaise commented on MCOMPILER-303:
---
The needed fix for this issue is simply to upgrade the dependency:
{code:xml}
org.ow2.asm
asm
6.0_BETA
{code}
and uncomment the code in AsmModuleInfoParser:
{code:java}
@Override
public JavaModuleDescriptor getModuleDescriptor( File modulePath )
throws IOException
{
final JavaModuleDescriptorWrapper wrapper = new
JavaModuleDescriptorWrapper();
InputStream in = getModuleInfoClass( modulePath );
if ( in != null )
{
ClassReader reader = new ClassReader( in );
reader.accept( new ClassVisitor( Opcodes.ASM6 )
{
@Override
public ModuleVisitor visitModule( String name, int arg1, String
arg2 )
{
wrapper.builder = JavaModuleDescriptor.newModule( name );
return new ModuleVisitor( Opcodes.ASM6 )
{
@Override
public void visitRequire( String module, int access,
String version )
{
wrapper.builder.requires( module );
}
};
}
}, 0 );
in.close();
}
else
{
wrapper.builder = JavaModuleDescriptor.newAutomaticModule( null );
}
return wrapper.builder.build();
}
{code}
> Failure of a build with JDK 9
> -
>
> Key: MCOMPILER-303
> URL: https://issues.apache.org/jira/browse/MCOMPILER-303
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.6.3
>
>
> {code}
> DEBUG] CompilerReuseStrategy: reuseCreated
> [DEBUG] useIncrementalCompilation enabled
> [ERROR] Failed to parse module-info:
> [ERROR] With reflect: null
> [ERROR] With asm: null
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile
> (default-testCompile) on project devday-workshop-service: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile failed:
> Failed to parse module-info -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile
> (default-testCompile) on project devday-workshop-service: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile failed:
> Failed to parse module-info
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.2
[jira] [Commented] (MCOMPILER-297) -J prefixed compilerArg not added to command line
[
https://issues.apache.org/jira/browse/MCOMPILER-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124657#comment-16124657
]
Karl Heinz Marbaise commented on MCOMPILER-297:
---
Have you checked to use {{true}} ?
> -J prefixed compilerArg not added to command line
> -
>
> Key: MCOMPILER-297
> URL: https://issues.apache.org/jira/browse/MCOMPILER-297
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: java full version "9-ea+169"
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\Dev\apache-maven-latest\bin\..
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Anthony Vanelverdinghe
> Attachments: reproducer.zip
>
>
> For a pom.xml with the following section in the compiler's configuration:
>
> --add-modules=java.xml.ws.annotation
> -J--add-modules=java.xml.ws.annotation
>
> Maven only adds the first argument to the actual command line. To reproduce,
> simply unzip and run `mvn -X compile`
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MCOMPILER-297) -J prefixed compilerArg not added to command line
[
https://issues.apache.org/jira/browse/MCOMPILER-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MCOMPILER-297:
--
Description:
For a pom.xml with the following section in the compiler's configuration:
{code:xml}
--add-modules=java.xml.ws.annotation
-J--add-modules=java.xml.ws.annotation
{code}
Maven only adds the first argument to the actual command line. To reproduce,
simply unzip and run `mvn -X compile`
was:
For a pom.xml with the following section in the compiler's configuration:
--add-modules=java.xml.ws.annotation
-J--add-modules=java.xml.ws.annotation
Maven only adds the first argument to the actual command line. To reproduce,
simply unzip and run `mvn -X compile`
> -J prefixed compilerArg not added to command line
> -
>
> Key: MCOMPILER-297
> URL: https://issues.apache.org/jira/browse/MCOMPILER-297
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: java full version "9-ea+169"
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\Dev\apache-maven-latest\bin\..
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Anthony Vanelverdinghe
> Attachments: reproducer.zip
>
>
> For a pom.xml with the following section in the compiler's configuration:
> {code:xml}
>
> --add-modules=java.xml.ws.annotation
> -J--add-modules=java.xml.ws.annotation
>
> {code}
> Maven only adds the first argument to the actual command line. To reproduce,
> simply unzip and run `mvn -X compile`
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-297) -J prefixed compilerArg not added to command line
[
https://issues.apache.org/jira/browse/MCOMPILER-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124673#comment-16124673
]
Karl Heinz Marbaise commented on MCOMPILER-297:
---
So after taken a more deep look into that a question is coming up. Why would
you like to configure a runtime option for JavaC via {{-J..}} option? For which
runtime? Maybe I misunderstand a thing here...
> -J prefixed compilerArg not added to command line
> -
>
> Key: MCOMPILER-297
> URL: https://issues.apache.org/jira/browse/MCOMPILER-297
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: java full version "9-ea+169"
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\Dev\apache-maven-latest\bin\..
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Anthony Vanelverdinghe
> Attachments: reproducer.zip
>
>
> For a pom.xml with the following section in the compiler's configuration:
> {code:xml}
>
> --add-modules=java.xml.ws.annotation
> -J--add-modules=java.xml.ws.annotation
>
> {code}
> Maven only adds the first argument to the actual command line. To reproduce,
> simply unzip and run `mvn -X compile`
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MCOMPILER-294) test-compile broken due to -Xmodule removal in jdk-ea167
[
https://issues.apache.org/jira/browse/MCOMPILER-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MCOMPILER-294:
-
Assignee: Robert Scholte
> test-compile broken due to -Xmodule removal in jdk-ea167
>
>
> Key: MCOMPILER-294
> URL: https://issues.apache.org/jira/browse/MCOMPILER-294
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Peter Parson
>Assignee: Robert Scholte
> Labels: jigsaw
> Fix For: 3.6.2
>
>
> [{{- Xmodule}} has been merged into
> {{--patch-module}}|https://bugs.openjdk.java.net/browse/JDK-8173777], and has
> obviously been [removed in JDK9 build
> 167|http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8178012].
> This change breaks {{test-compile}}, as [{{TestCompilerMojo}} uses
> {{-XModule}} to add
> reads|http://svn.apache.org/viewvc/maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java?view=markup#l266].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MCOMPILER-294) test-compile broken due to -Xmodule removal in jdk-ea167
[
https://issues.apache.org/jira/browse/MCOMPILER-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MCOMPILER-294.
-
Resolution: Fixed
> test-compile broken due to -Xmodule removal in jdk-ea167
>
>
> Key: MCOMPILER-294
> URL: https://issues.apache.org/jira/browse/MCOMPILER-294
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Peter Parson
>Assignee: Robert Scholte
> Labels: jigsaw
> Fix For: 3.6.2
>
>
> [{{- Xmodule}} has been merged into
> {{--patch-module}}|https://bugs.openjdk.java.net/browse/JDK-8173777], and has
> obviously been [removed in JDK9 build
> 167|http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8178012].
> This change breaks {{test-compile}}, as [{{TestCompilerMojo}} uses
> {{-XModule}} to add
> reads|http://svn.apache.org/viewvc/maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java?view=markup#l266].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MCOMPILER-297) -J prefixed compilerArg not added to command line
[
https://issues.apache.org/jira/browse/MCOMPILER-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124673#comment-16124673
]
Karl Heinz Marbaise edited comment on MCOMPILER-297 at 8/12/17 6:53 PM:
So after taken a more deep look into that a question is coming up. Why would
you like to configure a runtime option for JavaC via {{-J..}} option? For which
runtime? Maybe I misunderstand a thing here...
Supplemental: {{-J..}} [options are not
allowed|http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#commandlineargfile]
to be put into the {{@options}} file.
was (Author: khmarbaise):
So after taken a more deep look into that a question is coming up. Why would
you like to configure a runtime option for JavaC via {{-J..}} option? For which
runtime? Maybe I misunderstand a thing here...
> -J prefixed compilerArg not added to command line
> -
>
> Key: MCOMPILER-297
> URL: https://issues.apache.org/jira/browse/MCOMPILER-297
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: java full version "9-ea+169"
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\Dev\apache-maven-latest\bin\..
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Anthony Vanelverdinghe
> Attachments: reproducer.zip
>
>
> For a pom.xml with the following section in the compiler's configuration:
> {code:xml}
>
> --add-modules=java.xml.ws.annotation
> -J--add-modules=java.xml.ws.annotation
>
> {code}
> Maven only adds the first argument to the actual command line. To reproduce,
> simply unzip and run `mvn -X compile`
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MCOMPILER-293) Add advice message in case automodules are used
[
https://issues.apache.org/jira/browse/MCOMPILER-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MCOMPILER-293.
-
Resolution: Fixed
> Add advice message in case automodules are used
> ---
>
> Key: MCOMPILER-293
> URL: https://issues.apache.org/jira/browse/MCOMPILER-293
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.6.2
>
>
> As mentioned by the JSR-376 project lead:
> {quote}
> Strongly advise developers never to publish, for broad use, explicit modules
> that require automatic modules. That's risky: An automatic module is
> unreliable, since it can depend on types on the class path, and its name and
> exported packages could change if and when it's converted into an explicit
> module. It's fine to declare and use explicit modules that require automatic
> modules in limited settings, but they should never be published to Maven
> Central or any similar public repository.
> {quote}
> The maven-compiler-plugin should help making people aware of it. In case of
> an application (without exported packages) the message should be at INFO
> level, for libraries (with exported packages) the message should be at
> warning level.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MCOMPILER-293) Add advice message in case automodules are used
[
https://issues.apache.org/jira/browse/MCOMPILER-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MCOMPILER-293:
--
Fix Version/s: 3.6.2
> Add advice message in case automodules are used
> ---
>
> Key: MCOMPILER-293
> URL: https://issues.apache.org/jira/browse/MCOMPILER-293
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.6.2
>
>
> As mentioned by the JSR-376 project lead:
> {quote}
> Strongly advise developers never to publish, for broad use, explicit modules
> that require automatic modules. That's risky: An automatic module is
> unreliable, since it can depend on types on the class path, and its name and
> exported packages could change if and when it's converted into an explicit
> module. It's fine to declare and use explicit modules that require automatic
> modules in limited settings, but they should never be published to Maven
> Central or any similar public repository.
> {quote}
> The maven-compiler-plugin should help making people aware of it. In case of
> an application (without exported packages) the message should be at INFO
> level, for libraries (with exported packages) the message should be at
> warning level.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-289) Comments in module-info.java break test compile due to parser issue
[
https://issues.apache.org/jira/browse/MCOMPILER-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124679#comment-16124679
]
Karl Heinz Marbaise commented on MCOMPILER-289:
---
QDox version 2.0-M7 contains the fix for issue 22
> Comments in module-info.java break test compile due to parser issue
> ---
>
> Key: MCOMPILER-289
> URL: https://issues.apache.org/jira/browse/MCOMPILER-289
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: MacOS
>Reporter: Tomas Langer
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: reproducer.tar.gz
>
>
> When a comment exists within module definition (after opening curly braces of
> module), the test compile fails with
> {{[ERROR] With qdox: syntax error @[8,8] in
> file:/Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/main/java/module-info.java}}
> To reproduce:
> - unpack reproducer
> - go into subdirectory "maven-module-info-comments"
> - run "mvn test"
> To workaround:
> - remove comment on line 5 in src/main/java/module-info.java
> - run "mvn test"
> Full maven output log:
> {noformat}
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building module-info-comments 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> module-info-comments ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @
> module-info-comments ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to
> /Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/target/classes
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> module-info-comments ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.6.1:testCompile (default-testCompile) @
> module-info-comments ---
> [ERROR] Failed to parse module-info:
> [ERROR] With qdox: syntax error @[8,8] in
> file:/Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/main/java/module-info.java
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.659 s
> [INFO] Finished at: 2017-01-30T12:13:24+01:00
> [INFO] Final Memory: 14M/47M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile
> (default-testCompile) on project module-info-comments: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile failed:
> Failed to parse module-info -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile
> (default-testCompile) on project module-info-comments: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile failed:
> Failed to parse module-info
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCl
[jira] [Commented] (MCOMPILER-300) Maven compiler plugin 3.X.X recompiling generated sources and failing with compilation error
[ https://issues.apache.org/jira/browse/MCOMPILER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124684#comment-16124684 ] Karl Heinz Marbaise commented on MCOMPILER-300: --- Hm..without any log file or example project it's hard to say what the cause is? > Maven compiler plugin 3.X.X recompiling generated sources and failing with > compilation error > > > Key: MCOMPILER-300 > URL: https://issues.apache.org/jira/browse/MCOMPILER-300 > Project: Maven Compiler Plugin > Issue Type: Question >Affects Versions: 3.6.1 > Environment: windows >Reporter: Naresh B > Labels: build > > I am trying to build my source code with the latest maven version 3.5.0 and > with the latest maven-compiler-plugin version 3.6.1. I am seeing an issue > when building an EJB module in my project. maven-compiler-plugin is trying to > recompile the generated sources (stub EJB files) created by was6-maven-plugin > and it is failing with multiple compilation errors. This was not the case > with the earlier maven-compiler-plugin version 2.5.1. > This issue is coming only if I use maven-compiler-plugin versions 3.X.X. But > with the 2.X.X versions it simply says “nothing to compile” i mean it will > not recompile generated sources and my build works fine. Could you please > suggest what could be the issue? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MCOMPILER-244) Compiler plugin silently drops -XD flags when fork=false
[
https://issues.apache.org/jira/browse/MCOMPILER-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124691#comment-16124691
]
Karl Heinz Marbaise commented on MCOMPILER-244:
---
If you use {{true}} javac be called which then can use the given
options. If you don't use {{true}} the internal compiler api be
used and no such options can be changed during the build of Maven. You could
give them via {{MAVEN_OPTS}} also to the JVM which is used by Maven.
> Compiler plugin silently drops -XD flags when fork=false
>
>
> Key: MCOMPILER-244
> URL: https://issues.apache.org/jira/browse/MCOMPILER-244
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.0, 3.1, 3.2, 3.3
>Reporter: Paweł Kozioł
>
> I have Java code that uses two classes from private Java API
> (sun.security.\*). When i tried to compile it using jdk1.8.0_45 it failed
> with error saying that package sun.security.\* does not exist. I found that i
> should add flag {{-XDignore.symbol.file}} to compiler arguments.
> It turns out that Maven Compiler Plugin silently ignores that flag and it
> does not work unless you also specify {{true}} ([thanks to
> karmakaze from StackOverflow for
> sollution|http://stackoverflow.com/a/30472473])
> If you cannot fix this to work with fork=false maybe you could add printing
> warning/error to stdout?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MCOMPILER-289) Comments in module-info.java break test compile due to parser issue
[
https://issues.apache.org/jira/browse/MCOMPILER-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MCOMPILER-289:
--
Fix Version/s: 3.6.3
> Comments in module-info.java break test compile due to parser issue
> ---
>
> Key: MCOMPILER-289
> URL: https://issues.apache.org/jira/browse/MCOMPILER-289
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: MacOS
>Reporter: Tomas Langer
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.3
>
> Attachments: reproducer.tar.gz
>
>
> When a comment exists within module definition (after opening curly braces of
> module), the test compile fails with
> {{[ERROR] With qdox: syntax error @[8,8] in
> file:/Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/main/java/module-info.java}}
> To reproduce:
> - unpack reproducer
> - go into subdirectory "maven-module-info-comments"
> - run "mvn test"
> To workaround:
> - remove comment on line 5 in src/main/java/module-info.java
> - run "mvn test"
> Full maven output log:
> {noformat}
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building module-info-comments 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> module-info-comments ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @
> module-info-comments ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to
> /Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/target/classes
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> module-info-comments ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.6.1:testCompile (default-testCompile) @
> module-info-comments ---
> [ERROR] Failed to parse module-info:
> [ERROR] With qdox: syntax error @[8,8] in
> file:/Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/main/java/module-info.java
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.659 s
> [INFO] Finished at: 2017-01-30T12:13:24+01:00
> [INFO] Final Memory: 14M/47M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile
> (default-testCompile) on project module-info-comments: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile failed:
> Failed to parse module-info -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile
> (default-testCompile) on project module-info-comments: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile failed:
> Failed to parse module-info
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apac
[jira] [Assigned] (MCOMPILER-289) Comments in module-info.java break test compile due to parser issue
[
https://issues.apache.org/jira/browse/MCOMPILER-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MCOMPILER-289:
-
Assignee: Karl Heinz Marbaise (was: Robert Scholte)
> Comments in module-info.java break test compile due to parser issue
> ---
>
> Key: MCOMPILER-289
> URL: https://issues.apache.org/jira/browse/MCOMPILER-289
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: MacOS
>Reporter: Tomas Langer
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.3
>
> Attachments: reproducer.tar.gz
>
>
> When a comment exists within module definition (after opening curly braces of
> module), the test compile fails with
> {{[ERROR] With qdox: syntax error @[8,8] in
> file:/Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/main/java/module-info.java}}
> To reproduce:
> - unpack reproducer
> - go into subdirectory "maven-module-info-comments"
> - run "mvn test"
> To workaround:
> - remove comment on line 5 in src/main/java/module-info.java
> - run "mvn test"
> Full maven output log:
> {noformat}
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building module-info-comments 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> module-info-comments ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @
> module-info-comments ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to
> /Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/target/classes
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> module-info-comments ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.6.1:testCompile (default-testCompile) @
> module-info-comments ---
> [ERROR] Failed to parse module-info:
> [ERROR] With qdox: syntax error @[8,8] in
> file:/Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/main/java/module-info.java
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.659 s
> [INFO] Finished at: 2017-01-30T12:13:24+01:00
> [INFO] Final Memory: 14M/47M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile
> (default-testCompile) on project module-info-comments: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile failed:
> Failed to parse module-info -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile
> (default-testCompile) on project module-info-comments: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile failed:
> Failed to parse module-info
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain
[jira] [Closed] (MCOMPILER-289) Comments in module-info.java break test compile due to parser issue
[
https://issues.apache.org/jira/browse/MCOMPILER-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MCOMPILER-289.
-
Resolution: Fixed
Fixed in [r1804871|https://svn.apache.org/r1804871]
The solution might be superseded by MCOMPILER-303 using plexus-languages
component..
> Comments in module-info.java break test compile due to parser issue
> ---
>
> Key: MCOMPILER-289
> URL: https://issues.apache.org/jira/browse/MCOMPILER-289
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: MacOS
>Reporter: Tomas Langer
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.3
>
> Attachments: reproducer.tar.gz
>
>
> When a comment exists within module definition (after opening curly braces of
> module), the test compile fails with
> {{[ERROR] With qdox: syntax error @[8,8] in
> file:/Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/main/java/module-info.java}}
> To reproduce:
> - unpack reproducer
> - go into subdirectory "maven-module-info-comments"
> - run "mvn test"
> To workaround:
> - remove comment on line 5 in src/main/java/module-info.java
> - run "mvn test"
> Full maven output log:
> {noformat}
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building module-info-comments 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> module-info-comments ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @
> module-info-comments ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to
> /Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/target/classes
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> module-info-comments ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.6.1:testCompile (default-testCompile) @
> module-info-comments ---
> [ERROR] Failed to parse module-info:
> [ERROR] With qdox: syntax error @[8,8] in
> file:/Users/tomas/IdeaProjects/reproducers/maven-module-info-comments/src/main/java/module-info.java
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.659 s
> [INFO] Finished at: 2017-01-30T12:13:24+01:00
> [INFO] Final Memory: 14M/47M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile
> (default-testCompile) on project module-info-comments: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile failed:
> Failed to parse module-info -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile
> (default-testCompile) on project module-info-comments: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile failed:
> Failed to parse module-info
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apach
