[jira] Created: (MSOURCES-58) Maven Source Plugin does not work if project packaging=bundle (OSGi Bundle)
Maven Source Plugin does not work if project packaging=bundle (OSGi Bundle) --- Key: MSOURCES-58 URL: https://jira.codehaus.org/browse/MSOURCES-58 Project: Maven 2.x Source Plugin Issue Type: Bug Affects Versions: 2.1.2 Reporter: Hendy Irawan With project that configured as such: bundle ... org.apache.felix maven-bundle-plugin true Running mvn source:jar produces: [WARNING] NOT adding sources to artifacts with classifier as Maven only supports one classifier per artifact. Current artifact [id.co.bippo:magento-kettle:bundle:1.1.2-SNAPSHOT] has a [] classifier. It should create a source artifact just fine, the bundle packaging can be treated just like jar packaging. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MNG-5964) Corrupt artifact from stale repository makes build fail, even though correct artifact is available
Hendy Irawan created MNG-5964:
-
Summary: Corrupt artifact from stale repository makes build fail,
even though correct artifact is available
Key: MNG-5964
URL: https://issues.apache.org/jira/browse/MNG-5964
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.2.1
Reporter: Hendy Irawan
Priority: Critical
This POM
(https://repo1.maven.org/maven2/com/hp/hpl/jena/jena/2.6.4/jena-2.6.4.pom)
includes an external repository which is: http://openjena.org/repo
Unfortunately, that repo is now a parking page. Which makes builds problematic.
{code}
[INFO] Downloading:
https://repository-soluvas.forge.cloudbees.com/release/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[INFO] Downloading:
http://repo.cloudbees.com/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[INFO] Downloaded:
http://repo.cloudbees.com/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
(6 KB at 568.1 KB/sec)
[INFO] Downloading:
http://nexus.bippo.co.id/nexus/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[INFO] Downloading:
http://jasperreports.sourceforge.net/maven2/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[INFO] Downloading:
http://jaspersoft.artifactoryonline.com/jaspersoft/third-party-ce-artifacts/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[INFO] Downloading:
http://morphia.googlecode.com/svn/mavenrepo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[INFO] Downloading:
http://repo.typesafe.com/typesafe/releases/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[INFO] Downloading:
http://m2.neo4j.org/content/repositories/releases/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[INFO] Downloading:
http://repo.spring.io/milestone/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[INFO] Downloading: http://openjena.org/repo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[WARNING] Checksum validation failed, expected http://openjena.org/repo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[WARNING] Checksum validation failed, expected http://openjena.org/repo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[INFO] Downloaded: http://openjena.org/repo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
(21 KB at 22.3 KB/sec)
[INFO] Downloading:
http://openjena.org/repo-dev/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[WARNING] Checksum validation failed, expected http://openjena.org/repo-dev/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[WARNING] Checksum validation failed, expected http://openjena.org/repo-dev/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
[INFO] Downloaded:
http://openjena.org/repo-dev/com/hp/hpl/jena/iri/0.8/iri-0.8.pom (21 KB at 26.7
KB/sec)
[WARNING] The POM for com.hp.hpl.jena:iri:jar:0.8 is invalid, transitive
dependencies (if any) will not be available, enable debug logging for more
details
{code}
Exact same thing also happens for the JARs.
Please notice that the correct POMs and JARs are available from the other
repository (repo.cloudbees.com proxy), but Maven ignores that and continues to
use the corrupt artifacts, which causes:
{code}
[INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @
id.co.bippo.cart ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 82 source files to
/scratch/jenkins/workspace/bippo-commerce/cart/target/classes
[ERROR] error reading
/scratch/jenkins/workspace/bippo-commerce/.repository/com/hp/hpl/jena/iri/0.8/iri-0.8.jar;
error in opening zip file
[ERROR] error reading
/scratch/jenkins/workspace/bippo-commerce/.repository/com/ibm/icu/icu4j/3.4.4/icu4j-3.4.4.jar;
error in opening zip file
[ERROR] error reading
/scratch/jenkins/workspace/bippo-commerce/.repository/org/slf4j/slf4j-log4j12/1.7.12/slf4j-log4j12-1.7.12.jar;
error in opening zip file
[ERROR] error reading
/scratch/jenkins/workspace/bippo-commerce/.repository/log4j/log4j/1.2.13/log4j-1.2.13.jar;
error in opening zip file
[ERROR] error reading
/scratch/jenkins/workspace/bippo-commerce/.repository/com/hp/hpl/jena/iri/0.8/iri-0.8.jar;
error in opening zip file
[ERROR] error reading
/scratch/jenkins/workspace/bippo-commerce/.repository/com/ibm/icu/icu4j/3.4.4/icu4j-3.4.4.jar;
error in opening zip file
[ERROR] error reading
/scratch/jenkins/workspace/bippo-commerce/.repository/org/slf4j/slf4j-log4j12/1.7.12/slf4j-log4j12-1.7.12.jar;
error in opening zip file
[ERROR] error reading
/scratch/jenkins/workspace/bippo-commerce/.repository/log4j/log4j/1.2.13/log4j-1.2.13.jar;
error in opening zip file
{code}
which makes the build fail.
Please:
1. Ignore artifacts from invalid repos when there are correct artifacts from
other repo
2. Have a way to blacklist repos globally, preferably using ~/.m2/settings.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5964) Corrupt artifact from stale repository makes build fail, even though correct artifact is available
[
https://issues.apache.org/jira/browse/MNG-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110159#comment-15110159
]
Hendy Irawan commented on MNG-5964:
---
Workaround is to put this in {{~/.m2.settings.xml}} :
{code}
openjena.disable
true
repo-jena
Jena Maven - Repository
http://openjena.org/repo
false
false
repo-jena-dev
Jena Maven - Development Repository
default
http://openjena.org/repo-dev
false
true
{code}
I argue that this should be handled automatically by Maven and there's no need
for user to do this manually, in addition to the trouble/skills needed to
diagnose the problem, even when you know the workaround: there could be a bunch
of those hidden in transitive dependencies!
This is exactly why we have checksum validation so let's put it to good use.
> Corrupt artifact from stale repository makes build fail, even though correct
> artifact is available
> --
>
> Key: MNG-5964
> URL: https://issues.apache.org/jira/browse/MNG-5964
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Hendy Irawan
>Priority: Critical
>
> This POM
> (https://repo1.maven.org/maven2/com/hp/hpl/jena/jena/2.6.4/jena-2.6.4.pom)
> includes an external repository which is: http://openjena.org/repo
> Unfortunately, that repo is now a parking page. Which makes builds
> problematic.
> {code}
> [INFO] Downloading:
> https://repository-soluvas.forge.cloudbees.com/release/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://repo.cloudbees.com/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloaded:
> http://repo.cloudbees.com/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> (6 KB at 568.1 KB/sec)
> [INFO] Downloading:
> http://nexus.bippo.co.id/nexus/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://jasperreports.sourceforge.net/maven2/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://jaspersoft.artifactoryonline.com/jaspersoft/third-party-ce-artifacts/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://morphia.googlecode.com/svn/mavenrepo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://repo.typesafe.com/typesafe/releases/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://m2.neo4j.org/content/repositories/releases/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://repo.spring.io/milestone/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://openjena.org/repo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [WARNING] Checksum validation failed, expected e88206ec93de9f9b6b3259b07aa32e8e00cb90d3 for
> http://openjena.org/repo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [WARNING] Checksum validation failed, expected f173aa41f57e9b1d170e42cf6b6f3be5a8882168 for
> http://openjena.org/repo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloaded:
> http://openjena.org/repo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom (21 KB at 22.3
> KB/sec)
> [INFO] Downloading:
> http://openjena.org/repo-dev/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [WARNING] Checksum validation failed, expected 893c64b2141598ad999c3540c5f0ff24c38ce7ce for
> http://openjena.org/repo-dev/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [WARNING] Checksum validation failed, expected a2a942560bf2e1838cf48f9adc7042443e5adb3b for
> http://openjena.org/repo-dev/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloaded:
> http://openjena.org/repo-dev/com/hp/hpl/jena/iri/0.8/iri-0.8.pom (21 KB at
> 26.7 KB/sec)
> [WARNING] The POM for com.hp.hpl.jena:iri:jar:0.8 is invalid, transitive
> dependencies (if any) will not be available, enable debug logging for more
> details
> {code}
> Exact same thing also happens for the JARs.
> Please notice that the correct POMs and JARs are available from the other
> repository (repo.cloudbees.com proxy), but Maven ignores that and continues
> to use the corrupt artifacts, which causes:
> {code}
> [INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @
> id.co.b
[jira] [Comment Edited] (MNG-5964) Corrupt artifact from stale repository makes build fail, even though correct artifact is available
[
https://issues.apache.org/jira/browse/MNG-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110159#comment-15110159
]
Hendy Irawan edited comment on MNG-5964 at 1/21/16 6:38 AM:
Workaround is to put this in {{~/.m2.settings.xml}} :
{code}
openjena.disable
true
repo-jena
Jena Maven - Repository
http://openjena.org/repo
false
false
repo-jena-dev
Jena Maven - Development Repository
default
http://openjena.org/repo-dev
false
true
{code}
I argue that this should be handled automatically by Maven and there's no need
for user to do this manually, in addition to the trouble/skills needed to
diagnose the problem, even when you know the workaround: there could be a bunch
of those hidden in transitive dependencies!
This is exactly why we have checksum validation so let's put it to good use.
And besides, the corrupt website returns {{text/html}} for both POM and JAR
URLs, so it should be enough to discard them immediately.
was (Author: ceefour):
Workaround is to put this in {{~/.m2.settings.xml}} :
{code}
openjena.disable
true
repo-jena
Jena Maven - Repository
http://openjena.org/repo
false
false
repo-jena-dev
Jena Maven - Development Repository
default
http://openjena.org/repo-dev
false
true
{code}
I argue that this should be handled automatically by Maven and there's no need
for user to do this manually, in addition to the trouble/skills needed to
diagnose the problem, even when you know the workaround: there could be a bunch
of those hidden in transitive dependencies!
This is exactly why we have checksum validation so let's put it to good use.
> Corrupt artifact from stale repository makes build fail, even though correct
> artifact is available
> --
>
> Key: MNG-5964
> URL: https://issues.apache.org/jira/browse/MNG-5964
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Hendy Irawan
>Priority: Critical
>
> This POM
> (https://repo1.maven.org/maven2/com/hp/hpl/jena/jena/2.6.4/jena-2.6.4.pom)
> includes an external repository which is: http://openjena.org/repo
> Unfortunately, that repo is now a parking page. Which makes builds
> problematic.
> {code}
> [INFO] Downloading:
> https://repository-soluvas.forge.cloudbees.com/release/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://repo.cloudbees.com/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloaded:
> http://repo.cloudbees.com/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> (6 KB at 568.1 KB/sec)
> [INFO] Downloading:
> http://nexus.bippo.co.id/nexus/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://jasperreports.sourceforge.net/maven2/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://jaspersoft.artifactoryonline.com/jaspersoft/third-party-ce-artifacts/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://morphia.googlecode.com/svn/mavenrepo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://repo.typesafe.com/typesafe/releases/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://m2.neo4j.org/content/repositories/releases/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://repo.spring.io/milestone/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://openjen
[jira] [Comment Edited] (MNG-5964) Corrupt artifact from stale repository makes build fail, even though correct artifact is available
[
https://issues.apache.org/jira/browse/MNG-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110159#comment-15110159
]
Hendy Irawan edited comment on MNG-5964 at 1/22/16 6:19 AM:
Workaround is to put this in {{~/.m2.settings.xml}} :
{code}
openjena.disable
true
repo-jena
Jena Maven - Repository
http://openjena.org/repo
false
false
repo-jena-dev
Jena Maven - Development Repository
default
http://openjena.org/repo-dev
false
true
{code}
I argue that this should be handled automatically by Maven and there's no need
for user to do this manually, in addition to the trouble/skills needed to
diagnose the problem, even when you know the workaround: there could be a bunch
of those hidden in transitive dependencies!
This is exactly why we have checksum validation so let's put it to good use.
And besides, the corrupt website returns {{text/html}} for both POM and JAR
URLs, so it should be enough to discard them immediately.
was (Author: ceefour):
Workaround is to put this in {{~/.m2.settings.xml}} :
{code}
openjena.disable
true
repo-jena
Jena Maven - Repository
http://openjena.org/repo
false
false
repo-jena-dev
Jena Maven - Development Repository
default
http://openjena.org/repo-dev
false
true
{code}
I argue that this should be handled automatically by Maven and there's no need
for user to do this manually, in addition to the trouble/skills needed to
diagnose the problem, even when you know the workaround: there could be a bunch
of those hidden in transitive dependencies!
This is exactly why we have checksum validation so let's put it to good use.
And besides, the corrupt website returns {{text/html}} for both POM and JAR
URLs, so it should be enough to discard them immediately.
> Corrupt artifact from stale repository makes build fail, even though correct
> artifact is available
> --
>
> Key: MNG-5964
> URL: https://issues.apache.org/jira/browse/MNG-5964
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Hendy Irawan
>Priority: Critical
>
> This POM
> (https://repo1.maven.org/maven2/com/hp/hpl/jena/jena/2.6.4/jena-2.6.4.pom)
> includes an external repository which is: http://openjena.org/repo
> Unfortunately, that repo is now a parking page. Which makes builds
> problematic.
> {code}
> [INFO] Downloading:
> https://repository-soluvas.forge.cloudbees.com/release/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://repo.cloudbees.com/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloaded:
> http://repo.cloudbees.com/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> (6 KB at 568.1 KB/sec)
> [INFO] Downloading:
> http://nexus.bippo.co.id/nexus/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://jasperreports.sourceforge.net/maven2/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://jaspersoft.artifactoryonline.com/jaspersoft/third-party-ce-artifacts/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://morphia.googlecode.com/svn/mavenrepo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://repo.typesafe.com/typesafe/releases/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://m2.neo4j.org/content/repositories/releases/co
[jira] [Comment Edited] (MNG-5964) Corrupt artifact from stale repository makes build fail, even though correct artifact is available
[
https://issues.apache.org/jira/browse/MNG-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110159#comment-15110159
]
Hendy Irawan edited comment on MNG-5964 at 1/22/16 9:53 AM:
Workaround is to put this in {{~/.m2.settings.xml}} :
{code}
openjena.disable
true
repo-jena
Jena Maven - Repository
http://openjena.org/repo
false
false
repo-jena-dev
Jena Maven - Development Repository
default
http://openjena.org/repo-dev
false
false
{code}
I argue that this should be handled automatically by Maven and there's no need
for user to do this manually, in addition to the trouble/skills needed to
diagnose the problem, even when you know the workaround: there could be a bunch
of those hidden in transitive dependencies!
This is exactly why we have checksum validation so let's put it to good use.
And besides, the corrupt website returns {{text/html}} for both POM and JAR
URLs, so it should be enough to discard them immediately.
was (Author: ceefour):
Workaround is to put this in {{~/.m2.settings.xml}} :
{code}
openjena.disable
true
repo-jena
Jena Maven - Repository
http://openjena.org/repo
false
false
repo-jena-dev
Jena Maven - Development Repository
default
http://openjena.org/repo-dev
false
true
{code}
I argue that this should be handled automatically by Maven and there's no need
for user to do this manually, in addition to the trouble/skills needed to
diagnose the problem, even when you know the workaround: there could be a bunch
of those hidden in transitive dependencies!
This is exactly why we have checksum validation so let's put it to good use.
And besides, the corrupt website returns {{text/html}} for both POM and JAR
URLs, so it should be enough to discard them immediately.
> Corrupt artifact from stale repository makes build fail, even though correct
> artifact is available
> --
>
> Key: MNG-5964
> URL: https://issues.apache.org/jira/browse/MNG-5964
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Hendy Irawan
>Priority: Critical
>
> This POM
> (https://repo1.maven.org/maven2/com/hp/hpl/jena/jena/2.6.4/jena-2.6.4.pom)
> includes an external repository which is: http://openjena.org/repo
> Unfortunately, that repo is now a parking page. Which makes builds
> problematic.
> {code}
> [INFO] Downloading:
> https://repository-soluvas.forge.cloudbees.com/release/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://repo.cloudbees.com/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloaded:
> http://repo.cloudbees.com/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> (6 KB at 568.1 KB/sec)
> [INFO] Downloading:
> http://nexus.bippo.co.id/nexus/content/groups/public/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://jasperreports.sourceforge.net/maven2/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://jaspersoft.artifactoryonline.com/jaspersoft/third-party-ce-artifacts/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://morphia.googlecode.com/svn/mavenrepo/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://repo.typesafe.com/typesafe/releases/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO] Downloading:
> http://m2.neo4j.org/content/repositories/releases/com/hp/hpl/jena/iri/0.8/iri-0.8.pom
> [INFO
[jira] (MNG-2258) Wrong execution order of plugins in same phase
[ https://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304856#comment-304856 ] Hendy Irawan commented on MNG-2258: --- This bug isn't fixed yet. I'm using Maven 3.0.4 and the ordering is still arbitrary :( > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: https://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: Benson Margulies >Priority: Blocker > Fix For: 3.0.3 > > Attachments: mavenTest.zip > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2258) Wrong execution order of plugins in same phase
[ https://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304874#comment-304874 ] Hendy Irawan commented on MNG-2258: --- Thank you Barrie. I tried to reproduce the problem but it seems Maven 3.0.4 is fine! (yaay :-) The problem seems to be in a thirdparty plugin, org.apache.karaf.tooling : features-maven-plugin : generate-features-xml. For those curious, or want to test, the testcase is in : https://github.com/ceefour/generate-features-xml-bug Related bug : https://issues.apache.org/jira/browse/KARAF-1681 > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: https://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: Benson Margulies >Priority: Blocker > Fix For: 3.0.3 > > Attachments: mavenTest.zip > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-1012) with only doesn't work
[ https://jira.codehaus.org/browse/MNG-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312329#comment-312329 ] Hendy Irawan commented on MNG-1012: --- I agree with David. As it stands now, it's pretty annoying and unnecessary. The Parent POM coordinates are only used in repositories, but not in project *builds*. Please distinguish those two use cases. > with only doesn't work > -- > > Key: MNG-1012 > URL: https://jira.codehaus.org/browse/MNG-1012 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0-beta-1 >Reporter: Hao Chen > > Use the following in child pom.xml > > ../pom.xml > > Got error: > [INFO] Reason: Missing groupId element from parent element > Why do we need groupId, artifactId, and version? These data are already > contained in ../pom.xml. It should work the same as Maven 1.0 . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-1012) with only doesn't work
[ https://jira.codehaus.org/browse/MNG-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312329#comment-312329 ] Hendy Irawan edited comment on MNG-1012 at 10/25/12 4:29 PM: - I agree with David. As it stands now (Maven 3.0), it's pretty annoying and unnecessary. The Parent POM coordinates are only used in repositories, but not in project *builds*. Please distinguish those two use cases. was (Author: ceefour): I agree with David. As it stands now, it's pretty annoying and unnecessary. The Parent POM coordinates are only used in repositories, but not in project *builds*. Please distinguish those two use cases. > with only doesn't work > -- > > Key: MNG-1012 > URL: https://jira.codehaus.org/browse/MNG-1012 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0-beta-1 >Reporter: Hao Chen > > Use the following in child pom.xml > > ../pom.xml > > Got error: > [INFO] Reason: Missing groupId element from parent element > Why do we need groupId, artifactId, and version? These data are already > contained in ../pom.xml. It should work the same as Maven 1.0 . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5363) Regression for SSLv3
[ https://jira.codehaus.org/browse/MNG-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316181#comment-316181 ] Hendy Irawan commented on MNG-5363: --- +1... > Regression for SSLv3 > > > Key: MNG-5363 > URL: https://jira.codehaus.org/browse/MNG-5363 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Errors >Affects Versions: 3.0.4 > Environment: Operation system independent, but tested on Macbook Pro > with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine. >Reporter: James Kionka > > When attempting to access a Maven repository which uses SSLv3, you get the > following error, "javax.net.ssl.SSLException: Received fatal alert: > bad_record_mac". > Earlier versions of Maven used java.net.URLConnection which respects the > https.protocols system property. This allowed us to set it to SSLv3, which is > what our Maven repository uses. However, HttpClient ignores that property. In > other situations, we programmatically tell HttpClient to use SSLv3, which we > cannot do from our end. > You can find another person in the same situation here: > http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-340) is ignored by war:exploded
Hendy Irawan created MWAR-340:
-
Summary: is ignored by war:exploded
Key: MWAR-340
URL: https://jira.codehaus.org/browse/MWAR-340
Project: Maven WAR Plugin
Issue Type: Bug
Affects Versions: 2.5
Reporter: Hendy Irawan
e.g.
{code}
WEB-INF/classes/logback.xml
{code}
in the exploded directory, that/those file(s) is incorrectly still included.
However in the .war file, that file is properly excluded.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://jira.codehaus.org/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360788#comment-360788
]
Hendy Irawan commented on MJAVADOC-387:
---
{{doclint}} should be a configuration option in maven javadoc plugin, which the
user can set to {{none}} to disable in JDK8+.
In < JDK8, this configuration if set to {{none}} or {{auto}} will have no
effect. But if set to a valid value, should probably log a warning since
{{doclint}} is not supported.
Thus making everybody happy. :)
> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://jira.codehaus.org/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Reporter: Stephen Colebourne
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default
> settings, it rejects many HTML elements that are perfectly acceptable to
> browsers, and all invalid Javadoc references (@links). This is likely to
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can
> control the doclint tool (currently this requires using additionalparam
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
> not opt-out (ie. fix Oracle's messed up default). This will also make it much
> easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-340) is ignored by war:exploded
[
https://jira.codehaus.org/browse/MWAR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hendy Irawan updated MWAR-340:
--
Affects Version/s: 2.6
> is ignored by war:exploded
> --
>
> Key: MWAR-340
> URL: https://jira.codehaus.org/browse/MWAR-340
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.5, 2.6
>Reporter: Hendy Irawan
>
> e.g.
> {code}
> WEB-INF/classes/logback.xml
> {code}
> in the exploded directory, that/those file(s) is incorrectly still included.
> However in the .war file, that file is properly excluded.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-340) is ignored by war:exploded
[
https://jira.codehaus.org/browse/MWAR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365057#comment-365057
]
Hendy Irawan commented on MWAR-340:
---
Please take a look at this issue. Still happens on 2.6 :(
> is ignored by war:exploded
> --
>
> Key: MWAR-340
> URL: https://jira.codehaus.org/browse/MWAR-340
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.5, 2.6
>Reporter: Hendy Irawan
>
> e.g.
> {code}
> WEB-INF/classes/logback.xml
> {code}
> in the exploded directory, that/those file(s) is incorrectly still included.
> However in the .war file, that file is properly excluded.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] Commented: (WAGON-84) exception deploying with webdav
[ http://jira.codehaus.org/browse/WAGON-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176899#action_176899 ] Hendy Irawan commented on WAGON-84: --- wagon-webdav is now (name changed) wagon-webdav-jackrabbit I'm using 1.0-beta-5 and no longer having this problem I experienced this problem, along with WAGON-96 , when still using wagon-webdav 1.0-beta-2 > exception deploying with webdav > --- > > Key: WAGON-84 > URL: http://jira.codehaus.org/browse/WAGON-84 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-3 >Reporter: Brian Fox >Assignee: Brett Porter > Fix For: 1.0-beta-3 > > > 1.0-beta-2 was working reasonably well but when I try the 1.0-RC1, it seems > there is a regression: > Uploading: > http://sv1.tus.stchome.com/maven-repos/stc/com/stchome/adf/view/faces/adf-faces/1.0/adf-faces-1.0.pom > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Destination path exists and is not a WebDAV > collection (directory): http://sv1.tus.stchome.com/mave > n-repos/stc/com/stchome/adf/view/faces/adf-faces/1.0/ > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Destination path exists and is not a WebDAV collec > tion (directory): > http://sv1.tus.stchome.com/maven-repos/stc/com/stchome/adf/view/faces/adf-faces/1.0/ > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying > artifact: Destination path exists and is not a WebDAV col > lection (directory): > http://sv1.tus.stchome.com/maven-repos/stc/com/stchome/adf/view/faces/adf-faces/1.0/ > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:174) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: > Error deploying artifact: Destination path exists and is > not a WebDAV collection (directory): > http://sv1.tus.stchome.com/maven-repos/stc/com/stchome/adf/view/faces/adf-faces/1.0/ > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:94) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:152) > ... 18 more > Caused by: org.apache.maven.wagon.TransferFailedException: Destination path > exists and is not a WebDAV collection (directory): http: > //sv1.tus.stchome.com/maven-repos/stc/com/stchome/adf/view/faces/adf-faces/1.0/ > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.mkdirs(WebDavWagon.java:333) > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.put(WebDavWagon.java:236) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:237) > at > org.
[jira] Commented: (MWAR-187) regression running war packaging with maven 2.1
[
http://jira.codehaus.org/browse/MWAR-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=177311#action_177311
]
Hendy Irawan commented on MWAR-187:
---
Downgrading to war-plugin 2.0.2 didn't solve the problem for me, it gave me yet
another problem by including bad dependencies in WEB-INF/lib. (i.e., some
"provided" dependencies such as el-api and jsp-api were included).
I downgraded to war-plugin 2.1-alpha-2 which solved the problem, the most
recent version that worked for my case.
> regression running war packaging with maven 2.1
> ---
>
> Key: MWAR-187
> URL: http://jira.codehaus.org/browse/MWAR-187
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1-beta-1
> Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
> Java version: 1.6.0_11
> Java home: D:\platina\java\jdk6\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: nicolas de loof
>Priority: Minor
> Fix For: 2.1
>
>
> Using plugin version 2.1-beta-1, my webapp can't get packaged.
> It can be fixed by downgrading the plugin to 2.0.2
> {code}
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-war-plugin:2.1-beta-1:w
> ar' -->
> [DEBUG] (s) archiveClasses = false
> [DEBUG] (s) attachClasses = false
> [DEBUG] (s) cacheFile = D:\...\target\war\work\webapp-cache.xml
> [DEBUG] (s) classesClassifier = classes
> [DEBUG] (s) classesDirectory = D:\...\target\classes
> [DEBUG] (f) escapedBackslashesInFilePath = false
> [DEBUG] (s) failOnMissingWebXml = true
> [DEBUG] (f) filteringDeploymentDescriptors = false
> [DEBUG] (s) outputDirectory = D:\...\target
> [DEBUG] (s) primaryArtifact = true
> [DEBUG] (s) project = MavenProject:
> com.sfr.bios.pdc:bios-pdc-webservices:1.0.
> 0-SNAPSHOT @ D:\...\pom.xml
> [DEBUG] (f) session = org.apache.maven.execution.mavensess...@10f0a0
> [DEBUG] (s) useCache = true
> [DEBUG] (s) warName = bios-pdc
> [DEBUG] (s) warSourceDirectory = D:\...\src\main\webapp
> [DEBUG] (s) webappDirectory =
> D:\...\target\bios-pdc-webservices-1.0.0-SNAPSHOT
> [DEBUG] (s) workDirectory = D:\...\target\war\work
> [DEBUG] -- end configuration --
> [INFO] [war:war]
> [INFO] Packaging webapp
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] modelEncoding : modelEncoding : modelEncoding : modelEncoding
> Debugging information
> message : modelEncoding : modelEncoding
> cause-exception :
> com.thoughtworks.xstream.mapper.CannotResolveClassExceptio
> n
> cause-message : modelEncoding : modelEncoding
> class : org.apache.maven.plugin.war.util.WebappStructure
> required-type : org.apache.maven.model.Dependency
> path:
> /webapp-structure/dependenciesInfo/org.apache.maven.plugin
> .war.util.DependencyInfo/dependency/modelEncoding
> line number : 156
> ---
> [INFO]
>
> [INFO] Trace
> com.thoughtworks.xstream.converters.ConversionException: modelEncoding :
> modelEn
> coding : modelEncoding : modelEncoding
> Debugging information
> message : modelEncoding : modelEncoding
> cause-exception :
> com.thoughtworks.xstream.mapper.CannotResolveClassExceptio
> n
> cause-message : modelEncoding : modelEncoding
> class : org.apache.maven.plugin.war.util.WebappStructure
> required-type : org.apache.maven.model.Dependency
> path:
> /webapp-structure/dependenciesInfo/org.apache.maven.plugin
> .war.util.DependencyInfo/dependency/modelEncoding
> line number : 156
> ---
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
> er.java:89)
> at
> com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
> bstractReferenceUnmarshaller.java:63)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
> arshaller.java:76)
> at
> com.thoughtworks.xstream.converters.reflection.AbstractReflectionConv
> erter.unmarshallField(AbstractReflectionConverter.java:246)
> at
> com.thoughtworks.xstream.converters.reflection.AbstractReflectionConv
> erter.doUnmarshal(AbstractReflectionConverter.java:218)
> at
> com.thoughtworks.xstream.converters.reflection.AbstractReflectionConv
> erter.unmarshal(AbstractReflectionConverter.java:162)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
> er.java:82)
> at
> com.thoughtworks.
[jira] Commented: (MWAR-187) regression running war packaging with maven 2.1
[
http://jira.codehaus.org/browse/MWAR-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=181418#action_181418
]
Hendy Irawan commented on MWAR-187:
---
Using 2.1-alpha-1 although "solved" the problem, it still occurs if the build
is launched from a parent POM project, with the WAR project as a module.
> regression running war packaging with maven 2.1
> ---
>
> Key: MWAR-187
> URL: http://jira.codehaus.org/browse/MWAR-187
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1-beta-1
> Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
> Java version: 1.6.0_11
> Java home: D:\platina\java\jdk6\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: nicolas de loof
>Priority: Minor
> Fix For: 2.1
>
> Attachments: MWAR-187-bad_webapp_cache.zip
>
>
> Using plugin version 2.1-beta-1, my webapp can't get packaged.
> It can be fixed by downgrading the plugin to 2.0.2
> {code}
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-war-plugin:2.1-beta-1:w
> ar' -->
> [DEBUG] (s) archiveClasses = false
> [DEBUG] (s) attachClasses = false
> [DEBUG] (s) cacheFile = D:\...\target\war\work\webapp-cache.xml
> [DEBUG] (s) classesClassifier = classes
> [DEBUG] (s) classesDirectory = D:\...\target\classes
> [DEBUG] (f) escapedBackslashesInFilePath = false
> [DEBUG] (s) failOnMissingWebXml = true
> [DEBUG] (f) filteringDeploymentDescriptors = false
> [DEBUG] (s) outputDirectory = D:\...\target
> [DEBUG] (s) primaryArtifact = true
> [DEBUG] (s) project = MavenProject:
> com.sfr.bios.pdc:bios-pdc-webservices:1.0.
> 0-SNAPSHOT @ D:\...\pom.xml
> [DEBUG] (f) session = org.apache.maven.execution.mavensess...@10f0a0
> [DEBUG] (s) useCache = true
> [DEBUG] (s) warName = bios-pdc
> [DEBUG] (s) warSourceDirectory = D:\...\src\main\webapp
> [DEBUG] (s) webappDirectory =
> D:\...\target\bios-pdc-webservices-1.0.0-SNAPSHOT
> [DEBUG] (s) workDirectory = D:\...\target\war\work
> [DEBUG] -- end configuration --
> [INFO] [war:war]
> [INFO] Packaging webapp
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] modelEncoding : modelEncoding : modelEncoding : modelEncoding
> Debugging information
> message : modelEncoding : modelEncoding
> cause-exception :
> com.thoughtworks.xstream.mapper.CannotResolveClassExceptio
> n
> cause-message : modelEncoding : modelEncoding
> class : org.apache.maven.plugin.war.util.WebappStructure
> required-type : org.apache.maven.model.Dependency
> path:
> /webapp-structure/dependenciesInfo/org.apache.maven.plugin
> .war.util.DependencyInfo/dependency/modelEncoding
> line number : 156
> ---
> [INFO]
>
> [INFO] Trace
> com.thoughtworks.xstream.converters.ConversionException: modelEncoding :
> modelEn
> coding : modelEncoding : modelEncoding
> Debugging information
> message : modelEncoding : modelEncoding
> cause-exception :
> com.thoughtworks.xstream.mapper.CannotResolveClassExceptio
> n
> cause-message : modelEncoding : modelEncoding
> class : org.apache.maven.plugin.war.util.WebappStructure
> required-type : org.apache.maven.model.Dependency
> path:
> /webapp-structure/dependenciesInfo/org.apache.maven.plugin
> .war.util.DependencyInfo/dependency/modelEncoding
> line number : 156
> ---
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
> er.java:89)
> at
> com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
> bstractReferenceUnmarshaller.java:63)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
> arshaller.java:76)
> at
> com.thoughtworks.xstream.converters.reflection.AbstractReflectionConv
> erter.unmarshallField(AbstractReflectionConverter.java:246)
> at
> com.thoughtworks.xstream.converters.reflection.AbstractReflectionConv
> erter.doUnmarshal(AbstractReflectionConverter.java:218)
> at
> com.thoughtworks.xstream.converters.reflection.AbstractReflectionConv
> erter.unmarshal(AbstractReflectionConverter.java:162)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
> er.java:82)
> at
> com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
> bstractReferenceUnmarshaller.java:63)
> at
> com.thoughtworks.xstrea
