[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14694875#comment-14694875
]
Hervé Boutemy commented on MPIR-234:
notice that this is what I already did in MPIR-290: display only a part of the
scm git url in the report
the only weak part is that the algorithm to detect repo part from path part is
index of '.git'
but this is the update that made me think that we just need a clearly defined
separator for this info
and everything wil work well: no change in Maven core (keep path behaviour),
and update in MPIR scm report to better parse the scm url and display parts
nicely
and of course, update Maven scm to document the new url format (addition of
this separator to path) and improve the url parser
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)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven-plugins pull request: Updated docs URL for shade plugin
GitHub user edwardmlyte opened a pull request: https://github.com/apache/maven-plugins/pull/59 Updated docs URL for shade plugin Updated due to codehaus repo closing You can merge this pull request into a Git repository by running: $ git pull https://github.com/edwardmlyte/maven-plugins trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-plugins/pull/59.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #59 commit 58bf43d0dfe31663740f0a480da7da85c7f02e9e Author: edwardmlyte edwardml...@gmail.com Date: 2015-08-13T08:52:02Z Updated docs URL for shade plugin Updated due to codehaus repo closing --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Read timeout from repository ?
We are discussing (in https://issues.apache.org/jira/browse/MNG-5869) what appears to be a situation where an intermediate proxy sends an incorrect content-length and the download seems to wait indefinitely for the complete payload to await. Is there no timeout configured for a default get request at all ? (As Arnaud comments in the issue, it would appear to have been introduced somewhere after 3.1.1) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Read timeout from repository ?
Hi, I vaguely remember a discussion [1] regarding a too low RTO of 60s which was increased to a very high value ([2]) Cheers -- Olivier [1] http://markmail.org/message/yqlofeoah6bcxb4i [2] https://issues.apache.org/jira/browse/WAGON-365 On 13 August 2015 at 21:08, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: We are discussing (in https://issues.apache.org/jira/browse/MNG-5869) what appears to be a situation where an intermediate proxy sends an incorrect content-length and the download seems to wait indefinitely for the complete payload to await. Is there no timeout configured for a default get request at all ? (As Arnaud comments in the issue, it would appear to have been introduced somewhere after 3.1.1) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
IMHO, what is not clear in your explanations is that scm url is not the url of
the repo
scm url is scm:provider:provider-specific content
our git scm url is currently weak, since it does not define path in repo: then
just add it, in a location perfectly disctinct from repo url inside the scm url
then everything will work like svn, even if the feature is not provided by
the scm itself but by the Maven provider scm url format (which was not
necessary with svn)
Regards,
Hervé
- Mail original -
De: Lennart Jörelid lennart.jore...@gmail.com
À: Maven Developers List dev@maven.apache.org
Envoyé: Mercredi 12 Août 2015 02:31:33
Objet: Re: [jira] [Commented] (MPIR-234) SCM-link in site of multimodule
projects should not append module name by default (at least for git)
This is pretty much required whenever one uses a VCS which is not
Subversion.
Everything in Maven having to do with SCMs is very subversion-centric in
that:
1. By default, maven appends module names (not artifactIDs) to parent
projects's SCM URLs to form the SCM URL of a child. This does not work for
any Distributed VCS, as far as i know.
2. Since the SCM URLs are incorrectly extrapolated, one is forced to
repeat the calculation in every project, implying quite a lot of Maven
variables defined in the parents.
It should really be up to the SCM provide to perform all calculation of SCM
URLs. Git URLs are considerably different from SVN or CVS URLs. If the
provider can calulate the effective URL, let it. This would also simplify
the release process; the release plugin could simply query the active SCM
provider for all data it requires.
url${url.prefix}/${path.in.reactor}/url
properties
path.in.reactorthe/actual/vcs/path/not/the/module/names/path.in.reactor
/properties
distributionManagement
site
idsomeId/id
nametheNameOfSomeId/name
url${distro.url.prefix}/${path.in.reactor}/url
/site
/distributionManagement
scm
connection${scm.url.prefix}/${reactor.name}/connection
developerConnection${scm.url.prefix}/${reactor.name}/developerConnection
url${reactor.url.remote.prefix}/${reactor.name}/url
tagHEAD/tag
/scm
2015-08-11 21:31 GMT+02:00 Robert Scholte (JIRA) j...@apache.org:
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14682341#comment-14682341
]
Robert Scholte commented on MPIR-234:
-
The more I think about it, the more I like the idea of [~stephenc].
- No scm specific logic in Maven core.
- Relying on the scm of the parent isn't always correct. Instead only a
moduled pom can calculate the actual connection for its modules.
- For the m-release-p it'll be much easier: no scm on the execution root,
then it is not a valid release root. This will prevent a lot of issues when
starting a new Maven project which fail when tagging due to incorrect
inheritance.
This is actually one of the things I tried to fix with
maven-project-utils' [ScmUtils.java|
http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ScmUtils.java?view=markup
].
If we want to expose the connection for submodules like now is done for
svn, we could adjust the pom.xml during a release: all poms are touched
anyway and m-release-p already has the required scm dependency so the
calculation should be simple.
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
Re: svn commit: r1695142 - /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
see related https://issues.apache.org/jira/browse/DOXIA-436
Greetings! :)
-Lukas
Am 12.08.2015 um 23:54 schrieb herve.bout...@free.fr:
now that you told it, I'd seriously prefer change Doxia Markdown parser to use
an XhtmlParser instance internally instead of extending XhtmlParser while
completely replacing content parsed by the Xhtml parser: this would be a lot
more clear (and would avoid adding bloat to getType())
I didn't really try, I don't know if this change is really complex
did you try?
Regards,
Hervé
- Mail original -
De: Petar Tahchiev paranoia...@gmail.com
À: Maven Developers List dev@maven.apache.org
Envoyé: Mercredi 12 Août 2015 08:39:12
Objet: Re: svn commit: r1695142 -
/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
OK,
sorry I wasn't aware that user specifying an input encoding for xml file
would be considered as introducing a bug. Great for the test-case - I will
revert my changes and work for a fix in the MarkdownParser. Would
overriding the getType() method of the MarkdownParser be considered as a
valid solution?
2015-08-12 2:42 GMT+03:00 herve.bout...@free.fr:
IIUC, your concerns are about Mardown: if Markdown parser has a bug, don't
hesitate to fix it
but do not break content for normal XML parsers, like fml or xdoc
since your change did not make unit tests fail, this proves unit tests are
too weak: I just improved them in r1695408 to fail (and show clearly what
you are breaking)
and I reopened DOXIASITETOOLS-104
You're probably right that making Markdown parser *extend* XhtmlParser is
probably wrong: it should *use* an XhtmlParser, but not extend it
Regards,
Hervé
- Mail original -
De: Petar Tahchiev paranoia...@gmail.com
À: Maven Developers List dev@maven.apache.org
Envoyé: Mardi 11 Août 2015 11:36:28
Objet: Re: svn commit: r1695142 -
/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Hi Herve,
I did this because seems like a parser can be of type XML even if it's not
parsing only XML - for example the MarkdownParser (which is in doxia and
extends from the XmlParser) getType() returns 2 (XML parser type). I guess
there are two ways to go here - 1) first would be to allow the user to
force an encoding. It's his/hers decision and he/she takes the
responsibility. 2) Would be to override the XmlParser:getType() method in
MarkdownParser and make it return 0 (UNKNOWN_TYPE). To me this would lead
to inconsistency, because the MarkdownParser extends from XmlParser, but
returns another type. Furthermore I don't agree markdown syntax is in fact
xml syntax.
2015-08-11 11:04 GMT+03:00 herve.bout...@free.fr:
wow, I don't like this
in XML, encoding is self provided
with such feature, an XML-invalid document can be read by Maven (and
Maven
only, since it is XML-invalid)
I'm -1 on this: we can't help people make Maven-specific pseudo XML
Regards,
Hervé
- Mail original -
De: ptahch...@apache.org
À: comm...@maven.apache.org
Envoyé: Lundi 10 Août 2015 20:00:00
Objet: svn commit: r1695142 -
/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Author: ptahchiev
Date: Mon Aug 10 18:00:00 2015
New Revision: 1695142
URL: http://svn.apache.org/r1695142
Log:
Check for user's provided encoding, and only if it's null then use the
encoding of the xml document. Closes [DOXIASITETOOLS-104]
Modified:
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Modified:
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
URL:
http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java?rev=1695142r1=1695141r2=1695142view=diff
==
---
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
(original)
+++
maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Mon Aug 10 18:00:00 2015
@@ -389,7 +389,14 @@ public class DefaultSiteRenderer
switch ( parser.getType() )
{
case Parser.XML_TYPE:
-reader = ReaderFactory.newXmlReader( doc );
+if ( siteContext.getInputEncoding() != null )
+{
+reader = ReaderFactory.newReader( doc,
siteContext.getInputEncoding() );
+}
+else
+{
+reader =
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696261#comment-14696261
]
Chris Graham commented on MPIR-234:
---
it's a general contract that should be enforcer for every supported scm
(http://maven.apache.org/scm/scms-overview.html ): scm url should support going
from a parent to a child Maven module by adding the path to the url
One that made perfect sense in the CVS/SVN days, and these core concepts have
been etched in stone in the Maven SCM thinking. However, this is not always
possible with all SCM's.
The base assumption above, does not always hold true for Accurev, ClearCase,
RTC, and depending on how you set it up, possibly even Git.
Git can be nested, with a root pom (and moduleblah/module statements), or
flattened (and module../blah/module statements). If flattened, the
assumption above does not told true.
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)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696247#comment-14696247
]
Chris Graham commented on MPIR-234:
---
I see a general drift towards a Git centric discussion, which is understandable
as most of us use it. However, the entire Maven (and particularly the SCM APIs)
implementation (and therefore thinking) are meant to be SCM agnostic.
As for Flattened/Nested. Let me try to explain (I was rushed). When you perform
a release with MRP, you perform a tagging operation. With SVN, it's a path
within the repo. We only tag our own bit. In Git, the entire repo is tagged,
and in RTC, the Component has a Snapshot taken. In SVN you can check out just a
path into your WC - you can even cherry pick from where and create your own
working structure. This falls down as the MRP can not reconstruct this, hand
made, cherry picked dir structure; it can only check out one point, and thus
lends itself to a nest structure (if not enforces it). In Git, you clone and
entire repo, and in RTC/Clearcase you load an entire Component. RTC, like Git,
can have multiple folders worth (I think of them as eclipse projects - as
that's the space I work in - esp with RTC) available. In Git, it's easy (and
makes sense to) have a root pom and nested modules, an a dir format supported
by the MRP. In RTC, it's impossible to do with the Eclipse client to place a
pom.xml in the root of a component (although it is not forbidden from the
underlying SCM impl, it may be possible from the SCM command line). It really
wants one or more folders (ie eclipse projects) in the root level of a
Component. When you check them out (SCM load in rtc terms) you get all of the
projects/folders into the one check out dir. This is kind of forced by the
eclipse client as it looks for .project files when it checks out. So you end up
with a flattened structure. In all of the RTC examples I've work with, esp when
working with the MRP and the RTC SCM integration, I've always nested the
projects and manually created links in Eclipse. Most RTC based devs either do
not know a) you can actually do this, or b) do not want too. There is no
Project Set Support for RTC SCM in eclipse (although it's been requested). Does
that all make sense or have I actually made things worse?
In terms of ignore scm section that was more a reference to the
help:effective-pom comment, where the scm section of the pom is output in all
pom's not just the root one. I thought that the discussion may have been
heading in the direction of actually using the scm sections in non root poms,
as I seem to remember that there is/was a request to actually implement using
the sub module poms (non root ones) scm section, so you'd perform multiple
check out operations (to make the hand crafted, cherry picked option listed
above. This is not a thing that I am a fan of.
My point here, is that I don't think that the scm section should exist, or be
used, or displayed for anything other than the root pom.
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)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1695142 - /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
Hi Lukas: nice to se that it has catched your interest :) Yes, DOXIA-436 is the ideal, where we completely remove any Xhtml intermediate The idea here is less ambitious: just avoid extending XhtmlParser, since the source is not Xhtml/Xml But of course, don't hesitate to help! Regards, Hervé - Mail original - De: Lukas Theussl ltheu...@gmail.com À: Maven Developers List dev@maven.apache.org Envoyé: Jeudi 13 Août 2015 10:30:21 Objet: Re: svn commit: r1695142 - /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java see related https://issues.apache.org/jira/browse/DOXIA-436 Greetings! :) -Lukas Am 12.08.2015 um 23:54 schrieb herve.bout...@free.fr: now that you told it, I'd seriously prefer change Doxia Markdown parser to use an XhtmlParser instance internally instead of extending XhtmlParser while completely replacing content parsed by the Xhtml parser: this would be a lot more clear (and would avoid adding bloat to getType()) I didn't really try, I don't know if this change is really complex did you try? Regards, Hervé - Mail original - De: Petar Tahchiev paranoia...@gmail.com À: Maven Developers List dev@maven.apache.org Envoyé: Mercredi 12 Août 2015 08:39:12 Objet: Re: svn commit: r1695142 - /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java OK, sorry I wasn't aware that user specifying an input encoding for xml file would be considered as introducing a bug. Great for the test-case - I will revert my changes and work for a fix in the MarkdownParser. Would overriding the getType() method of the MarkdownParser be considered as a valid solution? 2015-08-12 2:42 GMT+03:00 herve.bout...@free.fr: IIUC, your concerns are about Mardown: if Markdown parser has a bug, don't hesitate to fix it but do not break content for normal XML parsers, like fml or xdoc since your change did not make unit tests fail, this proves unit tests are too weak: I just improved them in r1695408 to fail (and show clearly what you are breaking) and I reopened DOXIASITETOOLS-104 You're probably right that making Markdown parser *extend* XhtmlParser is probably wrong: it should *use* an XhtmlParser, but not extend it Regards, Hervé - Mail original - De: Petar Tahchiev paranoia...@gmail.com À: Maven Developers List dev@maven.apache.org Envoyé: Mardi 11 Août 2015 11:36:28 Objet: Re: svn commit: r1695142 - /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java Hi Herve, I did this because seems like a parser can be of type XML even if it's not parsing only XML - for example the MarkdownParser (which is in doxia and extends from the XmlParser) getType() returns 2 (XML parser type). I guess there are two ways to go here - 1) first would be to allow the user to force an encoding. It's his/hers decision and he/she takes the responsibility. 2) Would be to override the XmlParser:getType() method in MarkdownParser and make it return 0 (UNKNOWN_TYPE). To me this would lead to inconsistency, because the MarkdownParser extends from XmlParser, but returns another type. Furthermore I don't agree markdown syntax is in fact xml syntax. 2015-08-11 11:04 GMT+03:00 herve.bout...@free.fr: wow, I don't like this in XML, encoding is self provided with such feature, an XML-invalid document can be read by Maven (and Maven only, since it is XML-invalid) I'm -1 on this: we can't help people make Maven-specific pseudo XML Regards, Hervé - Mail original - De: ptahch...@apache.org À: comm...@maven.apache.org Envoyé: Lundi 10 Août 2015 20:00:00 Objet: svn commit: r1695142 - /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java Author: ptahchiev Date: Mon Aug 10 18:00:00 2015 New Revision: 1695142 URL: http://svn.apache.org/r1695142 Log: Check for user's provided encoding, and only if it's null then use the encoding of the xml document. Closes [DOXIASITETOOLS-104] Modified: maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java Modified: maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java URL: http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java?rev=1695142r1=1695141r2=1695142view=diff == --- maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java (original) +++
[jira] [Commented] (MPIR-234) SCM-link in site of multimodule projects should not append module name by default (at least for git)
[
https://issues.apache.org/jira/browse/MPIR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696274#comment-14696274
]
Chris Graham commented on MPIR-234:
---
So the question becomes what do we put on the Source Repository page for a
module without an explicit scm section.
We don't. Either N/A or See Root SCM URL.
This has just really driven it home for me: In SCM's like RTC/Clearcase/Accurev
(and a flattened Git), the concept of a SCM URL for a submodule makes no sense
at all. It is not possible. When you check out from these, it is an all or
nothing approach. You can not cherry pick the bits you want.
So, from my SCM agnostic POV, the poms SCM section is only of value (and valid)
in a a root (release) pom. It should not be displayed, or inferred from any
other (ie sub module) location.
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)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
