Maven 2 & 3

It doesn't need to be a complex project structure for this to cause pain.
I would like to set up a parent POM that can be inherited by all my projects so that I can specify common paths for them.

But if the scm.connection for my head of each of my projects is : http://MyMachine/svn/MyProject/trunk (which follows the Subversion convention) How do I specify this in the parent POM?
It will always append the artifactId to my Url causing it to fail.

Same goes for most of the other Urls.

If the auto replacement was switched off, then we could use explicit property replacement in the parent POM to clearly define our needs.

I realise I wasn't as clear in my comment above as I could have been. So I'll try again.

I want to be able to deploy the sites for my projects in a versioned manner.
Ie I want to retain the sites of all previously released versions of my components.
I imagine the structure for the web site to look something like :

/SomeProject/1.0
/SomeProject/1.1
/Anotherproject/1.0
/Anotherproject/2.0

etc

I also want to keep my POMs as clear and simple as possible, so I try and put as much common configuration in the common parent POM.
But the values for project#url and project#distributionManagement#site#url specified in the parent (and not overridden in the child) will automatically have the artifactId of the child appended to them. So there is no way to achieve the folder structure specified above using any kind of url statement in the parent POM.

I think Maven needs to stop automatically appending ${artifactId} to the url and site#url of the parent POM and instead encourage specification use of the actual url that is required, eg
http://myhost/maven-projects/${artifactId}/${version}
or whatever is required.

Now I believe versioned sites is something that the Maven group as a whole was planning on doing themselves, so this looks like an area that needs to be resolved.

The work around for this is top specify the project#url and project#distributionManangement#site#url in every POM.
Failure to do so means that :

If your parent POM defines its URLs as http://MyMachine/projects then the child projects will be published to reachable (but unversioned) locations such as http://MyMachine/projects/SomeProject on the projects site, but the site for the parent POM will be published to the root of your projects site, generally overwriting any general welcome page that might direct you to the other projects.

If your parent POM defines its URLs as http://MyMachine/projects/${artifactId} then the child projects will be published to locations such as http://MyMachine/projects/SomeProject/SomeProject but the parent POM will get published to an expected location like http://MyMachine/projects/MyPom.

So there is also inconsistency between a URL defined in a POM and one defined in a parent POM.
Please, please make it consistent, preferably by having no automatic appending of the artifactId for URLs defined in a parent POM and instead let us specify the location using build properties like http://MyMachine/projects/${artifactId}/${version} which are evaluated just like every other build property. The current behaviour is inconsistent with every other aspect of a Maven build.

If the URL is not inherited, you must define it in any child POM anyway, so your comments make not much sense to me. For me the only useful default is the path that was chosen in the SCM. This applies also if you add the version to the path.

Sorry Jorge, you lost me.

The URL is inherited (if it is not specified in the child POM), but at execution time (in the child) it becomes the inherited URL with the ${artifactId} specified in the child POM appended to it.

So deployment of the site for the parent POM is to an entirely different location (the root of the projects website) than for any children.
Ie there is no consistent site deployment location available to the parent POM and child projects.

IMHO it is not useful to attempt to inherit the SCM settings as the release-plugin needs to rewrite them in the child POM during release in any case. I think thats what you are referring to in your last 2 sentences. Correct me if I'm wrong.

But the thing thats a real killer (for us) is that because ${artifactId} is appended to the URLs we cannot craft an inheritable URL that includes the child project's version.

I'm inclined to close this issue as invalid anyway. A lot of my initial description does not really apply in the way I've described it - it was more or less a fact of my incomplete knowledge of Maven. My complaints in the second part of the description about artifacts with the same artifact id but different packaging is bad practice, since some plugins will fail to handle such artifacts.

For the SCM URLs we separate meanwhile between two cases:

1/ A POM inherits form a global POM: In this case the global POM's SCM URLs are not related to the POM inheriting the global POM's settings (since they define where the global POM's releases are managed) and the SCM section must be defined always.

2/ A POM inherits from a direct parent POM: In our case this means that the children also share the same release cycle i.e. from a Subversion SCM PoV the "trunk" is above the location of the parent POM. This also means that the POMs of the children do not have a SCM section at all, since they are never released standalone. Note, that the release plugin will also not add such a section, it only modifies the parent POM.

Both cases work well and none of my original description applies.

So there's only the project's URL and the distribution URL left. Honestly, I did not play yet with the site plugin enough to make any real valid comment on it. Our artifacts are too fine grained for a useful automated site generation and we keep documentation differently.

Well if you do, I'll have to create another issue with the same title and copy all of my comments (and some of yours) over there.

The auto append of ${artifactId} in child POMs is a real problem for url and site#url.

But if you do close I suppose I can probably represent the problem again in a much clearer form.
Its up to you.

This is an issue that we've been living with for ages and continues to result in hassle and bugs (today: MNG-3134).

MNG-3134 - if this is fixed then the inheritance based (i.e. not explicitly declared) site deployment location will now match the inheritance based (i.e. not explicitly declared) project URL location.

Yes, but that doesn't solve this issue.
Essentially the whole childPathAdjustment aware mechanism is the root cause of the problem being described here.

If there really is a need to deploy the project web sites in a structure that mirrors the structure of a project and its child modules (and I'm struggling to justify that) then I think there needs to be a distinction made between the URL generates for projects that are contained modules and those that are not but do use a URL form an inherited POM.

Unless there is someway to defined what ChildPathAdjustment aware strategy is to be used (and in this case it would be need to be NONE) it will continue to thwart the ability to define inherited URLs that resolve in the child to anything other than <site>/${artifactId} or <site>/${artifactid}/${ChildPathAdjustment}.

At no point can I specify an inheritable URL explicitly in the parent using resolvable project properties.
At no point can I introduce the ${version} into the URL using inheritance.

But I think its good that your patch should at least make all the URLs behave in the same (albeit poor IMHO) way.

Joerg,

I've come to the conclusion that while this is definitely an issue that should be resolved, we are going to deal with it by always exlicitly declaring url and site#url properties in our POMs to avoid the aberrant childPathAdjustment mechanism. And I don't believe that anyone else rates it highly enough to be bothered about fixing it.

So if you still want to close it, no argument from me.

I feel that there is still room for a third type of project relationship. A number of projects not sharing a release cycle, but hosted at the same location, with regular and predictable URLs. Certainly it's not essential, but having the variable interpolation instead of auto-append would make it easier to adjust URLs for all these projects, handling SVN relocates, etc. This would definitely be valuable to me.

Joerg, I'm satisfied that all my concerns raised with this issue have been resolved by http://jira.codehaus.org/browse/MNG-3244.
Did you still want to keep it open?

I've linked the superceding issue.

This issue is marked as fix verion = Maven 2.0.8, and so it show's up in the Maven 2.0.8 release notes, but actually it's just superceeded by MNG-3244, which is just a documentation update in 2.0.9 since the real fix was deemed not backward compatible. So not only is this not fixed, but it's not in 2.0.8.

As previously stated, the original request was created due to a lock of Maven knowledge. So it might have been closed long ago as INVALID.