Maven 1
  1. Maven 1
  2. MAVEN-1390

POM example <extends> doco is non-portable

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      In the documentation for the POM, the example includes:

      <extends>$

      {basedir}

      /../project.xml</extends>

      which will wreak havoc on any attempts to use the pom without having the parent project's files on hand. This means that this pom is next to useless, unless we can first checkout the parent project from scm or somesuch. The scm info is in the POM, so you see a circle beginning to emerge...

      We should change this example to be:

      <extends>$

      {maven.repo.local}

      /$

      {pom.groupId}

      /poms/$

      {pom.id}

      -$

      {pom.currentVersion}

      .pom</extends>

      where all pom.* values are filled in manually with the actual values.

        Issue Links

          Activity

          Hide
          Jörg Schaible added a comment -

          And how would you develop in a multiproject? If someone checks out from the repository, he has no "parent" pom in the local repo, nor is it copied there.

          Show
          Jörg Schaible added a comment - And how would you develop in a multiproject? If someone checks out from the repository, he has no "parent" pom in the local repo, nor is it copied there.
          Hide
          Trygve Laugstøl added a comment -

          I don't think we should change the behaviour of maven that much. We could enforce the idea that John Casey came up with when uploading artifacts so that the <extend> element it changes to the form that was suggested.

          Show
          Trygve Laugstøl added a comment - I don't think we should change the behaviour of maven that much. We could enforce the idea that John Casey came up with when uploading artifacts so that the <extend> element it changes to the form that was suggested.
          Hide
          Brett Porter added a comment -

          Joerg: it's chicken and the egg. If we add a dependency to the project it would be downloaded, but dependencies aren't done until the extended element is read.

          That issue would need to be resolved some way.

          Show
          Brett Porter added a comment - Joerg: it's chicken and the egg. If we add a dependency to the project it would be downloaded, but dependencies aren't done until the extended element is read. That issue would need to be resolved some way.
          Hide
          Jörg Schaible added a comment -

          Brett: Then why not deploy the resolved POM? No expand problem, no entity headache and anything is included and does not have to reference any external file.

          Show
          Jörg Schaible added a comment - Brett: Then why not deploy the resolved POM? No expand problem, no entity headache and anything is included and does not have to reference any external file.
          Hide
          Brett Porter added a comment -

          not compatible with the long term goal of building the structure from POMs that reside in the repository.

          Show
          Brett Porter added a comment - not compatible with the long term goal of building the structure from POMs that reside in the repository.
          Hide
          Jörg Schaible added a comment -

          But then you have to prevent people using entities or properties in a POM at all:

          <version>&my-comp-version;</version>

          is as evil than

          <version>$

          {my.comp.version}

          </version>

          Maybe it's just me, but I cannot follow the argumentation. Why does a resolved POM (i.e. no external references at all and all inherited tags embedded) interfere with that long term goal? The deployed POM would contain any information.

          Show
          Jörg Schaible added a comment - But then you have to prevent people using entities or properties in a POM at all: <version>&my-comp-version;</version> is as evil than <version>$ {my.comp.version} </version> Maybe it's just me, but I cannot follow the argumentation. Why does a resolved POM (i.e. no external references at all and all inherited tags embedded) interfere with that long term goal? The deployed POM would contain any information.
          Hide
          Jörg Schaible added a comment -

          duplicated now by MPPOM-4 and would also resolve MPPOM-1

          Show
          Jörg Schaible added a comment - duplicated now by MPPOM-4 and would also resolve MPPOM-1
          Hide
          Brett Porter added a comment -

          that's a tangent to the original issue.

          Yes, entities should be resolved if they are supported.

          Show
          Brett Porter added a comment - that's a tangent to the original issue. Yes, entities should be resolved if they are supported.
          Hide
          John Casey added a comment -

          Even if we're writing a clean, "standalone" pom to the repo, there is still the portability question for the sources themselves.

          A good example of the failing of ../project.xml is in the old jakarta-commons stuff. It's not like this anymore, but it used to be that you had to co the entire jarkarta-commons module (or at least the root of the module) in order to build any of the subprojects. This is simply an unwieldy way of doing things, and should be discouraged regardless of what we decide to do with pom:install and pom:deploy.

          Entities should be left out of the equation IMO, but they are currently the best solution in some cases, and if you're bent on using them then the entity definition file should be in the project root, because this file will not be deployed to any repo and will lead to the extends problem all over again if in ../deps.ent f.e. However, if you follow that rule, then all should be well with entities.

          We should also be dealing with "best practices" relating to entities in the doco, once we get MPPOM-4 figured out. I know some people hate the idea of using entities, but they're the cleanest solution without having transitive dep resolution in place. Instead of banning them, and dealing with a "black market" we need to address them and state a concrete position and usage rule in the documentation - legalize and tax, so to speak.

          These issues - MPPOM-4 and this one - are not in competition, I think, but complementary.

          Show
          John Casey added a comment - Even if we're writing a clean, "standalone" pom to the repo, there is still the portability question for the sources themselves. A good example of the failing of ../project.xml is in the old jakarta-commons stuff. It's not like this anymore, but it used to be that you had to co the entire jarkarta-commons module (or at least the root of the module) in order to build any of the subprojects. This is simply an unwieldy way of doing things, and should be discouraged regardless of what we decide to do with pom:install and pom:deploy. Entities should be left out of the equation IMO, but they are currently the best solution in some cases, and if you're bent on using them then the entity definition file should be in the project root, because this file will not be deployed to any repo and will lead to the extends problem all over again if in ../deps.ent f.e. However, if you follow that rule, then all should be well with entities. We should also be dealing with "best practices" relating to entities in the doco, once we get MPPOM-4 figured out. I know some people hate the idea of using entities, but they're the cleanest solution without having transitive dep resolution in place. Instead of banning them, and dealing with a "black market" we need to address them and state a concrete position and usage rule in the documentation - legalize and tax, so to speak. These issues - MPPOM-4 and this one - are not in competition, I think, but complementary.
          Hide
          Arik Kfir added a comment -

          I disagree. I wouldn't ban entities, but I think the correct solution to project inheritance is stating its parent project group+artifact IDs. Something like:
          <project>
          <extend>
          <groupId>parentProjectGroup</groupId>
          <artifactId>parentProjectArtifact</artifactId>
          <version>not sure about this...</version>
          </extend>
          ...
          </project>

          I believe a POM should be composed of a single file - it is not a source code that can use "#include" statements (borrowing some c syntax : it is a POM. A descriptor. Something else, and should be contained so that it can be passed around freely. It CAN however contain links to other "beings" such as dependencies, parent projects, etc.

          Anyway, that's how we view things over here, and frankly, we'd hate maven to ignore this issue and simply solve it by using entities - we would love to see some sort of declarative inheritance in maven - it's like a big chunk of a puzzle...

          Cheers..

          Show
          Arik Kfir added a comment - I disagree. I wouldn't ban entities, but I think the correct solution to project inheritance is stating its parent project group+artifact IDs. Something like: <project> <extend> <groupId>parentProjectGroup</groupId> <artifactId>parentProjectArtifact</artifactId> <version>not sure about this...</version> </extend> ... </project> I believe a POM should be composed of a single file - it is not a source code that can use "#include" statements (borrowing some c syntax : it is a POM. A descriptor. Something else, and should be contained so that it can be passed around freely. It CAN however contain links to other "beings" such as dependencies, parent projects, etc. Anyway, that's how we view things over here, and frankly, we'd hate maven to ignore this issue and simply solve it by using entities - we would love to see some sort of declarative inheritance in maven - it's like a big chunk of a puzzle... Cheers..
          Hide
          Brett Porter added a comment -

          now that we deploy the resolved pom, this is unnecessary for that use case.

          It's still an issue for checking out projects in isolation, but the feature is present in m2.

          Show
          Brett Porter added a comment - now that we deploy the resolved pom, this is unnecessary for that use case. It's still an issue for checking out projects in isolation, but the feature is present in m2.

            People

            • Assignee:
              Unassigned
              Reporter:
              John Casey
            • Votes:
              2 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: