[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&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&focusedCommentId=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&focusedCommentId=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 > org.apache.maven.sha