[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069249#comment-15069249
]
Jarkko Rantavuori commented on MNG-5756:
I can provide a patch/PR if that's what's needed. I guess this is too trivial
to interest people in participation, but in SO there's already been ~20 votes
about the subject.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-758) upgrade wagon-api from 1.0 to 2.x
[ https://issues.apache.org/jira/browse/MSITE-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069166#comment-15069166 ] Hervé Boutemy commented on MSITE-758: - does it only relates to Maven 2 support or will it really break (or take risks) on Maven 2 support? > upgrade wagon-api from 1.0 to 2.x > - > > Key: MSITE-758 > URL: https://issues.apache.org/jira/browse/MSITE-758 > Project: Maven Site Plugin > Issue Type: Task > Components: site:deploy >Affects Versions: 3.4 >Reporter: Hervé Boutemy > > I don't really know what changed from wagon-api 1.0 to 2.0 > or from 2.0 to 2.10 (= latest when writing this) > but this is just about the general idea of dropping old wagon 1.0 dependency > to get a newer one > for reference: > - Maven 2..x to 3.0.3 use wagon 1.0-beta > http://maven.apache.org/ref/3.0.3/apache-maven/dependencies.html > - Maven 3.0.4 uses wagon 2.2 > http://maven.apache.org/ref/3.0.4/apache-maven/dependencies.html > - Maven 3.0.5 uses wagon 2.4 > http://maven.apache.org/ref/3.0.5/apache-maven/dependencies.html > ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MSITE-758) upgrade wagon-api from 1.0 to 2.x
Hervé Boutemy created MSITE-758: --- Summary: upgrade wagon-api from 1.0 to 2.x Key: MSITE-758 URL: https://issues.apache.org/jira/browse/MSITE-758 Project: Maven Site Plugin Issue Type: Task Components: site:deploy Affects Versions: 3.4 Reporter: Hervé Boutemy I don't really know what changed from wagon-api 1.0 to 2.0 or from 2.0 to 2.10 (= latest when writing this) but this is just about the general idea of dropping old wagon 1.0 dependency to get a newer one for reference: - Maven 2..x to 3.0.3 use wagon 1.0-beta http://maven.apache.org/ref/3.0.3/apache-maven/dependencies.html - Maven 3.0.4 uses wagon 2.2 http://maven.apache.org/ref/3.0.4/apache-maven/dependencies.html - Maven 3.0.5 uses wagon 2.4 http://maven.apache.org/ref/3.0.5/apache-maven/dependencies.html ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MSITE-757) drop Maven 2 support
Hervé Boutemy created MSITE-757: --- Summary: drop Maven 2 support Key: MSITE-757 URL: https://issues.apache.org/jira/browse/MSITE-757 Project: Maven Site Plugin Issue Type: Task Affects Versions: 3.4 Reporter: Hervé Boutemy this will permit some code cleanup, since there are some hacks to make reporting work on both Maven 2 and Maven 3 (which has changed much) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSITE-755) upgrade Doxia and Doxia Sitetools from1.6 to 1.7
[ https://issues.apache.org/jira/browse/MSITE-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-755: Summary: upgrade Doxia and Doxia Sitetools from1.6 to 1.7 (was: upgrade Doxia and Doxia Sitetools to version 1.7) > upgrade Doxia and Doxia Sitetools from1.6 to 1.7 > > > Key: MSITE-755 > URL: https://issues.apache.org/jira/browse/MSITE-755 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5 > > > a lot of fixed issues > and new features: todo copy release notes once released -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSITE-755) upgrade Doxia and Doxia Sitetools from 1.6 to 1.7
[ https://issues.apache.org/jira/browse/MSITE-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-755: Description: a lot of fixed issues and cleanup and new features: todo copy release notes once released was: a lot of fixed issues and new features: todo copy release notes once released > upgrade Doxia and Doxia Sitetools from 1.6 to 1.7 > - > > Key: MSITE-755 > URL: https://issues.apache.org/jira/browse/MSITE-755 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5 > > > a lot of fixed issues and cleanup > and new features: todo copy release notes once released -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSITE-755) upgrade Doxia and Doxia Sitetools from 1.6 to 1.7
[ https://issues.apache.org/jira/browse/MSITE-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-755: Summary: upgrade Doxia and Doxia Sitetools from 1.6 to 1.7 (was: upgrade Doxia and Doxia Sitetools from1.6 to 1.7) > upgrade Doxia and Doxia Sitetools from 1.6 to 1.7 > - > > Key: MSITE-755 > URL: https://issues.apache.org/jira/browse/MSITE-755 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5 > > > a lot of fixed issues > and new features: todo copy release notes once released -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-101) Add ISO date format to site rendering context
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069156#comment-15069156
]
Hervé Boutemy commented on DOXIASITETOOLS-101:
--
this version of Doxia Site Rendering has already a lot of cleaning in a lot of
areas: let's clean another area :)
notice #createVelocityContext has been renamed now to better differentiate
Document processing from Site Template (skin) processing: see DOXIASITETOOLS-131
+1 for publishDate: removing unusable feature (never asked for) is a good
simplification
+1 for isoDateFormat
for each other idea, we need to discuss on separate threads, since we ned to
precise semantics (current, which is barely documented, and future which should
be documented :) ): general ideas seem relevant to me
there is just one common issue: compatibility
IMHO, just removing old variables will make old skins not work with newer
maven-site-plugin, which seems a bit rude
we need some transition, ideally with warnings (not sure it's easy to implement)
of course, for Maven-owned skins, we can update our skins immediately (then
require maven-site-plugin 3.5)
perhaps we need to think about adding feature regarding skins and
maven-site-plugin versions requirements: perhpase it's too much complexity for
low benefit...
> Add ISO date format to site rendering context
> -
>
> Key: DOXIASITETOOLS-101
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-101
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Michael Osipov
> Fix For: 1.7
>
>
> Currently we have {{dateFormat}} only which depends on {{site.xml}}, we need
> a standardized format which can we used in meta tags as well as throughout
> the site, if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5951) add an option to avoid path addition to inherited URLs
[
https://issues.apache.org/jira/browse/MNG-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069141#comment-15069141
]
Hervé Boutemy commented on MNG-5951:
now let's discuss about ideas of solutions:
I suppose we can add XML attribute(s) to each of the 5 inherited URLs to
customize inheritance behaviour (IIRC, this will be compatible with old Maven
version or with repository managers, since they are supposed to simply ignore
XML attributes)
then which attributes names, values, and semantics?
simple option: {{child.inherit.append.path}}: boolean, default value=true
will apply on childs when inheriting from current POM (because applying on
current pom when inheriting from its parent does not really have any meaning,
since configuration will override value instead of inheriting)
WDYT?
> add an option to avoid path addition to inherited URLs
> --
>
> Key: MNG-5951
> URL: https://issues.apache.org/jira/browse/MNG-5951
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.9
>Reporter: Jörg Sesterhenn
> Attachments: MNG-5951.zip
>
>
> What I am trying to achieve is
> the definition of a project.url in a parent pom
> in a way that all children inherit a url ending with
> {code}
> ${project.groupId}/${project.artifactId}/${project.version}/
> {code}
> in order to be able to publish sites of all artifacts in all versions in
> parallel
> without having to redefine the url in every child pom.
> This is currently not working as expected in maven due to the default child
> urls calculation which leads to urls that add up parent urls like
> http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
> The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
> child url calculation (those are the artifactIds of all parent poms beneath
> our enterprise parent pom where the url is defined) and *is expexted to not
> be there at all*. The repeated artifactID at the end of the url is
> superfluous as well but tollerable.
> I expect maven-core to be changed so that I can turn on/off the automatic
> calculation of child URLs as an option which is by default on (current
> behaviour so nothing will change unless configured explicitly).
> See the discussion in MSITE-672.
> As this can not be done in the maven-site-plugin there needs to be a change
> in Maven itself (core), in Maven Model Builder, ie the way effective model is
> calculated, and more precisely in the inheritance step:
> http://maven.apache.org/ref/current/maven-model-builder/.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5951) add an option to avoid path addition to inherited URLs
[
https://issues.apache.org/jira/browse/MNG-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069135#comment-15069135
]
Hervé Boutemy edited comment on MNG-5951 at 12/23/15 4:40 AM:
--
added unit test (just run {{mvn}}) to show the issue and limited solution by
using properties (to reduce complexity of copy/paste)
Notice: IIUC: this unit test shows a multi-module build, which does not really
have any meaning here
I suppose your use case is with independent single module builds which inherit
a parent pom
was (Author: hboutemy):
added unit test (just run {{mvn}}) to show the issue and limited solution by
using properties (to reduce complexity of copy/paste)
> add an option to avoid path addition to inherited URLs
> --
>
> Key: MNG-5951
> URL: https://issues.apache.org/jira/browse/MNG-5951
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.9
>Reporter: Jörg Sesterhenn
> Attachments: MNG-5951.zip
>
>
> What I am trying to achieve is
> the definition of a project.url in a parent pom
> in a way that all children inherit a url ending with
> {code}
> ${project.groupId}/${project.artifactId}/${project.version}/
> {code}
> in order to be able to publish sites of all artifacts in all versions in
> parallel
> without having to redefine the url in every child pom.
> This is currently not working as expected in maven due to the default child
> urls calculation which leads to urls that add up parent urls like
> http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
> The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
> child url calculation (those are the artifactIds of all parent poms beneath
> our enterprise parent pom where the url is defined) and *is expexted to not
> be there at all*. The repeated artifactID at the end of the url is
> superfluous as well but tollerable.
> I expect maven-core to be changed so that I can turn on/off the automatic
> calculation of child URLs as an option which is by default on (current
> behaviour so nothing will change unless configured explicitly).
> See the discussion in MSITE-672.
> As this can not be done in the maven-site-plugin there needs to be a change
> in Maven itself (core), in Maven Model Builder, ie the way effective model is
> calculated, and more precisely in the inheritance step:
> http://maven.apache.org/ref/current/maven-model-builder/.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5951) add an option to avoid path addition to inherited URLs
[
https://issues.apache.org/jira/browse/MNG-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-5951:
---
Attachment: MNG-5951.zip
added unit test (just run {{mvn}}) to show the issue and limited solution by
using properties (to reduce complexity of copy/paste)
> add an option to avoid path addition to inherited URLs
> --
>
> Key: MNG-5951
> URL: https://issues.apache.org/jira/browse/MNG-5951
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.9
>Reporter: Jörg Sesterhenn
> Attachments: MNG-5951.zip
>
>
> What I am trying to achieve is
> the definition of a project.url in a parent pom
> in a way that all children inherit a url ending with
> {code}
> ${project.groupId}/${project.artifactId}/${project.version}/
> {code}
> in order to be able to publish sites of all artifacts in all versions in
> parallel
> without having to redefine the url in every child pom.
> This is currently not working as expected in maven due to the default child
> urls calculation which leads to urls that add up parent urls like
> http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
> The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
> child url calculation (those are the artifactIds of all parent poms beneath
> our enterprise parent pom where the url is defined) and *is expexted to not
> be there at all*. The repeated artifactID at the end of the url is
> superfluous as well but tollerable.
> I expect maven-core to be changed so that I can turn on/off the automatic
> calculation of child URLs as an option which is by default on (current
> behaviour so nothing will change unless configured explicitly).
> See the discussion in MSITE-672.
> As this can not be done in the maven-site-plugin there needs to be a change
> in Maven itself (core), in Maven Model Builder, ie the way effective model is
> calculated, and more precisely in the inheritance step:
> http://maven.apache.org/ref/current/maven-model-builder/.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5951) add an option to avoid path addition to inherited URLs
[
https://issues.apache.org/jira/browse/MNG-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-5951:
---
Description:
What I am trying to achieve is
the definition of a project.url in a parent pom
in a way that all children inherit a url ending with
{code}
${project.groupId}/${project.artifactId}/${project.version}/
{code}
in order to be able to publish sites of all artifacts in all versions in
parallel
without having to redefine the url in every child pom.
This is currently not working as expected in maven due to the default child
urls calculation which leads to urls that add up parent urls like
http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
child url calculation (those are the artifactIds of all parent poms beneath our
enterprise parent pom where the url is defined) and *is expexted to not be
there at all*. The repeated artifactID at the end of the url is superfluous as
well but tollerable.
I expect maven-core to be changed so that I can turn on/off the automatic
calculation of child URLs as an option which is by default on (current
behaviour so nothing will change unless configured explicitly).
See the discussion in MSITE-672.
As this can not be done in the maven-site-plugin there needs to be a change in
Maven itself (core), in Maven Model Builder, ie the way effective model is
calculated, and more precisely in the inheritance step:
http://maven.apache.org/ref/current/maven-model-builder/.
was:
What I am trying to achieve is
the definition of a project.url in a parent pom
in a way that all children inherit a url ending with
{code}
${project.groupId}/${project.artifactId}/${project.version}/
{code}
in order to be able to publish sites of all artifacts in all versions in
parallel
without having to redefine the url in every child pom.
This is currently not working as expected in maven due to the default child
urls calculation which leads to urls that add up parent urls like
http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
child url calculation (those are the artifactIds of all parent poms beneath our
enterprise parent pom where the url is defined) and *is expexted to not be
there at all*. The repeated artifactID at the end of the url is superfluous as
well but tollerable.
I expect maven-core to be changed so that I can turn on/off the automatic
calculation of child URLs as an option which is by default on (current
behaviour so nothing will change unless configured explicitly).
See the discussion in MSITE-672.
As this can not be done in the maven-site-plugin there needs to be a change in
Maven Model Builder, ie the way effective model is calculated, and more
precisely in the inheritance step:
http://maven.apache.org/ref/current/maven-model-builder/.
> add an option to avoid path addition to inherited URLs
> --
>
> Key: MNG-5951
> URL: https://issues.apache.org/jira/browse/MNG-5951
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.9
>Reporter: Jörg Sesterhenn
>
> What I am trying to achieve is
> the definition of a project.url in a parent pom
> in a way that all children inherit a url ending with
> {code}
> ${project.groupId}/${project.artifactId}/${project.version}/
> {code}
> in order to be able to publish sites of all artifacts in all versions in
> parallel
> without having to redefine the url in every child pom.
> This is currently not working as expected in maven due to the default child
> urls calculation which leads to urls that add up parent urls like
> http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
> The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
> child url calculation (those are the artifactIds of all parent poms beneath
> our enterprise parent pom where the url is defined) and *is expexted to not
> be there at all*. The repeated artifactID at the end of the url is
> superfluous as well but tollerable.
> I expect maven-core to be changed so that I can turn on/off the automatic
> calculation of child URLs as an option which is by default on (current
> behaviour so nothing will change unless configured explicitly).
> See the discussion in MSITE-672.
> As this can not be done in the maven-site-plugin there needs to be a change
> in
[jira] [Updated] (MNG-5951) add an option to avoid path addition to inherited URLs
[
https://issues.apache.org/jira/browse/MNG-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-5951:
---
Description:
What I am trying to achieve is
the definition of a project.url in a parent pom
in a way that all children inherit a url ending with
{code}
${project.groupId}/${project.artifactId}/${project.version}/
{code}
in order to be able to publish sites of all artifacts in all versions in
parallel
without having to redefine the url in every child pom.
This is currently not working as expected in maven due to the default child
urls calculation which leads to urls that add up parent urls like
http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
child url calculation (those are the artifactIds of all parent poms beneath our
enterprise parent pom where the url is defined) and *is expexted to not be
there at all*. The repeated artifactID at the end of the url is superfluous as
well but tollerable.
I expect maven-core to be changed so that I can turn on/off the automatic
calculation of child URLs as an option which is by default on (current
behaviour so nothing will change unless configured explicitly).
See the discussion in MSITE-672.
As this can not be done in the maven-site-plugin there needs to be a change in
Maven Model Builder, ie the way effective model is calculated, and more
precisely in the inheritance step:
http://maven.apache.org/ref/current/maven-model-builder/.
was:
What I am trying to achieve is
the definition of a project.url in a parent pom
in a way that all children inherit a url ending with
{code}
${project.groupId}/${project.artifactId}/${project.version}/
{code}
in order to be able to publish sites of all artifacts in all versions in
parallel
without having to redefine the url in every child pom.
This is currently not working as expected in maven due to the default child
urls calculation which leads to urls that add up parent urls like
http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
child url calculation (those are the artifactIds of all parent poms beneath our
enterprise parent pom where the url is defined) and *is expexted to not be
there at all*. The repeated artifactID at the end of the url is superfluous as
well but tollerable.
I expect maven-core to be changed so that I can turn on/off the automatic
calculation of child URLs as an option which is by default on (current
behaviour so nothing will change unless configured explicitly).
See the discussion in MSITE-672.
As this can not be done in the maven-site-plugin there needs to be a change in
maven-core.
> add an option to avoid path addition to inherited URLs
> --
>
> Key: MNG-5951
> URL: https://issues.apache.org/jira/browse/MNG-5951
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.9
>Reporter: Jörg Sesterhenn
>
> What I am trying to achieve is
> the definition of a project.url in a parent pom
> in a way that all children inherit a url ending with
> {code}
> ${project.groupId}/${project.artifactId}/${project.version}/
> {code}
> in order to be able to publish sites of all artifacts in all versions in
> parallel
> without having to redefine the url in every child pom.
> This is currently not working as expected in maven due to the default child
> urls calculation which leads to urls that add up parent urls like
> http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
> The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
> child url calculation (those are the artifactIds of all parent poms beneath
> our enterprise parent pom where the url is defined) and *is expexted to not
> be there at all*. The repeated artifactID at the end of the url is
> superfluous as well but tollerable.
> I expect maven-core to be changed so that I can turn on/off the automatic
> calculation of child URLs as an option which is by default on (current
> behaviour so nothing will change unless configured explicitly).
> See the discussion in MSITE-672.
> As this can not be done in the maven-site-plugin there needs to be a change
> in Maven Model Builder, ie the way effective model is calculated, and more
> precisely in the inheritance step:
> http://maven.apache.org/ref/current/maven-model-builder/.
--
T
[jira] [Updated] (MNG-5951) add an option to avoid path addition to inherited URLs
[
https://issues.apache.org/jira/browse/MNG-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-5951:
---
Summary: add an option to avoid path addition to inherited URLs (was:
Interpolate project urls (site...) at child level)
> add an option to avoid path addition to inherited URLs
> --
>
> Key: MNG-5951
> URL: https://issues.apache.org/jira/browse/MNG-5951
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.9
>Reporter: Jörg Sesterhenn
>
> What I am trying to achieve is
> the definition of a project.url in a parent pom
> in a way that all children inherit a url ending with
> {code}
> ${project.groupId}/${project.artifactId}/${project.version}/
> {code}
> in order to be able to publish sites of all artifacts in all versions in
> parallel
> without having to redefine the url in every child pom.
> This is currently not working as expected in maven due to the default child
> urls calculation which leads to urls that add up parent urls like
> http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
> The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
> child url calculation (those are the artifactIds of all parent poms beneath
> our enterprise parent pom where the url is defined) and *is expexted to not
> be there at all*. The repeated artifactID at the end of the url is
> superfluous as well but tollerable.
> I expect maven-core to be changed so that I can turn on/off the automatic
> calculation of child URLs as an option which is by default on (current
> behaviour so nothing will change unless configured explicitly).
> See the discussion in MSITE-672.
> As this can not be done in the maven-site-plugin there needs to be a change
> in maven-core.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-672) Interpolation of site deploy URL not done in child
[
https://issues.apache.org/jira/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069106#comment-15069106
]
Hervé Boutemy commented on MSITE-672:
-
thank you for the update of MNG-5951 description: this makes now the
requirement/problem very clear
I'll just update the title: now it's clear that it's not about interpolation
but about inheritance (and now I know that this title was part of what was
confusing for me before :) )
And with all the preparation done during these 2 years, I now see how to
propose an implementation
and this could also meet MPIR-234 expectations (even if I don't think this is
the best solution for MPIR-234, but that's another story)
> Interpolation of site deploy URL not done in child
> --
>
> Key: MSITE-672
> URL: https://issues.apache.org/jira/browse/MSITE-672
> Project: Maven Site Plugin
> Issue Type: Wish
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Assignee: Hervé Boutemy
>
> I have my parent distribution site config filled out like so:
> {{scp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}/}}
> When the child tries to release:perform or {{site:deploy}} it tries to upload
> with the parent arifactId, groupId and version instead of the current project
> values. These should be interpolated like any other variables in the POM to
> prevent needless duplication in all children.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MSITE-756) add an option to dump Velocity processed Doxia files
[
https://issues.apache.org/jira/browse/MSITE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069095#comment-15069095
]
Hervé Boutemy edited comment on MSITE-756 at 12/23/15 3:42 AM:
---
yes, we can make the term more generic than {{saveVelocityDocument}} to be able
to support multiple templating engines (and update DOXIASITETOOLS-133 also)
And taking time to find a good name will help making things clear
notice there is another issue with the term to find: "template" has both
"templating engine" meaning and "site template" (ie. skin) meaning
And given that in this case, it's not about "site template"/skin but about
source Doxia document, {{savePreparedTemplate}} is not ok for me
in http://maven.apache.org/doxia/doxia-sitetools/, we say
bq. In addition, Doxia Sitetools processes files with extra .vm extension with
Velocity
{{saveProcessedDocuments}} for the mojo option? (notice I added a plural now :)
)
and {{processed}} for the directory name in {{target/generated-site}}?
was (Author: hboutemy):
yes, we can make the term more generic to be able to support multiple
templating engines (and update DOXIASITETOOLS-133 also)
And taking time to find a good name will help making things clear
notice there is another issue with the term to find: "template" has both
"templating engine" meaning and "site template" meaning
And given that in this case, it's not about "site template" but about source
Doxia document, {{savePreparedTemplate}} is not ok for me
in http://maven.apache.org/doxia/doxia-sitetools/, we say
bq. In addition, Doxia Sitetools processes files with extra .vm extension with
Velocity
{{saveProcessedDocuments}} for the mojo option?
and {{processed}} for the directory name in {{target/generated-site}}?
> add an option to dump Velocity processed Doxia files
>
>
> Key: MSITE-756
> URL: https://issues.apache.org/jira/browse/MSITE-756
> Project: Maven Site Plugin
> Issue Type: New Feature
> Components: doxia integration
>Affects Versions: 3.4
>Reporter: Hervé Boutemy
> Fix For: 3.5
>
>
> making feature prepared in DOXIASITETOOLS-133 available and configurable from
> maven-site-plugin
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-756) add an option to dump Velocity processed Doxia files
[
https://issues.apache.org/jira/browse/MSITE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069095#comment-15069095
]
Hervé Boutemy commented on MSITE-756:
-
yes, we can make the term more generic to be able to support multiple
templating engines (and update DOXIASITETOOLS-133 also)
And taking time to find a good name will help making things clear
notice there is another issue with the term to find: "template" has both
"templating engine" meaning and "site template" meaning
And given that in this case, it's not about "site template" but about source
Doxia document, {{savePreparedTemplate}} is not ok for me
in http://maven.apache.org/doxia/doxia-sitetools/, we say
bq. In addition, Doxia Sitetools processes files with extra .vm extension with
Velocity
{{saveProcessedDocument}} for the mojo option?
and {{processed}} for the directory name in {{target/generated-site}}?
> add an option to dump Velocity processed Doxia files
>
>
> Key: MSITE-756
> URL: https://issues.apache.org/jira/browse/MSITE-756
> Project: Maven Site Plugin
> Issue Type: New Feature
> Components: doxia integration
>Affects Versions: 3.4
>Reporter: Hervé Boutemy
> Fix For: 3.5
>
>
> making feature prepared in DOXIASITETOOLS-133 available and configurable from
> maven-site-plugin
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MSITE-756) add an option to dump Velocity processed Doxia files
[
https://issues.apache.org/jira/browse/MSITE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069095#comment-15069095
]
Hervé Boutemy edited comment on MSITE-756 at 12/23/15 3:39 AM:
---
yes, we can make the term more generic to be able to support multiple
templating engines (and update DOXIASITETOOLS-133 also)
And taking time to find a good name will help making things clear
notice there is another issue with the term to find: "template" has both
"templating engine" meaning and "site template" meaning
And given that in this case, it's not about "site template" but about source
Doxia document, {{savePreparedTemplate}} is not ok for me
in http://maven.apache.org/doxia/doxia-sitetools/, we say
bq. In addition, Doxia Sitetools processes files with extra .vm extension with
Velocity
{{saveProcessedDocuments}} for the mojo option?
and {{processed}} for the directory name in {{target/generated-site}}?
was (Author: hboutemy):
yes, we can make the term more generic to be able to support multiple
templating engines (and update DOXIASITETOOLS-133 also)
And taking time to find a good name will help making things clear
notice there is another issue with the term to find: "template" has both
"templating engine" meaning and "site template" meaning
And given that in this case, it's not about "site template" but about source
Doxia document, {{savePreparedTemplate}} is not ok for me
in http://maven.apache.org/doxia/doxia-sitetools/, we say
bq. In addition, Doxia Sitetools processes files with extra .vm extension with
Velocity
{{saveProcessedDocument}} for the mojo option?
and {{processed}} for the directory name in {{target/generated-site}}?
> add an option to dump Velocity processed Doxia files
>
>
> Key: MSITE-756
> URL: https://issues.apache.org/jira/browse/MSITE-756
> Project: Maven Site Plugin
> Issue Type: New Feature
> Components: doxia integration
>Affects Versions: 3.4
>Reporter: Hervé Boutemy
> Fix For: 3.5
>
>
> making feature prepared in DOXIASITETOOLS-133 available and configurable from
> maven-site-plugin
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DOXIASITETOOLS-133) for Velocity processed Doxia files (*.extension.vm), add an option to dump generated markup (= *.extension)
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed DOXIASITETOOLS-133. Resolution: Fixed Assignee: Hervé Boutemy > for Velocity processed Doxia files (*.extension.vm), add an option to dump > generated markup (= *.extension) > --- > > Key: DOXIASITETOOLS-133 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-133 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Site renderer >Affects Versions: 1.6 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > This will ease debugging when something gets wrong when Velocity is > interpreting content -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5756:
Labels: (was: close-pending)
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068986#comment-15068986
]
Michael Osipov commented on MNG-5756:
-
I do agree. Though, there is little participation on this issue and not further
complaints about confusion.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
> Labels: close-pending
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068974#comment-15068974
]
Jarkko Rantavuori commented on MNG-5756:
Surely this isn't close-pending due to that? Java 9 GA is currently scheduled
for March 2017, and has already been delayed. It's hardly a reason to not fix
this now. Even when it hits GA this will continue to be a problem in earlier
versions.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
> Labels: close-pending
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5917) Saved password with umlaut breaks deployment
[ https://issues.apache.org/jira/browse/MNG-5917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-5917. --- Resolution: Incomplete > Saved password with umlaut breaks deployment > > > Key: MNG-5917 > URL: https://issues.apache.org/jira/browse/MNG-5917 > Project: Maven > Issue Type: Bug > Components: Settings >Affects Versions: 3.3.3 > Environment: Fedora GNU/Linux 22 > Oracle Java 8.0.51 >Reporter: Christian Kalkhoff >Priority: Critical > Labels: close-pending > > My password to Artifactory contains a german umlaut (äöüÄÖÜß). I saved it > either encrypted and plain to settings.xml. > When I run release:perform the deployment breaks because artifactory refuses > the password. > I had a look with wireshark and the credentials contain a '?' where the > umlaut should be. > Logging in to artifactory using the web interfaces works with the password. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MCHECKSTYLE-309) Upgrade SLF4J dependency version
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MCHECKSTYLE-309.
--
Resolution: Incomplete
> Upgrade SLF4J dependency version
>
>
> Key: MCHECKSTYLE-309
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-309
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Reporter: Konstantin Pokrovsky
>Priority: Minor
> Labels: close-pending
>
> Checkstyle has dependencies on old SLF4J versions: slf4j-jdk14-1.5.6 and
> jcl-over-slf4j-1.5.6. Maven 3.3.3 provide SLF4J 1.7.5 in its libs. By default
> maven use simple provider for slf4j and it is backward compatible to API
> 1.5.6. But when I change the provier to logback API compatibility breaks:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.16:check (default) on
> project rt: Execution default of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.16:check failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-checkstyle-plugin:2.16:check:
> java.lang.NoSuchMethodError:
> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
> [ERROR] -
> [ERROR] realm =
> plugin>org.apache.maven.plugins:maven-checkstyle-plugin:2.16
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/C:/Users/kpokrovsky/.m2/repository/org/apache/maven/plugins/maven-checkstyle-plugin/2.16/maven-checkstyle-plugin-2.16.jar
> [ERROR] urls[1] =
> file:/C:/Users/kpokrovsky/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
> [ERROR] urls[2] =
> file:/C:/Users/kpokrovsky/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
> [ERROR] urls[3] =
> file:/C:/Users/kpokrovsky/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> {noformat}
> Please refer to http://www.slf4j.org/faq.html#compatibility - while API is
> backward compatible, bindings are not. So checkstyle has to keep its SLF4J
> versions in sync with maven's SLF4J providers.
> For now problem can be fixed by overriding plugin's dependencies:
> {noformat}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 2.16
>
>
> org.slf4j
> slf4j-jdk14
> 1.7.5
>
>
> org.slf4j
> jcl-over-slf4j
> 1.7.5
>
>
>
> {noformat}
> BTW, for some reason the issue does not appear on maven 3.2.3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5853) Can not set proxy port to 443
[ https://issues.apache.org/jira/browse/MNG-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-5853. --- Resolution: Incomplete > Can not set proxy port to 443 > - > > Key: MNG-5853 > URL: https://issues.apache.org/jira/browse/MNG-5853 > Project: Maven > Issue Type: Bug > Components: General, Settings >Affects Versions: 3.2.3 > Environment: mvn --version > Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; > 2014-08-12T03:58:10+07:00) > Maven home: /opt/maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/java/jdk1.7.0_67/jre > Default locale: en_US, platform encoding: ANSI_X3.4-1968 > OS name: "linux", version: "2.6.32-431.el6.x86_64", arch: "amd64", family: > "unix" > > > > true > http > x.x.x.x > 443 > > > www.google.com|*.somewhere.com > > > >Reporter: Chuyen Vo > Labels: close-pending > > org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec > execute > INFO: I/O exception (java.net.SocketException) caught when processing > request: java.security.NoSuchAlgorithmException: Error constructing > implementation (algorithm: Default, provider: SunJSSE, class: > sun.security.ssl.SSLContextImpl$DefaultSSLContext) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MCHECKSTYLE-252) Version 2.13 includes non-source files in checks
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MCHECKSTYLE-252.
--
Resolution: Incomplete
> Version 2.13 includes non-source files in checks
>
>
> Key: MCHECKSTYLE-252
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-252
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:checkstyle
>Affects Versions: 2.13
>Reporter: Michael Heuer
> Labels: close-pending
> Attachments: mcheckstyle-252.tar.gz
>
>
> Updating maven-checkstyle-plugin to version 2.13 and running
> {noformat}$ mvn site{noformat}
> now includes non-source files in its checks, e.g.
> {noformat}COPYING
> COPYING.LESSER
> target/generated-classes/cobertura/cobertura.properties{noformat}
> While it is rather amusing to have checkstyle complain that COPYING (the text
> of the GNU General Public License) doesn't include a license header, it seems
> that the default source root or one of the other properties new to version
> 2.13 does not have an appropriate default value. The target directory should
> also be excluded by default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MCHECKSTYLE-306) Support "ignoreInlineTags" property introduced in Checkstyle 6.8
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MCHECKSTYLE-306.
--
Resolution: Incomplete
> Support "ignoreInlineTags" property introduced in Checkstyle 6.8
>
>
> Key: MCHECKSTYLE-306
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-306
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
> Components: checkstyle:check
>Affects Versions: 2.16
>Reporter: Pierre Maréchal
> Labels: close-pending
>
> Currently using a Checkstyle version greater than 6.7 fails with the error :
> {quote}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.16:check (validate) on
> project parent: Failed during checkstyle configuration:
> cannot initialize module TreeWalker - Property 'ignoreInlineTags' in module
> TreeWalker does not exist, please check the documentation -> [Help 1]
> {quote}
> This property is part of SingleLineJavadoc
> (http://checkstyle.sourceforge.net/config_javadoc.html#SingleLineJavadoc)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5756:
Labels: close-pending (was: )
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
> Labels: close-pending
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068967#comment-15068967
]
Michael Osipov commented on MNG-5756:
-
Just a note: with Java 9 this will be completely irrelevant, see
[http://openjdk.java.net/projects/jigsaw/talks/prepare-for-jdk9-j1-2015.pdf|slides]
29, 30. You won't see any difference.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5756) Java home output in mvn -v is misleading
[
https://issues.apache.org/jira/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068967#comment-15068967
]
Michael Osipov edited comment on MNG-5756 at 12/23/15 12:48 AM:
Just a note: with Java 9 this will be completely irrelevant, see
[slides|http://openjdk.java.net/projects/jigsaw/talks/prepare-for-jdk9-j1-2015.pdf]
29, 30. You won't see any difference.
was (Author: michael-o):
Just a note: with Java 9 this will be completely irrelevant, see
[http://openjdk.java.net/projects/jigsaw/talks/prepare-for-jdk9-j1-2015.pdf|slides]
29, 30. You won't see any difference.
> Java home output in mvn -v is misleading
>
>
> Key: MNG-5756
> URL: https://issues.apache.org/jira/browse/MNG-5756
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
> Environment: any
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For example on my windows box, mvn -v prints the following:
> {code}
> Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
> {code}
> But my JAVA_HOME is actually
> {code}
> > echo %JAVA_HOME%
> C:\Program Files (x86)\Java\jdk1.7.0_51
> {code}
> In the source code, the line comes from:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
> {code}
> version.append( "Java home: " ).append( System.getProperty( "java.home",
> "" ) ).append( ls );
> {code}
> which is using property "java.home" to fetch java home. However, "java.home"
> property is not JAVA_HOME! This is explained in detail in here:
> http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
> To quote:
> {quote}
> What's the difference between JAVA_HOME and java.home?
> JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be
> set as an environment variable and referenced in Windows batch files or Unix
> scripts. I always have it in my Windows Control Panel and .tcsh files,along
> with other common environment variables. Some Java applications use the name
> jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
> been used since the beginning and is now a convention.
> java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
> Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
> environment variable. java.home is a build-in Java system property, whose
> value is the JRE install directory. Since all Java system properties are also
> exposed as Ant build properties, you can also use ${java.home} in
> build files.
> Would jre.home be a better name? Maybe, but I don't think Sun will change
> it.
> {quote}
> This is a source of constant confusion. Some stackoverflow threads to
> illustrate:
> http://stackoverflow.com/questions/15279586/java-home-in-maven
> http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
> The correct way to print JAVA_HOME would be to use
> System.getenv("JAVA_HOME"). Either that should be used or current output
> should be changed so it wouldn't be so misleading.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSHARED-288) Allow Maven Archiver to not include pom.xml and/or pom.properties files
[
https://issues.apache.org/jira/browse/MSHARED-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068961#comment-15068961
]
Michael Osipov commented on MSHARED-288:
Neither senstive data belong into the POM nor should one hardcode paths to
senstive information. Use profiles in {{settings.xml}}. This should be
dynamic/configurable inside your library.
> Allow Maven Archiver to not include pom.xml and/or pom.properties files
> ---
>
> Key: MSHARED-288
> URL: https://issues.apache.org/jira/browse/MSHARED-288
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-2.4
>Reporter: Justin Wesley
>Priority: Minor
>
> Currently, when configuring the archive for a package, the developer can only
> include both pom.properties and pom.xml files, or neither of them. They can't
> pick to only include one or the other.
> Some projects may want to ability to determine programatically basic
> information of the jar they have by using the properties file, but not
> include the pom.xml file as it may contain information that may expose
> information about the build that could be specific to a build machine or have
> locations to a license file or have the license key in the pom.xml that
> should/can not be public.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSHARED-419) Allow custom properties to be added to pom.properties
[
https://issues.apache.org/jira/browse/MSHARED-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-419:
---
Labels: close-pending (was: )
> Allow custom properties to be added to pom.properties
> -
>
> Key: MSHARED-419
> URL: https://issues.apache.org/jira/browse/MSHARED-419
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-2.6
>Reporter: Konstantin Shaposhnikov
> Labels: close-pending
>
> `pom.properties` is useful for storing things like build number, git hash,
> etc. Unfortunately currently its content is hard coded.
> It would be good to allow specifying additional properties to be written to
> pom properties via archiver configuration. Something like:
> {code}
>
>
> 10
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSHARED-191) Specification-Version must not contain "-SNAPSHOT"
[
https://issues.apache.org/jira/browse/MSHARED-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-191:
---
Priority: Critical (was: Major)
> Specification-Version must not contain "-SNAPSHOT"
> --
>
> Key: MSHARED-191
> URL: https://issues.apache.org/jira/browse/MSHARED-191
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-2.4.1
> Environment: Ubuntu 10.10, Maven 2.2.1 and Maven 3.0.3, OpenJDK
> Runtime Environment (IcedTea6 1.9.7) (6b20-1.9.7-0ubuntu1) (64 bits)
> Mint 17.1, Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode),
> Maven 3.2.5
>Reporter: Romain Buquet
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: maven-archiver-3.0.1
>
> Attachments: MSHARED-191.patch
>
>
> When building an artifact with a SNAPSHOT version,
> Specification-Version and Implementation-Version are both set to
> $\{pom.version\} (as described in the documentation).
> But this will break the deployment in a container like WebLogic Server 10.3.4.
> This behavior is compliant with specification
> http://download.oracle.com/javase/6/docs/technotes/guides/versioning/spec/versioning2.html#wp89939
> where it is said that "Specification version numbers use a Dewey decimal
> notation consisting of numbers seperated by periods"
> Further in this spec, in § "1.5.10 Rationale for limiting Implementation
> version numbers to identity", it is explained why Implementation-Version need
> to be compared strictly for equality.
> So we can understand that:
> * Specification-Version must NOT have "-SNAPSHOT" suffix. This is legal to
> keep only the beginning of $\{pom.version\}, because it represents the spec
> version, not the build ;
> * Implementation-Version has to be set to $\{pom.version\} to represent the
> exact version of the build.
> This used to be the behavior in Maven 1:
> http://maven.apache.org/maven-1.x/plugins/jar/manifest.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSHARED-191) Specification-Version must not contain "-SNAPSHOT"
[
https://issues.apache.org/jira/browse/MSHARED-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-191:
---
Attachment: (was: patch maven-archiver)
> Specification-Version must not contain "-SNAPSHOT"
> --
>
> Key: MSHARED-191
> URL: https://issues.apache.org/jira/browse/MSHARED-191
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-2.4.1
> Environment: Ubuntu 10.10, Maven 2.2.1 and Maven 3.0.3, OpenJDK
> Runtime Environment (IcedTea6 1.9.7) (6b20-1.9.7-0ubuntu1) (64 bits)
> Mint 17.1, Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode),
> Maven 3.2.5
>Reporter: Romain Buquet
>Assignee: Michael Osipov
> Fix For: maven-archiver-3.0.1
>
> Attachments: MSHARED-191.patch
>
>
> When building an artifact with a SNAPSHOT version,
> Specification-Version and Implementation-Version are both set to
> $\{pom.version\} (as described in the documentation).
> But this will break the deployment in a container like WebLogic Server 10.3.4.
> This behavior is compliant with specification
> http://download.oracle.com/javase/6/docs/technotes/guides/versioning/spec/versioning2.html#wp89939
> where it is said that "Specification version numbers use a Dewey decimal
> notation consisting of numbers seperated by periods"
> Further in this spec, in § "1.5.10 Rationale for limiting Implementation
> version numbers to identity", it is explained why Implementation-Version need
> to be compared strictly for equality.
> So we can understand that:
> * Specification-Version must NOT have "-SNAPSHOT" suffix. This is legal to
> keep only the beginning of $\{pom.version\}, because it represents the spec
> version, not the build ;
> * Implementation-Version has to be set to $\{pom.version\} to represent the
> exact version of the build.
> This used to be the behavior in Maven 1:
> http://maven.apache.org/maven-1.x/plugins/jar/manifest.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MSHARED-191) Specification-Version must not contain "-SNAPSHOT"
[
https://issues.apache.org/jira/browse/MSHARED-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068951#comment-15068951
]
Michael Osipov edited comment on MSHARED-191 at 12/23/15 12:27 AM:
---
Hi folks,
I have created a patch which solves the issue. Though, I am quite uncertain
about the selected version operation, especially the impact it might have.
Alternatively, one could use {{DefaultArtifactVersion}} and get the bits from
there.
Please test the patch and post you (negative) results. I would like to avoid
using {{DefaultArtifactVersion}} which is an implementation detail. I would
like to stick to {{getSelectedVersion}}.
was (Author: michael-o):
Hi folks,
I have created a patch which solves the issue. Though, I am quite uncertian
about the selected version operation, especially the impact it might have.
Alterantively, one could use {{DefaultArtifactVersion}} and get the bits from
there.
Please test the patch and post you (negative) results. I would like to avoid
using {{DefaultArtifactVersion}} which is an implementation detail. I would
like to stick to {{getSelectedVersion}}.
> Specification-Version must not contain "-SNAPSHOT"
> --
>
> Key: MSHARED-191
> URL: https://issues.apache.org/jira/browse/MSHARED-191
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-2.4.1
> Environment: Ubuntu 10.10, Maven 2.2.1 and Maven 3.0.3, OpenJDK
> Runtime Environment (IcedTea6 1.9.7) (6b20-1.9.7-0ubuntu1) (64 bits)
> Mint 17.1, Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode),
> Maven 3.2.5
>Reporter: Romain Buquet
>Assignee: Michael Osipov
> Fix For: maven-archiver-3.0.1
>
> Attachments: MSHARED-191.patch, patch maven-archiver
>
>
> When building an artifact with a SNAPSHOT version,
> Specification-Version and Implementation-Version are both set to
> $\{pom.version\} (as described in the documentation).
> But this will break the deployment in a container like WebLogic Server 10.3.4.
> This behavior is compliant with specification
> http://download.oracle.com/javase/6/docs/technotes/guides/versioning/spec/versioning2.html#wp89939
> where it is said that "Specification version numbers use a Dewey decimal
> notation consisting of numbers seperated by periods"
> Further in this spec, in § "1.5.10 Rationale for limiting Implementation
> version numbers to identity", it is explained why Implementation-Version need
> to be compared strictly for equality.
> So we can understand that:
> * Specification-Version must NOT have "-SNAPSHOT" suffix. This is legal to
> keep only the beginning of $\{pom.version\}, because it represents the spec
> version, not the build ;
> * Implementation-Version has to be set to $\{pom.version\} to represent the
> exact version of the build.
> This used to be the behavior in Maven 1:
> http://maven.apache.org/maven-1.x/plugins/jar/manifest.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSHARED-191) Specification-Version must not contain "-SNAPSHOT"
[
https://issues.apache.org/jira/browse/MSHARED-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-191:
---
Attachment: MSHARED-191.patch
Hi folks,
I have created a patch which solves the issue. Though, I am quite uncertian
about the selected version operation, especially the impact it might have.
Alterantively, one could use {{DefaultArtifactVersion}} and get the bits from
there.
Please test the patch and post you (negative) results. I would like to avoid
using {{DefaultArtifactVersion}} which is an implementation detail. I would
like to stick to {{getSelectedVersion}}.
> Specification-Version must not contain "-SNAPSHOT"
> --
>
> Key: MSHARED-191
> URL: https://issues.apache.org/jira/browse/MSHARED-191
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-2.4.1
> Environment: Ubuntu 10.10, Maven 2.2.1 and Maven 3.0.3, OpenJDK
> Runtime Environment (IcedTea6 1.9.7) (6b20-1.9.7-0ubuntu1) (64 bits)
> Mint 17.1, Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode),
> Maven 3.2.5
>Reporter: Romain Buquet
>Assignee: Michael Osipov
> Fix For: maven-archiver-3.0.1
>
> Attachments: MSHARED-191.patch, patch maven-archiver
>
>
> When building an artifact with a SNAPSHOT version,
> Specification-Version and Implementation-Version are both set to
> $\{pom.version\} (as described in the documentation).
> But this will break the deployment in a container like WebLogic Server 10.3.4.
> This behavior is compliant with specification
> http://download.oracle.com/javase/6/docs/technotes/guides/versioning/spec/versioning2.html#wp89939
> where it is said that "Specification version numbers use a Dewey decimal
> notation consisting of numbers seperated by periods"
> Further in this spec, in § "1.5.10 Rationale for limiting Implementation
> version numbers to identity", it is explained why Implementation-Version need
> to be compared strictly for equality.
> So we can understand that:
> * Specification-Version must NOT have "-SNAPSHOT" suffix. This is legal to
> keep only the beginning of $\{pom.version\}, because it represents the spec
> version, not the build ;
> * Implementation-Version has to be set to $\{pom.version\} to represent the
> exact version of the build.
> This used to be the behavior in Maven 1:
> http://maven.apache.org/maven-1.x/plugins/jar/manifest.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSHADE-195) createSourcesJar with source:jar-no-fork causes sources.jar to be deployed twice, causing the build to fail
[
https://issues.apache.org/jira/browse/MSHADE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068932#comment-15068932
]
Hudson commented on MSHADE-195:
---
SUCCESS: Integrated in maven-plugins #4913 (See
[https://builds.apache.org/job/maven-plugins/4913/])
[MSHADE-195] createSourcesJar with source:jar-no-fork causes sources.jar to be
deployed twice, causing the build to fail
o Updated to use correct source artifact type. (schulte:
[http://svn.apache.org/viewvc/?view=rev&rev=1721474])
*
maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java
> createSourcesJar with source:jar-no-fork causes sources.jar to be deployed
> twice, causing the build to fail
> ---
>
> Key: MSHADE-195
> URL: https://issues.apache.org/jira/browse/MSHADE-195
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.4
>Reporter: Esko Luontola
>Assignee: Christian Schulte
> Fix For: 2.4.3
>
> Attachments: MSHADE-195-example.zip
>
>
> The workaround described in https://issues.apache.org/jira/browse/MSHADE-120
> (i.e. running maven-source-plugin's jar-no-fork goal before shading) causes
> the problem that Maven will install and deploy the same sources.jar file
> twice:
> {noformat}
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> pricing-client ---
> [INFO] Installing xxx/pricing-client/target/pricing-client-0-SNAPSHOT.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.jar
> [INFO] Installing xxx/pricing-client/target/dependency-reduced-pom.xml to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.pom
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> {noformat}
> With maven-install-plugin this doesn't matter that much, but with
> maven-deploy-plugin it *fails the build*, because it tries to upload the
> sources.jar twice to the Maven repository and _Nexus doesn't allow that_:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project project: Failed to deploy artifacts: Could not transfer artifact
> xxx.availability:availability-client:jar:sources:1.0.24 from/to xxx-releases
> (http://xxx/nexus/content/repositories/releases): Failed to transfer file:
> http://xxx/nexus/content/repositories/releases//availability/availability-client/1.0.24/availability-client-1.0.24-sources.jar.
> Return code is: 400, ReasonPhrase: Bad Request.
> {noformat}
> I'm suspecting this to be something like the maven-source-plugin and
> maven-shade-plugin both attaching the same sources.jar to the build, when
> only one of them should do it. This problem only happens with the sources jar
> and not the main artifact, so a trick similar to replacing the main artifact
> is needed also for the sources jar.
> h4. Workaround
> Configure maven-source-plugin with {{false}}. Then the shade
> plugin will find the sources and include them in the shaded sources jar, but
> the sources jar won't be attached to the build twice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MSHADE-195) createSourcesJar with source:jar-no-fork causes sources.jar to be deployed twice, causing the build to fail
[
https://issues.apache.org/jira/browse/MSHADE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MSHADE-195.
Resolution: Fixed
Fix Version/s: 2.4.3
> createSourcesJar with source:jar-no-fork causes sources.jar to be deployed
> twice, causing the build to fail
> ---
>
> Key: MSHADE-195
> URL: https://issues.apache.org/jira/browse/MSHADE-195
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.4
>Reporter: Esko Luontola
>Assignee: Christian Schulte
> Fix For: 2.4.3
>
> Attachments: MSHADE-195-example.zip
>
>
> The workaround described in https://issues.apache.org/jira/browse/MSHADE-120
> (i.e. running maven-source-plugin's jar-no-fork goal before shading) causes
> the problem that Maven will install and deploy the same sources.jar file
> twice:
> {noformat}
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> pricing-client ---
> [INFO] Installing xxx/pricing-client/target/pricing-client-0-SNAPSHOT.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.jar
> [INFO] Installing xxx/pricing-client/target/dependency-reduced-pom.xml to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.pom
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> {noformat}
> With maven-install-plugin this doesn't matter that much, but with
> maven-deploy-plugin it *fails the build*, because it tries to upload the
> sources.jar twice to the Maven repository and _Nexus doesn't allow that_:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project project: Failed to deploy artifacts: Could not transfer artifact
> xxx.availability:availability-client:jar:sources:1.0.24 from/to xxx-releases
> (http://xxx/nexus/content/repositories/releases): Failed to transfer file:
> http://xxx/nexus/content/repositories/releases//availability/availability-client/1.0.24/availability-client-1.0.24-sources.jar.
> Return code is: 400, ReasonPhrase: Bad Request.
> {noformat}
> I'm suspecting this to be something like the maven-source-plugin and
> maven-shade-plugin both attaching the same sources.jar to the build, when
> only one of them should do it. This problem only happens with the sources jar
> and not the main artifact, so a trick similar to replacing the main artifact
> is needed also for the sources jar.
> h4. Workaround
> Configure maven-source-plugin with {{false}}. Then the shade
> plugin will find the sources and include them in the shaded sources jar, but
> the sources jar won't be attached to the build twice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (MSHADE-195) createSourcesJar with source:jar-no-fork causes sources.jar to be deployed twice, causing the build to fail
[
https://issues.apache.org/jira/browse/MSHADE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reopened MSHADE-195:
--
> createSourcesJar with source:jar-no-fork causes sources.jar to be deployed
> twice, causing the build to fail
> ---
>
> Key: MSHADE-195
> URL: https://issues.apache.org/jira/browse/MSHADE-195
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.4
>Reporter: Esko Luontola
>Assignee: Christian Schulte
> Attachments: MSHADE-195-example.zip
>
>
> The workaround described in https://issues.apache.org/jira/browse/MSHADE-120
> (i.e. running maven-source-plugin's jar-no-fork goal before shading) causes
> the problem that Maven will install and deploy the same sources.jar file
> twice:
> {noformat}
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> pricing-client ---
> [INFO] Installing xxx/pricing-client/target/pricing-client-0-SNAPSHOT.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.jar
> [INFO] Installing xxx/pricing-client/target/dependency-reduced-pom.xml to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.pom
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> {noformat}
> With maven-install-plugin this doesn't matter that much, but with
> maven-deploy-plugin it *fails the build*, because it tries to upload the
> sources.jar twice to the Maven repository and _Nexus doesn't allow that_:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project project: Failed to deploy artifacts: Could not transfer artifact
> xxx.availability:availability-client:jar:sources:1.0.24 from/to xxx-releases
> (http://xxx/nexus/content/repositories/releases): Failed to transfer file:
> http://xxx/nexus/content/repositories/releases//availability/availability-client/1.0.24/availability-client-1.0.24-sources.jar.
> Return code is: 400, ReasonPhrase: Bad Request.
> {noformat}
> I'm suspecting this to be something like the maven-source-plugin and
> maven-shade-plugin both attaching the same sources.jar to the build, when
> only one of them should do it. This problem only happens with the sources jar
> and not the main artifact, so a trick similar to replacing the main artifact
> is needed also for the sources jar.
> h4. Workaround
> Configure maven-source-plugin with {{false}}. Then the shade
> plugin will find the sources and include them in the shaded sources jar, but
> the sources jar won't be attached to the build twice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-5868.
--
Resolution: Fixed
This is not a Maven core issue. The 'maven-sources-plugin' attaches the source
artifact with type 'java-source' and the 'maven-shade-plugin' attaches the
source artifact with type 'jar'. That really are two different artifacts. The
'maven-shade-plugin' needs to use the same type as the 'maven-source-plugin'
does.
'AbstractSourceJarMojo.java':
{code}
/**
* @return The type {@code java-source}
*/
protected String getType()
{
return "java-source";
}
...
if ( attach )
{
projectHelper.attachArtifact( project, getType(), getClassifier(), outputFile
);
}
{code}
'ShadeMojo.jar':
{code}
if ( createSourcesJar )
{
projectHelper.attachArtifact( project, "jar", shadedClassifierName +
"-sources", sourcesJar );
}
...
projectHelper.attachArtifact( project, "jar", "sources", shadedSources );
{code}
This needs to be changed to read 'java-source' instead of 'jar'. You can easily
set a breakpoint at 'MavenProject.addAttachedArtifact' and see what is going on
yourself.
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> does not produce a failure
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts
[jira] [Comment Edited] (DOXIASITETOOLS-101) Add ISO date format to site rendering context
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068759#comment-15068759
]
Michael Osipov edited comment on DOXIASITETOOLS-101 at 12/22/15 9:35 PM:
-
I would perform a massive cleanup, several months ago I have analyzed the code
throughout multiple levels and there are too many obsolete code:
1. DoxiaSiteRenderingContext: Drop publishDate, there is no point where you can
set the date, the decoration model doesn't provide. Drop Velocity property too.
2. DefaultSiteRenderer#createVelocityContext: remove dateCreation and add
creationDate as object
3. DefaultSiteRenderer#createVelocityContext: drop dateRevision it always
corresponds to the current date (redundant)
4. DefaultSiteRenderer#createVelocityContext: remove default date format
setting because publishDate can never be null in DeocrationModel (there is
always a null check in getPublishDate). Default is always set in the
DecorationModel
5. add isoDateFormat for the context formatting internal dates like generated
at header or meta fields.
6. Cleanup site.vms for the aforementioned points
For some of the points I have already created JIRA issues. For the rest, I
would create additional tickets too. Fully trackable.
What do you think?
was (Author: michael-o):
I would perform a massive cleanup, several months ago I have analyzed the code
throughout multiple levels and there are too many obsolete code:
1. DoxiaSiteRenderingContext: Drop publishDate, there is no point where you can
set the date, the decoration model doesn't provide. Drop Velocity property too.
2. DefaultSiteRenderer#createVelocityContext: remove dateCreation and add
creationDate as object
3. DefaultSiteRenderer#createVelocityContext: drop dateRevision it always
corresponds to the current date (redundant)
4. DefaultSiteRenderer#createVelocityContext: remove default date format
setting because publishDate can never be null in DeocrationModel (there is
always a null check in getPublishDate). Default is always set in the
DecorationModel
5. add isoDateFormat for the context formatting internal dates like generated
at header or meta fields.
6. Cleanup site.vms for the aforementioned points
For some of the points I have already created JIRA issues.
What do you think?
> Add ISO date format to site rendering context
> -
>
> Key: DOXIASITETOOLS-101
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-101
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Michael Osipov
> Fix For: 1.7
>
>
> Currently we have {{dateFormat}} only which depends on {{site.xml}}, we need
> a standardized format which can we used in meta tags as well as throughout
> the site, if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-101) Add ISO date format to site rendering context
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068759#comment-15068759
]
Michael Osipov commented on DOXIASITETOOLS-101:
---
I would perform a massive cleanup, several months ago I have analyzed the code
throughout multiple levels and there are too many obsolete code:
1. DoxiaSiteRenderingContext: Drop publishDate, there is no point where you can
set the date, the decoration model doesn't provide. Drop Velocity property too.
2. DefaultSiteRenderer#createVelocityContext: remove dateCreation and add
creationDate as object
3. DefaultSiteRenderer#createVelocityContext: drop dateRevision it always
corresponds to the current date (redundant)
4. DefaultSiteRenderer#createVelocityContext: remove default date format
setting because publishDate can never be null in DeocrationModel (there is
always a null check in getPublishDate). Default is always set in the
DecorationModel
5. add isoDateFormat for the context formatting internal dates like generated
at header or meta fields.
6. Cleanup site.vms for the aforementioned points
For some of the points I have already created JIRA issues.
What do you think?
> Add ISO date format to site rendering context
> -
>
> Key: DOXIASITETOOLS-101
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-101
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Michael Osipov
> Fix For: 1.7
>
>
> Currently we have {{dateFormat}} only which depends on {{site.xml}}, we need
> a standardized format which can we used in meta tags as well as throughout
> the site, if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5895) Problem with CI friendly usage of ${..} which is already defined via property in pom file.
[
https://issues.apache.org/jira/browse/MNG-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-5895:
-
Attachment: x.diff
The attached file contains the differences between the {{master}} branch and
the {{mvn321}} branch which seemed to be causing the change in reactor order.
> Problem with CI friendly usage of ${..} which is already defined via property
> in pom file.
> --
>
> Key: MNG-5895
> URL: https://issues.apache.org/jira/browse/MNG-5895
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.2, 3.2.5, 3.3.1, 3.3.3
>Reporter: Karl Heinz Marbaise
> Attachments: x.diff
>
>
> I have test project where i defined the pom like this:
> {code:xml}
> 4.0.0
> com.soebes.examples.j2ee
> parent
> ${revision}
> pom
> {code}
> If i define the revision on command line like this.
> {{mvn -Drevision=1.0-SNAPSHOT clean package}}
> everything fine...
> But now i want to make the usage a bit more convenient so i added the
> following to my pom:
> {code:xml}
>
> UTF-8
> 1.0-SNAPSHOT
>
> {code}
> to have a default for revision which works fine now...
> But if i would like to overwrite the property from command line like this:
> {{mvn -Drevision=1.0 clean package}}
> the build failes in the following location:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (assemblies) on
> project assembly:
> Failed to create assembly: Unable to resolve dependencies for assembly
> 'archive': Failed to resolve dependencies for assembly:
> Unable to get dependency information for
> com.soebes.examples.j2ee:service-client:jar:1.0-SNAPSHOT:
> Failed to process POM for
> com.soebes.examples.j2ee:service-client:jar:1.0-SNAPSHOT:
> Non-resolvable parent POM for
> com.soebes.examples.j2ee:service-client:[unknown-version]:
> Failure to find com.soebes.examples.j2ee:parent:pom:${revision} in
> http://localhost:8081/nexus/content/groups/public was
> cached in the local repository, resolution will not be reattempted until the
> update interval of nexus has elapsed or
> updates are forced
> [ERROR] com.soebes.examples.j2ee:service-client:jar:1.0-SNAPSHOT
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5895) Problem with CI friendly usage of ${..} which is already defined via property in pom file.
[
https://issues.apache.org/jira/browse/MNG-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068700#comment-15068700
]
Karl Heinz Marbaise edited comment on MNG-5895 at 12/22/15 8:56 PM:
I'm using the following example project:
https://github.com/khmarbaise/javaee (The mvn321 branch of it):
So retest with Maven 3.2.5:
First run via {{mvn clean package}}
and than:
{code}
~/ws-git/javaee (mvn321)$ mvn -Drevision=2.0-SNAPSHOT clean package
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] domain
[INFO] service-client
[INFO] webgui
[INFO] service
[INFO] app
[INFO] appasm
[INFO] shade
[INFO] assembly
[INFO] parent
[INFO]
[INFO]
[INFO] Building domain 2.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.6.1:clean (default-clean) @ domain ---
[INFO] Deleting /Users/kama/ws-git/javaee/domain/target
[INFO]
[INFO] --- maven-enforcer-plugin:1.4:enforce (enforce-maven) @ domain ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ domain ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/domain/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ domain ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to
/Users/kama/ws-git/javaee/domain/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
domain ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/domain/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ domain
---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ domain ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.6:jar (default-jar) @ domain ---
[INFO] Building jar:
/Users/kama/ws-git/javaee/domain/target/domain-2.0-SNAPSHOT.jar
[INFO]
[INFO]
[INFO] Building service-client 2.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.6.1:clean (default-clean) @ service-client ---
[INFO] Deleting /Users/kama/ws-git/javaee/service-client/target
[INFO]
[INFO] --- maven-enforcer-plugin:1.4:enforce (enforce-maven) @ service-client
---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
service-client ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/service-client/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ service-client
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to
/Users/kama/ws-git/javaee/service-client/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
service-client ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/service-client/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
service-client ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ service-client ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.6:jar (default-jar) @ service-client ---
[INFO] Building jar:
/Users/kama/ws-git/javaee/service-client/target/service-client-2.0-SNAPSHOT.jar
[INFO]
[INFO]
[INFO] Building webgui 2.0-SNAPSHOT
[INFO]
Downloading:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/maven-metadata.xml
Downloaded:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/maven-metadata.xml
(780 B at 1.5 KB/sec)
Downloading:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/domain-1.1.2-20151128.003509-1.pom
Downloaded:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/domain-1.1.2-20151128.003509-1.pom
(788 B at 64.1 KB/sec)
Downloading:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/parent/1.1.2-SNAPSHOT/maven-metadata.xml
Downloaded:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2
[jira] [Comment Edited] (MNG-5895) Problem with CI friendly usage of ${..} which is already defined via property in pom file.
[
https://issues.apache.org/jira/browse/MNG-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068700#comment-15068700
]
Karl Heinz Marbaise edited comment on MNG-5895 at 12/22/15 8:41 PM:
So retest with Maven 3.2.5:
First run via {{mvn clean package}}
and than:
{code}
~/ws-git/javaee (mvn321)$ mvn -Drevision=2.0-SNAPSHOT clean package
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] domain
[INFO] service-client
[INFO] webgui
[INFO] service
[INFO] app
[INFO] appasm
[INFO] shade
[INFO] assembly
[INFO] parent
[INFO]
[INFO]
[INFO] Building domain 2.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.6.1:clean (default-clean) @ domain ---
[INFO] Deleting /Users/kama/ws-git/javaee/domain/target
[INFO]
[INFO] --- maven-enforcer-plugin:1.4:enforce (enforce-maven) @ domain ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ domain ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/domain/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ domain ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to
/Users/kama/ws-git/javaee/domain/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
domain ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/domain/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ domain
---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ domain ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.6:jar (default-jar) @ domain ---
[INFO] Building jar:
/Users/kama/ws-git/javaee/domain/target/domain-2.0-SNAPSHOT.jar
[INFO]
[INFO]
[INFO] Building service-client 2.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.6.1:clean (default-clean) @ service-client ---
[INFO] Deleting /Users/kama/ws-git/javaee/service-client/target
[INFO]
[INFO] --- maven-enforcer-plugin:1.4:enforce (enforce-maven) @ service-client
---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
service-client ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/service-client/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ service-client
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to
/Users/kama/ws-git/javaee/service-client/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
service-client ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/service-client/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
service-client ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ service-client ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.6:jar (default-jar) @ service-client ---
[INFO] Building jar:
/Users/kama/ws-git/javaee/service-client/target/service-client-2.0-SNAPSHOT.jar
[INFO]
[INFO]
[INFO] Building webgui 2.0-SNAPSHOT
[INFO]
Downloading:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/maven-metadata.xml
Downloaded:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/maven-metadata.xml
(780 B at 1.5 KB/sec)
Downloading:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/domain-1.1.2-20151128.003509-1.pom
Downloaded:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/domain-1.1.2-20151128.003509-1.pom
(788 B at 64.1 KB/sec)
Downloading:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/parent/1.1.2-SNAPSHOT/maven-metadata.xml
Downloaded:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/parent/1.1.2-SNAPSHOT/maven-metadata.xml
(607 B at 0.4 KB/sec)
Downloading:
http://localhost:8081/ne
[jira] [Commented] (MNG-5895) Problem with CI friendly usage of ${..} which is already defined via property in pom file.
[
https://issues.apache.org/jira/browse/MNG-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068700#comment-15068700
]
Karl Heinz Marbaise commented on MNG-5895:
--
So retest with Maven 3.2.5:
First run via {{mvn clean package}}
and than:
{code}
~/ws-git/javaee (mvn321)$ mvn -Drevision=2.0-SNAPSHOT clean package
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] domain
[INFO] service-client
[INFO] webgui
[INFO] service
[INFO] app
[INFO] appasm
[INFO] shade
[INFO] assembly
[INFO] parent
[INFO]
[INFO]
[INFO] Building domain 2.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.6.1:clean (default-clean) @ domain ---
[INFO] Deleting /Users/kama/ws-git/javaee/domain/target
[INFO]
[INFO] --- maven-enforcer-plugin:1.4:enforce (enforce-maven) @ domain ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ domain ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/domain/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ domain ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to
/Users/kama/ws-git/javaee/domain/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
domain ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/domain/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ domain
---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ domain ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.6:jar (default-jar) @ domain ---
[INFO] Building jar:
/Users/kama/ws-git/javaee/domain/target/domain-2.0-SNAPSHOT.jar
[INFO]
[INFO]
[INFO] Building service-client 2.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.6.1:clean (default-clean) @ service-client ---
[INFO] Deleting /Users/kama/ws-git/javaee/service-client/target
[INFO]
[INFO] --- maven-enforcer-plugin:1.4:enforce (enforce-maven) @ service-client
---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
service-client ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/service-client/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ service-client
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to
/Users/kama/ws-git/javaee/service-client/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
service-client ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/kama/ws-git/javaee/service-client/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
service-client ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ service-client ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.6:jar (default-jar) @ service-client ---
[INFO] Building jar:
/Users/kama/ws-git/javaee/service-client/target/service-client-2.0-SNAPSHOT.jar
[INFO]
[INFO]
[INFO] Building webgui 2.0-SNAPSHOT
[INFO]
Downloading:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/maven-metadata.xml
Downloaded:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/maven-metadata.xml
(780 B at 1.5 KB/sec)
Downloading:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/domain-1.1.2-20151128.003509-1.pom
Downloaded:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/domain/1.1.2-SNAPSHOT/domain-1.1.2-20151128.003509-1.pom
(788 B at 64.1 KB/sec)
Downloading:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/parent/1.1.2-SNAPSHOT/maven-metadata.xml
Downloaded:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/parent/1.1.2-SNAPSHOT/maven-metadata.xml
(607 B at 0.4 KB/sec)
Downloading:
http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/
[jira] [Comment Edited] (MJAVADOC-368) Can not use a comma (,) in option additionalparam
[
https://issues.apache.org/jira/browse/MJAVADOC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068566#comment-15068566
]
Michael Osipov edited comment on MJAVADOC-368 at 12/22/15 7:11 PM:
---
Given that the entire plugin parameter is ill-designed:
* wrong name, i.e., {{additionalparam}} Javadoc help taks about options and not
parameters
* wrong documentation
* wrong semantics
...
I would close this as WONTFIX and create two new tickets:
1. Create parameter {{/}} with proper
sematics
2. Deprecate {{}} in favor of 1.
This will avoid a lot of confusion.
WDYT?
was (Author: michael-o):
Given that the entire plugin parameter is ill-designed:
* wrong name, i.e., {{additionalparam}}
* wrong documentation
* wrong semantics
...
I would close this as WONTFIX and create two new tickets:
1. Create parameter {{/}} with proper
sematics
2. Deprecate {{}} in favor of 1.
This will avoid a lot of confusion.
WDYT?
> Can not use a comma (,) in option additionalparam
> -
>
> Key: MJAVADOC-368
> URL: https://issues.apache.org/jira/browse/MJAVADOC-368
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Andy Schönemann
>
> I would like to set an additional parameter for javadoc like
> {{-header 'A,B'}}
> But this is not possible! Every comma here separates the string into
> different parameters. So I'm not able to set parameters including commas.
> Furthermore, the options name is {{additionalparam}} and NOT
> {{additionalparamS}}. So it should not be possible to set multiple parameters
> here.
> I also tried
> {{-header 'A,B'}}
> but this doesn't work either.
> [Plugin
> documentation|http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalparam]
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MJAVADOC-368) Can not use a comma (,) in option additionalparam
[
https://issues.apache.org/jira/browse/MJAVADOC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068566#comment-15068566
]
Michael Osipov commented on MJAVADOC-368:
-
Given that the entire plugin parameter is ill-designed:
* wrong name, i.e., {{additionalparam}}
* wrong documentation
* wrong semantics
...
I would close this as WONTFIX and create two new tickets:
1. Create parameter {{/}} with proper
sematics
2. Deprecate {{}} in favor of 1.
This will avoid a lot of confusion.
WDYT?
> Can not use a comma (,) in option additionalparam
> -
>
> Key: MJAVADOC-368
> URL: https://issues.apache.org/jira/browse/MJAVADOC-368
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Andy Schönemann
>
> I would like to set an additional parameter for javadoc like
> {{-header 'A,B'}}
> But this is not possible! Every comma here separates the string into
> different parameters. So I'm not able to set parameters including commas.
> Furthermore, the options name is {{additionalparam}} and NOT
> {{additionalparamS}}. So it should not be possible to set multiple parameters
> here.
> I also tried
> {{-header 'A,B'}}
> but this doesn't work either.
> [Plugin
> documentation|http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalparam]
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-756) add an option to dump Velocity processed Doxia files
[
https://issues.apache.org/jira/browse/MSITE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068516#comment-15068516
]
Robert Scholte commented on MSITE-756:
--
I'm not sure if we should call it like this. I wonder if Velocity is still the
correct tool, since we can't update and I don't know if there is enough
activity on it. I'm thinking in terms of {{savePreparedTemplate}}
> add an option to dump Velocity processed Doxia files
>
>
> Key: MSITE-756
> URL: https://issues.apache.org/jira/browse/MSITE-756
> Project: Maven Site Plugin
> Issue Type: New Feature
> Components: doxia integration
>Affects Versions: 3.4
>Reporter: Hervé Boutemy
> Fix For: 3.5
>
>
> making feature prepared in DOXIASITETOOLS-133 available and configurable from
> maven-site-plugin
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MJAVADOC-368) Can not use a comma (,) in option additionalparam
[
https://issues.apache.org/jira/browse/MJAVADOC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068477#comment-15068477
]
Michael Osipov commented on MJAVADOC-368:
-
For {{header}}, there is a separate plugin parameter.
> Can not use a comma (,) in option additionalparam
> -
>
> Key: MJAVADOC-368
> URL: https://issues.apache.org/jira/browse/MJAVADOC-368
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Andy Schönemann
>
> I would like to set an additional parameter for javadoc like
> {{-header 'A,B'}}
> But this is not possible! Every comma here separates the string into
> different parameters. So I'm not able to set parameters including commas.
> Furthermore, the options name is {{additionalparam}} and NOT
> {{additionalparamS}}. So it should not be possible to set multiple parameters
> here.
> I also tried
> {{-header 'A,B'}}
> but this doesn't work either.
> [Plugin
> documentation|http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalparam]
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-204) CPD report : Required class was missing : org/w3c/dom/ElementTraversal
[
https://issues.apache.org/jira/browse/MPMD-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068463#comment-15068463
]
Alix Lourme commented on MPMD-204:
--
You had exactly the same problem ?! Perhaps a first "old" release of xercesImpl
2.11 had the bad _xml-apis_ dependency on Maven central ... but this is strange.
> CPD report : Required class was missing : org/w3c/dom/ElementTraversal
> --
>
> Key: MPMD-204
> URL: https://issues.apache.org/jira/browse/MPMD-204
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: CPD
>Affects Versions: 3.3, 3.4
> Environment: Maven 3.2.3
>Reporter: Alix Lourme
> Attachments: site-plexus-classpath.log
>
>
> Hi,
> Since _maven-pmd-plugin_ v3.3, on a simple pom :
> {code:xml}
>
>
> 4.0.0
> test
> test
> 1.0.0-SNAPSHOT
> jar
>
>
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.4
>
>
>
>
> {code}
> Command _mvn site_ gives :
> {quote}
> Caused by: org.apache.maven.plugin.PluginContainerException: A required class
> was missing while executing
> org.apache.maven.plugins:maven-site-plugin:3.3:site:
> org/w3c/dom/ElementTraversal
> {quote}
> Stack :
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/w3c/dom/ElementTraversal
> at java.lang.ClassLoader.defineClass1(Native Method)
> [...]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> at org.apache.xerces.jaxp.DocumentBuilderImpl.newDocument(Unknown
> Source)
> at
> net.sourceforge.pmd.cpd.XMLRenderer.createDocument(XMLRenderer.java:50)
> at net.sourceforge.pmd.cpd.XMLRenderer.render(XMLRenderer.java:73)
> at
> org.apache.maven.plugin.pmd.CpdReport.writeNonHtml(CpdReport.java:301)
> at org.apache.maven.plugin.pmd.CpdReport.executeCpd(CpdReport.java:260)
> at
> org.apache.maven.plugin.pmd.CpdReport.executeCpdWithClassloader(CpdReport.java:195)
> at
> org.apache.maven.plugin.pmd.CpdReport.canGenerateReport(CpdReport.java:170)
> [...]
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
> [...]
> Caused by: java.lang.ClassNotFoundException: org.w3c.dom.ElementTraversal
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> [...]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> [...]
> {code}
>
> Adding this override fix the problem, but could introduce some impacts on
> other report plugins :
> {code:xml}
>
>
>
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.4
>
>
> xml-apis
> xml-apis
> 1.4.01
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SCM-805) Add SVN --pin-externals option to copy command in Tag operations
[ https://issues.apache.org/jira/browse/SCM-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068446#comment-15068446 ] Michael Osipov edited comment on SCM-805 at 12/22/15 5:42 PM: -- Necessary changes in * SCM Provider API * SCM Provider SVNEXE * Maven SCM Plugin Since this requires an API change, pushing to 1.x, probably 1.10. was (Author: michael-o): Necessary changes in * SCM Provider API * SCM Provider SVNEXE * Maven SCM Plugin > Add SVN --pin-externals option to copy command in Tag operations > > > Key: SCM-805 > URL: https://issues.apache.org/jira/browse/SCM-805 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-svn > Environment: SVN 1.9+ >Reporter: Eduardo Hernández Guerra > Labels: externals, svn, tag > Fix For: 1.x > > > Starting from version 1.9, SVN client now supports the --pin-externals option > for the copy command, which is to be used when tagging. > I believe this should be implemented by default in SVN tag operations, and it > optionally could be disabled via a parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SCM-805) Add SVN --pin-externals option to copy command in Tag operations
[ https://issues.apache.org/jira/browse/SCM-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SCM-805: --- Fix Version/s: 1.x > Add SVN --pin-externals option to copy command in Tag operations > > > Key: SCM-805 > URL: https://issues.apache.org/jira/browse/SCM-805 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-svn > Environment: SVN 1.9+ >Reporter: Eduardo Hernández Guerra > Labels: externals, svn, tag > Fix For: 1.x > > > Starting from version 1.9, SVN client now supports the --pin-externals option > for the copy command, which is to be used when tagging. > I believe this should be implemented by default in SVN tag operations, and it > optionally could be disabled via a parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SCM-805) Add SVN --pin-externals option to copy command in Tag operations
[ https://issues.apache.org/jira/browse/SCM-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068446#comment-15068446 ] Michael Osipov commented on SCM-805: Necessary changes in * SCM Provider API * SCM Provider SVNEXE * Maven SCM Plugin > Add SVN --pin-externals option to copy command in Tag operations > > > Key: SCM-805 > URL: https://issues.apache.org/jira/browse/SCM-805 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-svn > Environment: SVN 1.9+ >Reporter: Eduardo Hernández Guerra > Labels: externals, svn, tag > > Starting from version 1.9, SVN client now supports the --pin-externals option > for the copy command, which is to be used when tagging. > I believe this should be implemented by default in SVN tag operations, and it > optionally could be disabled via a parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MRELEASE-549) Pin svn:externals when tagging
[
https://issues.apache.org/jira/browse/MRELEASE-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068422#comment-15068422
]
Michael Osipov edited comment on MRELEASE-549 at 12/22/15 5:36 PM:
---
I have checked the what would is necessary to implement this. There are several
layers to propagate this, bottom-up:
1.1 SCM Provider API
1.2 SCM Provider SVNEXE
1.3 Maven SCM Plugin
2.1 Maven Release Manager
2.2 Maven Release Plugin
While the change itself is cheap, the doing takes some work. Especially we are
changing interface, therefore this can happen in at least a minor release.
Meanwhile I would recommend to use a shell alias for {{svn}} as {{svn
--pin-externals}}.
was (Author: michael-o):
I have checked the what would is necessary to implement this. There are several
layers to propagate this, bottom-up:
1.1 SCM Provider API
1.2 SCM Provider SVNEXE
1.2 Maven SCM Plugin
2.1 Maven Release Manager
2.2 Maven Release Plugin
While the change itself is cheap, the doing takes some work. Especially we are
changing interface, therefore this can happen in at least a minor release.
Meanwhile I would recommend to use a shell alias for {{svn}} as {{svn
--pin-externals}}.
> Pin svn:externals when tagging
> --
>
> Key: MRELEASE-549
> URL: https://issues.apache.org/jira/browse/MRELEASE-549
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: prepare
>Affects Versions: 2.0
>Reporter: Stephen Connolly
>Assignee: Michael Osipov
>
> svn:externals is a property set on directories in a subversion repository.
> there are two classes of svn:externals, ones which specify a revision and
> ones which do not.
> when creating a tag, the tag should only contain svn:externals which have
> been pinned to specific revisions, otherwise the tag is not a tag, i.e. it is
> subject to change.
> A generic solution (i.e. not SVN specific) would be to add preTagGoals and
> postTagGoals so that a custom goal could be invoked around creating the tag.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MRELEASE-549) Pin svn:externals when tagging
[
https://issues.apache.org/jira/browse/MRELEASE-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068422#comment-15068422
]
Michael Osipov edited comment on MRELEASE-549 at 12/22/15 5:35 PM:
---
I have checked the what would is necessary to implement this. There are several
layers to propagate this, bottom-up:
1.1 SCM Provider API
1.2 SCM Provider SVNEXE
1.2 Maven SCM Plugin
2.1 Maven Release Manager
2.2 Maven Release Plugin
While the change itself is cheap, the doing takes some work. Especially we are
changing interface, therefore this can happen in at least a minor release.
Meanwhile I would recommend to use a shell alias for {{svn}} as {{svn
--pin-externals}}.
was (Author: michael-o):
I have checked the what would is necessary to implement this. There are several
layers to propagate this, bottom-up:
1.1 SCM Provider API
1.2 SCM Provider SVNEXE
1.2 Maven SCM Plugin
2.1 Maven Release Manager
2.2 Maven Release Plugin
While the change itself is cheap, the doing takes some work. Especially we are
changing interface, therefore this can happen in at least a minor release.
> Pin svn:externals when tagging
> --
>
> Key: MRELEASE-549
> URL: https://issues.apache.org/jira/browse/MRELEASE-549
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: prepare
>Affects Versions: 2.0
>Reporter: Stephen Connolly
>Assignee: Michael Osipov
>
> svn:externals is a property set on directories in a subversion repository.
> there are two classes of svn:externals, ones which specify a revision and
> ones which do not.
> when creating a tag, the tag should only contain svn:externals which have
> been pinned to specific revisions, otherwise the tag is not a tag, i.e. it is
> subject to change.
> A generic solution (i.e. not SVN specific) would be to add preTagGoals and
> postTagGoals so that a custom goal could be invoked around creating the tag.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-549) Pin svn:externals when tagging
[ https://issues.apache.org/jira/browse/MRELEASE-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068422#comment-15068422 ] Michael Osipov commented on MRELEASE-549: - I have checked the what would is necessary to implement this. There are several layers to propagate this, bottom-up: 1.1 SCM Provider API 1.2 SCM Provider SVNEXE 1.2 Maven SCM Plugin 2.1 Maven Release Manager 2.2 Maven Release Plugin While the change itself is cheap, the doing takes some work. Especially we are changing interface, therefore this can happen in at least a minor release. > Pin svn:externals when tagging > -- > > Key: MRELEASE-549 > URL: https://issues.apache.org/jira/browse/MRELEASE-549 > Project: Maven Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.0 >Reporter: Stephen Connolly >Assignee: Michael Osipov > > svn:externals is a property set on directories in a subversion repository. > there are two classes of svn:externals, ones which specify a revision and > ones which do not. > when creating a tag, the tag should only contain svn:externals which have > been pinned to specific revisions, otherwise the tag is not a tag, i.e. it is > subject to change. > A generic solution (i.e. not SVN specific) would be to add preTagGoals and > postTagGoals so that a custom goal could be invoked around creating the tag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPMD-204) CPD report : Required class was missing : org/w3c/dom/ElementTraversal
[
https://issues.apache.org/jira/browse/MPMD-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068401#comment-15068401
]
Anders Wallgren commented on MPMD-204:
--
[~axel3rd] Thanks for that comment -- it made me realize that my local repo was
the problem! I blew away the contents and re-downloaded and got past the
problem.
> CPD report : Required class was missing : org/w3c/dom/ElementTraversal
> --
>
> Key: MPMD-204
> URL: https://issues.apache.org/jira/browse/MPMD-204
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: CPD
>Affects Versions: 3.3, 3.4
> Environment: Maven 3.2.3
>Reporter: Alix Lourme
> Attachments: site-plexus-classpath.log
>
>
> Hi,
> Since _maven-pmd-plugin_ v3.3, on a simple pom :
> {code:xml}
>
>
> 4.0.0
> test
> test
> 1.0.0-SNAPSHOT
> jar
>
>
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.4
>
>
>
>
> {code}
> Command _mvn site_ gives :
> {quote}
> Caused by: org.apache.maven.plugin.PluginContainerException: A required class
> was missing while executing
> org.apache.maven.plugins:maven-site-plugin:3.3:site:
> org/w3c/dom/ElementTraversal
> {quote}
> Stack :
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/w3c/dom/ElementTraversal
> at java.lang.ClassLoader.defineClass1(Native Method)
> [...]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> at org.apache.xerces.jaxp.DocumentBuilderImpl.newDocument(Unknown
> Source)
> at
> net.sourceforge.pmd.cpd.XMLRenderer.createDocument(XMLRenderer.java:50)
> at net.sourceforge.pmd.cpd.XMLRenderer.render(XMLRenderer.java:73)
> at
> org.apache.maven.plugin.pmd.CpdReport.writeNonHtml(CpdReport.java:301)
> at org.apache.maven.plugin.pmd.CpdReport.executeCpd(CpdReport.java:260)
> at
> org.apache.maven.plugin.pmd.CpdReport.executeCpdWithClassloader(CpdReport.java:195)
> at
> org.apache.maven.plugin.pmd.CpdReport.canGenerateReport(CpdReport.java:170)
> [...]
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
> [...]
> Caused by: java.lang.ClassNotFoundException: org.w3c.dom.ElementTraversal
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> [...]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> [...]
> {code}
>
> Adding this override fix the problem, but could introduce some impacts on
> other report plugins :
> {code:xml}
>
>
>
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.4
>
>
> xml-apis
> xml-apis
> 1.4.01
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MRELEASE-907) Upgrade Plexus-utils to 3.0.15 to match with maven-scm
[ https://issues.apache.org/jira/browse/MRELEASE-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRELEASE-907: Fix Version/s: (was: 3.0) > Upgrade Plexus-utils to 3.0.15 to match with maven-scm > -- > > Key: MRELEASE-907 > URL: https://issues.apache.org/jira/browse/MRELEASE-907 > Project: Maven Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.5.1 >Reporter: Dan Tran > > For my case when release with p4maven, maven-release-plugin fails since it > plexus-utils is 3.0.10 with some classloader issue ( sorry, dont have the > stack trace) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRELEASE-896) Disable and deprecate useReleaseProfile parameter
[
https://issues.apache.org/jira/browse/MRELEASE-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068381#comment-15068381
]
Michael Osipov commented on MRELEASE-896:
-
I think this is a duplicate of MRELEASE-356. Can I merge those two?
> Disable and deprecate useReleaseProfile parameter
> -
>
> Key: MRELEASE-896
> URL: https://issues.apache.org/jira/browse/MRELEASE-896
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: perform
>Affects Versions: 2.5.1
>Reporter: Stefan Ferstl
>Priority: Minor
>
> There are some indications [1, 2] that the {{release-profile}} will disappear
> from Maven's super POM somewhen in the future. There was also an attempt back
> in 2009 to remove it but it was re-added again [3].
> In order to support the removal of this profile, I suggest to disable its
> default activation in the maven-release-plugin. Additionally, I suggest to
> deprecate the {{useReleaseProfile}} parameter in the {{PerformReleaseMojo}}.
> [1]
> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L100
> [2]
> http://mail-archives.apache.org/mod_mbox/maven-dev/201411.mbox/%3c20141128002840.32fcb4340...@dd34514.kasserver.com%3e
> [3]
> https://github.com/apache/maven/commit/3870ab0e6021eb17d04883f97fe144d2db96e745
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MRELEASE-884) SCM null password configured at settings.xml's server becomes '{}'
[
https://issues.apache.org/jira/browse/MRELEASE-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-884:
Labels: close-pending (was: )
> SCM null password configured at settings.xml's server becomes '{}'
> --
>
> Key: MRELEASE-884
> URL: https://issues.apache.org/jira/browse/MRELEASE-884
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.4, 2.5
>Reporter: Dan Tran
> Labels: close-pending
>
> This is specially case found under p4maven where an empty password should
> kicks in Perforce P4Ticket authentication feature. Due to this bug this
> feature does not never trigger
> SCM plugin does not have this issue. only release plugin
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-884) SCM null password configured at settings.xml's server becomes '{}'
[
https://issues.apache.org/jira/browse/MRELEASE-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068372#comment-15068372
]
Michael Osipov commented on MRELEASE-884:
-
Does this apply for Perforce only?
> SCM null password configured at settings.xml's server becomes '{}'
> --
>
> Key: MRELEASE-884
> URL: https://issues.apache.org/jira/browse/MRELEASE-884
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.4, 2.5
>Reporter: Dan Tran
> Labels: close-pending
>
> This is specially case found under p4maven where an empty password should
> kicks in Perforce P4Ticket authentication feature. Due to this bug this
> feature does not never trigger
> SCM plugin does not have this issue. only release plugin
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SCM-813) SVN fails when trying to create a branch with nested directories
[
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068275#comment-15068275
]
Michael Osipov commented on SCM-813:
If you want to test, please clone and install locally. Maybe Jenkins will
deploy snapshots.
I cannot tell you about the release planning of 1.9.5. It depends on the open
bugs.
> SVN fails when trying to create a branch with nested directories
>
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 1.9.5
>
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SCM-813) SVN fails when trying to create a branch with nested directories
[
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SCM-813.
--
Resolution: Fixed
Tests fixed with
https://git-wip-us.apache.org/repos/asf?p=maven-scm.git;a=commit;h=5c303e41f51ed8c4698863940ef6099e7c825faa
> SVN fails when trying to create a branch with nested directories
>
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 1.9.5
>
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SCM-813) SVN fails when trying to create a branch with nested directories
[
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068094#comment-15068094
]
Jakub Bochenski commented on SCM-813:
-
Thanks -- is this going to be included in next snapshot build so I can test it?
Any word when 1.9.5 release is planned?
> SVN fails when trying to create a branch with nested directories
>
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 1.9.5
>
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (SCM-813) SVN fails when trying to create a branch with nested directories
[
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened SCM-813:
Test cases need to be changed.
> SVN fails when trying to create a branch with nested directories
>
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 1.9.5
>
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1210) Load test-classes and test dependencies into isolated loader
[ https://issues.apache.org/jira/browse/SUREFIRE-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068035#comment-15068035 ] Pavel Kh commented on SUREFIRE-1210: Thanks Tibor. We are experiencing blockers on 2.19 because of JVM forced exit bugs. Just wanted to know. > Load test-classes and test dependencies into isolated loader > > > Key: SUREFIRE-1210 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1210 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: mike duigou > > Currently both the artifact and it's tests are loaded in to the same > classloader. The test-classes and test dependencies are also placed ahead of > the artifact classes in the search path. This can cause problems if the test > classes contains mocks classes with the same name as artifact classes that > aren't intended for use by all tests. > The test classes and test dependencies should be placed in their own > classloader, a child of whichever classloader is being used for the artifact > and run dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1210) Load test-classes and test dependencies into isolated loader
[ https://issues.apache.org/jira/browse/SUREFIRE-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067987#comment-15067987 ] Tibor Digana commented on SUREFIRE-1210: The Version 2.19.1 will be in Maven central in a week. I was ill so unable to work on Surefire. > Load test-classes and test dependencies into isolated loader > > > Key: SUREFIRE-1210 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1210 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: mike duigou > > Currently both the artifact and it's tests are loaded in to the same > classloader. The test-classes and test dependencies are also placed ahead of > the artifact classes in the search path. This can cause problems if the test > classes contains mocks classes with the same name as artifact classes that > aren't intended for use by all tests. > The test classes and test dependencies should be placed in their own > classloader, a child of whichever classloader is being used for the artifact > and run dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SCM-805) Add SVN --pin-externals option to copy command in Tag operations
[ https://issues.apache.org/jira/browse/SCM-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SCM-805: --- Fix Version/s: (was: 1.9.5) > Add SVN --pin-externals option to copy command in Tag operations > > > Key: SCM-805 > URL: https://issues.apache.org/jira/browse/SCM-805 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-svn > Environment: SVN 1.9+ >Reporter: Eduardo Hernández Guerra > Labels: externals, svn, tag > > Starting from version 1.9, SVN client now supports the --pin-externals option > for the copy command, which is to be used when tagging. > I believe this should be implemented by default in SVN tag operations, and it > optionally could be disabled via a parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SCM-813) SVN fails when trying to create a branch with nested directories
[
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SCM-813.
--
Resolution: Fixed
Fixed with
https://git-wip-us.apache.org/repos/asf?p=maven-scm.git;a=commit;h=1aa703942bac334d93cf66e32b3625cbe279fd30.
> SVN fails when trying to create a branch with nested directories
>
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 1.9.5
>
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SCM-813) SVN fails when trying to create a branch with nested directories
[
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SCM-813:
---
Summary: SVN fails when trying to create a branch with nested directories
(was: SVN fails when trying to create a branch with nested folders)
> SVN fails when trying to create a branch with nested directories
>
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 1.9.5
>
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SCM-813) SVN fails when trying to create a branch with nested folders
[
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SCM-813:
---
Fix Version/s: 1.9.5
> SVN fails when trying to create a branch with nested folders
>
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 1.9.5
>
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MJAVADOC-368) Can not use a comma (,) in option additionalparam
[
https://issues.apache.org/jira/browse/MJAVADOC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067941#comment-15067941
]
ASF GitHub Bot commented on MJAVADOC-368:
-
GitHub user boillodmanuel opened a pull request:
https://github.com/apache/maven-plugins/pull/75
Fix "Can not use a comma (,) in option additionalparam"
PR for https://issues.apache.org/jira/browse/MJAVADOC-368
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/restlet/maven-plugins trunk
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/maven-plugins/pull/75.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #75
commit d6b6da9e83217755efb0b441e89e4e016e1bce9e
Author: Manuel Boillod
Date: 2015-12-22T10:46:13Z
Fix "Can not use a comma (,) in option additionalparam"
Fix https://issues.apache.org/jira/browse/MJAVADOC-368
> Can not use a comma (,) in option additionalparam
> -
>
> Key: MJAVADOC-368
> URL: https://issues.apache.org/jira/browse/MJAVADOC-368
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Andy Schönemann
>
> I would like to set an additional parameter for javadoc like
> {{-header 'A,B'}}
> But this is not possible! Every comma here separates the string into
> different parameters. So I'm not able to set parameters including commas.
> Furthermore, the options name is {{additionalparam}} and NOT
> {{additionalparamS}}. So it should not be possible to set multiple parameters
> here.
> I also tried
> {{-header 'A,B'}}
> but this doesn't work either.
> [Plugin
> documentation|http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalparam]
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SCM-813) SVN fails when trying to create a branch with nested folders
[
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned SCM-813:
--
Assignee: Michael Osipov
> SVN fails when trying to create a branch with nested folders
>
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Assignee: Michael Osipov
>Priority: Critical
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SCM-813) SVN fails when trying to create a branch with nested folders
[
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067934#comment-15067934
]
Michael Osipov commented on SCM-813:
Confirmed. Branch and tag are seperate from the API POV but not for Subversion
which means that both branch ({{cp}}) and tag ({{cp}}) should work the same.
I will add the missing parents switch.
> SVN fails when trying to create a branch with nested folders
>
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Priority: Critical
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNGSITE-267) Update plugin versions etc.on Using Extensions site.
[
https://issues.apache.org/jira/browse/MNGSITE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067847#comment-15067847
]
Karl Heinz Marbaise edited comment on MNGSITE-267 at 12/22/15 9:43 AM:
---
Fixed in [r1721320|http://svn.apache.org/r1721320]
Fixed link in [r1721322|http://svn.apache.org/r1721322]
was (Author: khmarbaise):
Fixed in [r1721320|http://svn.apache.org/r1721320]
> Update plugin versions etc.on Using Extensions site.
>
>
> Key: MNGSITE-267
> URL: https://issues.apache.org/jira/browse/MNGSITE-267
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
>
> Update the used plugin versions etc. on the {{Using Extensions}} site.
> http://maven.apache.org/guides/mini/guide-using-extensions.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNGSITE-267) Update plugin versions etc.on Using Extensions site.
[
https://issues.apache.org/jira/browse/MNGSITE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNGSITE-267.
---
Resolution: Fixed
Assignee: Karl Heinz Marbaise
Fixed in [r1721320|http://svn.apache.org/r1721320]
> Update plugin versions etc.on Using Extensions site.
>
>
> Key: MNGSITE-267
> URL: https://issues.apache.org/jira/browse/MNGSITE-267
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
>
> Update the used plugin versions etc. on the {{Using Extensions}} site.
> http://maven.apache.org/guides/mini/guide-using-extensions.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a failure
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reopened MNG-5868:
--
Hi,
i have created a example project which shows the behaviour has not being
changed for all Maven versions (3.0.5, 3.1.1, 3.2.5, 3.3.9 and current on git
master)..
https://github.com/khmarbaise/mshade/tree/master/mshade-195
In the project there are also checked in the log files that i have produced to
see what is happening...
So either this issue is not solved or the root cause is something different...
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> does not produce a failure
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which mea
[jira] [Comment Edited] (SUREFIRE-1210) Load test-classes and test dependencies into isolated loader
[ https://issues.apache.org/jira/browse/SUREFIRE-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067639#comment-15067639 ] Pavel Kh edited comment on SUREFIRE-1210 at 12/22/15 8:30 AM: -- Hi guys. When are you going to roll out 2.19.1 to maven central repo? was (Author: pkhlebnikov): Hi guys. When are you going to push 2.19.1 to maven central repo? > Load test-classes and test dependencies into isolated loader > > > Key: SUREFIRE-1210 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1210 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: mike duigou > > Currently both the artifact and it's tests are loaded in to the same > classloader. The test-classes and test dependencies are also placed ahead of > the artifact classes in the search path. This can cause problems if the test > classes contains mocks classes with the same name as artifact classes that > aren't intended for use by all tests. > The test classes and test dependencies should be placed in their own > classloader, a child of whichever classloader is being used for the artifact > and run dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSITE-672) Interpolation of site deploy URL not done in child
[
https://issues.apache.org/jira/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067724#comment-15067724
]
Jörg Sesterhenn commented on MSITE-672:
---
I am all for a step-by-step solution here. Just wanted to make a step.
Since you already suggested more than two years ago that there is nothing that
can be done in the site plugin to improve the current situation I thought the
logical step would be to address the issue in maven-core.
If my usecase (publishing all versions of sites in parallel / single point of
configuration) is invalid or should be managed in any other way I expect this
to be documented.
> Interpolation of site deploy URL not done in child
> --
>
> Key: MSITE-672
> URL: https://issues.apache.org/jira/browse/MSITE-672
> Project: Maven Site Plugin
> Issue Type: Wish
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Assignee: Hervé Boutemy
>
> I have my parent distribution site config filled out like so:
> {{scp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}/}}
> When the child tries to release:perform or {{site:deploy}} it tries to upload
> with the parent arifactId, groupId and version instead of the current project
> values. These should be interpolated like any other variables in the POM to
> prevent needless duplication in all children.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
