[jira] [Created] (MNGSITE-279) Introductory material lacks a key piece of information for rank beginners
Rebeccah Quevedo-Prastein created MNGSITE-279: - Summary: Introductory material lacks a key piece of information for rank beginners Key: MNGSITE-279 URL: https://issues.apache.org/jira/browse/MNGSITE-279 Project: Maven Project Web Site Issue Type: Improvement Reporter: Rebeccah Quevedo-Prastein Priority: Minor As someone absolutely brand new to Maven, I couldn't figure out from the web site how to get Maven to know what project I want to build (I work in Windows, but I imagine Linux users might have a similar issue). Fortunately, I googled and found an online tutorial and it mentioned to open a cmd window and navigate to the directory containing the POM file for the project, then execute the mvn command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSITE-769) Can't use property in breadcrumbs items in child module site descriptor
[
https://issues.apache.org/jira/browse/MSITE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MSITE-769.
---
Resolution: Fixed
Assignee: Hervé Boutemy
Fix Version/s: 3.5.1
> Can't use property in breadcrumbs items in child module site descriptor
> ---
>
> Key: MSITE-769
> URL: https://issues.apache.org/jira/browse/MSITE-769
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: inheritance, site descriptor
>Affects Versions: 3.5
>Reporter: Tony Chemit
>Assignee: Hervé Boutemy
>Priority: Critical
> Fix For: 3.5.1
>
> Attachments: MSITE-769.zip
>
>
> In a multi-module project, I have this in pom module site descriptor
> {noformat}
>
>
>href="${project.url}/v/${siteDeployClassifier}/en/index.html"/>
>
> {noformat}
> While running mvn site, the build fail with this error :
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Illegal character in path at
> index 1: ${project.url}/index.html
> at java.net.URI.create(URI.java:852)
> at
> org.apache.maven.doxia.site.decoration.inheritance.URIPathDescriptor.(URIPathDescriptor.java:69)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler$URLContainer.rebaseLink(DefaultDecorationModelInheritanceAssembler.java:453)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.rebaseLinkItemPaths(DefaultDecorationModelInheritanceAssembler.java:300)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.mergeLinkItemLists(DefaultDecorationModelInheritanceAssembler.java:326)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleBodyInheritance(DefaultDecorationModelInheritanceAssembler.java:228)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:109)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1171)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:423)
> at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel(AbstractSiteDescriptorMojo.java:86)
> at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:279)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:151)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:135)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.net.URISyntaxException: Illegal character in path at index 1:
> ${project.url}/index.html
> at java.net.URI$Parser.fail(URI.java:2848)
> at java.net.URI$Parser.checkChars(URI.java:3021)
> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
> at java.net.URI$Parser.parse(URI.java:3063)
> at java.net.URI.(URI.java:588)
> at java.net.URI.create(URI.java:850)
> ... 34 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-769) Can't use property in breadcrumbs items in child module site descriptor
[
https://issues.apache.org/jira/browse/MSITE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222539#comment-15222539
]
Hervé Boutemy commented on MSITE-769:
-
thgis is far more expressive than a syntax
> Can't use property in breadcrumbs items in child module site descriptor
> ---
>
> Key: MSITE-769
> URL: https://issues.apache.org/jira/browse/MSITE-769
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: inheritance, site descriptor
>Affects Versions: 3.5
>Reporter: Tony Chemit
>Priority: Critical
> Fix For: 3.5.1
>
> Attachments: MSITE-769.zip
>
>
> In a multi-module project, I have this in pom module site descriptor
> {noformat}
>
>
>href="${project.url}/v/${siteDeployClassifier}/en/index.html"/>
>
> {noformat}
> While running mvn site, the build fail with this error :
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Illegal character in path at
> index 1: ${project.url}/index.html
> at java.net.URI.create(URI.java:852)
> at
> org.apache.maven.doxia.site.decoration.inheritance.URIPathDescriptor.(URIPathDescriptor.java:69)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler$URLContainer.rebaseLink(DefaultDecorationModelInheritanceAssembler.java:453)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.rebaseLinkItemPaths(DefaultDecorationModelInheritanceAssembler.java:300)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.mergeLinkItemLists(DefaultDecorationModelInheritanceAssembler.java:326)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleBodyInheritance(DefaultDecorationModelInheritanceAssembler.java:228)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:109)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1171)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:423)
> at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel(AbstractSiteDescriptorMojo.java:86)
> at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:279)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:151)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:135)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.net.URISyntaxException: Illegal character in path at index 1:
> ${project.url}/index.html
> at java.net.URI$Parser.fail(URI.java:2848)
> at java.net.URI$Parser.checkChars(URI.java:3021)
> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
> at java.net.URI$Parser.parse(URI.java:3063)
> at java.net.URI.(URI.java:588)
> at java.net.URI.create(URI.java:850)
> ... 34 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-164) don't use document date from Sink API as creation date but as "date" without precision on created or last modified
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222531#comment-15222531
]
Hervé Boutemy commented on DOXIASITETOOLS-164:
--
for Doxia 2.0, we have time to work on it, starting by checking how this date()
Sink API is used in every markup
then we'll see what we can do better than the current "date"
> don't use document date from Sink API as creation date but as "date" without
> precision on created or last modified
> --
>
> Key: DOXIASITETOOLS-164
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-164
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Affects Versions: 1.7
>Reporter: Hervé Boutemy
> Fix For: 1.7.1
>
>
> as seen in DOXIA-541, the meaning of the date is not defined in Doxia: then
> it seems it's up to the content writer to choose...
> and it was a wrong choice to name the content of date field of the document
> as {{dateCreation}} variable in DOXIA-315 / DOXIASITETOOLS-20
> [r771801|http://svn.apache.org/r771801] in 2009
> let's start by showing the weak sematic before choosing what to do: creation
> date, last modification date, or even add some more features like multiple
> dates (for example "created : last modified")?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MPH-117) Upgrade plexus-utils to 3.0.22
[ https://issues.apache.org/jira/browse/MPH-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPH-117: --- Assignee: Karl Heinz Marbaise > Upgrade plexus-utils to 3.0.22 > -- > > Key: MPH-117 > URL: https://issues.apache.org/jira/browse/MPH-117 > Project: Maven Help Plugin > Issue Type: Improvement >Affects Versions: 2.2.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 2.2.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5900) early interpolation: support ${this.*} as expression
[
https://issues.apache.org/jira/browse/MNG-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222500#comment-15222500
]
Christian Schulte commented on MNG-5900:
Just noticed myself that
{code}
${immediate.interpolation.due.to.final}
{code}
is yet a different use-case. Let's just not call it {{this}}, please. Maybe
{{current}} just to avoid using a Java keyword?
> early interpolation: support ${this.*} as expression
>
>
> Key: MNG-5900
> URL: https://issues.apache.org/jira/browse/MNG-5900
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Right now we have $\{project.\*} which always interpolates values based on
> the final project: "classical" interpolation is "late" interpolation. So it
> is not possible that parent poms can lock values, ie avoid child poms
> override. By adding $\{this} for "early" interpolation, it will be possible
> to have intermediate interpolation.
> If a pomfile depends on a parent, that parent will first resolve all
> $\{this.\*} values for itself. Once the fully inherited pom is there, all
> $\{project.\*} will be resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5900) early interpolation: support ${this.*} as expression
[
https://issues.apache.org/jira/browse/MNG-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222486#comment-15222486
]
Christian Schulte edited comment on MNG-5900 at 4/1/16 10:59 PM:
-
I would expect {{this}} to reference the effective model the same way the Java
{{this}} keyword references the "effective" object.
??{{this}} has been the best name so far??
I think {{final}} would be the matching Java keyword with comparable semantics.
There already is an issue filed requesting to add {{final}} and {{override}}
attributes to all POM elements to control inheritance processing. We already
have {{combine.children}} etc. attributes so maybe we just add {{final}} and
{{override}} attributes the same way and control property interpolation based
on the existence of those attributes?
So a parent pom.xml could declare
{code}
${immediate.interpolation.due.to.final}
{code}
was (Author: schulte77):
I would expect {{this}} to reference the effective model the same way the Java
{{this}} keyword references the "effective" object.
??{{this}} has been the best name so far??
I think {{final}} would be the matching Java keyword with comparable semantics.
There already is an issue filed requesting to add {{final}} and {{override}}
attributes to all POM elements to control inheritance processing. We already
have {{combine.children}} etc. attributes so maybe we just add {{final}} and
{{override}} attributes the same way and control property inteprolation based
on the existence of those attributes?
So a parent pom.xml could declare
{code}
${immediate.interpolation.due.to.final}
{code}
> early interpolation: support ${this.*} as expression
>
>
> Key: MNG-5900
> URL: https://issues.apache.org/jira/browse/MNG-5900
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Right now we have $\{project.\*} which always interpolates values based on
> the final project: "classical" interpolation is "late" interpolation. So it
> is not possible that parent poms can lock values, ie avoid child poms
> override. By adding $\{this} for "early" interpolation, it will be possible
> to have intermediate interpolation.
> If a pomfile depends on a parent, that parent will first resolve all
> $\{this.\*} values for itself. Once the fully inherited pom is there, all
> $\{project.\*} will be resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5900) early interpolation: support ${this.*} as expression
[
https://issues.apache.org/jira/browse/MNG-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222486#comment-15222486
]
Christian Schulte commented on MNG-5900:
I would expect {{this}} to reference the effective model the same way the Java
{{this}} keyword references the "effective" object.
??{{this}} has been the best name so far??
I think {{final}} would be the matching Java keyword with comparable semantics.
There already is an issue filed requesting to add {{final}} and {{override}}
attributes to all POM elements to control inheritance processing. We already
have {{combine.children}} etc. attributes so maybe we just add {{final}} and
{{override}} attributes the same way and control property inteprolation based
on the existence of those attributes?
So a parent pom.xml could declare
{code}
${immediate.interpolation.due.to.final}
{code}
> early interpolation: support ${this.*} as expression
>
>
> Key: MNG-5900
> URL: https://issues.apache.org/jira/browse/MNG-5900
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Right now we have $\{project.\*} which always interpolates values based on
> the final project: "classical" interpolation is "late" interpolation. So it
> is not possible that parent poms can lock values, ie avoid child poms
> override. By adding $\{this} for "early" interpolation, it will be possible
> to have intermediate interpolation.
> If a pomfile depends on a parent, that parent will first resolve all
> $\{this.\*} values for itself. Once the fully inherited pom is there, all
> $\{project.\*} will be resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5900) early interpolation: support ${this.*} as expression
[
https://issues.apache.org/jira/browse/MNG-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222398#comment-15222398
]
Robert Scholte commented on MNG-5900:
-
What's misleading about it? It will be replaced with its value within this
pom.xml, whereas {{$\{project.*\}}} will be replaced with the effective project
value. The comparison with Java's 'this' is quite good, hence that's why I
suggested it.
I don't like the idea of different delimiters, it'll make parsing extra complex
and I don't see advantage of it. Introducing a new variable makes more sense
and {{this}} has been the best name so far.
> early interpolation: support ${this.*} as expression
>
>
> Key: MNG-5900
> URL: https://issues.apache.org/jira/browse/MNG-5900
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Right now we have $\{project.\*} which always interpolates values based on
> the final project: "classical" interpolation is "late" interpolation. So it
> is not possible that parent poms can lock values, ie avoid child poms
> override. By adding $\{this} for "early" interpolation, it will be possible
> to have intermediate interpolation.
> If a pomfile depends on a parent, that parent will first resolve all
> $\{this.\*} values for itself. Once the fully inherited pom is there, all
> $\{project.\*} will be resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5900) early interpolation: support ${this.*} as expression
[
https://issues.apache.org/jira/browse/MNG-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222359#comment-15222359
]
Christian Schulte commented on MNG-5900:
Regarding {noformat}${this.*}{noformat} properties: I think {{this}} is
misleading. I would prefer introducing a different syntax. For example:
Immediate interpolation is requested by using a different syntax like
{noformat}$${project.url}{noformat} or {noformat}@{project.url}{noformat}, etc.
WDYT
> early interpolation: support ${this.*} as expression
>
>
> Key: MNG-5900
> URL: https://issues.apache.org/jira/browse/MNG-5900
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Right now we have $\{project.\*} which always interpolates values based on
> the final project: "classical" interpolation is "late" interpolation. So it
> is not possible that parent poms can lock values, ie avoid child poms
> override. By adding $\{this} for "early" interpolation, it will be possible
> to have intermediate interpolation.
> If a pomfile depends on a parent, that parent will first resolve all
> $\{this.\*} values for itself. Once the fully inherited pom is there, all
> $\{project.\*} will be resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-769) Can't use property in breadcrumbs items in child module site descriptor
[
https://issues.apache.org/jira/browse/MSITE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222355#comment-15222355
]
Christian Schulte commented on MSITE-769:
-
Regarding {noformat}${this.*}{noformat} properties: I think {{this}} is
misleading. I would prefer introducing a different syntax. For example:
Immediate interpolation is requested by using a different syntax like
{noformat}$${project.url}{noformat} or {noformat}@{project.url}{noformat}, etc.
WDYT
> Can't use property in breadcrumbs items in child module site descriptor
> ---
>
> Key: MSITE-769
> URL: https://issues.apache.org/jira/browse/MSITE-769
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: inheritance, site descriptor
>Affects Versions: 3.5
>Reporter: Tony Chemit
>Priority: Critical
> Attachments: MSITE-769.zip
>
>
> In a multi-module project, I have this in pom module site descriptor
> {noformat}
>
>
>href="${project.url}/v/${siteDeployClassifier}/en/index.html"/>
>
> {noformat}
> While running mvn site, the build fail with this error :
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Illegal character in path at
> index 1: ${project.url}/index.html
> at java.net.URI.create(URI.java:852)
> at
> org.apache.maven.doxia.site.decoration.inheritance.URIPathDescriptor.(URIPathDescriptor.java:69)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler$URLContainer.rebaseLink(DefaultDecorationModelInheritanceAssembler.java:453)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.rebaseLinkItemPaths(DefaultDecorationModelInheritanceAssembler.java:300)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.mergeLinkItemLists(DefaultDecorationModelInheritanceAssembler.java:326)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleBodyInheritance(DefaultDecorationModelInheritanceAssembler.java:228)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:109)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1171)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:423)
> at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel(AbstractSiteDescriptorMojo.java:86)
> at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:279)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:151)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:135)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.net.URISyntaxException: Illegal character in path at index 1:
> ${project.url}/index.html
> at java.net.URI$Parser.fail(URI.java:2848)
> at java.net.URI$Parser.checkChars(URI.java:3021)
> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
> at java.net.URI$Parser.parse(URI.java:3063)
> at java.net.URI.(URI.java:588)
> at java.net.URI.create(URI.java:850)
> ... 34 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-769) Can't use property in breadcrumbs items in child module site descriptor
[
https://issues.apache.org/jira/browse/MSITE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1594#comment-1594
]
Hudson commented on MSITE-769:
--
FAILURE: Integrated in maven-plugins #5568 (See
[https://builds.apache.org/job/maven-plugins/5568/])
[MSITE-769] add support for site.xml early interpolation as ${this.*}
(hboutemy: [http://svn.apache.org/viewvc/?view=rev=1737429])
* maven-site-plugin/pom.xml
*
maven-site-plugin/src/it/inheritance-interpolation/repo-parent/src/site/site.xml
> Can't use property in breadcrumbs items in child module site descriptor
> ---
>
> Key: MSITE-769
> URL: https://issues.apache.org/jira/browse/MSITE-769
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: inheritance, site descriptor
>Affects Versions: 3.5
>Reporter: Tony Chemit
>Priority: Critical
> Attachments: MSITE-769.zip
>
>
> In a multi-module project, I have this in pom module site descriptor
> {noformat}
>
>
>href="${project.url}/v/${siteDeployClassifier}/en/index.html"/>
>
> {noformat}
> While running mvn site, the build fail with this error :
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Illegal character in path at
> index 1: ${project.url}/index.html
> at java.net.URI.create(URI.java:852)
> at
> org.apache.maven.doxia.site.decoration.inheritance.URIPathDescriptor.(URIPathDescriptor.java:69)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler$URLContainer.rebaseLink(DefaultDecorationModelInheritanceAssembler.java:453)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.rebaseLinkItemPaths(DefaultDecorationModelInheritanceAssembler.java:300)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.mergeLinkItemLists(DefaultDecorationModelInheritanceAssembler.java:326)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleBodyInheritance(DefaultDecorationModelInheritanceAssembler.java:228)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:109)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1171)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:423)
> at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel(AbstractSiteDescriptorMojo.java:86)
> at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:279)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:151)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:135)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.net.URISyntaxException: Illegal character in path at index 1:
> ${project.url}/index.html
> at java.net.URI$Parser.fail(URI.java:2848)
> at java.net.URI$Parser.checkChars(URI.java:3021)
> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
> at java.net.URI$Parser.parse(URI.java:3063)
> at java.net.URI.(URI.java:588)
> at java.net.URI.create(URI.java:850)
> ... 34 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MPH-107) Mojos use inconsistent line endings throughout
[
https://issues.apache.org/jira/browse/MPH-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPH-107:
---
Fix Version/s: 2.2.1
> Mojos use inconsistent line endings throughout
> --
>
> Key: MPH-107
> URL: https://issues.apache.org/jira/browse/MPH-107
> Project: Maven Help Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 2.2.1
>
>
> Most mojos use {{\n}} instead of using system line ending. This looks weird
> on Windows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-771) FAQ Entry for difference between mvn site and mvn site:site is incorrect
[
https://issues.apache.org/jira/browse/MSITE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1524#comment-1524
]
Michael Osipov commented on MSITE-771:
--
Funny this, see
[here|https://github.com/apache/maven/blob/HEAD/maven-core/src/main/resources/META-INF/plexus/components.xml#L89-L112].
It is accumulative. The lifecycle reference is confusing.
> FAQ Entry for difference between mvn site and mvn site:site is incorrect
>
>
> Key: MSITE-771
> URL: https://issues.apache.org/jira/browse/MSITE-771
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.5
>Reporter: Konrad Windszus
>Assignee: Michael Osipov
>
> The documentation entry 1 at
> https://maven.apache.org/plugins/maven-site-plugin/faq.html is incorrect.
> It states
> {quote}
> mvn site
> Calls the site phase of the site lifecycle, which consists in the
> following life cycle phases: pre-site, site, post-site and site-deploy. See
> Lifecycle Reference
> {quote}
> Actually {{site}} will only execute the phases {{pre-site}} and {{site}} but
> neither {{post-site}} nor {{site-deploy}}. All the four phases are only
> executed if you execute {{site-deploy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCHANGES-367) Release maven-changes-plugin 2.12
[ https://issues.apache.org/jira/browse/MCHANGES-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1514#comment-1514 ] Subin Sugunan commented on MCHANGES-367: Awesome. > Release maven-changes-plugin 2.12 > - > > Key: MCHANGES-367 > URL: https://issues.apache.org/jira/browse/MCHANGES-367 > Project: Maven Changes Plugin > Issue Type: Task > Components: github >Affects Versions: 2.12 >Reporter: Subin Sugunan >Assignee: Michael Osipov > Labels: build > > Hello > We use enterprise GitHub and we would like to utilize the enterprise support > added as part of https://issues.apache.org/jira/browse/MCHANGES-305 > We have tested and verified maven-changes-plugin:2.12-SNAPSHOT and its > working as expected. > As per the > [maven-changes-plugin|https://maven.apache.org/plugins/maven-changes-plugin/] > site, 2.11 was released on 2014-09-24, which is more than an year old now. > It will be nice to have maven-changes-plugin:2.12 released. > Thanks > Subin Sugunan -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MRELEASE-947) Wiki page URL for maven-release-plugin is wrong - post Codehaus termination
[
https://issues.apache.org/jira/browse/MRELEASE-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MRELEASE-947.
---
Resolution: Fixed
Fixed with [r1737423|http://svn.apache.org/r1737423].
> Wiki page URL for maven-release-plugin is wrong - post Codehaus termination
> ---
>
> Key: MRELEASE-947
> URL: https://issues.apache.org/jira/browse/MRELEASE-947
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: documentation
>Reporter: Brian Brooks
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.0
>
>
> On the page https://maven.apache.org/maven-release/maven-release-plugin/
> This link is invalid
> http://docs.codehaus.org/display/MAVENUSER/Release+Plugin
> It's referenced by this text
> "Usage
> General instructions on how to use the Release Plugin can be found on the
> usage page. Some more specific use cases are described in the examples given
> below. Last but not least, users occasionally contribute additional examples,
> tips or errata to the plugin's wiki page."
> The March 2015 thread between Herve Boutemy and Martin Gainty on the
> maven-dev mailing list seems to document the problem and provide the base URL
> for a new URL...
> {quote}
> > From: herve.bout...@free.fr
> > To: d...@maven.apache.org
> > Subject: Codehaus EOL and MAVENUSER Confluence Wiki
> > Date: Wed, 4 Mar 2015 02:20:09 +0100
> >
> > Hi,
> >
> > I got a report from someone about links from Jira to old Codehaus MAVEN
> > Confluence Wiki [1]: I explained that we already copied the content to ASF
> > MAVENOLD [2] as read-only and copied useful content to ASF MAVEN [3]
> >
> > Then ok for Codehaus MAVEN Confluence Wiki.
> >
> > But what about Codehaus MAVENUSER Confluence Wiki [4]?
> > Is the whole content useful? Should we have the same strategy than MAVEN?
> > Who
> > could do that?
> MG>http://docs.codehaus.org/display/MAVENUSER/Home;jsessionid=A686FD6E6C1DA1A824E695ABEB288143
> MG>Codehaus content is useful..but will require resource who can understand
> and write legible
> cyrilic..
> MG>Can Igor port the pages with cyrilic to ASF MAVEN[3]?
> >
> > Or should we only copy relevant pages to MAVEN? How to do that (I didn't
> > find
> > any way to export even a simple page to later reimport)
> >
> > Any thoughts?
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] http://docs.codehaus.org/display/MAVEN/
> >
> > [2] https://cwiki.apache.org/confluence/display/MAVENOLD/
> >
> > [3] https://cwiki.apache.org/confluence/display/MAVEN/
> >
> > [4] http://docs.codehaus.org/display/MAVENUSER/
> {quote}
> Source:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201503.mbox/%3cblu172-w470a03aa20e3c140dadf55ae...@phx.gbl%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MRELEASE-947) Wiki page URL for maven-release-plugin is wrong - post codehaus termination
[
https://issues.apache.org/jira/browse/MRELEASE-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-947:
Summary: Wiki page URL for maven-release-plugin is wrong - post codehaus
termination (was: wiki page url for maven-release-plugin is wrong - post
codehaus termination)
> Wiki page URL for maven-release-plugin is wrong - post codehaus termination
> ---
>
> Key: MRELEASE-947
> URL: https://issues.apache.org/jira/browse/MRELEASE-947
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: documentation
>Reporter: Brian Brooks
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.0
>
>
> On the page https://maven.apache.org/maven-release/maven-release-plugin/
> This link is invalid
> http://docs.codehaus.org/display/MAVENUSER/Release+Plugin
> It's referenced by this text
> "Usage
> General instructions on how to use the Release Plugin can be found on the
> usage page. Some more specific use cases are described in the examples given
> below. Last but not least, users occasionally contribute additional examples,
> tips or errata to the plugin's wiki page."
> The March 2015 thread between Herve Boutemy and Martin Gainty on the
> maven-dev mailing list seems to document the problem and provide the base URL
> for a new URL...
> {quote}
> > From: herve.bout...@free.fr
> > To: d...@maven.apache.org
> > Subject: Codehaus EOL and MAVENUSER Confluence Wiki
> > Date: Wed, 4 Mar 2015 02:20:09 +0100
> >
> > Hi,
> >
> > I got a report from someone about links from Jira to old Codehaus MAVEN
> > Confluence Wiki [1]: I explained that we already copied the content to ASF
> > MAVENOLD [2] as read-only and copied useful content to ASF MAVEN [3]
> >
> > Then ok for Codehaus MAVEN Confluence Wiki.
> >
> > But what about Codehaus MAVENUSER Confluence Wiki [4]?
> > Is the whole content useful? Should we have the same strategy than MAVEN?
> > Who
> > could do that?
> MG>http://docs.codehaus.org/display/MAVENUSER/Home;jsessionid=A686FD6E6C1DA1A824E695ABEB288143
> MG>Codehaus content is useful..but will require resource who can understand
> and write legible
> cyrilic..
> MG>Can Igor port the pages with cyrilic to ASF MAVEN[3]?
> >
> > Or should we only copy relevant pages to MAVEN? How to do that (I didn't
> > find
> > any way to export even a simple page to later reimport)
> >
> > Any thoughts?
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] http://docs.codehaus.org/display/MAVEN/
> >
> > [2] https://cwiki.apache.org/confluence/display/MAVENOLD/
> >
> > [3] https://cwiki.apache.org/confluence/display/MAVEN/
> >
> > [4] http://docs.codehaus.org/display/MAVENUSER/
> {quote}
> Source:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201503.mbox/%3cblu172-w470a03aa20e3c140dadf55ae...@phx.gbl%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MRELEASE-947) Wiki page URL for maven-release-plugin is wrong - post Codehaus termination
[
https://issues.apache.org/jira/browse/MRELEASE-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-947:
Summary: Wiki page URL for maven-release-plugin is wrong - post Codehaus
termination (was: Wiki page URL for maven-release-plugin is wrong - post
codehaus termination)
> Wiki page URL for maven-release-plugin is wrong - post Codehaus termination
> ---
>
> Key: MRELEASE-947
> URL: https://issues.apache.org/jira/browse/MRELEASE-947
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: documentation
>Reporter: Brian Brooks
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.0
>
>
> On the page https://maven.apache.org/maven-release/maven-release-plugin/
> This link is invalid
> http://docs.codehaus.org/display/MAVENUSER/Release+Plugin
> It's referenced by this text
> "Usage
> General instructions on how to use the Release Plugin can be found on the
> usage page. Some more specific use cases are described in the examples given
> below. Last but not least, users occasionally contribute additional examples,
> tips or errata to the plugin's wiki page."
> The March 2015 thread between Herve Boutemy and Martin Gainty on the
> maven-dev mailing list seems to document the problem and provide the base URL
> for a new URL...
> {quote}
> > From: herve.bout...@free.fr
> > To: d...@maven.apache.org
> > Subject: Codehaus EOL and MAVENUSER Confluence Wiki
> > Date: Wed, 4 Mar 2015 02:20:09 +0100
> >
> > Hi,
> >
> > I got a report from someone about links from Jira to old Codehaus MAVEN
> > Confluence Wiki [1]: I explained that we already copied the content to ASF
> > MAVENOLD [2] as read-only and copied useful content to ASF MAVEN [3]
> >
> > Then ok for Codehaus MAVEN Confluence Wiki.
> >
> > But what about Codehaus MAVENUSER Confluence Wiki [4]?
> > Is the whole content useful? Should we have the same strategy than MAVEN?
> > Who
> > could do that?
> MG>http://docs.codehaus.org/display/MAVENUSER/Home;jsessionid=A686FD6E6C1DA1A824E695ABEB288143
> MG>Codehaus content is useful..but will require resource who can understand
> and write legible
> cyrilic..
> MG>Can Igor port the pages with cyrilic to ASF MAVEN[3]?
> >
> > Or should we only copy relevant pages to MAVEN? How to do that (I didn't
> > find
> > any way to export even a simple page to later reimport)
> >
> > Any thoughts?
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] http://docs.codehaus.org/display/MAVEN/
> >
> > [2] https://cwiki.apache.org/confluence/display/MAVENOLD/
> >
> > [3] https://cwiki.apache.org/confluence/display/MAVEN/
> >
> > [4] http://docs.codehaus.org/display/MAVENUSER/
> {quote}
> Source:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201503.mbox/%3cblu172-w470a03aa20e3c140dadf55ae...@phx.gbl%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MSITE-771) FAQ Entry for difference between mvn site and mvn site:site is incorrect
[
https://issues.apache.org/jira/browse/MSITE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSITE-771:
Assignee: Michael Osipov
> FAQ Entry for difference between mvn site and mvn site:site is incorrect
>
>
> Key: MSITE-771
> URL: https://issues.apache.org/jira/browse/MSITE-771
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.5
>Reporter: Konrad Windszus
>Assignee: Michael Osipov
>
> The documentation entry 1 at
> https://maven.apache.org/plugins/maven-site-plugin/faq.html is incorrect.
> It states
> {quote}
> mvn site
> Calls the site phase of the site lifecycle, which consists in the
> following life cycle phases: pre-site, site, post-site and site-deploy. See
> Lifecycle Reference
> {quote}
> Actually {{site}} will only execute the phases {{pre-site}} and {{site}} but
> neither {{post-site}} nor {{site-deploy}}. All the four phases are only
> executed if you execute {{site-deploy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MRELEASE-947) wiki page url for maven-release-plugin is wrong - post codehaus termination
[
https://issues.apache.org/jira/browse/MRELEASE-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MRELEASE-947:
---
Assignee: Michael Osipov
> wiki page url for maven-release-plugin is wrong - post codehaus termination
> ---
>
> Key: MRELEASE-947
> URL: https://issues.apache.org/jira/browse/MRELEASE-947
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: documentation
>Reporter: Brian Brooks
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.0
>
>
> On the page https://maven.apache.org/maven-release/maven-release-plugin/
> This link is invalid
> http://docs.codehaus.org/display/MAVENUSER/Release+Plugin
> It's referenced by this text
> "Usage
> General instructions on how to use the Release Plugin can be found on the
> usage page. Some more specific use cases are described in the examples given
> below. Last but not least, users occasionally contribute additional examples,
> tips or errata to the plugin's wiki page."
> The March 2015 thread between Herve Boutemy and Martin Gainty on the
> maven-dev mailing list seems to document the problem and provide the base URL
> for a new URL...
> {quote}
> > From: herve.bout...@free.fr
> > To: d...@maven.apache.org
> > Subject: Codehaus EOL and MAVENUSER Confluence Wiki
> > Date: Wed, 4 Mar 2015 02:20:09 +0100
> >
> > Hi,
> >
> > I got a report from someone about links from Jira to old Codehaus MAVEN
> > Confluence Wiki [1]: I explained that we already copied the content to ASF
> > MAVENOLD [2] as read-only and copied useful content to ASF MAVEN [3]
> >
> > Then ok for Codehaus MAVEN Confluence Wiki.
> >
> > But what about Codehaus MAVENUSER Confluence Wiki [4]?
> > Is the whole content useful? Should we have the same strategy than MAVEN?
> > Who
> > could do that?
> MG>http://docs.codehaus.org/display/MAVENUSER/Home;jsessionid=A686FD6E6C1DA1A824E695ABEB288143
> MG>Codehaus content is useful..but will require resource who can understand
> and write legible
> cyrilic..
> MG>Can Igor port the pages with cyrilic to ASF MAVEN[3]?
> >
> > Or should we only copy relevant pages to MAVEN? How to do that (I didn't
> > find
> > any way to export even a simple page to later reimport)
> >
> > Any thoughts?
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] http://docs.codehaus.org/display/MAVEN/
> >
> > [2] https://cwiki.apache.org/confluence/display/MAVENOLD/
> >
> > [3] https://cwiki.apache.org/confluence/display/MAVEN/
> >
> > [4] http://docs.codehaus.org/display/MAVENUSER/
> {quote}
> Source:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201503.mbox/%3cblu172-w470a03aa20e3c140dadf55ae...@phx.gbl%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MRELEASE-947) wiki page url for maven-release-plugin is wrong - post codehaus termination
[
https://issues.apache.org/jira/browse/MRELEASE-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-947:
Fix Version/s: 3.0
> wiki page url for maven-release-plugin is wrong - post codehaus termination
> ---
>
> Key: MRELEASE-947
> URL: https://issues.apache.org/jira/browse/MRELEASE-947
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: documentation
>Reporter: Brian Brooks
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.0
>
>
> On the page https://maven.apache.org/maven-release/maven-release-plugin/
> This link is invalid
> http://docs.codehaus.org/display/MAVENUSER/Release+Plugin
> It's referenced by this text
> "Usage
> General instructions on how to use the Release Plugin can be found on the
> usage page. Some more specific use cases are described in the examples given
> below. Last but not least, users occasionally contribute additional examples,
> tips or errata to the plugin's wiki page."
> The March 2015 thread between Herve Boutemy and Martin Gainty on the
> maven-dev mailing list seems to document the problem and provide the base URL
> for a new URL...
> {quote}
> > From: herve.bout...@free.fr
> > To: d...@maven.apache.org
> > Subject: Codehaus EOL and MAVENUSER Confluence Wiki
> > Date: Wed, 4 Mar 2015 02:20:09 +0100
> >
> > Hi,
> >
> > I got a report from someone about links from Jira to old Codehaus MAVEN
> > Confluence Wiki [1]: I explained that we already copied the content to ASF
> > MAVENOLD [2] as read-only and copied useful content to ASF MAVEN [3]
> >
> > Then ok for Codehaus MAVEN Confluence Wiki.
> >
> > But what about Codehaus MAVENUSER Confluence Wiki [4]?
> > Is the whole content useful? Should we have the same strategy than MAVEN?
> > Who
> > could do that?
> MG>http://docs.codehaus.org/display/MAVENUSER/Home;jsessionid=A686FD6E6C1DA1A824E695ABEB288143
> MG>Codehaus content is useful..but will require resource who can understand
> and write legible
> cyrilic..
> MG>Can Igor port the pages with cyrilic to ASF MAVEN[3]?
> >
> > Or should we only copy relevant pages to MAVEN? How to do that (I didn't
> > find
> > any way to export even a simple page to later reimport)
> >
> > Any thoughts?
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] http://docs.codehaus.org/display/MAVEN/
> >
> > [2] https://cwiki.apache.org/confluence/display/MAVENOLD/
> >
> > [3] https://cwiki.apache.org/confluence/display/MAVEN/
> >
> > [4] http://docs.codehaus.org/display/MAVENUSER/
> {quote}
> Source:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201503.mbox/%3cblu172-w470a03aa20e3c140dadf55ae...@phx.gbl%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCHANGES-367) Release maven-changes-plugin 2.12
[ https://issues.apache.org/jira/browse/MCHANGES-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222198#comment-15222198 ] Michael Osipov commented on MCHANGES-367: - Release should be available on Monday. > Release maven-changes-plugin 2.12 > - > > Key: MCHANGES-367 > URL: https://issues.apache.org/jira/browse/MCHANGES-367 > Project: Maven Changes Plugin > Issue Type: Task > Components: github >Affects Versions: 2.12 >Reporter: Subin Sugunan >Assignee: Michael Osipov > Labels: build > > Hello > We use enterprise GitHub and we would like to utilize the enterprise support > added as part of https://issues.apache.org/jira/browse/MCHANGES-305 > We have tested and verified maven-changes-plugin:2.12-SNAPSHOT and its > working as expected. > As per the > [maven-changes-plugin|https://maven.apache.org/plugins/maven-changes-plugin/] > site, 2.11 was released on 2014-09-24, which is more than an year old now. > It will be nice to have maven-changes-plugin:2.12 released. > Thanks > Subin Sugunan -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-164) don't use document date from Sink API as creation date but as "date" without precision on created or last modified
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222193#comment-15222193
]
Michael Osipov commented on DOXIASITETOOLS-164:
---
I agree here but if there is no semantics one cannot reasonably use it in our
skins and I guess that 90 % of the people use our skins and not customs one.
For a value which cannot reasonbly used, especially for SEO, *I would drop it
altogether*. People only look at "Last Published". They do not care when the
document has been modified last.
> don't use document date from Sink API as creation date but as "date" without
> precision on created or last modified
> --
>
> Key: DOXIASITETOOLS-164
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-164
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Affects Versions: 1.7
>Reporter: Hervé Boutemy
> Fix For: 1.7.1
>
>
> as seen in DOXIA-541, the meaning of the date is not defined in Doxia: then
> it seems it's up to the content writer to choose...
> and it was a wrong choice to name the content of date field of the document
> as {{dateCreation}} variable in DOXIA-315 / DOXIASITETOOLS-20
> [r771801|http://svn.apache.org/r771801] in 2009
> let's start by showing the weak sematic before choosing what to do: creation
> date, last modification date, or even add some more features like multiple
> dates (for example "created : last modified")?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DOXIASITETOOLS-164) don't use document date from Sink API as creation date but as "date" without precision on created or last modified
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222193#comment-15222193
]
Michael Osipov edited comment on DOXIASITETOOLS-164 at 4/1/16 7:12 PM:
---
I agree here but if there is no semantics one cannot reasonably use it in our
skins and I guess that 90 % of the people use our skins and not customs one.
For a value which cannot reasonbly used, especially for SEO, *I would drop it
altogether in 2.0 along with Doxia 2.0*. People only look at "Last Published".
They do not care when the document has been modified last.
was (Author: michael-o):
I agree here but if there is no semantics one cannot reasonably use it in our
skins and I guess that 90 % of the people use our skins and not customs one.
For a value which cannot reasonbly used, especially for SEO, *I would drop it
altogether*. People only look at "Last Published". They do not care when the
document has been modified last.
> don't use document date from Sink API as creation date but as "date" without
> precision on created or last modified
> --
>
> Key: DOXIASITETOOLS-164
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-164
> Project: Maven Doxia Sitetools
> Issue Type: Bug
> Components: Site renderer
>Affects Versions: 1.7
>Reporter: Hervé Boutemy
> Fix For: 1.7.1
>
>
> as seen in DOXIA-541, the meaning of the date is not defined in Doxia: then
> it seems it's up to the content writer to choose...
> and it was a wrong choice to name the content of date field of the document
> as {{dateCreation}} variable in DOXIA-315 / DOXIASITETOOLS-20
> [r771801|http://svn.apache.org/r771801] in 2009
> let's start by showing the weak sematic before choosing what to do: creation
> date, last modification date, or even add some more features like multiple
> dates (for example "created : last modified")?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MEAR-227) Configuration option includeInApplicationXml accesible for all modules
[ https://issues.apache.org/jira/browse/MEAR-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marek Gregor updated MEAR-227: -- Description: Currently includeInApplicationXml configuration option is available only for jarModule: https://maven.apache.org/plugins/maven-ear-plugin/modules.html#jarModule We need to use it also for another module (in our case it is webModule). I think it will be fine to enable this option for all modules (ejb, web, ...). The motivation is to enable specific ear to be built with modules by default not described in application.xml. Person responsible for deploying will add modules to application.xml based on current case. was: Currently includeInApplicationXml configuration option is available only for jarModule: https://maven.apache.org/plugins/maven-ear-plugin/modules.html#jarModule We need to use it also for another module (in our case it is webModule). I think it will be fine to enable this option for all modules (ejb, web, ...). Motivation is to enable specific ear to be built with modules by default not described in application.xml. Person responsible for deploying will add modules to application.xml based on current case. > Configuration option includeInApplicationXml accesible for all modules > -- > > Key: MEAR-227 > URL: https://issues.apache.org/jira/browse/MEAR-227 > Project: Maven Ear Plugin > Issue Type: Improvement >Reporter: Marek Gregor > > Currently includeInApplicationXml configuration option is available only for > jarModule: > https://maven.apache.org/plugins/maven-ear-plugin/modules.html#jarModule > We need to use it also for another module (in our case it is webModule). I > think it will be fine to enable this option for all modules (ejb, web, ...). > The motivation is to enable specific ear to be built with modules by default > not described in application.xml. Person responsible for deploying will add > modules to application.xml based on current case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MEAR-227) Configuration option includeInApplicationXml accesible for all modules
[ https://issues.apache.org/jira/browse/MEAR-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marek Gregor updated MEAR-227: -- Description: Currently includeInApplicationXml configuration option is available only for jarModule: https://maven.apache.org/plugins/maven-ear-plugin/modules.html#jarModule We need to use it also for another module (in our case it is webModule). I think it will be fine to enable this option for all modules (ejb, web, ...). Motivation is to enable specific ear to be built with modules by default not described in application.xml. Person responsible for deploying will add modules to application.xml based on current case. was: Currently includeInApplicationXml configuration option is available only for jarModule: https://maven.apache.org/plugins/maven-ear-plugin/modules.html#jarModule We need to use it also for another module (in our case it is webModule). I think it will be fine to enable this option for all modules (ejb, web, ...). > Configuration option includeInApplicationXml accesible for all modules > -- > > Key: MEAR-227 > URL: https://issues.apache.org/jira/browse/MEAR-227 > Project: Maven Ear Plugin > Issue Type: Improvement >Reporter: Marek Gregor > > Currently includeInApplicationXml configuration option is available only for > jarModule: > https://maven.apache.org/plugins/maven-ear-plugin/modules.html#jarModule > We need to use it also for another module (in our case it is webModule). I > think it will be fine to enable this option for all modules (ejb, web, ...). > Motivation is to enable specific ear to be built with modules by default not > described in application.xml. Person responsible for deploying will add > modules to application.xml based on current case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MEAR-227) Configuration option includeInApplicationXml accesible for all modules
Marek Gregor created MEAR-227: - Summary: Configuration option includeInApplicationXml accesible for all modules Key: MEAR-227 URL: https://issues.apache.org/jira/browse/MEAR-227 Project: Maven Ear Plugin Issue Type: Improvement Reporter: Marek Gregor Currently includeInApplicationXml configuration option is available only for jarModule: https://maven.apache.org/plugins/maven-ear-plugin/modules.html#jarModule We need to use it also for another module (in our case it is webModule). I think it will be fine to enable this option for all modules (ejb, web, ...). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MANTTASKS-251) Maven-ant-tasks does not always respect mirrors from settings.xml
Markus Lenzbauer created MANTTASKS-251:
--
Summary: Maven-ant-tasks does not always respect mirrors from
settings.xml
Key: MANTTASKS-251
URL: https://issues.apache.org/jira/browse/MANTTASKS-251
Project: Maven Ant Tasks
Issue Type: Bug
Components: dependencies task
Affects Versions: 2.1.3, 3.0.0-beta-1
Reporter: Markus Lenzbauer
The Maven-ant-tasks do not respect the mirrors defined in settings.xml.
For example with
com.vaadin.external.atmosphere:atmosphere-runtime:2.2.7.vaadin1 this is
problematic because this artifact has a dependency to
org.sonatype.oss:oss-parent:5 and contains also a repository definition for
oss.sonatype.org as http://oss.sonatype.org/content/repositories/releases.
But this repository does not contain version 5 of oss-parent anymore and
returns an HTML error page instead.
Maven central would contain this version but is not used although set as mirror.
Steps to reproduce:
Use this settings.xml:
{noformat}
http://maven.apache.org/SETTINGS/1.1.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0
http://maven.apache.org/xsd/settings-1.1.0.xsd;>
central
central
http://repo.maven.apache.org/maven2/
*
{noformat}
and this build.xml:
{noformat}
{noformat}
ant -verbose creates the following output:
{noformat}
[artifact:dependencies] Maven Ant Tasks version: 2.1.4-SNAPSHOT
[artifact:dependencies] Loading Maven settings file:
/.m2/settings.xml
[artifact:dependencies] Loading Maven settings file:
/apache-maven-3.2.5/conf/settings.xml
[artifact:dependencies] Using local repository: /.m2/repository
[artifact:dependencies] Resolving dependencies...
[artifact:dependencies] Using remote repositories:
- id=central, url=http://repo.maven.apache.org/maven2/, releases=enabled,
snapshots=disabled, authentication=null
org.apache.maven:super-pom:pom:2.0 (selected)
[artifact:dependencies] Downloading:
com/vaadin/external/atmosphere/atmosphere-runtime/2.2.7.vaadin1/atmosphere-runtime-2.2.7.vaadin1.pom
from repository central at http://repo.maven.apache.org/maven2/
[artifact:dependencies] Transferring 11K from central
[artifact:dependencies] Downloading:
org/sonatype/oss/oss-parent/5/oss-parent-5.pom from repository oss.sonatype.org
at http://oss.sonatype.org/content/repositories/releases
[artifact:dependencies] Transferring 0K from oss.sonatype.org
[artifact:dependencies] [WARNING] *** CHECKSUM FAILED - Checksum failed on
download: local = '81ffbd1712afe8cdf138b570c0fc9934742c33c1'; remote = '
[artifact:dependencies] 301' - RETRYING
[artifact:dependencies] Downloading:
org/sonatype/oss/oss-parent/5/oss-parent-5.pom from repository oss.sonatype.org
at http://oss.sonatype.org/content/repositories/releases
[artifact:dependencies] Transferring 0K from oss.sonatype.org
[artifact:dependencies] [WARNING] *** CHECKSUM FAILED - Checksum failed on
download: local = '81ffbd1712afe8cdf138b570c0fc9934742c33c1'; remote = '
[artifact:dependencies] 301' - IGNORING
[artifact:dependencies] An error has occurred while processing the Maven
artifact tasks.
[artifact:dependencies] Diagnosis:
[artifact:dependencies]
[artifact:dependencies] Unable to resolve artifact: Unable to get dependency
information: Unable to read the metadata file for artifact
'com.vaadin.external.atmosphere:atmosphere-runtime:jar': Cannot find parent:
org.sonatype.oss:oss-parent for project:
com.vaadin.external.atmosphere:atmosphere-project:pom:2.2.7.vaadin1 for project
com.vaadin.external.atmosphere:atmosphere-project:pom:2.2.7.vaadin1
[artifact:dependencies]
com.vaadin.external.atmosphere:atmosphere-runtime:jar:2.2.7.vaadin1
[artifact:dependencies]
[artifact:dependencies] from the specified remote repositories:
[artifact:dependencies] central (http://repo.maven.apache.org/maven2/)
[artifact:dependencies]
[artifact:dependencies] Path to dependency:
[artifact:dependencies] 1) org.apache.maven:super-pom:pom:2.0
[artifact:dependencies]
[artifact:dependencies]
[artifact:dependencies] Not a v4.0.0 POM. for project
org.sonatype.oss:oss-parent at
/.m2/repository/org/sonatype/oss/oss-parent/5/oss-parent-5.pom
{noformat}
This behavior and a possible fix is already described in the comments of
[MANTTASKS-157] but this issue has recently been closed without fixing it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5993) Confusing error message in case of missing/empty artifactId and version in pluginManagement
Konrad Windszus created MNG-5993:
Summary: Confusing error message in case of missing/empty
artifactId and version in pluginManagement
Key: MNG-5993
URL: https://issues.apache.org/jira/browse/MNG-5993
Project: Maven
Issue Type: Improvement
Components: Dependencies
Affects Versions: 3.3.9
Reporter: Konrad Windszus
Executing any goals/phases on this pom.xml leads to a weird error
{code}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
com.example.group
testinvalidpom
0.0.1-SNAPSHOT
{code}
The error being emitted is
{code}
[ERROR] Error resolving version for plugin ':null' from the repositories [local
(), nexus ()]: Plugin not found in any plugin
repository -> [Help 1]
{code}
Even with debug you only see something like this
{code}
[ERROR] Error resolving version for plugin ':null' from the repositories [...]:
Plugin not found in any plugin repository -> [Help 1]
org.apache.maven.plugin.version.PluginVersionResolutionException: Error
resolving version for plugin ':null' from the repositories [local
(/Users/konradwindszus/.m2/repository), nexus
(https://repo.int.netcentric.biz/nexus/content/groups/public/)]: Plugin not
found in any plugin repository
at
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.selectVersion(DefaultPluginVersionResolver.java:236)
at
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository(DefaultPluginVersionResolver.java:148)
at
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve(DefaultPluginVersionResolver.java:96)
at
org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions(LifecyclePluginResolver.java:89)
at
org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:116)
at
org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:135)
at
org.apache.maven.lifecycle.internal.builder.BuilderCommon.resolveBuildPlan(BuilderCommon.java:97)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:109)
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:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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)
{code}
In this example the error is easy to spot, but for bigger pom.xmls with more
complex hierarchies it is very hard.
Some basic validation should take place that on the merged pom.xml all of
groupId, artifactId and version is available and if that is not the case, the
line number of the pom.xml together with the filename should be given out,
where the according information is missing.
A similar error is emitted in case the groupId element is missing as well or
there is an empty artifactId.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MINVOKER-202) Remove unused ant dependency
[
https://issues.apache.org/jira/browse/MINVOKER-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221635#comment-15221635
]
Hudson commented on MINVOKER-202:
-
FAILURE: Integrated in maven-plugins #5566 (See
[https://builds.apache.org/job/maven-plugins/5566/])
[MINVOKER-202] Remove unused ant dependency (khmarbaise:
[http://svn.apache.org/viewvc/?view=rev=1737354])
* maven-invoker-plugin/pom.xml
> Remove unused ant dependency
>
>
> Key: MINVOKER-202
> URL: https://issues.apache.org/jira/browse/MINVOKER-202
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> The following dependency seemed not being used:
> {code:xml}
>
> org.apache.ant
> ant
> 1.8.1
>
>
> org.apache.ant
> ant-launcher
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MINVOKER-202) Remove unused ant dependency
[
https://issues.apache.org/jira/browse/MINVOKER-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MINVOKER-202.
Resolution: Fixed
Assignee: Karl Heinz Marbaise
Done in [r1737354|http://svn.apache.org/r1737354]
> Remove unused ant dependency
>
>
> Key: MINVOKER-202
> URL: https://issues.apache.org/jira/browse/MINVOKER-202
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> The following dependency seemed not being used:
> {code:xml}
>
> org.apache.ant
> ant
> 1.8.1
>
>
> org.apache.ant
> ant-launcher
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Moved] (MINVOKER-202) Remove unused ant dependency
[
https://issues.apache.org/jira/browse/MINVOKER-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise moved MJAR-211 to MINVOKER-202:
---
Fix Version/s: (was: 3.0.0)
3.0.0
Affects Version/s: (was: 3.0.0)
3.0.0
Key: MINVOKER-202 (was: MJAR-211)
Project: Maven Invoker Plugin (was: Maven JAR Plugin)
> Remove unused ant dependency
>
>
> Key: MINVOKER-202
> URL: https://issues.apache.org/jira/browse/MINVOKER-202
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> The following dependency seemed not being used:
> {code:xml}
>
> org.apache.ant
> ant
> 1.8.1
>
>
> org.apache.ant
> ant-launcher
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MJAR-211) Remove unused ant dependency
Karl Heinz Marbaise created MJAR-211:
Summary: Remove unused ant dependency
Key: MJAR-211
URL: https://issues.apache.org/jira/browse/MJAR-211
Project: Maven JAR Plugin
Issue Type: Improvement
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
Priority: Minor
Fix For: 3.0.0
The following dependency seemed not being used:
{code:xml}
org.apache.ant
ant
1.8.1
org.apache.ant
ant-launcher
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-773) The evaluation of the within the settings.xml does not work
[
https://issues.apache.org/jira/browse/MSITE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221442#comment-15221442
]
Konrad Windszus commented on MSITE-773:
---
The according code is at
https://github.com/apache/maven-plugins/blob/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/deploy/AbstractDeployMojo.java#L675.
> The evaluation of the within the settings.xml does not work
> ---
>
> Key: MSITE-773
> URL: https://issues.apache.org/jira/browse/MSITE-773
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.5
>Reporter: Konrad Windszus
>
> Although the m-s-p evaluates the configuration within the settings.xml it
> does not correctly evaluate the {{wagonProvider}} element in the settings.xml
> (https://maven.apache.org/guides/mini/guide-wagon-providers.html).
> Using it leads to exceptions like this
> {code}
> Unable to configure Wagon: 'dav': While configuring wagon for 'nexus': Unable
> to apply wagon configuration. Cannot find 'wagonProvider' in class
> org.apache.maven.wagon.providers.webdav.WebDavWagon
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSITE-773) The evaluation of the within the settings.xml does not work
Konrad Windszus created MSITE-773:
-
Summary: The evaluation of the within the
settings.xml does not work
Key: MSITE-773
URL: https://issues.apache.org/jira/browse/MSITE-773
Project: Maven Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.5
Reporter: Konrad Windszus
Although the m-s-p evaluates the configuration within the settings.xml it does
not correctly evaluate the {{wagonProvider}} element in the settings.xml
(https://maven.apache.org/guides/mini/guide-wagon-providers.html).
Using it leads to exceptions like this
{code}
Unable to configure Wagon: 'dav': While configuring wagon for 'nexus': Unable
to apply wagon configuration. Cannot find 'wagonProvider' in class
org.apache.maven.wagon.providers.webdav.WebDavWagon
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-827) Passing "-pl" via arguments is not accepted
[
https://issues.apache.org/jira/browse/MRELEASE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221343#comment-15221343
]
Christian Brugger commented on MRELEASE-827:
I faced the same problem, that "-pl" and "-am" is not passed to the maven
execution when performing the release.
We have a multi-module project, where some of the modules do assemble some
products and use some common modules.
In order to release only specific products, we use -pl and -am.
I have tried to change the maven-release-manager (and the maven-release-plugin
to use the changed maven-release-manager) to pass -pl and -am to the maven
execution and it worked perfectly.
Is there any chance that this behaviour will be implemented soon?
> Passing "-pl" via arguments is not accepted
> ---
>
> Key: MRELEASE-827
> URL: https://issues.apache.org/jira/browse/MRELEASE-827
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.4
>Reporter: Konrad Windszus
>
> If I try to pass on a "-pl" to the forked Maven via arguments, I get the
> following exception:
> Failed to re-parse additional arguments for Maven
> {noformat}
> Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
> project testproject: Failed to re-parse additional arguments for Maven
> invocation.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> 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:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> 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.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:100)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:66)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to re-parse
> additional arguments for Maven invocation.
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:281)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:232)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Failed
> to re-parse additional arguments for Maven invocation.
> at
> org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89)
> at
> org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:44)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
> at
>
