exported pom.xml should contain full pom information

Details

  • Type: Wish Wish
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0-alpha-1
  • Fix Version/s: 2.0-alpha-3
  • Component/s: None
  • Labels:
    None

Description

When you install a module in the local repo the pom.xml file is copied (it's also included in jars). That's very good. However if my project is a module (i.e it depends on some parent(s)), the pom.xml that is dumped only contains partial information (it does not contain inherited information).

Thus it can be used standalone and does not offer all the information there is about the module.

As the pom is fully constructed in memory, it would be nice to dump it from memory instead of copying the pom.xml file.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Joerg Schaible added a comment -

Just for reference:
MAVEN-1390
MPPOM-4

Show
Joerg Schaible added a comment - Just for reference: MAVEN-1390 MPPOM-4
Hide
Permalink
Michal Maczka added a comment -

I also think that this is a way to go.

Say we have parent project P1 and child project P2.

There are two possible sources of errors here:

a) P2 pom is deployed to repository and P1 pom is missing there (from my experience this happens very often).
b) P1 and P2 are both in the snapshot state. P1 and P2 poms are deployed to repository, then P1 pom
is changed (e.g. some dependencies are upgraded) and then re-deployed to the repository.
After that operation P2 pom in the repository will be also indirectly changed.
It is questionable if this is a desired thing. Taking into the consideration the fact that we have
multilevel inheritance it can easily lead to the problems which are difficult to detect and it can break builds which would work if "expanded" poms were deployed to the repository.

Other reasons why this is a good idea:

  • It should be easy to write a tool which reuses m2 repository metadata. Project inheritance in m2 is very complex and is mostly irrelevant for such tools. So this will help to widespread the acceptance of poms as the artifact repository metadata.
  • Process of resolving transitive dependencies should be fast. So it would be better if less operations for building "full poms" were needed. This can be addressed in m2 in a different way (e.g. local database of POMs can be build) but again such thing for efficiency must be reimplemented by any other tools.
Show
Michal Maczka added a comment - I also think that this is a way to go. Say we have parent project P1 and child project P2. There are two possible sources of errors here: a) P2 pom is deployed to repository and P1 pom is missing there (from my experience this happens very often). b) P1 and P2 are both in the snapshot state. P1 and P2 poms are deployed to repository, then P1 pom is changed (e.g. some dependencies are upgraded) and then re-deployed to the repository. After that operation P2 pom in the repository will be also indirectly changed. It is questionable if this is a desired thing. Taking into the consideration the fact that we have multilevel inheritance it can easily lead to the problems which are difficult to detect and it can break builds which would work if "expanded" poms were deployed to the repository. Other reasons why this is a good idea:
  • It should be easy to write a tool which reuses m2 repository metadata. Project inheritance in m2 is very complex and is mostly irrelevant for such tools. So this will help to widespread the acceptance of poms as the artifact repository metadata.
  • Process of resolving transitive dependencies should be fast. So it would be better if less operations for building "full poms" were needed. This can be addressed in m2 in a different way (e.g. local database of POMs can be build) but again such thing for efficiency must be reimplemented by any other tools.
Hide
Permalink
Brett Porter added a comment -

decision on this:

resolved in the JAR: yes
resolved in the repository: no

why? references to SNAPSHOT data will get out of date. Can't see a use case for doing this in the actual repository other than reproducibility, but you can make a release which will resolve versions for that.

Show
Brett Porter added a comment - decision on this: resolved in the JAR: yes resolved in the repository: no why? references to SNAPSHOT data will get out of date. Can't see a use case for doing this in the actual repository other than reproducibility, but you can make a release which will resolve versions for that.

People

  • Assignee:
    John Casey
    Reporter:
    Vincent Massol
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: