[jira] (MNG-5605) ssh-wagon hangs
[
https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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}
org.apache.maven.wagon
wagon-ssh
2.9-econtract-1
{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-tabpanel&focusedCommentId=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 ] 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-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-414) Artifacts missing from test classpath.
[ https://jira.codehaus.org/browse/MJAVADOC-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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-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: > >... > 1.0 > 1.0 > ... > > 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:comment-tabpanel&focusedCommentId=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: > >... > 1.0 > 1.0 > ... > > 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: > >... > 1.0 > 1.0 > ... > > 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] (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] (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: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-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] (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-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] (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}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 2.13
>
>
> anygroup
> anyfile
> xml
>
>
>
> {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
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.ge
[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] (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: > >... > 1.0 > 1.0 > ... > > 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] (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-tabpanel&focusedCommentId=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 {{}} 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}
>
>
> sites
> Project Website
>
> scp://server/sites/${project.artifactId}/${project.version}
>
>
> {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 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] (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] (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)
