maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Connolly (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
Date Mon, 17 Aug 2015 07:50:48 GMT

    [ https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699138#comment-14699138
] 

Stephen Connolly commented on MPIR-234:
---------------------------------------

Maven is opinionated with its defaults... but you can almost always override those defaults...

How does introducing strict defaults that cannot be overridden help things?

So say we introduce a stronger convention that module names must be the same as their artifactId
(unless you set some flag because you are a legacy project and you don't want to ruin your
SCM history by moving files between directories)

How does somebody find the module in the checkout?

We would still need a page on the module's site that says: "Ok so you want to get the source
code for this, well you need to check out all of this and it's available at xyz/uvw"... in
fact it would be even more important to have such a page because it's not like as if the module
would be following the conventions.

On top of that, I've had reactors that were 3 or 4 levels deep... a convention like module
name === artifactId doesn't help there... because you still need to find the parent module
and the grandparent module in order to locate the module from the root...

Did I mention that we had one case of three modules with the same artifactId and differing
groupId? (all providing a service-impl but for different contexts) Yes it was potentially
confusing, but it would jump out very fast if you ended up with more than one on your classpath
because the war plugin would prefix all of them with a groupId, so you'd very quickly find
the issue.

Every module site needs a page that answers the question "How do I find this module in SCM?".


* For SCMs such as Subversion it is tempting to give people the direct answer... *BUT* I argue
that the direct answer is actually the wrong thing. We should be getting people to check out
the release root always and navigate from there... otherwise you will have a non-resolvable
parent... that leads to deploying -SNAPSHOT builds to the remote repo... that leads to people
having to run {{mvn clean install -DskipTests}} all the time to be sure that they are using
the latest code... or it leads to that "download the internet once every day" when the latest
-SNAPSHOTs deployed nightly by the CI server get pulled down and now the rug has been pulled
out from under you in mid-debugging a bug. (Aside: should people deploy -SNAPSHOTs? Yes, but
only with a defined consistent set of rules... and when you communicate those rules you should
not force developers to use a specific updatePolicy in their settings. Some things that the
rules should cover: 1. If there is some toolchain that not everyone has, then the CI server
should have that toolchain and handle the deployment of the bits of that. 2. When does the
CI server do deploys nightly/every commit/when triggered manually. Pick one, stick with it.
3. Cross team boundary publishing of work in progress... it is better to give such releases
as -alpha versions, but some people prefer loosey-goosey)

* For SCMs such as Git, Accurev, Mercurial, etc, we cannot give you the "this module only"
answer, we are forced to give you the release root answer... and we therefore need to start
giving people directions to the module within the release root.

You cannot convince me that any module site should not have a "How do I find this module in
SCM?", so what are you arguing for?

* That the instructions should be more comprehensive when the module != release root? I'm
fine with that, in fact that is something I want. Better instructions on the page would help
the junior developers.

* That the module name should be recommended to be the same as the artifactId? I'm fine with
that - as long as it is a recommendation... I'm even fine with an enforcer rule to assist
organizations that decide to mandate enforcing that recommendation... I'm not fine with forcing
that recommendation down everyone's necks ;-)

* Something else?

I suspect we may actually be in violent agreement but just so caught up in our perspectives
to miss the actual real conclusion that can be drawn here!

> 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/, git@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)

Mime
View raw message