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