[jira] [Commented] (MENFORCER-357) RequirePluginVersions not recognizing versions-from-properties
[
https://issues.apache.org/jira/browse/MENFORCER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17203805#comment-17203805
]
Stephen Connolly commented on MENFORCER-357:
Also, building from the root with `-rf` will pass... Seems to only be building
a full build from the root that triggers the issue
> RequirePluginVersions not recognizing versions-from-properties
> --
>
> Key: MENFORCER-357
> URL: https://issues.apache.org/jira/browse/MENFORCER-357
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Jeffrey Bennett
>Priority: Major
> Attachments: Annotation 2020-08-02 024036.png, child-pom.xml,
> parent-pom.xml, sample-pom.xml
>
>
> Fails (plugin version as a property applied in pluginManagement):
> {code:xml}
>
> 1.0.0
>
>
>
>
>
> org.examplesome-plugin
> ${some.plugin.version}
>
>
>
>
>
> org.example
> some-plugin
>
>
>
> {code}
> Works OK: (plugin version as a raw-version in pluginManagement):
> {code:xml}
>
>
>
>
> org.example
> some-plugin
> 1.0.0
>
>
>
>
>
> org.example
> some-plugin
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MENFORCER-357) RequirePluginVersions not recognizing versions-from-properties
[
https://issues.apache.org/jira/browse/MENFORCER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17203804#comment-17203804
]
Stephen Connolly commented on MENFORCER-357:
I can confirm this issue is real. Issue is not present in 1.4.1 version of the
plugin.
> RequirePluginVersions not recognizing versions-from-properties
> --
>
> Key: MENFORCER-357
> URL: https://issues.apache.org/jira/browse/MENFORCER-357
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Jeffrey Bennett
>Priority: Major
> Attachments: Annotation 2020-08-02 024036.png, child-pom.xml,
> parent-pom.xml, sample-pom.xml
>
>
> Fails (plugin version as a property applied in pluginManagement):
> {code:xml}
>
> 1.0.0
>
>
>
>
>
> org.examplesome-plugin
> ${some.plugin.version}
>
>
>
>
>
> org.example
> some-plugin
>
>
>
> {code}
> Works OK: (plugin version as a raw-version in pluginManagement):
> {code:xml}
>
>
>
>
> org.example
> some-plugin
> 1.0.0
>
>
>
>
>
> org.example
> some-plugin
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MENFORCER-357) RequirePluginVersions not recognizing versions-from-properties
[
https://issues.apache.org/jira/browse/MENFORCER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MENFORCER-357:
---
Affects Version/s: 3.0.0-M3
> RequirePluginVersions not recognizing versions-from-properties
> --
>
> Key: MENFORCER-357
> URL: https://issues.apache.org/jira/browse/MENFORCER-357
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Jeffrey Bennett
>Priority: Major
> Attachments: Annotation 2020-08-02 024036.png, child-pom.xml,
> parent-pom.xml, sample-pom.xml
>
>
> Fails (plugin version as a property applied in pluginManagement):
> {code:xml}
>
> 1.0.0
>
>
>
>
>
> org.examplesome-plugin
> ${some.plugin.version}
>
>
>
>
>
> org.example
> some-plugin
>
>
>
> {code}
> Works OK: (plugin version as a raw-version in pluginManagement):
> {code:xml}
>
>
>
>
> org.example
> some-plugin
> 1.0.0
>
>
>
>
>
> org.example
> some-plugin
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-267) add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
[
https://issues.apache.org/jira/browse/MDEPLOY-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048533#comment-17048533
]
Stephen Connolly commented on MDEPLOY-267:
--
Thus no new property.
> add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
> -
>
> Key: MDEPLOY-267
> URL: https://issues.apache.org/jira/browse/MDEPLOY-267
> Project: Maven Deploy Plugin
> Issue Type: New Feature
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.0.0
>
>
> maven-release-plugin creates a commit where the pom is not a SNAPSHOT
> version: if CI system is configured to build on every commit and to deploy
> the artifacts on every build (with the intent in general to deploy updated
> SNAPSHOTs on every commit), the CI will deploy the non-SNAPSHOT that has
> already been deployed by the user who launched {{mvn release:perform}}, then
> it will generate an error (trying to override existing release artifact)
> and/or create new staging repository and/or override artifacts partially (if
> repository not configured to block overrides)
> we can add a new parameter {{-DdeployOnlySnaphots=true/false}}: it will be
> false per default for normal use, but can be configured to true in users' CI
> system.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-267) add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
[
https://issues.apache.org/jira/browse/MDEPLOY-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048532#comment-17048532
]
Stephen Connolly commented on MDEPLOY-267:
--
I wonder... could we change the type of `skip` from a boolean to an “extended
boolean” where `releases` is true if the version is a release and `snapshots`
is true if a snapshot while empty string and `true` are true always?
> add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
> -
>
> Key: MDEPLOY-267
> URL: https://issues.apache.org/jira/browse/MDEPLOY-267
> Project: Maven Deploy Plugin
> Issue Type: New Feature
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.0.0
>
>
> maven-release-plugin creates a commit where the pom is not a SNAPSHOT
> version: if CI system is configured to build on every commit and to deploy
> the artifacts on every build (with the intent in general to deploy updated
> SNAPSHOTs on every commit), the CI will deploy the non-SNAPSHOT that has
> already been deployed by the user who launched {{mvn release:perform}}, then
> it will generate an error (trying to override existing release artifact)
> and/or create new staging repository and/or override artifacts partially (if
> repository not configured to block overrides)
> we can add a new parameter {{-DdeployOnlySnaphots=true/false}}: it will be
> false per default for normal use, but can be configured to true in users' CI
> system.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-267) add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
[
https://issues.apache.org/jira/browse/MDEPLOY-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048526#comment-17048526
]
Stephen Connolly commented on MDEPLOY-267:
--
So if we have a reproducible build, I may want to build the tag and install it
locally... but by accident if I type ‘mvn deploy` without configuration of the
altRepo to point to my local repo manager things will blow up.
You’ve just convinced me that we need this for both the install and deploy
plugins on different property names
> add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
> -
>
> Key: MDEPLOY-267
> URL: https://issues.apache.org/jira/browse/MDEPLOY-267
> Project: Maven Deploy Plugin
> Issue Type: New Feature
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.0.0
>
>
> maven-release-plugin creates a commit where the pom is not a SNAPSHOT
> version: if CI system is configured to build on every commit and to deploy
> the artifacts on every build (with the intent in general to deploy updated
> SNAPSHOTs on every commit), the CI will deploy the non-SNAPSHOT that has
> already been deployed by the user who launched {{mvn release:perform}}, then
> it will generate an error (trying to override existing release artifact)
> and/or create new staging repository and/or override artifacts partially (if
> repository not configured to block overrides)
> we can add a new parameter {{-DdeployOnlySnaphots=true/false}}: it will be
> false per default for normal use, but can be configured to true in users' CI
> system.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-267) add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
[
https://issues.apache.org/jira/browse/MDEPLOY-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048519#comment-17048519
]
Stephen Connolly commented on MDEPLOY-267:
--
And I don’t see profiles as inherently evil... that we allowed specifying
dependencies or dependency versions in profiles... that’s evil.
> add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
> -
>
> Key: MDEPLOY-267
> URL: https://issues.apache.org/jira/browse/MDEPLOY-267
> Project: Maven Deploy Plugin
> Issue Type: New Feature
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.0.0
>
>
> maven-release-plugin creates a commit where the pom is not a SNAPSHOT
> version: if CI system is configured to build on every commit and to deploy
> the artifacts on every build (with the intent in general to deploy updated
> SNAPSHOTs on every commit), the CI will deploy the non-SNAPSHOT that has
> already been deployed by the user who launched {{mvn release:perform}}, then
> it will generate an error (trying to override existing release artifact)
> and/or create new staging repository and/or override artifacts partially (if
> repository not configured to block overrides)
> we can add a new parameter {{-DdeployOnlySnaphots=true/false}}: it will be
> false per default for normal use, but can be configured to true in users' CI
> system.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-267) add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
[
https://issues.apache.org/jira/browse/MDEPLOY-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048518#comment-17048518
]
Stephen Connolly commented on MDEPLOY-267:
--
`skipSnapshots` would be incredibly useful as a safety net for things like the
bug in the release plugin pre 2.5.2 when it stopped parsing git correctly and
would try to release snapshots
> add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
> -
>
> Key: MDEPLOY-267
> URL: https://issues.apache.org/jira/browse/MDEPLOY-267
> Project: Maven Deploy Plugin
> Issue Type: New Feature
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.0.0
>
>
> maven-release-plugin creates a commit where the pom is not a SNAPSHOT
> version: if CI system is configured to build on every commit and to deploy
> the artifacts on every build (with the intent in general to deploy updated
> SNAPSHOTs on every commit), the CI will deploy the non-SNAPSHOT that has
> already been deployed by the user who launched {{mvn release:perform}}, then
> it will generate an error (trying to override existing release artifact)
> and/or create new staging repository and/or override artifacts partially (if
> repository not configured to block overrides)
> we can add a new parameter {{-DdeployOnlySnaphots=true/false}}: it will be
> false per default for normal use, but can be configured to true in users' CI
> system.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-267) add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
[
https://issues.apache.org/jira/browse/MDEPLOY-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048516#comment-17048516
]
Stephen Connolly commented on MDEPLOY-267:
--
If you are follow the “git-ops” style where you release build pushing to a
release branch then you can have configured your ‘deploy’ branch to activate
the release profile which would change the property value
> add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
> -
>
> Key: MDEPLOY-267
> URL: https://issues.apache.org/jira/browse/MDEPLOY-267
> Project: Maven Deploy Plugin
> Issue Type: New Feature
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.0.0
>
>
> maven-release-plugin creates a commit where the pom is not a SNAPSHOT
> version: if CI system is configured to build on every commit and to deploy
> the artifacts on every build (with the intent in general to deploy updated
> SNAPSHOTs on every commit), the CI will deploy the non-SNAPSHOT that has
> already been deployed by the user who launched {{mvn release:perform}}, then
> it will generate an error (trying to override existing release artifact)
> and/or create new staging repository and/or override artifacts partially (if
> repository not configured to block overrides)
> we can add a new parameter {{-DdeployOnlySnaphots=true/false}}: it will be
> false per default for normal use, but can be configured to true in users' CI
> system.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-267) add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
[
https://issues.apache.org/jira/browse/MDEPLOY-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048515#comment-17048515
]
Stephen Connolly commented on MDEPLOY-267:
--
I prefer the name `skipReleases` which should also have it’s mirror:
`skipSnapshots`
> add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
> -
>
> Key: MDEPLOY-267
> URL: https://issues.apache.org/jira/browse/MDEPLOY-267
> Project: Maven Deploy Plugin
> Issue Type: New Feature
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.0.0
>
>
> maven-release-plugin creates a commit where the pom is not a SNAPSHOT
> version: if CI system is configured to build on every commit and to deploy
> the artifacts on every build (with the intent in general to deploy updated
> SNAPSHOTs on every commit), the CI will deploy the non-SNAPSHOT that has
> already been deployed by the user who launched {{mvn release:perform}}, then
> it will generate an error (trying to override existing release artifact)
> and/or create new staging repository and/or override artifacts partially (if
> repository not configured to block overrides)
> we can add a new parameter {{-DdeployOnlySnaphots=true/false}}: it will be
> false per default for normal use, but can be configured to true in users' CI
> system.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-267) add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
[ https://issues.apache.org/jira/browse/MDEPLOY-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048316#comment-17048316 ] Stephen Connolly commented on MDEPLOY-267: -- Note, I am not arguing for this property... as it increases the number of configuration flags that have inter-connected logic and thus makes things harder to reason on... rather I am rejecting your reasoning for rejecting it 藍 > add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false) > - > > Key: MDEPLOY-267 > URL: https://issues.apache.org/jira/browse/MDEPLOY-267 > Project: Maven Deploy Plugin > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.0.0 > > > in case of maven-release-plugin it happen the pom contains non SNAPSHOT > version and so CI system try to deploy the artifacts this can generate an > error and/or create new staging repository > we can add a new parameter -DdeployOnlySnaphots=true/false. For backward > compat it will be false per default but users will be able to configure their > CI system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-267) add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
[ https://issues.apache.org/jira/browse/MDEPLOY-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048315#comment-17048315 ] Stephen Connolly commented on MDEPLOY-267: -- Not true. I might want to configure my release profile to have it off in order to ensure that all release deployments are made through the release plugin. > add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false) > - > > Key: MDEPLOY-267 > URL: https://issues.apache.org/jira/browse/MDEPLOY-267 > Project: Maven Deploy Plugin > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.0.0 > > > in case of maven-release-plugin it happen the pom contains non SNAPSHOT > version and so CI system try to deploy the artifacts this can generate an > error and/or create new staging repository > we can add a new parameter -DdeployOnlySnaphots=true/false. For backward > compat it will be false per default but users will be able to configure their > CI system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-267) add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false)
[ https://issues.apache.org/jira/browse/MDEPLOY-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048303#comment-17048303 ] Stephen Connolly commented on MDEPLOY-267: -- So IIUC the issue here is where you are using the release plugin *and* building every commit. Thus when you build the release commit in between where the mainline has SNAPSHOTS you try to deploy, but without the correct deploy goals and may miss deployment artifact’s as well as potentially fail if you collide with artifacts from the actual release build. I agree that is problematic, But it’s problematic because of choices made by the user that Maven cannot know about. I’m now 2+ years following a pattern where *every* commit on master is a release build with the Maven release plugin... but we never push the master branch back, rather throw it away... we push the tag back though... and this is *awesome*... no longer do we have diffs on the master branch... with that choice of how to do CI this is not an issue Similarly, it would be trivial to write a “guard” plugin that sets a system property if the current version is not a SNAPSHOT. Thus you could run `mvn guard:check deploy` from the CI server and have `guard:check` set the skip properties for install and deploy plugins... OTOH if we we want to add config here as this ticket is suggesting then we should be complete and add a property to skip deploying SNAPSHOTS as well as one to skip releases... and add same properties to the install plugin > add a parameter to not deploy non snapshots (-DdeployOnlySnaphots=true/false) > - > > Key: MDEPLOY-267 > URL: https://issues.apache.org/jira/browse/MDEPLOY-267 > Project: Maven Deploy Plugin > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.0.0 > > > in case of maven-release-plugin it happen the pom contains non SNAPSHOT > version and so CI system try to deploy the artifacts this can generate an > error and/or create new staging repository > we can add a new parameter -DdeployOnlySnaphots=true/false. For backward > compat it will be false per default but users will be able to configure their > CI system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5652) "supplies"/"provides"/"proffers" concept proposal
[
https://issues.apache.org/jira/browse/MNG-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999071#comment-16999071
]
Stephen Connolly commented on MNG-5652:
---
It is in no way obsolete.
1. Java modules are orthogonal in some ways, plus we still have lots of
duplicate artifacts
2. Maven shouldn’t be *just* JVM, and non-JVM needs will require this also
3. I have already integrated this into the PDT proposal
> "supplies"/"provides"/"proffers" concept proposal
> -
>
> Key: MNG-5652
> URL: https://issues.apache.org/jira/browse/MNG-5652
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Stephen Connolly
>Priority: Major
>
> The exact name is still undecided. Some candidate names are: "supplies",
> "provides", and "proffers"
> h2. "supplies" concept proposal
> ===
> h3. Introduction
>
> The following is a proposal for Maven in a post-modelVersion-4.0.0 era. The
> aim of this proposal is to simplify the management of dependency trees in the
> decentralised era of artifact production that we find ourselves in.
> The core issue is that different organisations can produce artifacts that may
> overlap. The easiest example is the servlet-api. If we restrict ourselves to
> version 2.5 of the servlet specification there are quite a few artifacts that
> all deliver the exact same content:
> * {{jetty:servlet-api:2.5-6.0.2}}
> * {{org.daisy.libs:servlet-api:2.5.0}}
> * {{org.mortbay.jetty:servlet-api-2.5:6.1.14}}
> * {{org.jboss.spec.javax.servlet:jboss-servlet-api_2.5_spec:1.0.1.Final}}
> * etc
> **Note:** this is a generic problem that is not restricted to the
> servlet-api, the servlet-api just provides the example that will be most
> familiar to everyone.
> So where these multiple artifacts supplying the equivalent content becomes a
> problem is when the dependency tree is being calculated. If you have two
> dependencies each declaring transitive dependencies on different artifacts
> that supply equivalent content, then you end up with two copies of the same
> JAR file in your classpath.
> In the case of the servlet-api, the hack most people use is to declare the
> servlet-api with scope `provided` thus preventing it from being transitive.
> This is, however, a hack. In a more ideal world it would be better to let the
> servlet-api be transitive and only when we get to the WAR module would we
> declare that a specific servlet-api is to be provided in the containers that
> the WAR is targets for deployment into.
> We can take a second example that does not have the luxury of a *de facto*
> hack.
> * {{javax.faces:jsf-api:2.1}}
> * {{org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec:2.1.28.Final}}
> * {{org.apache.myfaces.core:myfaces-api:2.1.13}}
> Now in the case of the JSF API, you are supposed to bundle the JSF API in
> your WAR file. So if I use three JSF component libraries, I could very well
> end up with three different but equivalent JSF API jars in my WAR file.
> Ideally what we want is some way of telling Maven that these artifacts are
> equivalent.
> Proposal
>
> Introduce the concept of "supplies" to the project model. The concept needs
> three changes to the project model:
> 1. An explicit top level construct for a project to explicitly declare
> up-front artifacts that it knows - at the time the project is being authored
> - to contain equivalent content to at least a subset of the project's
> content. Declarations could include a claim from: `subset`, `superset`,
> `disjoint` and `equivalent` with the default being `disjoint`.
> 2. An explicit sub-element of the `dependency` construct to allow consumers
> to *post-facto* declare a specific dependency as supplying equivalent content
> for other dependencies
> 3. An extension to the `dependency/excludes/exclude` construct to allow
> consumers to remove claims a dependency makes with respect to supplying
> equivalent content
> By way of illustration, here are some examples of these constructs mapped to
> a Model Version 4.0.0 like XML schema. As the post-modelVersion-4.0.0 schema
> is not yet known, this represents the best way to illustrate how the concept
> will work, but note that this proposal does not suggest a schema for this
> concept.
> h3. Example 1
> This illustrates how we would want, say, the `myfaces-api` project model to
> look.
> {code:xml}
>
> org.apache.myfaces.core
> myfaces-api
> 2.1.3
> ...
>
>
> javax.faces
> jsf-api
> [2.1,2.2)
> superset
>
>
> org.jboss.spec.javax.faces
> jboss-jsf-api_2.1_spec
> equivalent
>
>
> ...
>
> {code}
> This indicates that the {{myfaces-api}} artifact is intended to be useable as
> a drop-in replacement for either
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942581#comment-16942581
]
Stephen Connolly commented on MNG-6656:
---
If we are going for 3.7.0 then I would disagree with
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
A Maven 3.7.0, IMHO, should have this feature enabled by default... if that
means we need a couple of releases to iron out the bugs, so be it. I would also
allow a pom.xml property to disable the feature for that project and all
inheriting projects that do not turn it back on.
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MNG-6667) Hint at Maven upgrade requirement when trying to build a pom.xml with a newer modelVersion
[ https://issues.apache.org/jira/browse/MNG-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly resolved MNG-6667. --- Resolution: Fixed Fix Version/s: 3.6.2 > Hint at Maven upgrade requirement when trying to build a pom.xml with a newer > modelVersion > -- > > Key: MNG-6667 > URL: https://issues.apache.org/jira/browse/MNG-6667 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Stephen Connolly >Assignee: Stephen Connolly >Priority: Major > Labels: maven-5.x-preparation > Fix For: 3.6.2 > > > In order to allow us to bump the modelVersion *for building* we need Maven to > alert users about the updated building requirements. > NOTE: We will always need to *deploy* a modelVersion 4.0.0 pom.xml so that > consumers can consume dependencies, but we can *build* with a newer model > version and produce the corresponding modelVersion 4.0.0 pom.xml for > deployment (this would be flattened so that it has no parent). The build pom > only needs to be deployed if it is being used as a parent, in which case: > * The pom using it as a parent will have to have a newer or same modelVersion > as its parent > On that basis we can either > * Deploy the newer modelVersion parent pom with a classifier and its 4.0.0 > (best-effort) equivalent without a classifier, then when building the child, > we look for the parent with classifier and only if missing do we fall back to > look for a modelVersion 4.0.0 parent. > * Deploy the newer modelVersion parent pom as normal, since you need to have > a newer modelVersion to be a child and we only deploy flattened 4.0.0 > compatibility poms for the children, no legacy consumer will ever have to > parse the parent > Determination of which of these two approaches to use is out of scope for > this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6667) Hint at Maven upgrade requirement when trying to build a pom.xml with a newer modelVersion
[ https://issues.apache.org/jira/browse/MNG-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853679#comment-16853679 ] Stephen Connolly commented on MNG-6667: --- https://gitbox.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/mng-6667 > Hint at Maven upgrade requirement when trying to build a pom.xml with a newer > modelVersion > -- > > Key: MNG-6667 > URL: https://issues.apache.org/jira/browse/MNG-6667 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Stephen Connolly >Assignee: Stephen Connolly >Priority: Major > Labels: maven-5.x-preparation > > In order to allow us to bump the modelVersion *for building* we need Maven to > alert users about the updated building requirements. > NOTE: We will always need to *deploy* a modelVersion 4.0.0 pom.xml so that > consumers can consume dependencies, but we can *build* with a newer model > version and produce the corresponding modelVersion 4.0.0 pom.xml for > deployment (this would be flattened so that it has no parent). The build pom > only needs to be deployed if it is being used as a parent, in which case: > * The pom using it as a parent will have to have a newer or same modelVersion > as its parent > On that basis we can either > * Deploy the newer modelVersion parent pom with a classifier and its 4.0.0 > (best-effort) equivalent without a classifier, then when building the child, > we look for the parent with classifier and only if missing do we fall back to > look for a modelVersion 4.0.0 parent. > * Deploy the newer modelVersion parent pom as normal, since you need to have > a newer modelVersion to be a child and we only deploy flattened 4.0.0 > compatibility poms for the children, no legacy consumer will ever have to > parse the parent > Determination of which of these two approaches to use is out of scope for > this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6667) Hint at Maven upgrade requirement when trying to build a pom.xml with a newer modelVersion
Stephen Connolly created MNG-6667: - Summary: Hint at Maven upgrade requirement when trying to build a pom.xml with a newer modelVersion Key: MNG-6667 URL: https://issues.apache.org/jira/browse/MNG-6667 Project: Maven Issue Type: Improvement Components: core Reporter: Stephen Connolly Assignee: Stephen Connolly In order to allow us to bump the modelVersion *for building* we need Maven to alert users about the updated building requirements. NOTE: We will always need to *deploy* a modelVersion 4.0.0 pom.xml so that consumers can consume dependencies, but we can *build* with a newer model version and produce the corresponding modelVersion 4.0.0 pom.xml for deployment (this would be flattened so that it has no parent). The build pom only needs to be deployed if it is being used as a parent, in which case: * The pom using it as a parent will have to have a newer or same modelVersion as its parent On that basis we can either * Deploy the newer modelVersion parent pom with a classifier and its 4.0.0 (best-effort) equivalent without a classifier, then when building the child, we look for the parent with classifier and only if missing do we fall back to look for a modelVersion 4.0.0 parent. * Deploy the newer modelVersion parent pom as normal, since you need to have a newer modelVersion to be a child and we only deploy flattened 4.0.0 compatibility poms for the children, no legacy consumer will ever have to parse the parent Determination of which of these two approaches to use is out of scope for this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1623) TempWmicBatchFile.bat is left in project dirs after surefire tests are run
[ https://issues.apache.org/jira/browse/SUREFIRE-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16830720#comment-16830720 ] Stephen Connolly commented on SUREFIRE-1623: [~tibor17] your last comment does not reflect the ASF core principle of [community over code|https://blogs.apache.org/foundation/entry/asf_15_community_over_code]. I am assuming this was just a temporary lapse of judgement. I respectfully request that you revise or delete this comment and apologize to [~ChrisGWarp] [Code of Conduct|https://www.apache.org/foundation/policies/conduct.html] > TempWmicBatchFile.bat is left in project dirs after surefire tests are run > -- > > Key: SUREFIRE-1623 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1623 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M3 >Reporter: Chris Graham >Assignee: Tibor Digana >Priority: Blocker > > WINDOWS ONLY: > When the WMIC command it run to obtain the process start time, the current > implementation leaves behind a batch file, TempWmicBatchFile.bat, which is > zero bytes long. > This file needs to be removed post execution. > Leaving it behind will interfere with the release plugin as a scm status call > will fail with files needing to be added. Simply ignoring the file is a very > sloppy approach. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-5667) Either install or deploy
[
https://issues.apache.org/jira/browse/MNG-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625548#comment-16625548
]
Stephen Connolly commented on MNG-5667:
---
Hmmm actually I think this proposal is the wrong way to do this.
I think we should keep the linear lifecycle, *but* _either_ the install plugin
(in fact plugins in general) should be aware of the final phase and if that
final phase is {{deploy}} then it should skip pushing the artifacts to the
local repository cache but instead put a dirty flag on the artifacts in the
local repository cache _or_ the deploy plugin should put the dirty flag in
place so that the hash gets checked and that way we can save re-downloading a
very large artifact.
Use Case 1: I have a number of projects where some artifacts should never be
deployed but other artifacts should. But allow for sub-reactor builds I need to
install them, but they should never be deployed. (So I have something like this
in those pom files:
{code:xml}
maven-deploy-plugin
true
org.sonatype.plugins
nexus-staging-maven-plugin
true
{code}
Now if we fork the lifecycle, then I cannot build something that depends on
that locally without including the non-deployed module in the reactor.
Given that these are time-consuming docker images used for integration testing,
i'd rather not rebuild them every time I want to run {{mvn test -f
integration-tests/pom.xml -Dtest=SomeNewTestCaseIAmWriting}} during iterative
development.
Use Case 2: The large artifacts.
I have had projects in the past where Maven builds a 9GB artifact (ISO image of
a VM... yeah don't ask). That can be a pain to upload... but if I then need to
turn around and download it again immediately after uploading it... that would
be really bad.
It may be that the solution for use case 2 is to have the deploy plugin also do
an install... but you can see why I think this is not entirely a trivial
solution.
Use Case 3: What should we then do with {{mvn clean install deploy}}
Once we actually have a forked lifecycle then {{mvn clean install deploy}}
actually becomes a legitimate request (and unlike now where we can say "Well
{{deploy}} implies {{install}} so please don't do that) we may find that we
have users crawling out of the woodwork with more exotic use cases.
> Either install or deploy
>
>
> Key: MNG-5667
> URL: https://issues.apache.org/jira/browse/MNG-5667
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>
> Original proposal
> {quote}
> PROPOSAL 2: Either install or deploy
> In general one should either run 'mvn verify' or 'mvn deploy', there's often
> no reason to run 'mvn install'. The only reason I can think of is when you
> have 2 separate projects (not part of the same multimodule), one depending on
> the other and you want to test this.
> To ensure that your projects build the same as your co-workers, you should
> always try to deploy it. However, there are several reasons why a deploy
> could fail: network problems, authentication/authorization issues, repository
> manager policies, etc. However, this is still after every install-phase, so
> the local repository is polluted.
> This is as unpleasant as for a developer local repository as for a CI-server
> local repo.
>
> The proposal is to "branch" the final phases.
> Calling any phase up until the verify will stay the same.
> Calling 'mvn install' would call these phases: validate ... verify, install
> (nothing new here)
> Calling 'mvn deploy' would call these phases: validate ... verify, deploy
> (no more install)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6429) Integration Test site publishing requires Java 7 (or javadoc errors ignored)
[
https://issues.apache.org/jira/browse/MNG-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6429:
--
Fix Version/s: (was: 3.5.4)
3.6.0-candidate
> Integration Test site publishing requires Java 7 (or javadoc errors ignored)
>
>
> Key: MNG-6429
> URL: https://issues.apache.org/jira/browse/MNG-6429
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.4
>Reporter: Stephen Connolly
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> {code:java}
> [INFO]
> 7 errors
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Maven Core ITs 2.1-SNAPSHOT SUCCESS [ 38.586
> s]
> [INFO] Maven IT Support ... SUCCESS [ 2.726 s]
> [INFO] Maven IT :: Plugins SUCCESS [ 2.693 s]
> [INFO] Maven IT Plugin :: Active Collection ... FAILURE [ 15.162
> s]
> [INFO] Maven IT Plugin :: Ant-Based ... SKIPPED
> [INFO] Maven IT Plugin :: Artifact SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency A SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency B SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency C SKIPPED
> [INFO] Maven IT Plugin :: Class Loader SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Aggregator .. SKIPPED
> [INFO] Maven IT Plugin :: Configuration ... SKIPPED
> [INFO] Maven IT Plugin :: Context Passing . SKIPPED
> [INFO] Maven ITs :: Core Plugin Stubs . SKIPPED
> [INFO] Maven IT Clean Plugin Stub 0.1-stub-SNAPSHOT ... SKIPPED
> [INFO] Maven IT Compiler Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT Deploy Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT EAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT EJB Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Install Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT JAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Javadoc Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Plugin Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT RAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Resources Plugin Stub 0.1-stub-SNAPSHOT ... SKIPPED
> [INFO] Maven IT Site Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT Source Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT Surefire Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT WAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Plugin :: Dependency Collection ... SKIPPED
> [INFO] Maven IT Plugin :: Dependency Resolution ... SKIPPED
> [INFO] Maven IT Plugin :: Expression .. SKIPPED
> [INFO] Maven IT Plugin :: Error Mojos . SKIPPED
> [INFO] Maven IT Component . SKIPPED
> [INFO] Maven IT Plugin :: Extension Consumer .. SKIPPED
> [INFO] Maven IT Plugin :: Extension Provider .. SKIPPED
> [INFO] Maven IT Plugin :: Fork SKIPPED
> [INFO] Maven IT Plugin :: Invalid Descriptor .. SKIPPED
> [INFO] Maven IT Plugin :: Log File SKIPPED
> [INFO] Maven IT Helper Library SKIPPED
> [INFO] Maven IT Plugin :: Model Interpolation . SKIPPED
> [INFO] Maven IT Plugin :: No Default Component SKIPPED
> [INFO] Maven IT Plugin :: No Project .. SKIPPED
> [INFO] Maven IT Plugin :: Online .. SKIPPED
> [INFO] Maven IT Plugin :: Optional Mojos .. SKIPPED
> [INFO] Maven IT Plugin :: Packaging ... SKIPPED
> [INFO] Maven IT Plugin :: Parameter Implementation SKIPPED
> [INFO] Maven IT Plugin :: Plugin Dependency ... SKIPPED
> [INFO] Maven IT Plugin :: Project . SKIPPED
> [INFO] Maven IT Plugin :: Project Interpolation ... SKIPPED
> [INFO] Maven IT Plugin :: Setter .. SKIPPED
> [INFO] Maven IT Plugin :: Singleton Component . SKIPPED
> [INFO] Maven IT Plugin :: Site SKIPPED
> [INFO] Maven IT Plugin :: Toolchain ... SKIPPED
> [INFO] Maven IT Plugin :: Touch ... SKIPPED
> [INFO] Maven IT Plugin :: Uses Properties Plugin .. SKIPPED
> [INFO] Maven IT Plugin :: Uses Wagon Plugin ... SKIPPED
> [INFO] Maven IT Plugin :: This plugin should contain the mojos
[jira] [Updated] (MNG-6429) Integration Test site publishing requires Java 7 (or javadoc errors ignored)
[
https://issues.apache.org/jira/browse/MNG-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6429:
--
Affects Version/s: 3.5.4
> Integration Test site publishing requires Java 7 (or javadoc errors ignored)
>
>
> Key: MNG-6429
> URL: https://issues.apache.org/jira/browse/MNG-6429
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.4
>Reporter: Stephen Connolly
>Priority: Critical
> Fix For: 3.5.4
>
>
> {code:java}
> [INFO]
> 7 errors
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Maven Core ITs 2.1-SNAPSHOT SUCCESS [ 38.586
> s]
> [INFO] Maven IT Support ... SUCCESS [ 2.726 s]
> [INFO] Maven IT :: Plugins SUCCESS [ 2.693 s]
> [INFO] Maven IT Plugin :: Active Collection ... FAILURE [ 15.162
> s]
> [INFO] Maven IT Plugin :: Ant-Based ... SKIPPED
> [INFO] Maven IT Plugin :: Artifact SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency A SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency B SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency C SKIPPED
> [INFO] Maven IT Plugin :: Class Loader SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Aggregator .. SKIPPED
> [INFO] Maven IT Plugin :: Configuration ... SKIPPED
> [INFO] Maven IT Plugin :: Context Passing . SKIPPED
> [INFO] Maven ITs :: Core Plugin Stubs . SKIPPED
> [INFO] Maven IT Clean Plugin Stub 0.1-stub-SNAPSHOT ... SKIPPED
> [INFO] Maven IT Compiler Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT Deploy Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT EAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT EJB Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Install Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT JAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Javadoc Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Plugin Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT RAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Resources Plugin Stub 0.1-stub-SNAPSHOT ... SKIPPED
> [INFO] Maven IT Site Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT Source Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT Surefire Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT WAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Plugin :: Dependency Collection ... SKIPPED
> [INFO] Maven IT Plugin :: Dependency Resolution ... SKIPPED
> [INFO] Maven IT Plugin :: Expression .. SKIPPED
> [INFO] Maven IT Plugin :: Error Mojos . SKIPPED
> [INFO] Maven IT Component . SKIPPED
> [INFO] Maven IT Plugin :: Extension Consumer .. SKIPPED
> [INFO] Maven IT Plugin :: Extension Provider .. SKIPPED
> [INFO] Maven IT Plugin :: Fork SKIPPED
> [INFO] Maven IT Plugin :: Invalid Descriptor .. SKIPPED
> [INFO] Maven IT Plugin :: Log File SKIPPED
> [INFO] Maven IT Helper Library SKIPPED
> [INFO] Maven IT Plugin :: Model Interpolation . SKIPPED
> [INFO] Maven IT Plugin :: No Default Component SKIPPED
> [INFO] Maven IT Plugin :: No Project .. SKIPPED
> [INFO] Maven IT Plugin :: Online .. SKIPPED
> [INFO] Maven IT Plugin :: Optional Mojos .. SKIPPED
> [INFO] Maven IT Plugin :: Packaging ... SKIPPED
> [INFO] Maven IT Plugin :: Parameter Implementation SKIPPED
> [INFO] Maven IT Plugin :: Plugin Dependency ... SKIPPED
> [INFO] Maven IT Plugin :: Project . SKIPPED
> [INFO] Maven IT Plugin :: Project Interpolation ... SKIPPED
> [INFO] Maven IT Plugin :: Setter .. SKIPPED
> [INFO] Maven IT Plugin :: Singleton Component . SKIPPED
> [INFO] Maven IT Plugin :: Site SKIPPED
> [INFO] Maven IT Plugin :: Toolchain ... SKIPPED
> [INFO] Maven IT Plugin :: Touch ... SKIPPED
> [INFO] Maven IT Plugin :: Uses Properties Plugin .. SKIPPED
> [INFO] Maven IT Plugin :: Uses Wagon Plugin ... SKIPPED
> [INFO] Maven IT Plugin :: This plugin should contain the mojos needed by all
> tests. SKIPPED
> [INFO] Maven IT Plugin
[jira] [Updated] (MNG-6429) Integration Test site publishing requires Java 7 (or javadoc errors ignored)
[
https://issues.apache.org/jira/browse/MNG-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6429:
--
Priority: Critical (was: Major)
> Integration Test site publishing requires Java 7 (or javadoc errors ignored)
>
>
> Key: MNG-6429
> URL: https://issues.apache.org/jira/browse/MNG-6429
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.4
>Reporter: Stephen Connolly
>Priority: Critical
> Fix For: 3.5.4
>
>
> {code:java}
> [INFO]
> 7 errors
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Maven Core ITs 2.1-SNAPSHOT SUCCESS [ 38.586
> s]
> [INFO] Maven IT Support ... SUCCESS [ 2.726 s]
> [INFO] Maven IT :: Plugins SUCCESS [ 2.693 s]
> [INFO] Maven IT Plugin :: Active Collection ... FAILURE [ 15.162
> s]
> [INFO] Maven IT Plugin :: Ant-Based ... SKIPPED
> [INFO] Maven IT Plugin :: Artifact SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency A SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency B SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency C SKIPPED
> [INFO] Maven IT Plugin :: Class Loader SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Aggregator .. SKIPPED
> [INFO] Maven IT Plugin :: Configuration ... SKIPPED
> [INFO] Maven IT Plugin :: Context Passing . SKIPPED
> [INFO] Maven ITs :: Core Plugin Stubs . SKIPPED
> [INFO] Maven IT Clean Plugin Stub 0.1-stub-SNAPSHOT ... SKIPPED
> [INFO] Maven IT Compiler Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT Deploy Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT EAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT EJB Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Install Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT JAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Javadoc Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Plugin Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT RAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Resources Plugin Stub 0.1-stub-SNAPSHOT ... SKIPPED
> [INFO] Maven IT Site Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT Source Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT Surefire Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT WAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Plugin :: Dependency Collection ... SKIPPED
> [INFO] Maven IT Plugin :: Dependency Resolution ... SKIPPED
> [INFO] Maven IT Plugin :: Expression .. SKIPPED
> [INFO] Maven IT Plugin :: Error Mojos . SKIPPED
> [INFO] Maven IT Component . SKIPPED
> [INFO] Maven IT Plugin :: Extension Consumer .. SKIPPED
> [INFO] Maven IT Plugin :: Extension Provider .. SKIPPED
> [INFO] Maven IT Plugin :: Fork SKIPPED
> [INFO] Maven IT Plugin :: Invalid Descriptor .. SKIPPED
> [INFO] Maven IT Plugin :: Log File SKIPPED
> [INFO] Maven IT Helper Library SKIPPED
> [INFO] Maven IT Plugin :: Model Interpolation . SKIPPED
> [INFO] Maven IT Plugin :: No Default Component SKIPPED
> [INFO] Maven IT Plugin :: No Project .. SKIPPED
> [INFO] Maven IT Plugin :: Online .. SKIPPED
> [INFO] Maven IT Plugin :: Optional Mojos .. SKIPPED
> [INFO] Maven IT Plugin :: Packaging ... SKIPPED
> [INFO] Maven IT Plugin :: Parameter Implementation SKIPPED
> [INFO] Maven IT Plugin :: Plugin Dependency ... SKIPPED
> [INFO] Maven IT Plugin :: Project . SKIPPED
> [INFO] Maven IT Plugin :: Project Interpolation ... SKIPPED
> [INFO] Maven IT Plugin :: Setter .. SKIPPED
> [INFO] Maven IT Plugin :: Singleton Component . SKIPPED
> [INFO] Maven IT Plugin :: Site SKIPPED
> [INFO] Maven IT Plugin :: Toolchain ... SKIPPED
> [INFO] Maven IT Plugin :: Touch ... SKIPPED
> [INFO] Maven IT Plugin :: Uses Properties Plugin .. SKIPPED
> [INFO] Maven IT Plugin :: Uses Wagon Plugin ... SKIPPED
> [INFO] Maven IT Plugin :: This plugin should contain the mojos needed by all
> tests. SKIPPED
> [INFO] Maven
[jira] [Updated] (MNG-6429) Integration Test site publishing requires Java 7 (or javadoc errors ignored)
[
https://issues.apache.org/jira/browse/MNG-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6429:
--
Fix Version/s: 3.5.4
> Integration Test site publishing requires Java 7 (or javadoc errors ignored)
>
>
> Key: MNG-6429
> URL: https://issues.apache.org/jira/browse/MNG-6429
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.4
>Reporter: Stephen Connolly
>Priority: Critical
> Fix For: 3.5.4
>
>
> {code:java}
> [INFO]
> 7 errors
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Maven Core ITs 2.1-SNAPSHOT SUCCESS [ 38.586
> s]
> [INFO] Maven IT Support ... SUCCESS [ 2.726 s]
> [INFO] Maven IT :: Plugins SUCCESS [ 2.693 s]
> [INFO] Maven IT Plugin :: Active Collection ... FAILURE [ 15.162
> s]
> [INFO] Maven IT Plugin :: Ant-Based ... SKIPPED
> [INFO] Maven IT Plugin :: Artifact SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency A SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency B SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Dependency C SKIPPED
> [INFO] Maven IT Plugin :: Class Loader SKIPPED
> [INFO] Maven IT Plugin :: Class Loader :: Aggregator .. SKIPPED
> [INFO] Maven IT Plugin :: Configuration ... SKIPPED
> [INFO] Maven IT Plugin :: Context Passing . SKIPPED
> [INFO] Maven ITs :: Core Plugin Stubs . SKIPPED
> [INFO] Maven IT Clean Plugin Stub 0.1-stub-SNAPSHOT ... SKIPPED
> [INFO] Maven IT Compiler Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT Deploy Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT EAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT EJB Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Install Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT JAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Javadoc Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Plugin Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT RAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Resources Plugin Stub 0.1-stub-SNAPSHOT ... SKIPPED
> [INFO] Maven IT Site Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT Source Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
> [INFO] Maven IT Surefire Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
> [INFO] Maven IT WAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
> [INFO] Maven IT Plugin :: Dependency Collection ... SKIPPED
> [INFO] Maven IT Plugin :: Dependency Resolution ... SKIPPED
> [INFO] Maven IT Plugin :: Expression .. SKIPPED
> [INFO] Maven IT Plugin :: Error Mojos . SKIPPED
> [INFO] Maven IT Component . SKIPPED
> [INFO] Maven IT Plugin :: Extension Consumer .. SKIPPED
> [INFO] Maven IT Plugin :: Extension Provider .. SKIPPED
> [INFO] Maven IT Plugin :: Fork SKIPPED
> [INFO] Maven IT Plugin :: Invalid Descriptor .. SKIPPED
> [INFO] Maven IT Plugin :: Log File SKIPPED
> [INFO] Maven IT Helper Library SKIPPED
> [INFO] Maven IT Plugin :: Model Interpolation . SKIPPED
> [INFO] Maven IT Plugin :: No Default Component SKIPPED
> [INFO] Maven IT Plugin :: No Project .. SKIPPED
> [INFO] Maven IT Plugin :: Online .. SKIPPED
> [INFO] Maven IT Plugin :: Optional Mojos .. SKIPPED
> [INFO] Maven IT Plugin :: Packaging ... SKIPPED
> [INFO] Maven IT Plugin :: Parameter Implementation SKIPPED
> [INFO] Maven IT Plugin :: Plugin Dependency ... SKIPPED
> [INFO] Maven IT Plugin :: Project . SKIPPED
> [INFO] Maven IT Plugin :: Project Interpolation ... SKIPPED
> [INFO] Maven IT Plugin :: Setter .. SKIPPED
> [INFO] Maven IT Plugin :: Singleton Component . SKIPPED
> [INFO] Maven IT Plugin :: Site SKIPPED
> [INFO] Maven IT Plugin :: Toolchain ... SKIPPED
> [INFO] Maven IT Plugin :: Touch ... SKIPPED
> [INFO] Maven IT Plugin :: Uses Properties Plugin .. SKIPPED
> [INFO] Maven IT Plugin :: Uses Wagon Plugin ... SKIPPED
> [INFO] Maven IT Plugin :: This plugin should contain the mojos needed by all
> tests. SKIPPED
> [INFO] Maven IT Plugin ::
[jira] [Created] (MNG-6429) Integration Test site publishing requires Java 7 (or javadoc errors ignored)
Stephen Connolly created MNG-6429:
-
Summary: Integration Test site publishing requires Java 7 (or
javadoc errors ignored)
Key: MNG-6429
URL: https://issues.apache.org/jira/browse/MNG-6429
Project: Maven
Issue Type: Bug
Reporter: Stephen Connolly
{code:java}
[INFO]
7 errors
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Maven Core ITs 2.1-SNAPSHOT SUCCESS [ 38.586 s]
[INFO] Maven IT Support ... SUCCESS [ 2.726 s]
[INFO] Maven IT :: Plugins SUCCESS [ 2.693 s]
[INFO] Maven IT Plugin :: Active Collection ... FAILURE [ 15.162 s]
[INFO] Maven IT Plugin :: Ant-Based ... SKIPPED
[INFO] Maven IT Plugin :: Artifact SKIPPED
[INFO] Maven IT Plugin :: Class Loader :: Dependency A SKIPPED
[INFO] Maven IT Plugin :: Class Loader :: Dependency B SKIPPED
[INFO] Maven IT Plugin :: Class Loader :: Dependency C SKIPPED
[INFO] Maven IT Plugin :: Class Loader SKIPPED
[INFO] Maven IT Plugin :: Class Loader :: Aggregator .. SKIPPED
[INFO] Maven IT Plugin :: Configuration ... SKIPPED
[INFO] Maven IT Plugin :: Context Passing . SKIPPED
[INFO] Maven ITs :: Core Plugin Stubs . SKIPPED
[INFO] Maven IT Clean Plugin Stub 0.1-stub-SNAPSHOT ... SKIPPED
[INFO] Maven IT Compiler Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
[INFO] Maven IT Deploy Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
[INFO] Maven IT EAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
[INFO] Maven IT EJB Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
[INFO] Maven IT Install Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
[INFO] Maven IT JAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
[INFO] Maven IT Javadoc Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
[INFO] Maven IT Plugin Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
[INFO] Maven IT RAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
[INFO] Maven IT Resources Plugin Stub 0.1-stub-SNAPSHOT ... SKIPPED
[INFO] Maven IT Site Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
[INFO] Maven IT Source Plugin Stub 0.1-stub-SNAPSHOT .. SKIPPED
[INFO] Maven IT Surefire Plugin Stub 0.1-stub-SNAPSHOT SKIPPED
[INFO] Maven IT WAR Plugin Stub 0.1-stub-SNAPSHOT . SKIPPED
[INFO] Maven IT Plugin :: Dependency Collection ... SKIPPED
[INFO] Maven IT Plugin :: Dependency Resolution ... SKIPPED
[INFO] Maven IT Plugin :: Expression .. SKIPPED
[INFO] Maven IT Plugin :: Error Mojos . SKIPPED
[INFO] Maven IT Component . SKIPPED
[INFO] Maven IT Plugin :: Extension Consumer .. SKIPPED
[INFO] Maven IT Plugin :: Extension Provider .. SKIPPED
[INFO] Maven IT Plugin :: Fork SKIPPED
[INFO] Maven IT Plugin :: Invalid Descriptor .. SKIPPED
[INFO] Maven IT Plugin :: Log File SKIPPED
[INFO] Maven IT Helper Library SKIPPED
[INFO] Maven IT Plugin :: Model Interpolation . SKIPPED
[INFO] Maven IT Plugin :: No Default Component SKIPPED
[INFO] Maven IT Plugin :: No Project .. SKIPPED
[INFO] Maven IT Plugin :: Online .. SKIPPED
[INFO] Maven IT Plugin :: Optional Mojos .. SKIPPED
[INFO] Maven IT Plugin :: Packaging ... SKIPPED
[INFO] Maven IT Plugin :: Parameter Implementation SKIPPED
[INFO] Maven IT Plugin :: Plugin Dependency ... SKIPPED
[INFO] Maven IT Plugin :: Project . SKIPPED
[INFO] Maven IT Plugin :: Project Interpolation ... SKIPPED
[INFO] Maven IT Plugin :: Setter .. SKIPPED
[INFO] Maven IT Plugin :: Singleton Component . SKIPPED
[INFO] Maven IT Plugin :: Site SKIPPED
[INFO] Maven IT Plugin :: Toolchain ... SKIPPED
[INFO] Maven IT Plugin :: Touch ... SKIPPED
[INFO] Maven IT Plugin :: Uses Properties Plugin .. SKIPPED
[INFO] Maven IT Plugin :: Uses Wagon Plugin ... SKIPPED
[INFO] Maven IT Plugin :: This plugin should contain the mojos needed by all
tests. SKIPPED
[INFO] Maven IT Plugin :: Plexus Utils 1.1 SKIPPED
[INFO] Maven IT Plugin :: Plexus Utils New SKIPPED
[INFO] Maven IT Plugin :: Plexus Component API SKIPPED
[INFO] Maven IT Plugin :: Log4J Client SKIPPED
[INFO] Maven IT Plugin :: Extension 1 . SKIPPED
[INFO] Maven IT Plugin :: Extension 2 . SKIPPED
[INFO] Maven IT Plugin :: Plexus Lifecycle
[jira] [Updated] (MNG-6049) Add behavior to filter resolved version ranges of an artifact
[
https://issues.apache.org/jira/browse/MNG-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6049:
--
Fix Version/s: (was: 3.6.0-candidate)
3.6.x-candidate
> Add behavior to filter resolved version ranges of an artifact
> -
>
> Key: MNG-6049
> URL: https://issues.apache.org/jira/browse/MNG-6049
> Project: Maven
> Issue Type: Improvement
> Components: core, Dependencies
>Reporter: Uwe Barthel
>Priority: Critical
> Fix For: 3.6.x-candidate
>
>
> The discussion on issue MNG-3092 shows the seriously needs of different kinds
> of version range resolving in Maven.
> This solution provides a hook for Maven extensions/plugins to change the list
> of resolved version range results as required.
> The {{DefaultVersionRangeResolver}} will be extended with a filter for
> version range results. A new interface {{VersionRangeResultFilter}} is added
> and a non-filtering {{DefaultVersionRangeResultFilter}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6399: -- Fix Version/s: (was: 3.6.0-candidate) 3.6.x-candidate > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.6.x-candidate > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6164) Collections inconsistently immutable
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6164:
--
Fix Version/s: (was: 3.6.0-candidate)
3.6.x-candidate
> Collections inconsistently immutable
>
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Christian Schulte
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> There are plenty of places where empty collections are returned from public
> API in methods written like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections.emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable.
> All those methods should return a collection with consistent "mutability":
> either mutable, either immutable.
> Given empty immutable collections do not cause harm until now, switching
> consistently to immutable collections is more conservative and should not be
> risky
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5971:
--
Fix Version/s: (was: 3.6.0-candidate)
3.6.x-candidate
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
> Fix For: 3.6.x-candidate
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5951) add an option to avoid path addition to inherited URLs
[
https://issues.apache.org/jira/browse/MNG-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5951:
--
Fix Version/s: (was: 3.6.0-candidate)
3.6.x-candidate
> add an option to avoid path addition to inherited URLs
> --
>
> Key: MNG-5951
> URL: https://issues.apache.org/jira/browse/MNG-5951
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.9
>Reporter: Jörg Sesterhenn
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.6.x-candidate
>
> Attachments: MNG-5951.zip
>
>
> What I am trying to achieve is
> the definition of a project.url in a parent pom
> in a way that all children inherit a url ending with
> {code}
> ${project.groupId}/${project.artifactId}/${project.version}/
> {code}
> in order to be able to publish sites of all artifacts in all versions in
> parallel
> without having to redefine the url in every child pom.
> This is currently not working as expected in maven due to the default child
> urls calculation which leads to urls that add up parent urls like
> http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
> The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
> child url calculation (those are the artifactIds of all parent poms beneath
> our enterprise parent pom where the url is defined) and *is expexted to not
> be there at all*. The repeated artifactID at the end of the url is
> superfluous as well but tollerable.
> I expect maven-core to be changed so that I can turn on/off the automatic
> calculation of child URLs as an option which is by default on (current
> behaviour so nothing will change unless configured explicitly).
> See the discussion in MSITE-672.
> As this can not be done in the maven-site-plugin there needs to be a change
> in Maven itself (core), in Maven Model Builder, ie the way effective model is
> calculated, and more precisely in the inheritance step:
> http://maven.apache.org/ref/current/maven-model-builder/.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6059) Important use cases not covered, as child.inherit.append.path affects all children
[
https://issues.apache.org/jira/browse/MNG-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6059:
--
Fix Version/s: (was: 3.6.0-candidate)
3.6.x-candidate
> Important use cases not covered, as child.inherit.append.path affects all
> children
> --
>
> Key: MNG-6059
> URL: https://issues.apache.org/jira/browse/MNG-6059
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
> Environment: Apache Maven 3.4.0-SNAPSHOT
> (227085283b6379038ec16f4cf9ad2e8869cef694; 2016-07-06T21:29:12+02:00)
>Reporter: Andreas Sewe
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.6.x-candidate
>
>
> The {{child.inherit.append.path}} attribute introduced with MNG-5951
> unfortunately does not support the use case where the children of the element
> with the attribute should follow different inheritance rules. Take a typical
> configuration for Github, for example (taken from
> ):
> {noformat}
>
>
> scm:git:git://github.com/simpligility/ossrh-demo.git
>
> scm:git:ssh://github.com:simpligility/ossrh-demo.git
> http://github.com/simpligility/ossrh-demo/tree/master
>
> {noformat}
> If the {{ossrh-demo.git}} repository contains a child module called
> {{some-module}}, then that child’s {{scm/url}} should become
> {{http://github.com/simpligility/ossrh-demo/tree/master/some-module}} as per
> the normal inheritance rules, but both the {{scm/connection}} and
> {{scm/developerConnection}} URLs should remain unchanged.
> Unfortunately, this is not possible with {{*child*.inherit.append.path}},
> which acts on all children simultaneously.
> IMHO, this is a conceptual problem. In particular, setting
> {{child.inherit.append.path}} on the *root* element to just control a single
> child ({{project/url}}) feels wrong, as the attribute is in all likelihood
> not even located close to the {{}} element it controls.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6169) Lifecycle/binding plugin version updates
[ https://issues.apache.org/jira/browse/MNG-6169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6169: -- Fix Version/s: (was: 3.6.0-candidate) 3.6.x-candidate > Lifecycle/binding plugin version updates > > > Key: MNG-6169 > URL: https://issues.apache.org/jira/browse/MNG-6169 > Project: Maven > Issue Type: Improvement > Components: core, Dependencies >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.6.x-candidate > > > Regular plugin update to absorb changes if plugin version is not specified in > the client POM. > ||groupId||artifactId||[previous > version|http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html]||target > version|| > |org.apache.maven.plugins |maven-clean-plugin|2.5|2.6.1| > |org.apache.maven.plugins |maven-site-plugin|3.3|3.6| > |org.apache.maven.plugins |maven-install-plugin|2.4|2.5.2| > |org.apache.maven.plugins |maven-deploy-plugin|2.7|2.8.2| > |org.apache.maven.plugins |maven-resources-plugin|2.6|3.0.2| > |org.apache.maven.plugins |maven-compiler-plugin|3.1|3.5.1| > |org.apache.maven.plugins |maven-surefire-plugin|2.12.4|2.20| > |org.apache.maven.plugins |maven-jar-plugin|2.4|3.0.2| > |org.apache.maven.plugins |maven-ejb-plugin|2.3|2.5.1| > |org.apache.maven.plugins |maven-plugin-plugin|3.2|3.3| > |org.apache.maven.plugins |maven-war-plugin|2.2|3.0.0| > |org.apache.maven.plugins |maven-ear-plugin|2.8|2.9.1| > |org.apache.maven.plugins |maven-rar-plugin|2.2|2.4| -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5761: -- Fix Version/s: (was: 3.6.0-candidate) 3.6.x-candidate > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 3.6.x-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6401) Cannot interpolate property in proxy port of settings.xml
[
https://issues.apache.org/jira/browse/MNG-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6401:
--
Fix Version/s: (was: 3.6.0-candidate)
3.6.x-candidate
> Cannot interpolate property in proxy port of settings.xml
> -
>
> Key: MNG-6401
> URL: https://issues.apache.org/jira/browse/MNG-6401
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.0, 3.5.3
>Reporter: KATADA Junya
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> If you use a property in proxy port of settings.xml, the property is not
> replaced and the port number is "0" instead of property value.
> My minimal demo about this problem is
> [here|https://github.com/jkatada/maven-property-demo].
> In my demo, export two environment variables as follows.
> {code}
> export MAVEN_PROXY_HOST_STRING=proxy.foo.com
> export MAVEN_PROXY_PORT_INT=18080
> {code}
> These variables are used in settings.xml for proxy settings.
> {code:xml}
>
> my_proxy
> true
> http
> ${env.MAVEN_PROXY_HOST_STRING}
> ${env.MAVEN_PROXY_PORT_INT}
> local.net|some.host.com
>
> {code}
> Execute maven-help-plugin to show effective settings.xml.
> {code}
> mvn help:effective-settings -X
> {code}
> The result is as follows.
> {code:xml}
>
> 0
> proxy.foo.com
> local.net|some.host.com
> my_proxy
>
> {code}
> `*${env.MAVEN_PROXY_HOST_STRING}*` is replaced with `*proxy.foo.com*`,
> but `*${env.MAVEN_PROXY_PORT_INT}*` is not replaced with `*18080*`.
> I found the following WARNING message in console.
> {code:java}
> [WARNING] Some problems were encountered while building the effective settings
> [WARNING] Unable to parse element 'port', must be an integer (position:
> END_TAG seen ...${env.MAVEN_PROXY_PORT_INT}... @12:47) caused
> by: java.lang.NumberFormatException: For input string:
> "${env.MAVEN_PROXY_PORT_INT}" @ /root/.m2/settings.xml, line 12, column 47
> {code}
> I think that the cause of this problem is to parse settings.xml before
> interpolation.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-1577) dependencyManagement does not work for transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-1577: -- Fix Version/s: (was: 3.6.0-candidate) 3.6.x-candidate > dependencyManagement does not work for transitive dependencies > -- > > Key: MNG-1577 > URL: https://issues.apache.org/jira/browse/MNG-1577 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0 >Reporter: Joerg Schaible >Priority: Major > Fix For: 2.0.6, 3.6.x-candidate > > Attachments: MNG-1577-trunk-final.patch, mng1577.patch, > mng1577a.patch, mng1577b.patch, mng1577c.patch, mng1577d.patch, > mng1577e-trunk.patch, mng1577e.patch, mng1577f.patch, mng1577trunk.patch, > site.patch > > > The dependencyManagement does not work for transient dependencies. The > specified version is ignored. > Use case: > Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT > and B-SNAPSHOT > Project A is child of Main and depends directly on commons-beanutils (version > inherited from Main) > Project B is child of Main and depends directly on commons-digester (version > inherited from Main) > Project C is child of Main and depends directly on A & B (versions inherited > from Main) > A is compiled and tests are run using commons-beanutils-1.7.0 > B is compiled and tests are run using commons-digester-1.6 and > commons-beanutils-1.6, since digester is dependend on this > C is compiled and tests are run using commons-beanutils-1.7.0 > Integration tests of B did not verify, that B is behaving as expected in this > scenario. B might fail with 1.7.0 and it is not even recognized. > If I add beanutils also as direct dependency to B, it works fine, but then > are transitive dependency useless. It should be possible to define at least > in the dependencyManagement, that the versions of transient dependencies also > defined in the dependencyManagement have priority. > - Jörg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5227:
--
Fix Version/s: (was: 3.6.0-candidate)
3.6.x-candidate
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: 3.6.x-candidate
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-4508) No way to avoid adding artifactId to site urls
[
https://issues.apache.org/jira/browse/MNG-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-4508:
--
Fix Version/s: (was: 3.6.0-candidate)
3.6.x-candidate
> No way to avoid adding artifactId to site urls
> --
>
> Key: MNG-4508
> URL: https://issues.apache.org/jira/browse/MNG-4508
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Richard van der Hoff
>Assignee: Hervé Boutemy
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> Currently, whenever a child pom inherits from a parent (and doesn't override
> the relevant settings), both project.url and
> project.distributionManagement.site.url have the name of the child artifact
> appended.
> It would be nice to be able to have something like
> {code:xml}
> scpexe://host/blah/${project.artifactId}/${project.version}
> {code}
> and have this inherited to all child poms in the obvious way.
> My usecase for this is that we have a single parent pom for all our projects,
> with useful settings such as distributionManagement, and I'd like to be able
> to deploy their sites to a single directory and have Apache generate me a
> directory listing for all the child projects. However, I curently have no way
> of releasing the parent project without obliterating the list of child
> projects.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6135:
--
Fix Version/s: (was: 3.6.0-candidate)
3.6.x-candidate
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.6.x-candidate
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6399: -- Fix Version/s: (was: 3.6.0) 3.6.0-candidate > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.6.0-candidate > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6215) 'mvn --encrypt-password' doesn't prompt in Git Bash
[
https://issues.apache.org/jira/browse/MNG-6215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6215:
--
Fix Version/s: (was: 3.5.x-candidate)
3.6.x-candidate
> 'mvn --encrypt-password' doesn't prompt in Git Bash
> ---
>
> Key: MNG-6215
> URL: https://issues.apache.org/jira/browse/MNG-6215
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.9
> Environment: git version 2.12.2.windows.2
> jdk 8u111
> windows 7 pro
>Reporter: Alex Pintilie
>Priority: Major
> Fix For: 3.6.x-candidate
>
> Attachments: screenshot.jpg
>
>
> When I try to encrypt a password with {{mvn --encrypt-password}} in the Git
> Bash, I get no prompt like in the windows command prompt. Instead I get some
> empty curly braces {} (see screenshot).
> {{git version 2.12.2.windows.2}}
> Regards,
> Alex
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5984) Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5984:
--
Fix Version/s: (was: 3.5.x-candidate)
3.6.x-candidate
> Maven core extension resolution ignores repositories from activeByDefault
> profiles in settings.xml
> --
>
> Key: MNG-5984
> URL: https://issues.apache.org/jira/browse/MNG-5984
> Project: Maven
> Issue Type: Bug
> Components: Profiles, Settings
>Affects Versions: 3.3.9
>Reporter: Gabriël Konat
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> When building a project with a core extension in {{.mvn/extensions.xml}},
> where the core extension is not installed locally but needs to be retrieved
> from a remote repository, profiles from {{settings.xml}} with repositories
> which are {{true}}, are ignored, failing
> the resolution of the core extension.
> If the profile is activated from within an {{activeProfiles}} section, they
> are not ignored and resolution succeeds.
> Concrete example:
> {code:xml|title=.mvn/extensions.xml}
>
>
>
> org.metaborg
> spoofax-maven-plugin-pomless
> 2.0.0-SNAPSHOT
>
>
> {code}
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
> true
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> {code}
> Results in failed resolution:
> {code:title=mvn -Dmaven.repo.local=.cleanmvnrepo clean verify}
> [WARNING] The POM for
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT is missing, no
> dependency information available
> [WARNING] Failed to read extensions descriptor
> /Users/gohla/spoofax/master/repo/spoofax-releng/sdf/org.metaborg.meta.lang.sdf/.mvn/extensions.xml:
> Plugin org.metaborg:spoofax-maven-plugin-pomless:2.0.0-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT
> {code}
> Whereas with the following settings file it succeeds to resolve the core
> extension:
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> add-metaborg-snapshot-repos
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5639:
--
Fix Version/s: (was: 3.5.x-candidate)
3.6.x-candidate
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Priority: Minor
> Fix For: 3.6.x-candidate
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6275:
--
Fix Version/s: (was: 3.5.x-candidate)
3.6.x-candidate
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Stephen Connolly
>Priority: Critical
> Fix For: 3.6.x-candidate
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5868:
--
Fix Version/s: (was: 3.5.x-candidate)
3.6.x-candidate
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> does not produce a failure
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.6.x-candidate
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-4463) Dependency management import should support version ranges.
[
https://issues.apache.org/jira/browse/MNG-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-4463:
--
Fix Version/s: (was: 3.5.x-candidate)
3.6.x-candidate
> Dependency management import should support version ranges.
> ---
>
> Key: MNG-4463
> URL: https://issues.apache.org/jira/browse/MNG-4463
> Project: Maven
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Maven 2.2.1
>Reporter: Rob ten Hove
>Priority: Major
> Fix For: 3.6.x-candidate
>
>
> Version ranges cannot be used for artifacts with {{import}} scope. If a
> version range is used for such an artifact, Maven cannot find it. Looking at
> the console output shows that it takes the version range as the version,
> without resolving it:
> {noformat}Downloading:
> http://some-repo/group/artifact/[1.0.0,2.0.0)/artifact-[1.0.0,2.0.0).pom{noformat}
> This is the POM snippet:
> {code:xml}
>
>
>
> group
> artifact
> [1.0.0,2.0.0)
>
> pom
> import
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6391) Printout version of last built module in reactor build
[
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6391:
--
Fix Version/s: (was: 3.5.x-candidate)
3.6.x-candidate
> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version
> printout but also the last built module.
> {code:java}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the
> version printout.
> Also this is not the order I configured the modules in the parent pom but I
> think this could be something on my side.
> {code:java}
>
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-4347) import-scoped dependencies of direct dependencies are not resolved using profile modifications from settings.xml
[ https://issues.apache.org/jira/browse/MNG-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-4347: -- Fix Version/s: (was: 3.5.x-candidate) 3.6.x-candidate > import-scoped dependencies of direct dependencies are not resolved using > profile modifications from settings.xml > > > Key: MNG-4347 > URL: https://issues.apache.org/jira/browse/MNG-4347 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies, General, > Profiles, Settings >Affects Versions: 2.2.1 >Reporter: John Casey >Priority: Critical > Fix For: 2.2.2, 3.6.x-candidate > > > Given: > * project A lists project B as a dependency > * project B lists project C as an import-scoped entry in dependencyManagement > * project B's dependency version for project C is a SNAPSHOT > * the user's settings.xml file modifies the definition of the central > repository to enable searching for SNAPSHOT artifacts. > When project A's dependency POMs are retrieved as part of collecting the > transitive dependency closure for A, B's project instance is built. During > this process, the POM for project C should be retrieved from central > (according to the modifications in settings.xml). However, the profile > information from the settings.xml is never applied to project B's POM, and > never modifies the central repository definition found there. Since the > default definition for the repository 'central' from the super POM has > snapshots disabled, project C's POM cannot be found, and the build fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-2893: -- Fix Version/s: (was: 3.5.x-candidate) 3.6.x-candidate > Update the DefaultPluginManager to not use a project depMan for controlling > it's transitive dependencies > > > Key: MNG-2893 > URL: https://issues.apache.org/jira/browse/MNG-2893 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: Jason van Zyl >Priority: Major > Fix For: 3.2.x, 3.6.x-candidate > > > An adjustment to MNG-1577. The classpath for plugins should not be affected > by a projects depMan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6209) inconsistent activation of components from multiple extensions=true plugins
[ https://issues.apache.org/jira/browse/MNG-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6209: -- Fix Version/s: (was: 3.5.x-candidate) 3.6.x-candidate > inconsistent activation of components from multiple extensions=true plugins > --- > > Key: MNG-6209 > URL: https://issues.apache.org/jira/browse/MNG-6209 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko >Priority: Major > Fix For: 3.6.x-candidate > > > This is a regression introduced by the fix for MNG-5742. When multiple > extensions=true plugins configured in the build, when mojos from one such > plugin are executed, components from other extensions are ignored. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6112: -- Fix Version/s: (was: 3.5.x-candidate) 3.6.x-candidate > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Priority: Major > Fix For: 3.6.x-candidate > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5359: -- Fix Version/s: (was: 3.5.x-candidate) 3.6.x-candidate > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar >Priority: Major > Fix For: 3.6.x-candidate > > Attachments: MNG-5359-IT.patch, binding-test.zip > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6114: -- Fix Version/s: (was: 3.5.x-candidate) 3.6.x-candidate > Elements from the global settings should be ordered before elements from the > user settings. > --- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Major > Fix For: 3.6.x-candidate > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6069) Migrate to non deprecated parts of Commons CLI
[
https://issues.apache.org/jira/browse/MNG-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6069:
--
Fix Version/s: (was: 3.5.x-candidate)
3.6.x-candidate
> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
> Issue Type: Improvement
> Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information"
> ).build()
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5600:
--
Fix Version/s: (was: 3.5.x-candidate)
3.6.x-candidate
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
>Priority: Major
> Fix For: 3.6.x-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6281) ArrayIndexOutOfBoundsException caused by pom.xml with invalid/duplicate XML
[ https://issues.apache.org/jira/browse/MNG-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6281: -- Fix Version/s: (was: 3.5.x-candidate) 3.6.x-candidate > ArrayIndexOutOfBoundsException caused by pom.xml with invalid/duplicate XML > --- > > Key: MNG-6281 > URL: https://issues.apache.org/jira/browse/MNG-6281 > Project: Maven > Issue Type: Sub-task > Components: POM >Affects Versions: 3.5.0 >Reporter: Robert Scholte >Priority: Major > Fix For: 3.6.x-candidate > > > This is a hard one to recognize and to reproduce, but there are cases where > (for unknown reasons) that the content of the XML is duplicated in the pom > file. > Up until version 3.5.0 this was not an issue, because the XML parser stopped > parsing once hitting the closing project-tag, ignoring any content afterwards. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6216: -- Fix Version/s: (was: 3.5.x-candidate) 3.6.x-candidate > ArrayIndexOutOfBoundsException 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 >Priority: Major > Fix For: 3.6.x-candidate > > 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 (v7.6.3#76005)
[jira] [Updated] (MNG-5527) Dependency management import should support relocations.
[
https://issues.apache.org/jira/browse/MNG-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5527:
--
Fix Version/s: (was: 3.5.x-candidate)
3.6.x-candidate
> Dependency management import should support relocations.
>
>
> Key: MNG-5527
> URL: https://issues.apache.org/jira/browse/MNG-5527
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Environment: maven-3.1.0
> Fedora 18 x86_64
>Reporter: Matous Jobanek
>Priority: Major
> Fix For: 3.6.x-candidate
>
>
> Consider the following scenario:
> {code:xml}
>
> 4.0.0
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
>
>
> new.groupId.bom
> my-artifactId-bom
> 2.0
>
>
>
> {code}
> {code:xml}
>
> 4.0.0
> my.project.groupId
> my-project
> 1.0
> war
>
>
>
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
> import
>
>
>
> ...
>
> {code}
> The expected result according to [1]:
> During building the "my-project" it should print the WARNING with the
> information about the relocation and it should be automatically redirected
> from old.groupId.bom:my-artifactId-bom:1.0 to
> new.groupId.bom:my-artifactId-bom:2.0 and use dependencies from the new pom.
> Actual results:
> There is no WARNING and no redirection to the new pom and maven is trying to
> obtain dependencies from the old pom (old.groupId.bom:my-artifactId-bom:1.0).
>
> Nevertheless, when the pom is declared as a "normal dependency" (not in the
> "dependencyManagement" part) it works without any problem - it prints the
> WARNING and redirects to the new pom, but this is not the case we are using.
> [1] http://maven.apache.org/guides/mini/guide-relocation.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6424) Upgrade plexus-interpolation to 1.25
[ https://issues.apache.org/jira/browse/MNG-6424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6424: -- Fix Version/s: (was: 3.5.4-candidate) 3.6.x-candidate > Upgrade plexus-interpolation to 1.25 > > > Key: MNG-6424 > URL: https://issues.apache.org/jira/browse/MNG-6424 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.5.4 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.6.x-candidate > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6383) ProjectBuilder unnecessarily rebuilds modules with ci-friendly versions
[
https://issues.apache.org/jira/browse/MNG-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6383:
--
Fix Version/s: (was: 3.5.4-candidate)
3.6.x-candidate
> ProjectBuilder unnecessarily rebuilds modules with ci-friendly versions
> ---
>
> Key: MNG-6383
> URL: https://issues.apache.org/jira/browse/MNG-6383
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Christoph Kunze
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.6.x-candidate
>
> Attachments: sample-project.tar.gz
>
>
> Consider a multi-module project that uses ci-friendly versions (i.e. the root
> pom declares ${revision}).
> While "scanning for projects", the DefaultProjectBuilder (build:347) uses a
> two-phase approach.
> 1) build:390 populates a set of interimResults and a projectIndex. The keys
> of the projectIndex take the form groupId:artifactId:packaging:version and
> the version always is the interpolated version (i.e. 1.0-SNAPSHOT rather than
> ${revision}).
> 2) build:573 calls initProject which in line 638 attempts to retrieve the
> previously constructed parent project from the projectIndex. However, the key
> used here still contains the uninterpolated version (i.e. ${revision}) so
> *the* *parent project is never found*. In line 652, the parent project is
> therefore constructed anew:
> {code:java}
> parent = build( parentPomFile, projectBuildingRequest ).getProject();
> {code}
> This is not only ineffective but also causes problems, e.g. if the parent
> imports a bom module from the same reactor, this leads to a warning "Failed
> to build parent project" and potential follow-up problems. Also, the maven
> assembly plugin seems to fail on such projects.
> *Details*
> - The ModelBuildingResult created in the first phase contains a list of
> modelIds. They key used to add an entry to the project index always
> corresponds to the *first* item in this list:
> {code:java}
> // DefaultProjectBuilder:436
> projectIndex.put( result.getModelIds().get( 0 ), project )
> {code}
> However, the key used to retrieve the entry during the processing of its
> child is the *second* element from the modelIds list:
> {code:java}
> // DefaultProjectBuilder:636
> String parentModelId = result.getModelIds().get( 1 );
> MavenProject parent = projects.get( parentModelId );
> {code}
> The list items are created by DefaultModelBuilder.build:244. First a
> "lineage" of the current module is built. Then the first element of the
> lineage, corresponding to the current module, gets interpolated. The other
> lineage items *do not get interpolated*, i.e. they still contain the
> placeholder version.
> The list of modelIds is then constructed from the lineage, leading to the
> first element having an interpolated version whereas all other elements have
> a placeholder version.
> {code:java}
> // DefaultModelBuilder:411
> for ( ModelData currentData : lineage )
> {
> String modelId = ( currentData != superData ) ? currentData.getId() : "";
> result.addModelId( modelId );
> {code}
> *Fix*
> One way to fix the issue might be to interpolate all elements of the lineage
> in DefaultModelBuilder.build:244, or to at least replace their versions.
> The following modification (hacky and probably faulty, for demonstration
> purpose only) fixed the issue for my project:
> {code:java}
> // model interpolation
> resultModel = interpolateModel( resultModel, request, problems );
> resultData.setModel( resultModel );
> /* new code starts here */
> if ( resultModel.getParent() != null )
> {
> final ModelData parentData = lineage.get( 1 );
> final Model interpolatedParent = interpolateModel( parentData.getModel(),
> request, problems );
> // parentData.setModel( interpolatedParent );
> parentData.setVersion( interpolatedParent.getVersion() );
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6096) Deprecate DefaultArtifactVersion class
[ https://issues.apache.org/jira/browse/MNG-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6096: -- Fix Version/s: (was: 3.5.4-candidate) 3.6.x-candidate > Deprecate DefaultArtifactVersion class > -- > > Key: MNG-6096 > URL: https://issues.apache.org/jira/browse/MNG-6096 > Project: Maven > Issue Type: Task > Components: core >Affects Versions: needing-scrub-3.4.0-fallout >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.6.x-candidate > > > The DefaultArtifactVersion class parses the version of the artifacts but in > many situations it does not work correctly. > Furthermore based on the references and hints given here: > https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6389) Move the toolchains model to a separate artifactId
[ https://issues.apache.org/jira/browse/MNG-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6389: -- Fix Version/s: (was: 3.5.4-candidate) 3.6.x-candidate > Move the toolchains model to a separate artifactId > -- > > Key: MNG-6389 > URL: https://issues.apache.org/jira/browse/MNG-6389 > Project: Maven > Issue Type: Improvement > Components: Toolchains >Affects Versions: 3.5.3 >Reporter: George Gastaldi >Priority: Major > Fix For: 3.6.x-candidate > > > Just as maven-model and maven-settings, it would be nice to have a > maven-toolchains artifactId containing only the model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6028) When a reactor build fails maven should include current goals in resume suggestion
[
https://issues.apache.org/jira/browse/MNG-6028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6028:
--
Fix Version/s: (was: 3.5.4-candidate)
3.6.x-candidate
> When a reactor build fails maven should include current goals in resume
> suggestion
> --
>
> Key: MNG-6028
> URL: https://issues.apache.org/jira/browse/MNG-6028
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Axel Fontaine
>Priority: Major
> Fix For: 3.6.x-candidate
>
>
> Start multiproject build at root with mvn clean install
> if module-a fails you currently get
> {noformat}[ERROR] After correcting the problems, you can resume the build
> with the command
> [ERROR] mvn -rf :module-a{noformat}
> to be able to easily copy-paste this it would be much nicer if the goals were
> already filled in:
> {noformat}[ERROR] After correcting the problems, you can resume the build
> with the command
> [ERROR] mvn clean install -rf :module-a{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6256) Maven script can break if "-f" path contains special characters
[
https://issues.apache.org/jira/browse/MNG-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6256:
--
Fix Version/s: (was: 3.5.4-candidate)
3.6.x-candidate
> Maven script can break if "-f" path contains special characters
>
>
> Key: MNG-6256
> URL: https://issues.apache.org/jira/browse/MNG-6256
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 10 with PowerShell
>Reporter: Christoph Etzel
>Priority: Major
> Fix For: 3.6.x-candidate
>
>
> Executing maven on Windows using the {{\-f}} or {{--file}} parameter to
> specify an alternate POM file can break the script if the path contains
> special characters.
> It was originally discovered on a Windows Jenkins instance with working
> directory located under C:\Program Files (x86)\Jenkins..
> Example:
> {code:java}mvn -f "folderWithClosing)Bracket/pomFolder"{code}
> Command line output: {{"Bracket/pomFolder" kann syntaktisch an dieser Stelle
> nicht verarbeitet werden.}}
> Just for fun: Starting calc from maven script using {{\-f}}
> {code:java}mvn -f " ' & start calc"{code}
> Command line output: {{POM file '}} and a new calculator process
> The bug was introduced with commit
> https://github.com/apache/maven/commit/f8ab2a650f32d5d87126d341d9bbfccbf99fd0ca
> for issue MNG-5889.
> Workaround: Use maven 3.3.9 or below
> Possible fix: Escape {{%FILE_ARG%}} and {{%POM_DIR%}} with {{"}} in {{echo}}
> commands in {{maven.cmd}} (line 120 and 129).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6372) On Windows with -T option, Maven can output spurious ANSI escapes such as [0m [0m
[
https://issues.apache.org/jira/browse/MNG-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6372:
--
Summary: On Windows with -T option, Maven can output spurious ANSI escapes
such as [0m [0m (was: On Windows with -T option, Maven can output spurios ANSI
escapes such as {{[0m [0m}})
> On Windows with -T option, Maven can output spurious ANSI escapes such as [0m
> [0m
> -
>
> Key: MNG-6372
> URL: https://issues.apache.org/jira/browse/MNG-6372
> Project: Maven
> Issue Type: New Feature
>Affects Versions: 3.5.3
>Reporter: Stephen Connolly
>Priority: Major
>
> Found during the release vote of Maven 3.5.3
> A regression introduced by the upgrade of JAnsi to 1.17. Rumoured fixed in
> 1.18
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6372) On Windows with -T option, Maven can output spurios ANSI escapes such as {{[0m [0m}}
Stephen Connolly created MNG-6372:
-
Summary: On Windows with -T option, Maven can output spurios ANSI
escapes such as {{[0m [0m}}
Key: MNG-6372
URL: https://issues.apache.org/jira/browse/MNG-6372
Project: Maven
Issue Type: New Feature
Affects Versions: 3.5.3
Reporter: Stephen Connolly
Found during the release vote of Maven 3.5.3
A regression introduced by the upgrade of JAnsi to 1.17. Rumoured fixed in 1.18
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6363) Remove secret thread configuration property from code
[
https://issues.apache.org/jira/browse/MNG-6363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6363:
--
Fix Version/s: (was: 3.5.3)
3.5.4
> Remove secret thread configuration property from code
> -
>
> Key: MNG-6363
> URL: https://issues.apache.org/jira/browse/MNG-6363
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.5.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> Currently the code of Maven core {{MavenCli}} contains something like this:
> {code:java}
> final String threadConfiguration = commandLine.hasOption(
> CLIManager.THREADS )
> ? commandLine.getOptionValue( CLIManager.THREADS )
> : request.getSystemProperties().getProperty(
> MavenCli.THREADS_DEPRECATED ); // TODO Remove this setting.
> Note that the int-tests use it
> {code}
> We should remove the {{THREADS_DEPRECATED}} part here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6364) Enhanced Jenkinsfile to Build Core with JDK 9
[ https://issues.apache.org/jira/browse/MNG-6364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6364: -- Fix Version/s: (was: 3.5.3) 3.5.4 > Enhanced Jenkinsfile to Build Core with JDK 9 > - > > Key: MNG-6364 > URL: https://issues.apache.org/jira/browse/MNG-6364 > Project: Maven > Issue Type: Improvement > Components: Bootstrap Build >Affects Versions: 3.5.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.5.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6362) Add documentation information for GitHub
[ https://issues.apache.org/jira/browse/MNG-6362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6362: -- Fix Version/s: (was: 3.5.3) 3.5.4 > Add documentation information for GitHub > > > Key: MNG-6362 > URL: https://issues.apache.org/jira/browse/MNG-6362 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.5.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.5.4 > > > Create an information page for GitHub users about contribution etc. > Things like: README.md, CONTRIBUTION.md, pull_request_template.md -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SUREFIRE-1477) CI support for parallel test execution
Stephen Connolly created SUREFIRE-1477:
--
Summary: CI support for parallel test execution
Key: SUREFIRE-1477
URL: https://issues.apache.org/jira/browse/SUREFIRE-1477
Project: Maven Surefire
Issue Type: New Feature
Reporter: Stephen Connolly
CI build servers often want to use multiple compute resources to reduce build
times in exchange for additional CPU costs.
One of the biggest consumers of build time is test execution, so much so that
people are often willing to run multiple builds in parallel on different
machines in order to get the total testing wall clock time lower.
For example:
[https://wiki.jenkins.io/display/JENKINS/Parallel+Test+Executor+Plugin]
It would be nice if surefire made all this easier and more CI system agnostic.
We already have some of this available:
[https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#runOrder]
has the option {{balanced}} that will use a statistics file
{{.surefire-X}} to distribute tests between different parallel worker
threads.
What is needed to make this better is the ability to use the {{balanced}} run
ordering across Maven JVMs.
If we had two system properties:
* {{surefire.mvnCount}}
* {{surefire.mvnOffset}}
Then surefire could use the {{balanced}} run order to deterministically decide
the ordered list of tests... it would then start at {{mvnOffset}} and run every
{{mvnCount}}th test.
CI users could then run three maven builds in parallel:
* {{mvn -Dsurefire.mvnCount=3 -Dsurefire.mvnOffset=0 test}}
* {{mvn -Dsurefire.mvnCount=3 -Dsurefire.mvnOffset=1 test}}
* {{mvn -Dsurefire.mvnCount=3 -Dsurefire.mvnOffset=2 test}}
This would ensure that all the tests are run once, but the wall clock time
should be best case approx 1/3th of the wall clock for the full build time
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-510) Investigate JavadocUtil.invokeMaven
Stephen Connolly created MJAVADOC-510: - Summary: Investigate JavadocUtil.invokeMaven Key: MJAVADOC-510 URL: https://issues.apache.org/jira/browse/MJAVADOC-510 Project: Maven Javadoc Plugin Issue Type: Task Reporter: Stephen Connolly Spotted while fine-tuning the Jenkinsfile builds. Unclear why Javadoc plugin needs to fork Maven and whether it is doing it the correct way if the requirement is actually valid. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MNG-6316) Dummy issue to check jira integration of jenkins
[ https://issues.apache.org/jira/browse/MNG-6316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MNG-6316. - Resolution: Won't Fix This issue has done it's job > Dummy issue to check jira integration of jenkins > > > Key: MNG-6316 > URL: https://issues.apache.org/jira/browse/MNG-6316 > Project: Maven > Issue Type: Bug >Affects Versions: wontfix-candidate >Reporter: Stephen Connolly >Priority: Trivial > > Dummy issue to check JIRA issue notification -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MNG-6316) Dummy issue to check jira integration of jenkins
Stephen Connolly created MNG-6316: - Summary: Dummy issue to check jira integration of jenkins Key: MNG-6316 URL: https://issues.apache.org/jira/browse/MNG-6316 Project: Maven Issue Type: Bug Affects Versions: wontfix-candidate Reporter: Stephen Connolly Priority: Trivial Dummy issue to check JIRA issue notification -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6255) Maven script cannot parse jvm.config with CRLF
[
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6255:
--
Fix Version/s: (was: 3.5.2)
> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will
> not parse it correctly. The script uses the {{tr}} command to change *LF* to
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (MNG-6255) Maven script cannot parse jvm.config with CRLF
[
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly reopened MNG-6255:
---
> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will
> not parse it correctly. The script uses the {{tr}} command to change *LF* to
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (MNG-6255) Maven script cannot parse jvm.config with CRLF
[
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly resolved MNG-6255.
---
Resolution: Fixed
Fix Version/s: 3.5.2
> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
> Fix For: 3.5.2
>
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will
> not parse it correctly. The script uses the {{tr}} command to change *LF* to
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6209) inconsistent activation of components from multiple extensions=true plugins
[ https://issues.apache.org/jira/browse/MNG-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6209: -- Fix Version/s: (was: 3.5.1) 3.5.x-candidate > inconsistent activation of components from multiple extensions=true plugins > --- > > Key: MNG-6209 > URL: https://issues.apache.org/jira/browse/MNG-6209 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.x-candidate > > > This is a regression introduced by the fix for MNG-5742. When multiple > extensions=true plugins configured in the build, when mojos from one such > plugin are executed, components from other extensions are ignored. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6275:
--
Fix Version/s: (was: 3.5.1)
3.5.x-candidate
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Stephen Connolly
>Priority: Critical
> Fix For: 3.5.x-candidate
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly reopened MNG-6275:
---
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Stephen Connolly
>Priority: Critical
> Fix For: 3.5.x-candidate
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly resolved MNG-6275.
---
Resolution: Fixed
Merged in master toward 3.5.1
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Stephen Connolly
>Priority: Critical
> Fix For: 3.5.1
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148765#comment-16148765 ] Stephen Connolly commented on MNG-6216: --- [~rfscholte] we need to decide whether to resolve this issue or not. I propose we resolve this issue and spin off a task to try and identify the root cause of the corrupted POMs > ArrayIndexOutOfBoundsException 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.4.14#64029)
[jira] [Updated] (MNG-6037) add gossip slf4j provider support
[ https://issues.apache.org/jira/browse/MNG-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6037: -- Fix Version/s: (was: wontfix-candidate) > add gossip slf4j provider support > - > > Key: MNG-6037 > URL: https://issues.apache.org/jira/browse/MNG-6037 > Project: Maven > Issue Type: New Feature > Components: Logging >Affects Versions: 3.3.9 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > > Gossip slf4j provider: https://github.com/jdillon/gossip > Jason Dillon provided a pull request https://github.com/apache/maven/pull/81 > this implementation adds color to level rendering and error rendering > I removed the message colorization support (that added color by recognizing > patterns in messages) from the logging implementation and implemented it > directly in messages in MNG-3507 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (MNG-5988) Dependency mediation should prioritize transitive dependencies based on scope.
[
https://issues.apache.org/jira/browse/MNG-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly reopened MNG-5988:
---
Assignee: (was: Christian Schulte)
Re-opening as not actually fixed after 3.5.0 reset
> Dependency mediation should prioritize transitive dependencies based on scope.
> --
>
> Key: MNG-5988
> URL: https://issues.apache.org/jira/browse/MNG-5988
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.3
>Reporter: Jostein Gogstad
>Priority: Critical
> Fix For: needing-scrub-3.4.0-fallout
>
> Attachments: Collected.svg, MNG-5988.zip, PRE.svg, Resolved.svg
>
>
> The
> [documentation|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]
> states that dependency mediation only supports "nearest definition",
> regardless of the scope of the parent dependency.
> If both compile- and test scoped dependencies shares the same transitive
> dependency, the test-scoped one will win if it has shallower depth. That in
> turn will lead to runtime exceptions since the transitive dependency is no
> longer on the classpath.
> Take the following pom from a typical [Spring
> Boot|http://projects.spring.io/spring-boot/] application. Since the
> {{camel-test-spring}} dependency also depends on spring, it wins and Spring
> is no longer available to the application at runtime.
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
> 4.0.0
> com.example
> bugreport
> jar
> 1.0.0-SNAPSHOT
>
>
> org.springframework.boot
> spring-boot-starter-web
> 1.3.2.RELEASE
>
>
> org.apache.camel
> camel-test-spring
> 2.16.2
> test
>
>
>
> {code}
> Now look for {{spring-beans}} or {{spring-context}} in the following
> dependency graphs:
> {code:xml|title=mvn dependency:tree (with camel-test-spring)}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ bugreport ---
> [INFO] com.example:bugreport:jar:1.0.0-SNAPSHOT
> [INFO] +-
> org.springframework.boot:spring-boot-starter-web:jar:1.3.2.RELEASE:compile
> [INFO] | +-
> org.springframework.boot:spring-boot-starter:jar:1.3.2.RELEASE:compile
> [INFO] | | +- org.springframework.boot:spring-boot:jar:1.3.2.RELEASE:compile
> [INFO] | | +-
> org.springframework.boot:spring-boot-autoconfigure:jar:1.3.2.RELEASE:compile
> [INFO] | | +-
> org.springframework.boot:spring-boot-starter-logging:jar:1.3.2.RELEASE:compile
> [INFO] | | | +- ch.qos.logback:logback-classic:jar:1.1.3:compile
> [INFO] | | | | \- ch.qos.logback:logback-core:jar:1.1.3:compile
> [INFO] | | | +- org.slf4j:jcl-over-slf4j:jar:1.7.13:compile
> [INFO] | | | +- org.slf4j:jul-to-slf4j:jar:1.7.13:compile
> [INFO] | | | \- org.slf4j:log4j-over-slf4j:jar:1.7.13:compile
> [INFO] | | \- org.yaml:snakeyaml:jar:1.16:runtime
> [INFO] | +-
> org.springframework.boot:spring-boot-starter-tomcat:jar:1.3.2.RELEASE:compile
> [INFO] | | +- org.apache.tomcat.embed:tomcat-embed-core:jar:8.0.30:compile
> [INFO] | | +- org.apache.tomcat.embed:tomcat-embed-el:jar:8.0.30:compile
> [INFO] | | +-
> org.apache.tomcat.embed:tomcat-embed-logging-juli:jar:8.0.30:compile
> [INFO] | | \-
> org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.0.30:compile
> [INFO] | +-
> org.springframework.boot:spring-boot-starter-validation:jar:1.3.2.RELEASE:compile
> [INFO] | | \- org.hibernate:hibernate-validator:jar:5.2.2.Final:compile
> [INFO] | | +- javax.validation:validation-api:jar:1.1.0.Final:compile
> [INFO] | | +- org.jboss.logging:jboss-logging:jar:3.2.1.Final:compile
> [INFO] | | \- com.fasterxml:classmate:jar:1.1.0:compile
> [INFO] | +- com.fasterxml.jackson.core:jackson-databind:jar:2.6.5:compile
> [INFO] | | +-
> com.fasterxml.jackson.core:jackson-annotations:jar:2.6.0:compile
> [INFO] | | \- com.fasterxml.jackson.core:jackson-core:jar:2.6.5:compile
> [INFO] | +- org.springframework:spring-web:jar:4.2.4.RELEASE:compile
> [INFO] | \- org.springframework:spring-webmvc:jar:4.2.4.RELEASE:compile
> [INFO] \- org.apache.camel:camel-test-spring:jar:2.16.2:test
> [INFO]+- org.apache.camel:camel-test:jar:2.16.2:test
> [INFO]| +- org.apache.camel:camel-core:jar:2.16.2:test
> [INFO]| | \- org.slf4j:slf4j-api:jar:1.6.6:compile
> [INFO]| \- junit:junit:jar:4.11:test
> [INFO]| \- org.hamcrest:hamcrest-core:jar:1.3:test
> [INFO]+- org.apache.camel:camel-spring:jar:2.16.2:test
> [INFO]+-
[jira] [Resolved] (MNG-6037) add gossip slf4j provider support
[ https://issues.apache.org/jira/browse/MNG-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly resolved MNG-6037. --- Resolution: Won't Fix > add gossip slf4j provider support > - > > Key: MNG-6037 > URL: https://issues.apache.org/jira/browse/MNG-6037 > Project: Maven > Issue Type: New Feature > Components: Logging >Affects Versions: 3.3.9 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: wontfix-candidate > > > Gossip slf4j provider: https://github.com/jdillon/gossip > Jason Dillon provided a pull request https://github.com/apache/maven/pull/81 > this implementation adds color to level rendering and error rendering > I removed the message colorization support (that added color by recognizing > patterns in messages) from the logging implementation and implemented it > directly in messages in MNG-3507 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5639:
--
Fix Version/s: (was: 3.5.1-candidate)
(was: 3.2.2)
3.5.x-candidate
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Priority: Minor
> Fix For: 3.5.x-candidate
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-2893: -- Fix Version/s: (was: 3.5.1-candidate) 3.5.x-candidate > Update the DefaultPluginManager to not use a project depMan for controlling > it's transitive dependencies > > > Key: MNG-2893 > URL: https://issues.apache.org/jira/browse/MNG-2893 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Fix For: 3.2.x, 3.5.x-candidate > > > An adjustment to MNG-1577. The classpath for plugins should not be affected > by a projects depMan. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-5527) Dependency management import should support relocations.
[
https://issues.apache.org/jira/browse/MNG-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5527:
--
Fix Version/s: (was: 3.5.1-candidate)
3.5.x-candidate
> Dependency management import should support relocations.
>
>
> Key: MNG-5527
> URL: https://issues.apache.org/jira/browse/MNG-5527
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Environment: maven-3.1.0
> Fedora 18 x86_64
>Reporter: Matous Jobanek
> Fix For: 3.5.x-candidate
>
>
> Consider the following scenario:
> {code:xml}
>
> 4.0.0
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
>
>
> new.groupId.bom
> my-artifactId-bom
> 2.0
>
>
>
> {code}
> {code:xml}
>
> 4.0.0
> my.project.groupId
> my-project
> 1.0
> war
>
>
>
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
> import
>
>
>
> ...
>
> {code}
> The expected result according to [1]:
> During building the "my-project" it should print the WARNING with the
> information about the relocation and it should be automatically redirected
> from old.groupId.bom:my-artifactId-bom:1.0 to
> new.groupId.bom:my-artifactId-bom:2.0 and use dependencies from the new pom.
> Actual results:
> There is no WARNING and no redirection to the new pom and maven is trying to
> obtain dependencies from the old pom (old.groupId.bom:my-artifactId-bom:1.0).
>
> Nevertheless, when the pom is declared as a "normal dependency" (not in the
> "dependencyManagement" part) it works without any problem - it prints the
> WARNING and redirects to the new pom, but this is not the case we are using.
> [1] http://maven.apache.org/guides/mini/guide-relocation.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6112: -- Fix Version/s: (was: 3.5.1-candidate) 3.5.x-candidate > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte > Fix For: 3.5.x-candidate > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5600:
--
Fix Version/s: (was: 3.5.1-candidate)
3.5.x-candidate
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
> Fix For: 3.5.x-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-4347) import-scoped dependencies of direct dependencies are not resolved using profile modifications from settings.xml
[ https://issues.apache.org/jira/browse/MNG-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-4347: -- Fix Version/s: (was: 3.5.1-candidate) 3.5.x-candidate > import-scoped dependencies of direct dependencies are not resolved using > profile modifications from settings.xml > > > Key: MNG-4347 > URL: https://issues.apache.org/jira/browse/MNG-4347 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies, General, > Profiles, Settings >Affects Versions: 2.2.1 >Reporter: John Casey >Priority: Critical > Fix For: 2.2.2, 3.5.x-candidate > > > Given: > * project A lists project B as a dependency > * project B lists project C as an import-scoped entry in dependencyManagement > * project B's dependency version for project C is a SNAPSHOT > * the user's settings.xml file modifies the definition of the central > repository to enable searching for SNAPSHOT artifacts. > When project A's dependency POMs are retrieved as part of collecting the > transitive dependency closure for A, B's project instance is built. During > this process, the POM for project C should be retrieved from central > (according to the modifications in settings.xml). However, the profile > information from the settings.xml is never applied to project B's POM, and > never modifies the central repository definition found there. Since the > default definition for the repository 'central' from the super POM has > snapshots disabled, project C's POM cannot be found, and the build fails. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-5984) Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5984:
--
Fix Version/s: (was: 3.5.1-candidate)
3.5.x-candidate
> Maven core extension resolution ignores repositories from activeByDefault
> profiles in settings.xml
> --
>
> Key: MNG-5984
> URL: https://issues.apache.org/jira/browse/MNG-5984
> Project: Maven
> Issue Type: Bug
> Components: Profiles, Settings
>Affects Versions: 3.3.9
>Reporter: Gabriël Konat
>Priority: Minor
> Fix For: 3.5.x-candidate
>
>
> When building a project with a core extension in {{.mvn/extensions.xml}},
> where the core extension is not installed locally but needs to be retrieved
> from a remote repository, profiles from {{settings.xml}} with repositories
> which are {{true}}, are ignored, failing
> the resolution of the core extension.
> If the profile is activated from within an {{activeProfiles}} section, they
> are not ignored and resolution succeeds.
> Concrete example:
> {code:xml|title=.mvn/extensions.xml}
>
>
>
> org.metaborg
> spoofax-maven-plugin-pomless
> 2.0.0-SNAPSHOT
>
>
> {code}
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
> true
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> {code}
> Results in failed resolution:
> {code:title=mvn -Dmaven.repo.local=.cleanmvnrepo clean verify}
> [WARNING] The POM for
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT is missing, no
> dependency information available
> [WARNING] Failed to read extensions descriptor
> /Users/gohla/spoofax/master/repo/spoofax-releng/sdf/org.metaborg.meta.lang.sdf/.mvn/extensions.xml:
> Plugin org.metaborg:spoofax-maven-plugin-pomless:2.0.0-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT
> {code}
> Whereas with the following settings file it succeeds to resolve the core
> extension:
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> add-metaborg-snapshot-repos
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5359: -- Fix Version/s: (was: 3.5.1-candidate) 3.5.x-candidate > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar > Fix For: 3.5.x-candidate > > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6114: -- Fix Version/s: (was: 3.5.1-candidate) 3.5.x-candidate > Elements from the global settings should be ordered before elements from the > user settings. > --- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte > Fix For: 3.5.x-candidate > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6069) Migrate to non deprecated parts of Commons CLI
[
https://issues.apache.org/jira/browse/MNG-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6069:
--
Fix Version/s: (was: 3.5.1-candidate)
3.5.x-candidate
> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
> Issue Type: Improvement
> Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.x-candidate
>
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information"
> ).build()
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148748#comment-16148748 ] Stephen Connolly commented on MNG-6216: --- I've merged https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=c9a288d8b1090fa957d6caccc12f0bf13bb5e267 given that the build passed > ArrayIndexOutOfBoundsException 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.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148733#comment-16148733 ] Stephen Connolly commented on MNG-6216: --- [~rfscholte] were you running parallel builds or two maven sessions concurrently? (Perhaps your IDE was downloading POMs concurrently with your maven CLI build?) The rebased https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/MNG-6216/5/pipeline which has the plexus update should handle the doubled pom's (though it would be good to find out where they were originating) I am now wondering if there could be some IDE background downloading and not doing in a concurrent safe way > ArrayIndexOutOfBoundsException 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.4.14#64029)
[jira] [Closed] (MNG-6195) Use consistent quoting forms in mvn launcher script
[
https://issues.apache.org/jira/browse/MNG-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MNG-6195.
-
> Use consistent quoting forms in mvn launcher script
> ---
>
> Key: MNG-6195
> URL: https://issues.apache.org/jira/browse/MNG-6195
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.0-alpha-1, 3.5.0-beta-1
>Reporter: Stephen Connolly
>Assignee: Stephen Connolly
> Fix For: 3.5.0
>
>
> We have different forms of quoting in the shell script. We should pick a
> consistent policy and follow that.
> Specific areas of concern around backticks and {{$(...)}}
> Solaris 10 is known to have a true BourneShell which does not understand
> {{$(...)}} but the backtick style is very hard to quote effectively
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148700#comment-16148700 ] Stephen Connolly edited comment on MNG-6216 at 8/31/17 9:17 AM: [~mttjj] What mirror software are you using? There are some mirrors available that have a "feature" to rewrite the pom.xml on the fly and remove and inject things in the poms, e.g. removing the section or even injecting a replacement one. IIRC neither nexus nor archivia have that "feature" (or if they have the feature they do not have it enabled by default) but if you are using the other one, it may be a useful data-point was (Author: stephenc): What mirror software are you using? There are some mirrors available that have a "feature" to rewrite the pom.xml on the fly and remove and inject things in the poms, e.g. removing the section or even injecting a replacement one. IIRC neither nexus nor archivia have that "feature" (or if they have the feature they do not have it enabled by default) but if you are using the other one, it may be a useful data-point > ArrayIndexOutOfBoundsException 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.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148700#comment-16148700 ] Stephen Connolly commented on MNG-6216: --- What mirror software are you using? There are some mirrors available that have a "feature" to rewrite the pom.xml on the fly and remove and inject things in the poms, e.g. removing the section or even injecting a replacement one. IIRC neither nexus nor archivia have that "feature" (or if they have the feature they do not have it enabled by default) but if you are using the other one, it may be a useful data-point > ArrayIndexOutOfBoundsException 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.4.14#64029)
[jira] [Commented] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148694#comment-16148694
]
Stephen Connolly commented on MNG-6275:
---
Pulling back in scope for 3.5.1 as we look to have a candidate viable fix:
https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/activity?branch=mng-6275
https://github.com/apache/maven/compare/mng-6275
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 3.5.1
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly reassigned MNG-6275:
-
Assignee: Stephen Connolly (was: Robert Scholte)
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Stephen Connolly
>Priority: Critical
> Fix For: 3.5.1
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
