Non sparse-checkout SCM support

temporary move set fix version to 2.1.

This patch enables the release of child modules even with SCMs which doesn't support sparse checkout. The trick is to parse the pom to be released and search for a similar pom in the target/checkout directory. Then use this poms directory for running the release-perform goals.

There is currently a small issue left with child modules releasing because we get the childModules relative path added to the base SCM-URL. This is needed for SVN but breaks a lot other SCMs. The workaround is to add a <scm> section to each submodule until we fixed this bug.

the broken <scm> URL assembling is done in the following code parts:

• DefaultModelInheritanceAssembler#assembleModelInheritance calls
  childScm.setDeveloperConnection( appendPath( parentScm.getDeveloperConnection(), child.getArtifactId(), childPathAdjustment, appendPaths ) );

• MavenProject#getModulePathAdjustment which actually creates the pathAdjustment

Just to be clear, the URL inheritance is broken by design of POM 4.0.0 (MNG-2006). This is just another change that can only be safely made for a new model version.

Not sure Benjamin. Is it possible that the DefaultModelInheritanceAssembler asks the respective maven-scm-provider if the URL needs any adoption at all? Or is this part too early in the lifecycle to get access to the maven-scm-provider?

Or is this part too early in the lifecycle to get access to the maven-scm-provider?

Yes. Also, how would you find this maven-scm-provider, e.g. there is no artifact id/version mentioned in the URL, add another black magic discovery? In general, I have a strong objection against the idea that construction of the effective POM requires pluggable/external components as this makes the POM depend on a specific runtime environment (e.g. Maven class loader hierarchy) and hinders its consumption in tools other than Maven. The POM should be fully declarative and be controlled by fixed/well-known rules.

new version. MRELEASE-457.2.patch now closes the XmlReader + a few codestyle fixes

Note: Mercurial does not (yet) support sparse checkouts, but you can use hg archive --include <MODULE> target/checkout, akin to using e.g. svn export.

txs Jesse, but then you'd most probably need to pimp the maven-scm-api and hack something into the hg provider. Because usually the scm-provider only gets the checkout URL. But in this case you would additionally need the path to the child module. This information is currently not available.

Can this be implemented with the projectPath concept that the release plugin already understands?

ie change the git provider to parse the additional path information into the scm repository's projectPath attribute. Then as long as you follow the convention in placing modules in a subdirectory named for the module it should just work.

Of course it would be even better if the childPathAdjustment code was changed to use the relative path between module and parent rather than artifactId. I think even SVN modules that don't follow the convention are already broken in this regard.

patch tested with this project (https://github.com/olamy/scm-git-test) to release only my-app or my-app-webapp and it works.
Someone else wants to review ?

Hi Olivier!

Please also check Grants comment with the projectPath. Hi is right that I (mis-?) used an existing parameter for passing the information about the found child pom. Otoh I think changing the project path is also not the correct way. To be completely clean, we probably need to introduce a new parameter. But not sure if this is really needed - that's why I didn't commit it myself but asked for reviews

LieGrue,
strub

Grant, I've looked at my patch again and it seems that the solution of passing the child modules location via the releaseDescriptors checkoutPath property is the least intrusive way. Using the projectPath would change lot of functionality and would break a few other things as far as I've seen.