[
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/,
> [email protected]: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)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
