POM example <extends> doco is non-portable

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.

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.

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.

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.

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

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>$

</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.

that's a tangent to the original issue.

Yes, entities should be resolved if they are supported.

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.

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..

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.