[ 
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)

Reply via email to