[jira] [Commented] (MNG-5305) Deprecate relativePath
[ https://issues.apache.org/jira/browse/MNG-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15348030#comment-15348030 ] Reto Gmür commented on MNG-5305: I figured the build pom would be generated and reside in the repos, I still think its an unnecessary increase of complexity. So far I haven't seen any compelling usecase where a relative path is necessary (i.e. things couldn't also be implemented just having the version number of the parent). > Deprecate relativePath > -- > > Key: MNG-5305 > URL: https://issues.apache.org/jira/browse/MNG-5305 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Reto Gmuer > Labels: close-pending > > The concept of relativePath is alien to the overall Maven design of having > project directory that only depends on entities in the repositories. With > relative-paths the build might yield to different results depending on were a > project folder is located in the local filesystem. > The parent POM resolution was changed in Maven 3. Because of this explicit > relativePaths need to be specified more often for reactor builds to be built > in the correct order. The reason for this (according to Maven 3.x > compatibility note) is to improve consistency: "In Maven 2, building the > child project in isolation could fail while the reactor build would succeed > to resolve the parent.". However this behaviour is inconsistent with the > resolution of the other dependencies, in fact the above is true for any Maven > version when a dependency that is part of the reactor is not available in a > suitable versions in the repository: in this case the build of the individual > project fails while the build of the whole reactor succeeds. > Because of this relativePath should be marked as deprecated and the parent > should be treated like a dependency when computing the build order of reactor > projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5305) Deprecate relativePath
[
https://issues.apache.org/jira/browse/MNG-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15341986#comment-15341986
]
Robert Scholte commented on MNG-5305:
-
So I caused some confusion. So let me be more clear: when splitting it up, you
will only work with the build-pom, it is still called {{pom.xml}}. The
distribution-pom is *generated* based on the build-pom and will end up in the
repositories. The end-user won't notice any difference in its build process.
> Deprecate relativePath
> --
>
> Key: MNG-5305
> URL: https://issues.apache.org/jira/browse/MNG-5305
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Reto Gmuer
> Labels: close-pending
>
> The concept of relativePath is alien to the overall Maven design of having
> project directory that only depends on entities in the repositories. With
> relative-paths the build might yield to different results depending on were a
> project folder is located in the local filesystem.
> The parent POM resolution was changed in Maven 3. Because of this explicit
> relativePaths need to be specified more often for reactor builds to be built
> in the correct order. The reason for this (according to Maven 3.x
> compatibility note) is to improve consistency: "In Maven 2, building the
> child project in isolation could fail while the reactor build would succeed
> to resolve the parent.". However this behaviour is inconsistent with the
> resolution of the other dependencies, in fact the above is true for any Maven
> version when a dependency that is part of the reactor is not available in a
> suitable versions in the repository: in this case the build of the individual
> project fails while the build of the whole reactor succeeds.
> Because of this relativePath should be marked as deprecated and the parent
> should be treated like a dependency when computing the build order of reactor
> projects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5305) Deprecate relativePath
[ https://issues.apache.org/jira/browse/MNG-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15341738#comment-15341738 ] Reto Gmür commented on MNG-5305: I see no compelling reason why multi-module build cannot be implemented without the relative-path and without depending on the artifacts being available. The parent can be considered in the build-order like a dependency. Splitting build-pom and distribution-poms makes things unnecessarily more complex. Having to update parent-vesion number is something that can easily be automated in a reactor. Leaving out the version number as [~rfscholte] suggests would promote a policy of keeping all modules with synced version numbers and always releasing everything together, I think this is an anti-pattern as it promotes unnecessary releases of modules and ultimately leads to less modular architectures as the advantage of having frequently updated semantically versioned modules gets lost. > Deprecate relativePath > -- > > Key: MNG-5305 > URL: https://issues.apache.org/jira/browse/MNG-5305 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Reto Gmuer > Labels: close-pending > > The concept of relativePath is alien to the overall Maven design of having > project directory that only depends on entities in the repositories. With > relative-paths the build might yield to different results depending on were a > project folder is located in the local filesystem. > The parent POM resolution was changed in Maven 3. Because of this explicit > relativePaths need to be specified more often for reactor builds to be built > in the correct order. The reason for this (according to Maven 3.x > compatibility note) is to improve consistency: "In Maven 2, building the > child project in isolation could fail while the reactor build would succeed > to resolve the parent.". However this behaviour is inconsistent with the > resolution of the other dependencies, in fact the above is true for any Maven > version when a dependency that is part of the reactor is not available in a > suitable versions in the repository: in this case the build of the individual > project fails while the build of the whole reactor succeeds. > Because of this relativePath should be marked as deprecated and the parent > should be treated like a dependency when computing the build order of reactor > projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5305) Deprecate relativePath
[ https://issues.apache.org/jira/browse/MNG-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337780#comment-15337780 ] Robert Scholte commented on MNG-5305: - With maven-3.x the build-pom(used to build) and distribution-pom(being uploaded) are exactly the same. If we decide to split this is in the next major version of Maven, it is not the parents relativePath but the parents version in the build-pom which becomes obsolete in case of a multimodule project. In the distribution-pom the relative path should be removed and the version of the parent should be added, because only with coordinates it is possible to do resolution. > Deprecate relativePath > -- > > Key: MNG-5305 > URL: https://issues.apache.org/jira/browse/MNG-5305 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Reto Gmuer > Labels: close-pending > > The concept of relativePath is alien to the overall Maven design of having > project directory that only depends on entities in the repositories. With > relative-paths the build might yield to different results depending on were a > project folder is located in the local filesystem. > The parent POM resolution was changed in Maven 3. Because of this explicit > relativePaths need to be specified more often for reactor builds to be built > in the correct order. The reason for this (according to Maven 3.x > compatibility note) is to improve consistency: "In Maven 2, building the > child project in isolation could fail while the reactor build would succeed > to resolve the parent.". However this behaviour is inconsistent with the > resolution of the other dependencies, in fact the above is true for any Maven > version when a dependency that is part of the reactor is not available in a > suitable versions in the repository: in this case the build of the individual > project fails while the build of the whole reactor succeeds. > Because of this relativePath should be marked as deprecated and the parent > should be treated like a dependency when computing the build order of reactor > projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5305) Deprecate relativePath
[
https://issues.apache.org/jira/browse/MNG-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15336855#comment-15336855
]
Christian Schulte commented on MNG-5305:
If you add an empty {{}} element to your {{}}
declarations, you get the behaviour you are asking for. There are use cases the
{{}} is needed for. That is checking out a multi module project
and executing some phase from the default lifecycle before {{install}}. We need
to support {{mvn compile}} or {{mvn verify}} without any of the artifacts being
available in some repository (local or remote). I see no issue with searching a
parent pom on disk. It's documented and people should just know what they do. I
think Maven is doing the right thing here. If you checkout only a single
module, it will resolve the parent(s) from the repository, if you checkout the
complete multi-module project it will resolve the parent(s) from that project
structure.
> Deprecate relativePath
> --
>
> Key: MNG-5305
> URL: https://issues.apache.org/jira/browse/MNG-5305
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Reto Gmuer
>
> The concept of relativePath is alien to the overall Maven design of having
> project directory that only depends on entities in the repositories. With
> relative-paths the build might yield to different results depending on were a
> project folder is located in the local filesystem.
> The parent POM resolution was changed in Maven 3. Because of this explicit
> relativePaths need to be specified more often for reactor builds to be built
> in the correct order. The reason for this (according to Maven 3.x
> compatibility note) is to improve consistency: "In Maven 2, building the
> child project in isolation could fail while the reactor build would succeed
> to resolve the parent.". However this behaviour is inconsistent with the
> resolution of the other dependencies, in fact the above is true for any Maven
> version when a dependency that is part of the reactor is not available in a
> suitable versions in the repository: in this case the build of the individual
> project fails while the build of the whole reactor succeeds.
> Because of this relativePath should be marked as deprecated and the parent
> should be treated like a dependency when computing the build order of reactor
> projects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
