maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Connolly (JIRA)" <>
Subject [jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
Date Fri, 14 Aug 2015 13:30:46 GMT


Stephen Connolly commented on MPIR-234:

> It should not be displayed, or inferred from any other (ie sub module) location.

If you are looking at a module's site and you have to go changing it, you want to know how
to check out *that module*.

So there should be a "Source Repository" for sub-modules.

So let's take a concrete example: Surefire

I have no major complaints with the above page:

This has sub-module within the same GIT repo... let's pick one of them:

What I want is that the fact that this is a sub-component of the main repository should be
called out more explicitly, e.g.

$ git clone
$ cd maven-surefire/surefire-api

would be better checkout instructions.

NIT: those checkout instructions do not checkout the branch that the report was generated
from... so better yet would be

$ git clone -b surefire-2.18.1_vote-1
$ cd maven-surefire/surefire-api

On the other hand, it is really annoying with SVN to always be having the URL in the report
as that of the tag... really great would be to give the links for the branch the release was
cut from as well as the links to the tag

So you'd have

The source can be checked out anonymously from GIT. To checkout the source code that for this
release use the following command:

$ git clone -b surefire-2.18.1_vote-1
$ cd maven-surefire/surefire-api

Alternatively if you want to check out the development stream you can use the following command:

$ git clone
$ cd maven-surefire/surefire-api

Now that page also brings up an additional topic... namely the "Web Access" section.

The Web Access section currently assumes that you will navigate the repo exactly like the
file system... this is not entirely an unreasonable assumption... but it need not remain true,
for example there are some web browsers that use a query parameter for the repo path... so
the path needs to be encoded appropriately.

To me it would make more sense to have the Web Access link generated by a plugable strategy
and injected into the report using a role-hint...

so if I inject the {{<webAccess>github</webAccess>}} into the report... well that
assumes that GIT urls are for GitHub / GitHub enterprise and can compute the web access url
from the git url... much less for the user to configure and therefore much less to go wrong.

If the role is not injected, we could ask all providers to sniff check... so a
URL would be auto-sniffed by the github implementation and bonus the user didn't have to configure
anything... an implementation of {{none}} would suppress the link entirely for those people
who feel the need to hide.

> SCM-link in site of multimodule projects should not append module name by default (at
least for git)
> ----------------------------------------------------------------------------------------------------
>                 Key: MPIR-234
>                 URL:
>             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
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
I see,
and git:// 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
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

View raw message