[jira] (MSITE-725) site deploy, distributionManagement and pom inheritance : fail to resolve settings.xml properties
Guimiot Isabelle created MSITE-725:
--
Summary: site deploy, distributionManagement and pom inheritance :
fail to resolve settings.xml properties
Key: MSITE-725
URL: https://jira.codehaus.org/browse/MSITE-725
Project: Maven Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.4, 3.3
Environment: windows / linux
Reporter: Guimiot Isabelle
Priority: Critical
I have a blocker issue with distribution management URL for site deployment,
when I use a property coming from the maven settings.xml file, and I define the
distrib management in a super pom : it fails when running site deploy commands
on sub-projects.
You can reproduce it very easily :
- In the settings, add a property sitePublishDir pointing to
file://C:/whereyoudeploymavensites/
- Create a root project with this pom :
{code}
4.0.0
com.test
testsite1
1.0.0-SNAPSHOT
pom
level 1
site
${sitePublishDir}
org.apache.maven.plugins
maven-site-plugin
3.4
{code}
- create a sub project with this pom :
{code}
4.0.0
com.test
testsite1
1.0.0-SNAPSHOT
com.test
testsite2
1.0.0-SNAPSHOT
pom
level 2
{code}
Then, run a "clean install site-deploy" command on project root -> it works
Run the same command on the sub project, you get that error :
{code}
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 5.751 s
[INFO] Finished at: 2014-07-15T12:43:56+02:00
[INFO] Final Memory: 15M/224M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4:deploy (default-deploy) on
project testsite2: Execution default-deploy of goal
org.apache.maven.plugins:maven-site-plugin:3.4:deploy failed: Base URI is not
absolute: $%7bsitePublishDir%7d -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4:deploy (default-deploy) on
project testsite2: Execution default-deploy of goal
org.apache.maven.plugins:maven-site-plugin:3.4:deploy failed: Base URI is not
absolute: $%7bsitePublishDir%7d
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-deploy of goal org.apache.maven.plugins:maven-site-plugin:3.4:deploy
failed: Base URI is not absolute: $%7bsitePublishDir%7d
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExec
[jira] (DOXIA-492) Add support for doxia macros in markdown documents.
[
https://jira.codehaus.org/browse/DOXIA-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=349755#comment-349755
]
Santiago Mola commented on DOXIA-492:
-
This is a must for me. Fortunately, there is a workaround using velocity
macros: http://verhas.github.io/mdsnippet/
> Add support for doxia macros in markdown documents.
> ---
>
> Key: DOXIA-492
> URL: https://jira.codehaus.org/browse/DOXIA-492
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.4
>Reporter: Juergen Kellerer
> Attachments: screen.png
>
>
> It would be nice if doxia macros could be supported also inside markdown
> documents (similar to APT).
> Existing macros (especially snippet) is very useful, however with the power
> of maven there's the ability to register own macros for a build process which
> enables reuse of resources and improves dryness in general.
> A syntax which may work could be the following:
> * Block Level
> {noformat}
>#`??MACRO_NAME MACRO_ARGS`
> {noformat}
> * Inline
> {noformat}
> `??MACRO_NAME MACRO_ARGS`
> {noformat}
> Reference:
> http://hackage.haskell.org/packages/archive/yesod-markdown/0.0/doc/html/Yesod-Markdown-Macros.html
> E.g. using "Texts" it works just from the Editor:
> !screen.png!
> When macros are not interpreted, they fallback to a code block, thus it's
> easy to edit these sort of documents with one of the existing nice markdown
> editors.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (DOXIA-521) Markdown: Allow using the standard "" for code blocks
Santiago Mola created DOXIA-521: --- Summary: Markdown: Allow using the standard "" for code blocks Key: DOXIA-521 URL: https://jira.codehaus.org/browse/DOXIA-521 Project: Maven Doxia Issue Type: Improvement Components: Module - Markdown Affects Versions: 1.6 Reporter: Santiago Mola Pegdown, as well as other Markdown parsers, translates code blocks to . This is the standard as per the Markdown specifications and both themes and tools (e.g. http://highlightjs.org/) rely on this syntax. However, the doxia markdown module overrides this behaviour and uses ". It would be nice to revert the default behaviour to the standard. If there are use cases for such an alternative syntax, it could be provided as an option. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-735) Blame result on branched file is incorrect
[
https://jira.codehaus.org/browse/SCM-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=349767#comment-349767
]
Todd Currie commented on SCM-735:
-
This patch should be adjusted to take into account SCM-745. The regular
expression should not make use of the greedy wild card match, otherwise the
author name can become corrupted depending on the text of the change
description.
>From the attached patch:
@@ -36,7 +36,7 @@
public class PerforceFilelogConsumer {
private static final String PERFORCE_TIMESTAMP_PATTERN = "/MM/dd";
-private static final String LINE_PATTERN = "#(\\d+).*on (.*) by (.*)@";
+private static final String LINE_PATTERN = "#(\\d+) change (\\d+) .* on
(.*) by (.*)@";
Should be:
@@ -36,7 +36,7 @@
public class PerforceFilelogConsumer {
private static final String PERFORCE_TIMESTAMP_PATTERN = "/MM/dd";
-private static final String LINE_PATTERN = "#(\\d+).*on (.*) by (.*)@";
+private static final String LINE_PATTERN = "#(\\d+) change (\\d+) .*? on
(.*?) by (.*?)@";
> Blame result on branched file is incorrect
> --
>
> Key: SCM-735
> URL: https://jira.codehaus.org/browse/SCM-735
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-perforce
>Affects Versions: 1.8.1
>Reporter: Gregory SSI-YAN-KAI
> Attachments: scm.patch
>
>
> When a file is branched, its revision id restarts from 1.
> So, 2 different lines can have the same revision id even though they have
> been submitted in 2 different changelists.
> Since the perforce blame command is based on the revision id of each line,
> the result might be incorrect.
> The solution I'm proposing in the attached patch is to use changelist number
> to identify the author of a line.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-1378) Make dependencies of test-jars transitive
[ https://jira.codehaus.org/browse/MNG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=349768#comment-349768 ] Reto Gmuer commented on MNG-1378: - I agree with the last three comments. Write a test-utils artifact which can then be a test-scoped dependency of sub1 and sub2, test-utils will have commons-lang as a normal (compile-time) dependency. > Make dependencies of test-jars transitive > - > > Key: MNG-1378 > URL: https://jira.codehaus.org/browse/MNG-1378 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0 >Reporter: Mark Hobson > Fix For: Issues to be reviewed for 3.x > > Attachments: mng1378.tar.gz > > > test-jar transitive dependencies are calculated as per compile scope rather > than test scope. > The situation is demonstrated nicely in it0077: > * module sub1 has a test-scoped dependency of commons-lang > * module sub2 has a test-scoped dependency of sub1 test-jar > sub2 tests should inherit the commons-lang transitive dependency. For > example: > Index: > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > === > --- > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > (revision > 328307) > +++ > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > (working > copy) > @@ -1,6 +1,7 @@ > package org.apache.maven.it0077; > import junit.framework.TestCase; > +import org.apache.commons.lang.BooleanUtils; > public class PersonTwoTest > extends PersonTest > Results in: > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31] > package org.apache.commons.lang does not exist -- This message was sent by Atlassian JIRA (v6.1.6#6162)
