[jira] (MSITE-740) Allow multiple extensions for given format
Petar Tahchiev created MSITE-740: Summary: Allow multiple extensions for given format Key: MSITE-740 URL: https://jira.codehaus.org/browse/MSITE-740 Project: Maven Site Plugin Issue Type: Improvement Reporter: Petar Tahchiev There 2 issues in doxia and doxia-sitetools to address this issue (DOXIASITETOOLS-102 and DOXIA-527). So fixing those and upgrading the version of doxia should be enough. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-414) Artifacts missing from test classpath.
[ https://jira.codehaus.org/browse/MJAVADOC-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365038#comment-365038 ] Karl-Heinz Marbaise commented on MJAVADOC-414: -- Marcos, do you have the chance to create an integration test which shows that this patch will solve the problem? In relationship with the example projects? Artifacts missing from test classpath. -- Key: MJAVADOC-414 URL: https://jira.codehaus.org/browse/MJAVADOC-414 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10.1 Environment: Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) Java version: 1.7.0_65, vendor: Oracle Corporation Default locale: de_DE, platform encoding: UTF-8 Reporter: Christian Schulte Fix For: 2.10.3 Attachments: MJAVADOC-414.patch, mjavadoc-414.zip, mjavadoc-414.zip Upgrading the javadoc plugin to version 2.10 or 2.10.1, test documentation fails to find classpath elements from 'test' scope. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-425) Outdated doxia's version is used in plugin
[ https://jira.codehaus.org/browse/MJAVADOC-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MJAVADOC-425: - Fix Version/s: 2.10.3 Outdated doxia's version is used in plugin -- Key: MJAVADOC-425 URL: https://jira.codehaus.org/browse/MJAVADOC-425 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10.1 Reporter: Aleksey Nesterenko Fix For: 2.10.3 I've faced problems while generating linkcheck report on our project. Links are pointing to methods in javadoc generated html pages, but in final report lots of links are marked as invalid Analyzing of the problem let me noticed that maven-javadoc-plugin is using doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 pom: properties ... doxiaVersion1.0/doxiaVersion doxia-sitetoolsVersion1.0/doxia-sitetoolsVersion ... /properties My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and as you see it was fixed in doxia 1.4 Current latest doxia version is 1.6, so I think there's need of updating javadoc plugin. Steps of reproducing my problem: 1) git clone g...@github.com:checkstyle/checkstyle.git cd checkstyle/ git checkout checkstyle-6.3 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true -Dcobertura.skip=true 3) Open target/site/linkcheck.html Example of my current report: http://alexkravin.github.io/linkcheck/linkcheck.html As you can see - even invalid link will redirect you to proper location. E.g.: apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html error ../../../../../com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer,%20int): doesn't exist but it's valid http://alexkravin.github.io/linkcheck/apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer, int) One more case: http://docs.oracle.com/javase/7/docs/api/org/xml/sax/helpers.DefaultHandler.html?is-external=true: 404 Not Found This link is broken because DefaultHandler is preceded by dot instead of '/'. All other cases with links to docs.oracle.com/... are valid. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIASITETOOLS-102) Allow multiple extensions for given format
Petar Tahchiev created DOXIASITETOOLS-102: - Summary: Allow multiple extensions for given format Key: DOXIASITETOOLS-102 URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-102 Project: Maven Doxia Sitetools Issue Type: Improvement Reporter: Petar Tahchiev Hello, according to this thread here: https://github.com/asciidoctor/asciidoctor-maven-plugin/issues/125 people are requesting to allow multiple extensions (*.adoc and *.asciidoc) for the doxia renderer. I've done also a pull request to address this issue: https://github.com/apache/maven-doxia-sitetools/pull/1 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-414) Artifacts missing from test classpath.
[ https://jira.codehaus.org/browse/MJAVADOC-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MJAVADOC-414: - Fix Version/s: (was: next-release) 2.10.3 Artifacts missing from test classpath. -- Key: MJAVADOC-414 URL: https://jira.codehaus.org/browse/MJAVADOC-414 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10.1 Environment: Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) Java version: 1.7.0_65, vendor: Oracle Corporation Default locale: de_DE, platform encoding: UTF-8 Reporter: Christian Schulte Fix For: 2.10.3 Attachments: MJAVADOC-414.patch, mjavadoc-414.zip, mjavadoc-414.zip Upgrading the javadoc plugin to version 2.10 or 2.10.1, test documentation fails to find classpath elements from 'test' scope. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-347) javadoc:aggregate-jar doesn't create Javadoc JAR if failOnError=false and there is an error
[
https://jira.codehaus.org/browse/MJAVADOC-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MJAVADOC-347:
-
Fix Version/s: (was: next-release)
2.10.3
javadoc:aggregate-jar doesn't create Javadoc JAR if failOnError=false and
there is an error
---
Key: MJAVADOC-347
URL: https://jira.codehaus.org/browse/MJAVADOC-347
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.8.1
Reporter: Luis Miranda
Fix For: 2.10.3
Attachments:
0001-MJAVADOC-347-added-JavadocJarTest.testContinueIfFail.patch,
0002-MJAVADOC-347-continue-with-archive-creation-if-failO.patch
We are generating Javadocs for a large multi-module build, so there are bound
to be some errors (for example, in 3rd party dependencies).
Currently we set failOnError=false, but we found that the {{aggregate-jar}}
MOJO does not produce a JAR if there are errors. The problem comes down to
this code in JavadocJar:
{code}
try
{
executeReport( Locale.getDefault() );
if ( innerDestDir.exists() )
{
File outputFile = generateArchive( innerDestDir, finalName +
- + getClassifier() + .jar );
if ( !attach )
{
getLog().info( NOT adding javadoc to attached artifacts
list. );
}
else
{
// TODO: these introduced dependencies on the project are
going to become problematic - can we expor
// through metadata instead?
projectHelper.attachArtifact( project, javadoc,
getClassifier(), outputFile );
}
}
}
catch ( ArchiverException e )
{
failOnError( ArchiverException: Error while creating archive, e
);
}
catch ( IOException e )
{
failOnError( IOException: Error while creating archive, e );
}
catch ( MavenReportException e )
{
failOnError( MavenReportException: Error while creating
archive, e );
}
catch ( RuntimeException e )
{
failOnError( RuntimeException: Error while creating archive, e
);
}
{code}
If there is an error in {{executeReport( Locale.getDefault() )}} then the
MOJO will just give up and not try to create the archive. I think that if
failOnError is set, then we should try to create the archive anyway.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-414) Artifacts missing from test classpath.
[ https://jira.codehaus.org/browse/MJAVADOC-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MJAVADOC-414: - Fix Version/s: next-release Artifacts missing from test classpath. -- Key: MJAVADOC-414 URL: https://jira.codehaus.org/browse/MJAVADOC-414 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10.1 Environment: Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) Java version: 1.7.0_65, vendor: Oracle Corporation Default locale: de_DE, platform encoding: UTF-8 Reporter: Christian Schulte Fix For: next-release Attachments: MJAVADOC-414.patch, mjavadoc-414.zip, mjavadoc-414.zip Upgrading the javadoc plugin to version 2.10 or 2.10.1, test documentation fails to find classpath elements from 'test' scope. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-425) Outdated doxia's version is used in plugin
[ https://jira.codehaus.org/browse/MJAVADOC-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365039#comment-365039 ] Karl-Heinz Marbaise commented on MJAVADOC-425: -- Fixed in [r1666798|http://svn.apache.org/r1666798]. Upgraded to doxia 1.4 as a first step. Could check if this will solve your problem? I can provided a SNAPSHOT if you like? Outdated doxia's version is used in plugin -- Key: MJAVADOC-425 URL: https://jira.codehaus.org/browse/MJAVADOC-425 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10.1 Reporter: Aleksey Nesterenko Fix For: 2.10.3 I've faced problems while generating linkcheck report on our project. Links are pointing to methods in javadoc generated html pages, but in final report lots of links are marked as invalid Analyzing of the problem let me noticed that maven-javadoc-plugin is using doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 pom: properties ... doxiaVersion1.0/doxiaVersion doxia-sitetoolsVersion1.0/doxia-sitetoolsVersion ... /properties My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and as you see it was fixed in doxia 1.4 Current latest doxia version is 1.6, so I think there's need of updating javadoc plugin. Steps of reproducing my problem: 1) git clone g...@github.com:checkstyle/checkstyle.git cd checkstyle/ git checkout checkstyle-6.3 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true -Dcobertura.skip=true 3) Open target/site/linkcheck.html Example of my current report: http://alexkravin.github.io/linkcheck/linkcheck.html As you can see - even invalid link will redirect you to proper location. E.g.: apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html error ../../../../../com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer,%20int): doesn't exist but it's valid http://alexkravin.github.io/linkcheck/apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer, int) One more case: http://docs.oracle.com/javase/7/docs/api/org/xml/sax/helpers.DefaultHandler.html?is-external=true: 404 Not Found This link is broken because DefaultHandler is preceded by dot instead of '/'. All other cases with links to docs.oracle.com/... are valid. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-425) Outdated doxia's version is used in plugin
[ https://jira.codehaus.org/browse/MJAVADOC-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise reassigned MJAVADOC-425: Assignee: Karl-Heinz Marbaise Outdated doxia's version is used in plugin -- Key: MJAVADOC-425 URL: https://jira.codehaus.org/browse/MJAVADOC-425 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10.1 Reporter: Aleksey Nesterenko Assignee: Karl-Heinz Marbaise Fix For: 2.10.3 I've faced problems while generating linkcheck report on our project. Links are pointing to methods in javadoc generated html pages, but in final report lots of links are marked as invalid Analyzing of the problem let me noticed that maven-javadoc-plugin is using doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 pom: properties ... doxiaVersion1.0/doxiaVersion doxia-sitetoolsVersion1.0/doxia-sitetoolsVersion ... /properties My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and as you see it was fixed in doxia 1.4 Current latest doxia version is 1.6, so I think there's need of updating javadoc plugin. Steps of reproducing my problem: 1) git clone g...@github.com:checkstyle/checkstyle.git cd checkstyle/ git checkout checkstyle-6.3 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true -Dcobertura.skip=true 3) Open target/site/linkcheck.html Example of my current report: http://alexkravin.github.io/linkcheck/linkcheck.html As you can see - even invalid link will redirect you to proper location. E.g.: apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html error ../../../../../com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer,%20int): doesn't exist but it's valid http://alexkravin.github.io/linkcheck/apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer, int) One more case: http://docs.oracle.com/javase/7/docs/api/org/xml/sax/helpers.DefaultHandler.html?is-external=true: 404 Not Found This link is broken because DefaultHandler is preceded by dot instead of '/'. All other cases with links to docs.oracle.com/... are valid. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-462) Filter fileNames when creating archetype from existing project
[
https://jira.codehaus.org/browse/ARCHETYPE-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated ARCHETYPE-462:
Component/s: Creator
Filter fileNames when creating archetype from existing project
--
Key: ARCHETYPE-462
URL: https://jira.codehaus.org/browse/ARCHETYPE-462
Project: Maven Archetype
Issue Type: Bug
Components: Creator
Affects Versions: 2.2
Reporter: Petar Tahchiev
Hi guys,
i'm trying to create an archetype from an existing project. Some of my
classes are named xxxProduct where I would like to xxx to be replaced by a
custom property from the client. That's why I have defined my custom property
in the {{archetype.properties}} file:
{code}
project-name=xxx
{code}
It all works great - the class name becomes {{WhateverISpecifyProduct}} but
the filename is still {{xxxProduct.java}}. I have created a simple pull
request to allow also the filenames to be filtered with custom properties.
Please review it and merge if everything is OK.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (DOXIA-527) Allow multiple extensions for given format
Petar Tahchiev created DOXIA-527: Summary: Allow multiple extensions for given format Key: DOXIA-527 URL: https://jira.codehaus.org/browse/DOXIA-527 Project: Maven Doxia Issue Type: Improvement Reporter: Petar Tahchiev Hello, according to this thread here: https://github.com/asciidoctor/asciidoctor-maven-plugin/issues/125 people are requesting to allow multiple extensions (*.adoc and *.asciidoc) for the doxia renderer. I've done also a pull request to address this issue: https://github.com/apache/maven-doxia/pull/1 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[ https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365032#comment-365032 ] Robert Scholte commented on MNG-5605: - I realized a bit too late that wagon-ssh isn't part of the Maven distribution, see http://maven.apache.org/ref/3.2.5/apache-maven/dependencies.html However, it surprises me that this used to work with Maven-3.1.x and not in Maven-3.2.x anymore, like there's some kind of classloader issue. At least give wagon-ssh 2.9-SNAPSHOT a try, I assume you have specified wagon-ssh somewhere. ssh-wagon hangs --- Key: MNG-5605 URL: https://jira.codehaus.org/browse/MNG-5605 Project: Maven Issue Type: Bug Components: Deployment Affects Versions: 3.2.1 Reporter: Frank Cornelis Priority: Blocker Fix For: 3.3.2 When releasing (using maven-release-plugin) via Maven 3.1.1 everything works as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden hangs on the second ssh upload. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[
https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365031#comment-365031
]
Frank Cornelis commented on MNG-5605:
-
I'm trying out 3.2.6-SNAPSHOT with the project at:
https://github.com/e-Contract/mycarenet (check the pom.xml for the used release
config).
However, during {{mvn release:plugin}} I still get:
{code}
[INFO] [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ mycarenet
---
[INFO] Uploading:
scp://192.168.100.1/maven2/be/e_contract/mycarenet/1.2.1/mycarenet-1.2.1.pom
[INFO] 4/8 KB
[INFO] 8/8 KB
[INFO]
[INFO] Uploaded:
scp://192.168.100.1/maven2/be/e_contract/mycarenet/1.2.1/mycarenet-1.2.1.pom (8
KB at 4.2 KB/sec)
[INFO] Downloading:
scp://192.168.100.1/maven2/be/e_contract/mycarenet/maven-metadata.xml
[INFO] 892/891 B
{code}
The reported downloading size is one off and simply hangs on that.
ssh-wagon hangs
---
Key: MNG-5605
URL: https://jira.codehaus.org/browse/MNG-5605
Project: Maven
Issue Type: Bug
Components: Deployment
Affects Versions: 3.2.1
Reporter: Frank Cornelis
Priority: Blocker
Fix For: 3.3.2
When releasing (using maven-release-plugin) via Maven 3.1.1 everything works
as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden
hangs on the second ssh upload.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[
https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365031#comment-365031
]
Frank Cornelis edited comment on MNG-5605 at 3/15/15 5:04 AM:
--
I'm trying out 3.2.6-SNAPSHOT with the project at:
https://github.com/e-Contract/mycarenet (check the pom.xml for the used release
config).
However, during {{mvn release:perform}} I still get:
{code}
[INFO] [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ mycarenet
---
[INFO] Uploading:
scp://192.168.100.1/maven2/be/e_contract/mycarenet/1.2.1/mycarenet-1.2.1.pom
[INFO] 4/8 KB
[INFO] 8/8 KB
[INFO]
[INFO] Uploaded:
scp://192.168.100.1/maven2/be/e_contract/mycarenet/1.2.1/mycarenet-1.2.1.pom (8
KB at 4.2 KB/sec)
[INFO] Downloading:
scp://192.168.100.1/maven2/be/e_contract/mycarenet/maven-metadata.xml
[INFO] 892/891 B
{code}
The reported downloading size is one off and simply hangs on that.
was (Author: fcorneli):
I'm trying out 3.2.6-SNAPSHOT with the project at:
https://github.com/e-Contract/mycarenet (check the pom.xml for the used release
config).
However, during {{mvn release:plugin}} I still get:
{code}
[INFO] [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ mycarenet
---
[INFO] Uploading:
scp://192.168.100.1/maven2/be/e_contract/mycarenet/1.2.1/mycarenet-1.2.1.pom
[INFO] 4/8 KB
[INFO] 8/8 KB
[INFO]
[INFO] Uploaded:
scp://192.168.100.1/maven2/be/e_contract/mycarenet/1.2.1/mycarenet-1.2.1.pom (8
KB at 4.2 KB/sec)
[INFO] Downloading:
scp://192.168.100.1/maven2/be/e_contract/mycarenet/maven-metadata.xml
[INFO] 892/891 B
{code}
The reported downloading size is one off and simply hangs on that.
ssh-wagon hangs
---
Key: MNG-5605
URL: https://jira.codehaus.org/browse/MNG-5605
Project: Maven
Issue Type: Bug
Components: Deployment
Affects Versions: 3.2.1
Reporter: Frank Cornelis
Priority: Blocker
Fix For: 3.3.2
When releasing (using maven-release-plugin) via Maven 3.1.1 everything works
as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden
hangs on the second ssh upload.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[ https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365035#comment-365035 ] Frank Cornelis commented on MNG-5605: - Of course the maven-release-plugin refuses to prepare for a release when depending on a wagon-ssh 2.9-SNAPSHOT version. So I guess I'll have to do a local release of wagon-ssh first. ssh-wagon hangs --- Key: MNG-5605 URL: https://jira.codehaus.org/browse/MNG-5605 Project: Maven Issue Type: Bug Components: Deployment Affects Versions: 3.2.1 Reporter: Frank Cornelis Priority: Blocker Fix For: 3.3.2 When releasing (using maven-release-plugin) via Maven 3.1.1 everything works as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden hangs on the second ssh upload. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[
https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365036#comment-365036
]
Frank Cornelis commented on MNG-5605:
-
Doing a quick-and-dirty local release of wagon-ssh via:
{code}
git clone https://git-wip-us.apache.org/repos/asf/maven-wagon.git
cd maven-wagon
mvn versions:set -DnewVersion=2.9-econtract-1
mvn clean install -Dmaven.test.skip=true
{code}
and then referring to it via:
{code:xml}
extensions
extension
groupIdorg.apache.maven.wagon/groupId
artifactIdwagon-ssh/artifactId
version2.9-econtract-1/version
/extension
/extensions
{code}
indeed fixes the issue.
ssh-wagon hangs
---
Key: MNG-5605
URL: https://jira.codehaus.org/browse/MNG-5605
Project: Maven
Issue Type: Bug
Components: Deployment
Affects Versions: 3.2.1
Reporter: Frank Cornelis
Priority: Blocker
Fix For: 3.3.2
When releasing (using maven-release-plugin) via Maven 3.1.1 everything works
as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden
hangs on the second ssh upload.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[
https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365037#comment-365037
]
Robert Scholte commented on MNG-5605:
-
When doing a {{mvn deploy}} you don't have that issue? If that's the case, the
{{maven-release-plugin}} itself might add {{wagon-ssh}} to the classpath (
http://maven.apache.org/maven-release/maven-release-plugin/dependencies.html )
and that's wrong.
ssh-wagon hangs
---
Key: MNG-5605
URL: https://jira.codehaus.org/browse/MNG-5605
Project: Maven
Issue Type: Bug
Components: Deployment
Affects Versions: 3.2.1
Reporter: Frank Cornelis
Priority: Blocker
Fix For: 3.3.2
When releasing (using maven-release-plugin) via Maven 3.1.1 everything works
as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden
hangs on the second ssh upload.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-414) Artifacts missing from test classpath.
[ https://jira.codehaus.org/browse/MJAVADOC-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Srb updated MJAVADOC-414: Attachment: 0002-Fix-MJAVADOC-414.patch 0001-Add-IT-for-MJAVADOC-414.patch The patch adds project's classes to javadoc's classpath, if user runs goal which produces test javadocs. IT included, based on Christian's reproducer. Artifacts missing from test classpath. -- Key: MJAVADOC-414 URL: https://jira.codehaus.org/browse/MJAVADOC-414 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10.1 Environment: Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) Java version: 1.7.0_65, vendor: Oracle Corporation Default locale: de_DE, platform encoding: UTF-8 Reporter: Christian Schulte Fix For: 2.10.3 Attachments: 0001-Add-IT-for-MJAVADOC-414.patch, 0002-Fix-MJAVADOC-414.patch, MJAVADOC-414.patch, mjavadoc-414.zip, mjavadoc-414.zip Upgrading the javadoc plugin to version 2.10 or 2.10.1, test documentation fails to find classpath elements from 'test' scope. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-279) Empty maven.home should be treated like if it was unset
[
https://jira.codehaus.org/browse/MSHARED-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSHARED-279.
--
Resolution: Won't Fix
Assignee: Robert Scholte
if {{maven.home}} is empty, you'll probably have a serious problem. I won't fix
this unless there's a real testcase which exposes this problem.
Empty maven.home should be treated like if it was unset
---
Key: MSHARED-279
URL: https://jira.codehaus.org/browse/MSHARED-279
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-invoker
Affects Versions: maven-invoker-2.1.1, maven-invoker-2.1.2
Reporter: Mikolaj Izdebski
Assignee: Robert Scholte
Attachments: maven-invoker-MSHARED-279.patch
In my opinion if maven.home system property is defined to an empty string
then it should be treated as if it was undefined.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-20) Extend Invoker API to support the needs of the Release Plugin
[
https://jira.codehaus.org/browse/MSHARED-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MSHARED-20:
--
Fix Version/s: maven-invoker-3.0.0
Extend Invoker API to support the needs of the Release Plugin
-
Key: MSHARED-20
URL: https://jira.codehaus.org/browse/MSHARED-20
Project: Maven Shared Components
Issue Type: New Feature
Components: maven-invoker
Reporter: Benjamin Bentmann
Fix For: maven-invoker-3.0.0
We are happily maintaining (at least) two code bases to fork Maven: One in
the maven-invoker ({{Invoker}} and {{DefaultInvoker}}) and one in the
maven-release-manager ({{MavenExecutor}} and {{ForkedMavenExecutor}}). Some
far day in the future we might want to consolidate this stuff into a single
component.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-250) NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies
[
https://jira.codehaus.org/browse/MCHECKSTYLE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHECKSTYLE-250.
---
Resolution: Fixed
Fix Version/s: 2.15
Assignee: Dennis Lundberg
NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies
--
Key: MCHECKSTYLE-250
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-250
Project: Maven Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.13
Reporter: Konstantin Pokrovsky
Assignee: Dennis Lundberg
Fix For: 2.15
*Steps to reproduce:*
* Add non jar (XML for example) artifact dependency to plugin dependencies
section:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.13/version
dependencies
dependency
groupIdanygroup/groupId
artifactIdanyfile/artifactId
typexml/type
/dependency
/dependencies
/plugin
{code}
* Run _checkstyle:check_
Result:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check (default-cli) on
project rt: Execution default-cli of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
NullPointerException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check
(default-cli) on project rt: Execution default-cli of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.13:check failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 common frames omitted
Caused by: java.lang.NullPointerException: null
at
org.codehaus.plexus.resource.loader.JarHolder.getEntries(JarHolder.java:126)
at
org.codehaus.plexus.resource.loader.JarResourceLoader.loadJar(JarResourceLoader.java:100)
at
org.codehaus.plexus.resource.loader.JarResourceLoader.initialize(JarResourceLoader.java:63)
at
org.codehaus.plexus.resource.loader.JarResourceLoader.getResource(JarResourceLoader.java:141)
at
org.apache.maven.plugin.checkstyle.resource.LicenseResourceManager.getResource(LicenseResourceManager.java:75)
at
org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getOverridingProperties(DefaultCheckstyleExecutor.java:520)
at
[jira] (MSITE-617) Variable substitution in the site url doesn't work
[
https://jira.codehaus.org/browse/MSITE-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365045#comment-365045
]
Nikolay Rybak commented on MSITE-617:
-
Haven't had a change to really work on minimal example for quite some time, but
finally here it is: https://github.com/GreyTeardrop/maven-site-plugin-issue
Setup: parent project has {{distributionManagement}} section that refers to
variable {{nexus.url}} that comes from {{settings.xml}}. If built via reactor,
everything works fine. However, if parent and child are built separately (in
reality they have different lifecycles and live in different repositories) then
{{site:stage}} and {{site:deploy}} for child project break.
Steps to reproduce:
# {{cd parent; mvn -gs ../settings.xml install}}
# {{cd ../child; mvn -gs ../settings.xml verify site}}
# {{mvn -gs ../settings.xml site:deploy}}
{noformat}
$ mvn -gs ../settings.xml site:deploy
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building child 1.0.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-site-plugin:3.4:deploy (default-cli) @ child ---
SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.
http://${nexus.url}/nexus/content/repositories/site/ - Session: Opened
[INFO] Pushing
D:\Home\Grey\work\Projects\maven-site-plugin-issue\child\target\site
[INFO] to
http://${nexus.url}/nexus/content/repositories/site/../../../../../nexus:8081/nexus/content/repositories/site/child
http://${nexus.url}/nexus/content/repositories/site/ - Session: Disconnecting
http://${nexus.url}/nexus/content/repositories/site/ - Session: Disconnected
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1.418s
[INFO] Finished at: Sun Mar 15 21:04:41 EET 2015
[INFO] Final Memory: 11M/166M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4:deploy (default-cli) on project
child: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.4:deploy failed.
NullPointerException - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
{noformat}
If Site plugin version is changed to 3.0 beta 3 (using Maven 3.0.4) then
{{site:deploy}} and {{site:stage}} work just fine. As far as I understand, as
of version 3.0 Site plugin relativizes URLs based on top-level parent site's
URL, and seems not to expand variables in {{distributionManagement}} section.
Variable substitution in the site url doesn't work
--
Key: MSITE-617
URL: https://jira.codehaus.org/browse/MSITE-617
Project: Maven Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 2.3
Environment: Windows 7 and RHEL6
Reporter: Claus Nielsen
{{site:deploy}} fails because variable substitution in the site url no longer
works (it did in version 2.2).
The distributionManagement section in out POM looks something like this:
{code:xml}
distributionManagement
site
idsites/id
nameProject Website/name
urlscp://server/sites/${project.artifactId}/${project.version}/url
/site
/distributionManagement
{code}
Copying the site to the above mentioned url fails with this message:
{noformat}
[INFO] Error uploading site
Embedded error: Error performing commands for file transfer
Exit code: 1 - bash:
/sites/${project.artifactId}/${project.version}/../../id-of-the-artifact/0.2.8-SNAPSHOT:
bad substitution
{noformat}
Ie. the substitutiuon variables have not been substituted, instead the
property values have been appended to the url along with a few dots and
dashes.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINVOKER-173) The default values of parameters are not set as described.
[
https://jira.codehaus.org/browse/MINVOKER-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MINVOKER-173:
-
Fix Version/s: (was: 1.9.1)
The default values of parameters are not set as described.
--
Key: MINVOKER-173
URL: https://jira.codehaus.org/browse/MINVOKER-173
Project: Maven Invoker Plugin
Issue Type: Bug
Affects Versions: 1.9
Reporter: Karl-Heinz Marbaise
Assignee: Karl-Heinz Marbaise
Priority: Critical
The default values for the following parameters {{setupIncludes}}, {{goals}},
{{pomIncludes}} are not set according to the documented default values.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINVOKER-168) Document the supplemental information about the maven version
[ https://jira.codehaus.org/browse/MINVOKER-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MINVOKER-168: - Fix Version/s: (was: 1.9.1) 1.9 Document the supplemental information about the maven version - Key: MINVOKER-168 URL: https://jira.codehaus.org/browse/MINVOKER-168 Project: Maven Invoker Plugin Issue Type: Improvement Affects Versions: 1.9 Reporter: Karl-Heinz Marbaise Fix For: 1.9 The information about the mavenVersion variable should be documented somewhere. http://maven.apache.org/plugins/maven-invoker-plugin/examples/post-build-script.html Currently it is not documented. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-261) DefaultInvoker does not set M2_HOME
[
https://jira.codehaus.org/browse/MSHARED-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MSHARED-261:
--
Assignee: Robert Scholte
DefaultInvoker does not set M2_HOME
---
Key: MSHARED-261
URL: https://jira.codehaus.org/browse/MSHARED-261
Project: Maven Shared Components
Issue Type: Bug
Components: maven-invoker
Environment: * Win7 x64
* JDK 6
Reporter: Bernd Vogt
Assignee: Robert Scholte
Attachments: maven-invocation-its.zip
*Problem:*
Recently, some of our releases failed because the maven-release-plugin has
not re-used the Maven installation with which it was launched to perform the
actual release goals. It was noticeable that the release plugin has used the
Maven installation where the M2_HOME variable of the current machine has
pointed to...
After some investigation, I figured out, that the DefaultInvoker doesn't
propagate the Maven home directory to the M2_HOME env var of invoked Maven
processes but uses the mvn.bat of those Maven. The problem ist, that mvn.bat
at first looks-up for M2_HOME to launch the Maven which is located there...
So, if M2_HOME is already set this takes effect and not the Maven where the
invoked mvn.bat is contained in...
*Workaround for release problem:*
Configure release plugin to use the Maven executor 'forked-path' instead of
'invoke'
*Workaround when using Invoker:*
{{request.addShellEnvironment(M2_HOME,
invoker.getMavenHome().getAbsolutePath());}}
*Steps to reproduce:*
# Download and unzip attached test project
# cd to unzipped folder and {{mvn clean verify}}
# Take a look at contained {{DefaultInvokerIT}}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-425) Outdated doxia's version is used in plugin
[ https://jira.codehaus.org/browse/MJAVADOC-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MJAVADOC-425. Resolution: Fixed Outdated doxia's version is used in plugin -- Key: MJAVADOC-425 URL: https://jira.codehaus.org/browse/MJAVADOC-425 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10.1 Reporter: Aleksey Nesterenko Assignee: Karl-Heinz Marbaise Fix For: 2.10.3 I've faced problems while generating linkcheck report on our project. Links are pointing to methods in javadoc generated html pages, but in final report lots of links are marked as invalid Analyzing of the problem let me noticed that maven-javadoc-plugin is using doxia libs version 1.0, e.g. snippet from maven-javadoc-plugin version 2.10.1 pom: properties ... doxiaVersion1.0/doxiaVersion doxia-sitetoolsVersion1.0/doxia-sitetoolsVersion ... /properties My problem is close to this one http://jira.codehaus.org/browse/DOXIA-397 and as you see it was fixed in doxia 1.4 Current latest doxia version is 1.6, so I think there's need of updating javadoc plugin. Steps of reproducing my problem: 1) git clone g...@github.com:checkstyle/checkstyle.git cd checkstyle/ git checkout checkstyle-6.3 2) mvn clean install -DskipTests -Dpmd.skip=true -Dfindbugs.skip=true -Dcobertura.skip=true 3) Open target/site/linkcheck.html Example of my current report: http://alexkravin.github.io/linkcheck/linkcheck.html As you can see - even invalid link will redirect you to proper location. E.g.: apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html error ../../../../../com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer,%20int): doesn't exist but it's valid http://alexkravin.github.io/linkcheck/apidocs/com/puppycrawl/tools/checkstyle/grammars/GeneratedJavaRecognizer.html#GeneratedJavaRecognizer(antlr.TokenBuffer, int) One more case: http://docs.oracle.com/javase/7/docs/api/org/xml/sax/helpers.DefaultHandler.html?is-external=true: 404 Not Found This link is broken because DefaultHandler is preceded by dot instead of '/'. All other cases with links to docs.oracle.com/... are valid. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-414) Artifacts missing from test classpath.
[ https://jira.codehaus.org/browse/MJAVADOC-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MJAVADOC-414. Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1666819|http://svn.apache.org/r1666819]. Patch of Michael Srb applied. Thank you very much. Artifacts missing from test classpath. -- Key: MJAVADOC-414 URL: https://jira.codehaus.org/browse/MJAVADOC-414 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10.1 Environment: Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00) Java version: 1.7.0_65, vendor: Oracle Corporation Default locale: de_DE, platform encoding: UTF-8 Reporter: Christian Schulte Assignee: Karl-Heinz Marbaise Fix For: 2.10.3 Attachments: 0001-Add-IT-for-MJAVADOC-414.patch, 0002-Fix-MJAVADOC-414.patch, MJAVADOC-414.patch, mjavadoc-414.zip, mjavadoc-414.zip Upgrading the javadoc plugin to version 2.10 or 2.10.1, test documentation fails to find classpath elements from 'test' scope. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINVOKER-173) The default values of parameters are not set as described.
[
https://jira.codehaus.org/browse/MINVOKER-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MINVOKER-173.
Resolution: Cannot Reproduce
The default values of parameters are not set as described.
--
Key: MINVOKER-173
URL: https://jira.codehaus.org/browse/MINVOKER-173
Project: Maven Invoker Plugin
Issue Type: Bug
Affects Versions: 1.9
Reporter: Karl-Heinz Marbaise
Assignee: Karl-Heinz Marbaise
Priority: Critical
Fix For: 1.9.1
The default values for the following parameters {{setupIncludes}}, {{goals}},
{{pomIncludes}} are not set according to the documented default values.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-178) war plugin documentation and probably implementation is unaware of javaee 5
[ https://jira.codehaus.org/browse/MWAR-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MWAR-178. Resolution: Won't Fix If you have any objections don't hesitate to reopen the issue. war plugin documentation and probably implementation is unaware of javaee 5 --- Key: MWAR-178 URL: https://jira.codehaus.org/browse/MWAR-178 Project: Maven WAR Plugin Issue Type: New Feature Reporter: David Jencks The example I'm aware of: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html talks about using the war's manifest.mf classpath to include jars in the ear in the war module's classloader. In ee5, there's a ear lib directory: everything in that is automatically included in the ear level classloader, which is certainly available to every war, most likely by being a parent classloader to the war classloader. One consequence of this is that using the manifest classpath in a 1.4 container will likely result in each war getting separate copies of the lib jar classes whereas the ee5 lib directory will result in shared classes. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
