[ https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14693414#comment-14693414 ]
Stephen Connolly commented on MPIR-234: --------------------------------------- [~hboutemy] So my point is that the scm: URLs are not something that users understand. Technically also it is almost impossible with an URL like: {code} scm:svn:http://[username[:password]@]server_name[:port]/path/to/repository/path/inside/repository {code} to determine where the {{path/to/repository}} ends and the {{path/inside/repository}} starts. The only reason you need to determine this is when you are dealing with something where the {{path/inside/repository}} is something other than the empty string. The empty string case is easy, because you can expect to check-out the whole project. Once you are dealing with a sub-path of the repository you cannot check out just that sub-path (ok so subversion and CVS are special cases... but why should we make everything else adapt to these two special cases) So then we get to my proposal. I say if there is an explicit {{<scm>}} section in a pom file *then* that pom file represents a *release root*. You can expect to check out that SCM URL and get a whole chunk of the project that can be built independently from other projects. If there is no explicit {{<scm>}} section in the pom then you are not expected to be able to check out just that sub-module on its own. So the question becomes what do we put on the Source Repository page for a module without an explicit {{<scm>}} section. Well what we do is we copy *verbatim* the SCM checkout instructions from the release root and add {{cd path/to/module}} at the end of those instructions. There is a separate question to be answered about how things like Central's validation rules requiring a <scm> section in a pom file would work for those cases where inheritance does not follow aggregation... but since inheritance not following aggregations will require somebody to configure the {{groupId:artifactId}} of the release root (and possibly the relative path from the release root) in the report, we could just punt and ignore an explicit {{<scm>}} section if there is a configured release root. For model version 5, we should add a path from the scm connection as an element in the {{scm}} section so that url mangling never has to apply. > SCM-link in site of multimodule projects should not append module name by > default (at least for git) > ---------------------------------------------------------------------------------------------------- > > Key: MPIR-234 > URL: https://issues.apache.org/jira/browse/MPIR-234 > Project: Maven Project Info Reports Plugin > Issue Type: Bug > Components: scm > Affects Versions: 2.4 > Reporter: Mirko Friedenhagen > > I have setup a simple multi module project (see > https://github.com/mfriedenhagen/multi-module-sample/tree/multi-site-complex) > which uses git on github as {{scm}}. While rendering the site, MPIR will by > default add the name of the module to the SCM-URLs in source-repository.html. > So instead of https://github.com/mfriedenhagen/multi-module-sample/ I see > https://github.com/mfriedenhagen/multi-module-sample/core/, > g...@github.com:mfriedenhagen/multi-module-sample.git/core and > git://github.com/mfriedenhagen/multi-module-sample.git/core in the report for > the core module. All these URLs are invalid. For SVN this could be assumed to > be the right behaviour, for git and probably other SCMs this is not true. As > a workaround I have to reconfigure the scm section (see > https://github.com/mfriedenhagen/multi-module-sample/blob/multi-site-complex/core/pom.xml) > in the modules like this: > {code:xml} > <scm> > <connection>${project.parent.scm.connection}</connection> > > <developerConnection>${project.parent.scm.developerConnection}</developerConnection> > <url>${project.parent.scm.url}</url> > </scm> > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)