[jira] (SCM-773) Add support for branches in CVS provider
Julien HENRY created SCM-773: Summary: Add support for branches in CVS provider Key: SCM-773 URL: https://jira.codehaus.org/browse/SCM-773 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-cvs Reporter: Julien HENRY Current implementation of blame in CVS doesn't accept branch parameter (-r). It means that blame will always occurs on trunk. It should be possible to give a branch name in the CVS scm URL and then pass it to appropriate CVS command (at least CVS annotate). See http://durak.org/sean/pubs/software/cvsbook/Annotations-And-Branches.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] Created: (MINDEXER-41) Allow to index several artifacts with no classifier
Allow to index several artifacts with no classifier
---
Key: MINDEXER-41
URL: https://jira.codehaus.org/browse/MINDEXER-41
Project: Maven Indexer
Issue Type: Improvement
Reporter: Julien HENRY
See details in this thread:
http://maven.40175.n5.nabble.com/Search-with-several-artifacts-same-GAV-different-type-extension-td4902408.html
The key used by indexer is GAVC (GAV + classifier where classifier can be null).
With current design the indexer will only index one artifact with no classifier
(= main artifact) + optionally additional secondary artifacts with classifier.
This is an issue for custom packaging types that publish several artifacts with
different extensions but no classifier.
For example:
{code}
groupId
/artifactId
/version
/artifactId-version.pom
/artifactId-version.jar
/artifactId-version.tld
/artifactId-version.config
{code}
It would be good to include the extension in the index key = GAVCE. This way a
search will return jar, tld and config artifacts.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-108) Assembly Plugin Implicitly Excludes Empty Directory
[ https://jira.codehaus.org/browse/MASSEMBLY-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=280659#comment-280659 ] Julien HENRY commented on MASSEMBLY-108: We are facing the same issue: empty directory in a fileset are not copied to output folder but only when filtered is set to true. Assembly Plugin Implicitly Excludes Empty Directory --- Key: MASSEMBLY-108 URL: https://jira.codehaus.org/browse/MASSEMBLY-108 Project: Maven 2.x Assembly Plugin Issue Type: New Feature Affects Versions: 2.1 Reporter: Sharmarke Aden It seems that the inclusion of an empty directory isn't currently possible with the assembly plugin. This is a problem because I would like to have an empty logs directory included with my zip file assembly. It would be nice if the assembly plugin gave you the option to add empty directories to an assembly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-561) Encoding is broken when filtering is enabled
[
https://jira.codehaus.org/browse/MASSEMBLY-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=280180#comment-280180
]
Julien HENRY commented on MASSEMBLY-561:
It seems the part of the patch that fix the issue was applied in revision
1163853 even if the svn comment is Switch to java5 annotations for plexus
components.
I would like to say thank you but not sure if it was really your intension :)
So for me this issue can be marked as resolved (except that there is no IT) and
included in next release.
Thanks
Encoding is broken when filtering is enabled
Key: MASSEMBLY-561
URL: https://jira.codehaus.org/browse/MASSEMBLY-561
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Priority: Critical
Attachments: MASSEMBLY-561.patch
My resources are encoded in ISO-8859-1. I have specified encoding in the pom:
{code}project.build.sourceEncodingISO-8859-1/project.build.sourceEncoding{code}
I have written a custom assembly file and I am using resource filtering.
{code}...
fileSet
directory${project.basedir}/src/main/resources//directory
outputDirectory//outputDirectory
filteredtrue/filtered
/fileSet
...{code}
As a result all the french characters are broken in the resulting zip
assembly. My platform is Linux so the default platform encoding is UTF-8.
I have checked plugin code and I think I found the issue. This is in
FileFormatter.java, method doFileFilter():
{code}
configSource.getMavenFileFilter().copyFile( source, target, true,
configSource.getProject(),
configSource.getFilters(), isPropertiesFile, null,
configSource.getMavenSession() );
{code}
You can see that enconding is set to null, so I think it means using default
platform encoding... Would it be possible to use value of
project.build.sourceEncoding instead?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5169) New checksumPolicy: strict_if_exists
New checksumPolicy: strict_if_exists Key: MNG-5169 URL: https://jira.codehaus.org/browse/MNG-5169 Project: Maven 2 3 Issue Type: New Feature Components: Settings Reporter: Julien HENRY Hi, We have enabled checksumPolicyfail/checksumPolicy to prevent corruption of local repository. But it seems it is nearly unusable because in my company we are proxying some external repos where there is no checksum so the download fails. I would like to have a checksumPolicystrict_if_exists/checksumPolicy where the build fails when the checksum does not match but only log a warning when there is no remote checksum. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRESOURCES-151) Path for filters parameter is relative to the place from where the build was run
Path for filters parameter is relative to the place from where the build was
run
--
Key: MRESOURCES-151
URL: https://jira.codehaus.org/browse/MRESOURCES-151
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.5
Reporter: Julien HENRY
Priority: Minor
I am using copy-resources goal in a multi-module project with the following
configuration in a child module:
{code:xml}
configuration
filters
filtersrc/main/filters/filter.properties/filter
/filters
/configuration
{code}
The filter path is resolved differently depending on the place from where I run
the build (root aggregator project or child module).
The workaround is to always give absolute path using basedir property:
{code:xml}
configuration
filters
filter${basedir}/src/main/filters/filter.properties/filter
/filters
/configuration
{code}
What is confusing is that the first configuration works fine in the global
filter definition:
{code:xml}
build
filters
filtersrc/main/filters/filter.properties/filter
/filters
/build
{code}
Could you please make the behavior more consistent or at least put a warning in
documentation of the filters parameter.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-561) Encoding is broken when filtering is enabled
[
https://jira.codehaus.org/browse/MASSEMBLY-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274811#comment-274811
]
Julien HENRY commented on MASSEMBLY-561:
Hi John,
Did you have a chance to complete the review of my patch? Do you still have
issue with the integration test?
Thanks
Julien
Encoding is broken when filtering is enabled
Key: MASSEMBLY-561
URL: https://jira.codehaus.org/browse/MASSEMBLY-561
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Priority: Critical
Attachments: MASSEMBLY-561.patch
My resources are encoded in ISO-8859-1. I have specified encoding in the pom:
{code}project.build.sourceEncodingISO-8859-1/project.build.sourceEncoding{code}
I have written a custom assembly file and I am using resource filtering.
{code}...
fileSet
directory${project.basedir}/src/main/resources//directory
outputDirectory//outputDirectory
filteredtrue/filtered
/fileSet
...{code}
As a result all the french characters are broken in the resulting zip
assembly. My platform is Linux so the default platform encoding is UTF-8.
I have checked plugin code and I think I found the issue. This is in
FileFormatter.java, method doFileFilter():
{code}
configSource.getMavenFileFilter().copyFile( source, target, true,
configSource.getProject(),
configSource.getFilters(), isPropertiesFile, null,
configSource.getMavenSession() );
{code}
You can see that enconding is set to null, so I think it means using default
platform encoding... Would it be possible to use value of
project.build.sourceEncoding instead?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-561) Encoding is broken when filtering is enabled
[
https://jira.codehaus.org/browse/MASSEMBLY-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274153#comment-274153
]
Julien HENRY commented on MASSEMBLY-561:
Hi John,
The difficulty here is that the encoding of the test file should be ISO-8859-1
where all other files are UTF-8. I'm not sure applying svn patch is safe in
this case. Could you please chech that encoding of
src/it/projects/filtering-feature/filter-encoding-iso88591/src/main/config/iso88591.config
is ISO-8859-1 and that the french character was not corrupted by making
patch/uploading on JIRA//applying patch.
Thanks
Encoding is broken when filtering is enabled
Key: MASSEMBLY-561
URL: https://jira.codehaus.org/browse/MASSEMBLY-561
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Priority: Critical
Attachments: MASSEMBLY-561.patch
My resources are encoded in ISO-8859-1. I have specified encoding in the pom:
{code}project.build.sourceEncodingISO-8859-1/project.build.sourceEncoding{code}
I have written a custom assembly file and I am using resource filtering.
{code}...
fileSet
directory${project.basedir}/src/main/resources//directory
outputDirectory//outputDirectory
filteredtrue/filtered
/fileSet
...{code}
As a result all the french characters are broken in the resulting zip
assembly. My platform is Linux so the default platform encoding is UTF-8.
I have checked plugin code and I think I found the issue. This is in
FileFormatter.java, method doFileFilter():
{code}
configSource.getMavenFileFilter().copyFile( source, target, true,
configSource.getProject(),
configSource.getFilters(), isPropertiesFile, null,
configSource.getMavenSession() );
{code}
You can see that enconding is set to null, so I think it means using default
platform encoding... Would it be possible to use value of
project.build.sourceEncoding instead?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-561) Encoding is broken when filtering is enabled
[
https://jira.codehaus.org/browse/MASSEMBLY-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien HENRY updated MASSEMBLY-561:
---
Attachment: MASSEMBLY-561.patch
This patch add 2 integration tests (filtering with 2 different encoding) to
show the issue + the fix. We need 2 tests because if by chance your platform
encoding match the expected encoding, the test will pass even without the
patch. So if you don't apply the fix you should see one or two IT failures.
The fix is to add the encoding property to the assembly plugin like many other
plugins (I took code from maven-resources-plugin). The encoding is transmitted
to the function that do the filtering. You can also set the
project.build.sourceEncoding property in your pom. If no encoding is specified,
a warning will be displayed and default platform encoding will be used.
Encoding is broken when filtering is enabled
Key: MASSEMBLY-561
URL: https://jira.codehaus.org/browse/MASSEMBLY-561
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Priority: Critical
Attachments: MASSEMBLY-561.patch
My resources are encoded in ISO-8859-1. I have specified encoding in the pom:
{code}project.build.sourceEncodingISO-8859-1/project.build.sourceEncoding{code}
I have written a custom assembly file and I am using resource filtering.
{code}...
fileSet
directory${project.basedir}/src/main/resources//directory
outputDirectory//outputDirectory
filteredtrue/filtered
/fileSet
...{code}
As a result all the french characters are broken in the resulting zip
assembly. My platform is Linux so the default platform encoding is UTF-8.
I have checked plugin code and I think I found the issue. This is in
FileFormatter.java, method doFileFilter():
{code}
configSource.getMavenFileFilter().copyFile( source, target, true,
configSource.getProject(),
configSource.getFilters(), isPropertiesFile, null,
configSource.getMavenSession() );
{code}
You can see that enconding is set to null, so I think it means using default
platform encoding... Would it be possible to use value of
project.build.sourceEncoding instead?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-561) Encoding is broken when filtering is enabled
[
https://jira.codehaus.org/browse/MASSEMBLY-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273954#comment-273954
]
Julien HENRY edited comment on MASSEMBLY-561 at 7/22/11 8:00 AM:
-
This patch adds 2 integration tests (filtering with 2 different encodings) to
show the issue + the fix. We need 2 tests because if by chance your platform
encoding match the expected encoding, the test will pass even without the fix.
So if you don't apply the fix you should see at least one of the two ITs
failing.
The fix consists of adding an encoding property to the assembly plugin like
many other plugins (I took code from maven-resources-plugin). The encoding
value is transmitted to the function that do the filtering. You can also set
the project.build.sourceEncoding property in your pom. If no encoding is
specified, a warning will be displayed and default platform encoding will be
used.
was (Author: henryju):
This patch add 2 integration tests (filtering with 2 different encoding) to
show the issue + the fix. We need 2 tests because if by chance your platform
encoding match the expected encoding, the test will pass even without the
patch. So if you don't apply the fix you should see one or two IT failures.
The fix is to add the encoding property to the assembly plugin like many other
plugins (I took code from maven-resources-plugin). The encoding is transmitted
to the function that do the filtering. You can also set the
project.build.sourceEncoding property in your pom. If no encoding is specified,
a warning will be displayed and default platform encoding will be used.
Encoding is broken when filtering is enabled
Key: MASSEMBLY-561
URL: https://jira.codehaus.org/browse/MASSEMBLY-561
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Priority: Critical
Attachments: MASSEMBLY-561.patch
My resources are encoded in ISO-8859-1. I have specified encoding in the pom:
{code}project.build.sourceEncodingISO-8859-1/project.build.sourceEncoding{code}
I have written a custom assembly file and I am using resource filtering.
{code}...
fileSet
directory${project.basedir}/src/main/resources//directory
outputDirectory//outputDirectory
filteredtrue/filtered
/fileSet
...{code}
As a result all the french characters are broken in the resulting zip
assembly. My platform is Linux so the default platform encoding is UTF-8.
I have checked plugin code and I think I found the issue. This is in
FileFormatter.java, method doFileFilter():
{code}
configSource.getMavenFileFilter().copyFile( source, target, true,
configSource.getProject(),
configSource.getFilters(), isPropertiesFile, null,
configSource.getMavenSession() );
{code}
You can see that enconding is set to null, so I think it means using default
platform encoding... Would it be possible to use value of
project.build.sourceEncoding instead?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-624) Broken checksum files, xalan:xalan, xalan:serializer 2.7.1
[ https://jira.codehaus.org/browse/MEV-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273473#comment-273473 ] Julien HENRY commented on MEV-624: -- Are you sure this is fixed? I'm still facing the same issue with serializer. I have the following error in Nexus: The artifact /xalan/serializer/2.7.1/serializer-2.7.1.jar and it's remote checksums does not match in repository central! Broken checksum files, xalan:xalan, xalan:serializer 2.7.1 -- Key: MEV-624 URL: https://jira.codehaus.org/browse/MEV-624 Project: Maven Evangelism Issue Type: Bug Components: Checksum Failure Reporter: Max Bowsher Assignee: Juven Xu Downloading: http://maven2.mxtelecom.com/repository/xalan/xalan/2.7.1/xalan-2.7.1.jar 3101K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '75f1d83ce27bab5f29fff034fc74aa9f7266f22a'; remote = 'SHA1(xalan-2.7.1.jar)=' - RETRYING Downloading: http://maven2.mxtelecom.com/repository/xalan/xalan/2.7.1/xalan-2.7.1.jar 3101K downloaded Downloading: http://maven2.mxtelecom.com/repository/xalan/serializer/2.7.1/serializer-2.7.1.jar 271K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '4b4b18df434451249bb65a63f2fb69e215a6a020'; remote = 'SHA1(serializer-2.7.1.jar)=' - RETRYING Please fix these broken checksums -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-561) Encoding is broken when filtering is enabled
Encoding is broken when filtering is enabled
Key: MASSEMBLY-561
URL: https://jira.codehaus.org/browse/MASSEMBLY-561
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Priority: Critical
My resources are encoded in ISO-8859-1. I have specified encoding in the pom:
{code}project.build.sourceEncodingISO-8859-1/project.build.sourceEncoding{code}
I have written a custom assembly file and I am using resource filtering.
{code}...
fileSet
directory${project.basedir}/src/main/resources//directory
outputDirectory//outputDirectory
filteredtrue/filtered
/fileSet
...{code}
As a result all the french characters are broken in the resulting zip assembly.
My platform is Linux so the default platform encoding is UTF-8.
I have checked plugin code and I think I found the issue. This is in
FileFormatter.java, method doFileFilter():
{code}
configSource.getMavenFileFilter().copyFile( source, target, true,
configSource.getProject(),
configSource.getFilters(), isPropertiesFile, null,
configSource.getMavenSession() );
{code}
You can see that enconding is set to null, so I think it means using default
platform encoding... Would it be possible to use value of
project.build.sourceEncoding instead?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-559) useTransitiveDependencies leaks from one dependency set to another
useTransitiveDependencies leaks from one dependency set to another -- Key: MASSEMBLY-559 URL: http://jira.codehaus.org/browse/MASSEMBLY-559 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2.1 Reporter: Julien HENRY I have several dependencySets in my assembly descriptor. As soon as I let useTransitiveDependencies parameter to be true (set it or rely on default) for one dependency set, it will extend to all others dependency sets, even when their useTransitiveDependencies parameter is explicitly set to false. See attached test project. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-559) useTransitiveDependencies leaks from one dependency set to another
[ http://jira.codehaus.org/browse/MASSEMBLY-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien HENRY updated MASSEMBLY-559: --- Attachment: MASSEMBLY-559.tar.gz useTransitiveDependencies leaks from one dependency set to another -- Key: MASSEMBLY-559 URL: http://jira.codehaus.org/browse/MASSEMBLY-559 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2.1 Reporter: Julien HENRY Attachments: MASSEMBLY-559.tar.gz I have several dependencySets in my assembly descriptor. As soon as I let useTransitiveDependencies parameter to be true (set it or rely on default) for one dependency set, it will extend to all others dependency sets, even when their useTransitiveDependencies parameter is explicitly set to false. See attached test project. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-682) skipTests cannot be overridden by commandline param
skipTests cannot be overridden by commandline param - Key: SUREFIRE-682 URL: http://jira.codehaus.org/browse/SUREFIRE-682 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.7.1 Reporter: Julien HENRY This issue is very similar to SUREFIRE-319 When skipTests is defined in the pom, there is no way to override the value using -DskipTests or -DskipTests=true|false on the command line. I think it would be better if command line parameter could have higher priority over pom configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPIR-214) IOException when generating dependency report in a multi-module build
[
http://jira.codehaus.org/browse/MPIR-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien HENRY updated MPIR-214:
--
Attachment: bug dependency.PNG
Look at the attached screenshot. This is an extract of the Dependency File
Details section.
IOException when generating dependency report in a multi-module build
-
Key: MPIR-214
URL: http://jira.codehaus.org/browse/MPIR-214
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 2.3.1
Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100)
Java version: 1.6.0_20
Java home: D:\Julien\jdk1.6.0_20\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Julien HENRY
Attachments: bug dependency.PNG
Running mvn clean site on my project produce the following error:
{code}
[ERROR] IOException:
D:\Projects\jwebunit\jwebunit-commons-tests\target\classes (Acces denied)
java.io.FileNotFoundException:
D:\Projects\jwebunit\jwebunit-commons-tests\target\classes (Acces denied)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:114)
at java.util.jar.JarFile.init(JarFile.java:135)
at java.util.jar.JarFile.init(JarFile.java:99)
at
org.apache.maven.shared.jar.JarAnalyzer.init(JarAnalyzer.java:105)
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:273)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1374)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:544)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:271)
{code}
It doesn't prevent the build to complete.
You can reproduce on the project:
https://jwebunit.svn.sourceforge.net/svnroot/jwebunit/trunk
Build instructions (need toolchains):
http://jwebunit.sourceforge.net/building-maven.html#Installing_Maven
Running mvn clean project-info-reports:dependencies works fine so I guess
there is a bad interaction with another report.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-214) IOException when generating dependency report in a multi-module build
IOException when generating dependency report in a multi-module build
-
Key: MPIR-214
URL: http://jira.codehaus.org/browse/MPIR-214
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 2.3.1
Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100)
Java version: 1.6.0_20
Java home: D:\Julien\jdk1.6.0_20\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Julien HENRY
Running mvn clean site on my project produce the following error:
{code}
[ERROR] IOException: D:\Projects\jwebunit\jwebunit-commons-tests\target\classes
(Acces denied)
java.io.FileNotFoundException:
D:\Projects\jwebunit\jwebunit-commons-tests\target\classes (Acces denied)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:114)
at java.util.jar.JarFile.init(JarFile.java:135)
at java.util.jar.JarFile.init(JarFile.java:99)
at org.apache.maven.shared.jar.JarAnalyzer.init(JarAnalyzer.java:105)
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:273)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1374)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:544)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:271)
{code}
It doesn't prevent the build to complete.
You can reproduce on the project:
https://jwebunit.svn.sourceforge.net/svnroot/jwebunit/trunk
Build instructions (need toolchains):
http://jwebunit.sourceforge.net/building-maven.html#Installing_Maven
Running mvn clean project-info-reports:dependencies works fine so I guess there
is a bad interaction with another report.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-604) bump com.oracle/ojdbc14 to 10.2.0.4.0
[ http://jira.codehaus.org/browse/MEV-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237480#action_237480 ] Julien HENRY commented on MEV-604: -- There is a mistake on the repo: in the folder http://repo2.maven.org/maven2/com/oracle/ojdbc14/10.2.0.4.0/ we can find ojdbc14-10.2.0.3.0.pom (note the version mismatch). Could you please fix that. Thanks bump com.oracle/ojdbc14 to 10.2.0.4.0 - Key: MEV-604 URL: http://jira.codehaus.org/browse/MEV-604 Project: Maven Evangelism Issue Type: Improvement Reporter: Craig Assignee: Carlos Sanchez 10.2.0.4.0 has been released. It would be nice to have a pom in the repository for it. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4852) [Regression] Configuration of m-javadoc-p at reportSet level is not taken into account
[Regression] Configuration of m-javadoc-p at reportSet level is not taken into
account
--
Key: MNG-4852
URL: http://jira.codehaus.org/browse/MNG-4852
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_21
Reporter: Julien HENRY
In the JWebUnit project I am using Javadoc aggregation and I put configuration
at the reportSet level. But after upgrading to Maven 3 the configuration is
not taken into account. Moving the configuration to the top level/common
section works but may not be acceptable for all project especially when a
different configuration for each reportSet is needed.
{code:xml}
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.7/version
configuration
!-- What is put here is taken into account --
/configuration
reportSets
reportSet
idaggregate/id
configuration
!-- What is put here is NOT taken into account --
/configuration
reports
reportaggregate/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
{code}
- with Maven 2 I am using m-site-p 2.1.1
- with Maven 3 I am using m-site-p 3.0-beta-2
I don't know if this is a M3 or a m-site-p regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-512) [Regression] Configuration of m-javadoc-p at reportSet level is not taken into account
[
http://jira.codehaus.org/browse/MSITE-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237559#action_237559
]
Julien HENRY commented on MSITE-512:
You can try with JWebUnit trunk:
https://jwebunit.svn.sourceforge.net/svnroot/jwebunit/trunk/
But you have to configure a toolchains:
http://jwebunit.sourceforge.net/building-maven.html
Then run mvn clean site on the top level folder.
[Regression] Configuration of m-javadoc-p at reportSet level is not taken
into account
--
Key: MSITE-512
URL: http://jira.codehaus.org/browse/MSITE-512
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 3.0-beta-2
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_21
Reporter: Julien HENRY
Assignee: Olivier Lamy
In the JWebUnit project I am using Javadoc aggregation and I put
configuration at the reportSet level. But after upgrading to Maven 3 the
configuration is not taken into account. Moving the configuration to the top
level/common section works but may not be acceptable for all project
especially when a different configuration for each reportSet is needed.
{code:xml}
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.7/version
configuration
!-- What is put here is taken into account --
/configuration
reportSets
reportSet
idaggregate/id
configuration
!-- What is put here is NOT taken into account --
/configuration
reports
reportaggregate/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
{code}
- with Maven 2 I am using m-site-p 2.1.1
- with Maven 3 I am using m-site-p 3.0-beta-2
I don't know if this is a M3 or a m-site-p regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3814) Reactor builds fail due to erroneous cycle in project sorting which does not consider versions
[
http://jira.codehaus.org/browse/MNG-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233744#action_233744
]
Julien HENRY commented on MNG-3814:
---
If this is fixed maybe could you revert changes done in aggregator POM
maven-plugins.
Reactor builds fail due to erroneous cycle in project sorting which does not
consider versions
--
Key: MNG-3814
URL: http://jira.codehaus.org/browse/MNG-3814
Project: Maven 2 3
Issue Type: Bug
Components: Reactor and workspace
Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Fix For: 3.0-alpha-3
Just to officially track the reason why the parent POM {{maven-plugins}}
currently excludes the maven-project-info-reports-plugin from the reactor:
{noformat}
[INFO] Scanning for projects...
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] The projects in the reactor contain a cyclic reference:
Edge between
'Vertex{label='org.apache.maven.plugins:maven-remote-resources-plugin'}'
and
'Vertex{label='org.apache.maven.plugins:maven-project-info-reports-plugin'}'
introduces to cycle in the graph
org.apache.maven.plugins:maven-project-info-reports-plugin --
org.apache.maven.plugins:maven-remote-resources-plugin --
org.apache.maven.plugins:maven-project-info-reports-plugin
{noformat}
It appears the {{ProjectSorter}} does not take versions into account, i.e.
there is no cycle in a multi-module scenario like this:
{noformat}
parent:1
- plugin-a:2.0 which uses plugin-b:1.0
- plugin-b:2.0 which uses plugin-a:1.0
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-229) war:inplace overwrite files of current project by those coming from overlay war
[
http://jira.codehaus.org/browse/MWAR-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229602#action_229602
]
Julien HENRY commented on MWAR-229:
---
@Dennis : look at the IT. There is NO plugin configuration (relying on default
behaviour).
In my real project, here is what I have in my corporate parent pom:
{code}
pluginManagement
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.1-beta-1/version
/plugin
...
/pluginManagement
{code}
@Stephane : I tried to understand the code of the plugin and it seems most of
the code is common between goal inplace and goal exploded. With exploded goal,
the target folder where the webapp will be assembled (target/artifactId-XX) is
initially empty but with inplace goal, the target folder (src/main/webapp)
already contains the files of the current artifact. So I think the overlay
algorithm should be different in the two cases.
war:inplace overwrite files of current project by those coming from overlay
war
---
Key: MWAR-229
URL: http://jira.codehaus.org/browse/MWAR-229
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1-beta-1
Reporter: Julien HENRY
Attachments: MWAR-229-it.patch
I have a web application that depends on another WAR (overlay). According to
m-war-p documentation [1], when a file is present in both the application and
the dependent war, the current application is the priority. My understanding
is that when there are two files with same path
in both current application and dependent war, this is the file in current
application that should ultimately be taken to produce the final war.
Example:
current application contains the file src/main/webapp/WEB-INF/web.xml
dependent war contain a nearly empty file dependentWar.war!WEB-INF/web.xml
When I run mvn war:inplace I can read in the log:
[INFO] --- maven-war-plugin:2.1-beta-1:inplace (default-cli) @ myWebApp ---
...
[INFO] Processing war project
[INFO] Processing overlay[ id com.mycompany:dependentWar]
...
[INFO] File[WEB-INF/web.xml] belonged to overlay[currentBuild] so it will be
overwritten.
As a result the src/main/webapp/WEB-INF/web.xml file was overwritten in the
current application by the file coming from the dependent WAR.
If I run mvn war:exploded the result is correct and the file in
target/myCurrentWebApp-XX-SNAPSHOT/WEB-INF/web.xml is the one coming from the
current web app.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-229) war:inplace overwrite files of current project by those coming from overlay war
war:inplace overwrite files of current project by those coming from overlay war --- Key: MWAR-229 URL: http://jira.codehaus.org/browse/MWAR-229 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1-beta-1 Reporter: Julien HENRY I have a web application that depends on another WAR (overlay). According to m-war-p documentation [1], when a file is present in both the application and the dependent war, the current application is the priority. My understanding is that when there are two files with same path in both current application and dependent war, this is the file in current application that should ultimately be taken to produce the final war. Example: current application contains the file src/main/webapp/WEB-INF/web.xml dependent war contain a nearly empty file dependentWar.war!WEB-INF/web.xml When I run mvn war:inplace I can read in the log: [INFO] --- maven-war-plugin:2.1-beta-1:inplace (default-cli) @ myWebApp --- ... [INFO] Processing war project [INFO] Processing overlay[ id com.mycompany:dependentWar] ... [INFO] File[WEB-INF/web.xml] belonged to overlay[currentBuild] so it will be overwritten. As a result the src/main/webapp/WEB-INF/web.xml file was overwritten in the current application by the file coming from the dependent WAR. If I run mvn war:exploded the result is correct and the file in target/myCurrentWebApp-XX-SNAPSHOT/WEB-INF/web.xml is the one coming from the current web app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-229) war:inplace overwrite files of current project by those coming from overlay war
[ http://jira.codehaus.org/browse/MWAR-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien HENRY updated MWAR-229: -- Attachment: MWAR-229-it.patch war:inplace overwrite files of current project by those coming from overlay war --- Key: MWAR-229 URL: http://jira.codehaus.org/browse/MWAR-229 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1-beta-1 Reporter: Julien HENRY Attachments: MWAR-229-it.patch I have a web application that depends on another WAR (overlay). According to m-war-p documentation [1], when a file is present in both the application and the dependent war, the current application is the priority. My understanding is that when there are two files with same path in both current application and dependent war, this is the file in current application that should ultimately be taken to produce the final war. Example: current application contains the file src/main/webapp/WEB-INF/web.xml dependent war contain a nearly empty file dependentWar.war!WEB-INF/web.xml When I run mvn war:inplace I can read in the log: [INFO] --- maven-war-plugin:2.1-beta-1:inplace (default-cli) @ myWebApp --- ... [INFO] Processing war project [INFO] Processing overlay[ id com.mycompany:dependentWar] ... [INFO] File[WEB-INF/web.xml] belonged to overlay[currentBuild] so it will be overwritten. As a result the src/main/webapp/WEB-INF/web.xml file was overwritten in the current application by the file coming from the dependent WAR. If I run mvn war:exploded the result is correct and the file in target/myCurrentWebApp-XX-SNAPSHOT/WEB-INF/web.xml is the one coming from the current web app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4029) Import of pom dependencies incorrectly scopes dependencies as runtime
[ http://jira.codehaus.org/browse/MNG-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225092#action_225092 ] Julien HENRY commented on MNG-4029: --- Attached project seems to be broken (tar.gz contains only one binary file). Import of pom dependencies incorrectly scopes dependencies as runtime - Key: MNG-4029 URL: http://jira.codehaus.org/browse/MNG-4029 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.9 Reporter: Alex Deschapelles Attachments: testparent.tar.gz When dependencies are imported from a pom, they are resolved as runtime dependencies in the importing project. To test 1) Extract the attached project 2) cd into the testparent directory 3) mvn install 4) cd subparent/projectx 5) mvn dependency:resolve This will bring back : [INFO] The following files have been resolved: [INFO]antlr:antlr:jar:2.7.6:runtime [INFO]asm:asm:jar:1.5.3:runtime [INFO]asm:asm-attrs:jar:1.5.3:runtime [INFO]cglib:cglib:jar:2.1_3:runtime [INFO]com.test:hibernate-deps:pom:0.0.1-SNAPSHOT:import [INFO]com.test:spring-deps:pom:0.0.1-SNAPSHOT:import [INFO]commons-collections:commons-collections:jar:2.1.1:runtime [INFO]commons-logging:commons-logging:jar:1.1.1:runtime [INFO]dom4j:dom4j:jar:1.6.1:runtime [INFO]javax.transaction:jta:jar:1.0.1B:runtime [INFO]junit:junit:jar:4.5:test [INFO]net.sf.ehcache:ehcache:jar:1.2.3:runtime [INFO]org.hibernate:hibernate:jar:3.2.6.ga:runtime [INFO]org.springframework:spring:jar:2.5.6:runtime It would be more appropriate if the resolved scopes matched what is in the pom that defines them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4672) [regression] jnlp doesn't contains dependencies anymore when attaching sources to package phase
[ http://jira.codehaus.org/browse/MNG-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=220912#action_220912 ] Julien HENRY commented on MNG-4672: --- Thanks for the workaround, I confirm it works on my real project too. [regression] jnlp doesn't contains dependencies anymore when attaching sources to package phase --- Key: MNG-4672 URL: http://jira.codehaus.org/browse/MNG-4672 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0-alpha-7, 3.0-beta-1 Environment: Win XP Reporter: Julien HENRY Attachments: bug Maven 3 jnlp.zip running: mvn clean mvn package webstart:jnlp on the attached test project produce different result between Maven 2.2.1 and Maven 3-beta-1. With Maven 2 I have a jnlp and a zip file that contain all dependencies of the project (logback and slf4j in my sample project). With Maven 3 there is no dependency. Please note that the important point is that -sources generation is attached to the package phase (like with -DperformRelease=true). When I remove -sources generation it works with Maven 3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4672) [regression] jnlp doesn't contains dependencies anymore when attaching sources to package phase
[regression] jnlp doesn't contains dependencies anymore when attaching sources to package phase --- Key: MNG-4672 URL: http://jira.codehaus.org/browse/MNG-4672 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0-beta-1 Environment: Win XP Reporter: Julien HENRY Attachments: bug Maven 3 jnlp.zip running: mvn clean mvn package webstart:jnlp on the attached test project produce different result between Maven 2.2.1 and Maven 3-beta-1. With Maven 2 I have a jnlp and a zip file that contain all dependencies of the project (logback and slf4j in my sample project). With Maven 3 there is no dependency. Please note that the important point is that -sources generation is attached to the package phase (like with -DperformRelease=true). When I remove -sources generation it works with Maven 3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4451) Parametized groupId/ declarations fail in two level deep multi-module project
[
http://jira.codehaus.org/browse/MNG-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien HENRY updated MNG-4451:
--
Attachment: MNG-4451.zip
I have tested with Maven 3.0-beta-1 with the given sample project.
{code}
pom.xml
submoduleA
|-pom.xml
\-submoduleAA
\-pom.xml
{code}
The build is still failing when started from a clean repository from the root
pom. But when building each level one after one from the parent and using -N
option it works but with the following warning :
{code}
[submoduleA]$ mvn clean install -N
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
org.apache.maven.test-MNG-4451:submoduleA:pom:1.0.0-SNAPSHOT
[WARNING] 'groupId' contains an expression but should be a constant. @
${project.parent.groupId}.${project.parent.artifactId}:submoduleA:1.0.0-SNAPSHOT,
/home/julien/Programmation/maven/MNG-4451/submoduleA/pom.xml
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
{code}
So I suggest the answer is simply that it is not a good practice to have an
expression in groupId.
Parametized groupId/ declarations fail in two level deep multi-module
project
---
Key: MNG-4451
URL: http://jira.codehaus.org/browse/MNG-4451
Project: Maven 2 3
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 2.2.1
Environment: Windows XP, JDK 1.6.0_16
Reporter: J. Michael McGarr
Attachments: MNG-4451.zip
We utilized the appfuse 2.x multi-module project setup where the modules of
the project declare their own groupId/ value as:
{quote}
groupId$[pom.parent.groupId].$[pom.parent.artifactId]/groupId
{quote}
(note: replaced the curly braces with brackets due to a wiki error)
When you add a second level of modules, this approach does not seem to work
in Maven. The second level child module, which declares it parent to be a
first level child module. It appears that the parameter declaration in the
first-level module is ambiguous or is resolving to value as seen by the
second-level module. This can be seen below in the output of the error the
Maven reactor provides.
I was able to work around this error by changing the parametized groupId
declaration in the first-level module pom and making it explicit. If there
is something wrong with this approach or another parametized setting I need
to use, please let me know.
{quote}
C:\DEV\workspace\parentmvn clean install
[INFO] Scanning for projects...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: com.maventest.parent.first-level:second-level:jar:null
Reason: Cannot find parent: com.maventest.parent:first-level for project:
com.maventest.parent.first-level:second-level:jar:null for project
com.maventest.parent.first-level:second-level:jar:null
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
com.maventest.parent:first-level for project:
com.maventest.parent.first-level:second-level:jar:null for project
com.maventest.parent.first-level:second-level:jar:null
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:404)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
[jira] Commented: (MNG-4609) AMP packaging type is not seen as java project by cobertura
[
http://jira.codehaus.org/browse/MNG-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215652#action_215652
]
Julien HENRY commented on MNG-4609:
---
I'll report to the project.
In the plugin's pom it is said this plugin was inspired from maven-war-plugin.
Are you sure it will not break some default functionalities if I ask them to
change to:
{code}
component
roleorg.apache.maven.artifact.handler.ArtifactHandler/role
role-hintamp/role-hint
implementationorg.apache.maven.artifact.handler.DefaultArtifactHandler/implementation
configuration
extensionamp/extension
typeamp/type
packagingamp/packaging
languagejava/language
addedToClasspathtrue/addedToClasspath
includesDependenciestrue/includesDependencies
/configuration
/component
{code}
Thanks Benjamin.
AMP packaging type is not seen as java project by cobertura
---
Key: MNG-4609
URL: http://jira.codehaus.org/browse/MNG-4609
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Assignee: Benjamin Bentmann
I have a project that is using Maven Alfresco integration [1] to produce AMP
artifacts. There is a new packaging type amp. Looking at the source code of
the plugin the language is java [2].
On cobertura side there is a check [3] to prevent instrumentation in case of
non java artifact:
{code}
ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
if ( !java.equals( artifactHandler.getLanguage() ) )
{
getLog().info(
Not executing cobertura:instrument as the project is not a Java
classpath-capable package );
}
{code}
As AMP is supposed to be a java artifact (and that's actually true) I was
expecting cobertura to perform instrumentation. But in fact it is not:
{code}
[INFO]
[INFO] Building My Project AMP Packaging
[INFO]task-segment:
[org.codehaus.mojo:cobertura-maven-plugin:2.3:cobertura]
[INFO]
[INFO] Preparing cobertura:cobertura
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Storing buildNumber: 5 at timestamp: 1268819729587
[INFO] [nosnapshot:strip {execution: default}]
[INFO] Storing noSnapshotVersion: 0.1
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 8 resources to alfresco/module/fr.cirad.contrat
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [cobertura:instrument {execution: default-instrument}]
[INFO] Not executing cobertura:instrument as the project is not a Java
classpath-capable package
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
/var/lib/hudson/workspace/MyProject/trunk/target/surefire-reports
---
T E S T S
---
Running fr.myproject.contrat.CoreTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] [cobertura:cobertura {execution: default-cli}]
[INFO] Not executing cobertura:report as the cobertura data file
(/var/lib/hudson/workspace/MyProject/trunk/target/cobertura/cobertura.ser)
could not be found
[WARN] Cobertura report not found at
/var/lib/hudson/workspace/MyProject/trunk/target/site/cobertura/coverage.xml
{code}
Do you have any idea of the problem? Does it come from AMP plugin, cobertura
plugin or Maven core?
[1] http://wiki.alfresco.com/wiki/Managing_Alfresco_Lifecyle_with_Maven
[2]
http://maven-alfresco-archetypes.googlecode.com/svn/trunk/plugins/maven-amp-plugin/src/main/resources/META-INF/plexus/components.xml
[3]
http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.3/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4609) AMP packaging type is not seen as java project by cobertura
[
http://jira.codehaus.org/browse/MNG-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215653#action_215653
]
Julien HENRY commented on MNG-4609:
---
Reported: http://code.google.com/p/maven-alfresco-archetypes/issues/detail?id=52
AMP packaging type is not seen as java project by cobertura
---
Key: MNG-4609
URL: http://jira.codehaus.org/browse/MNG-4609
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Assignee: Benjamin Bentmann
I have a project that is using Maven Alfresco integration [1] to produce AMP
artifacts. There is a new packaging type amp. Looking at the source code of
the plugin the language is java [2].
On cobertura side there is a check [3] to prevent instrumentation in case of
non java artifact:
{code}
ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
if ( !java.equals( artifactHandler.getLanguage() ) )
{
getLog().info(
Not executing cobertura:instrument as the project is not a Java
classpath-capable package );
}
{code}
As AMP is supposed to be a java artifact (and that's actually true) I was
expecting cobertura to perform instrumentation. But in fact it is not:
{code}
[INFO]
[INFO] Building My Project AMP Packaging
[INFO]task-segment:
[org.codehaus.mojo:cobertura-maven-plugin:2.3:cobertura]
[INFO]
[INFO] Preparing cobertura:cobertura
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Storing buildNumber: 5 at timestamp: 1268819729587
[INFO] [nosnapshot:strip {execution: default}]
[INFO] Storing noSnapshotVersion: 0.1
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 8 resources to alfresco/module/fr.cirad.contrat
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [cobertura:instrument {execution: default-instrument}]
[INFO] Not executing cobertura:instrument as the project is not a Java
classpath-capable package
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
/var/lib/hudson/workspace/MyProject/trunk/target/surefire-reports
---
T E S T S
---
Running fr.myproject.contrat.CoreTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] [cobertura:cobertura {execution: default-cli}]
[INFO] Not executing cobertura:report as the cobertura data file
(/var/lib/hudson/workspace/MyProject/trunk/target/cobertura/cobertura.ser)
could not be found
[WARN] Cobertura report not found at
/var/lib/hudson/workspace/MyProject/trunk/target/site/cobertura/coverage.xml
{code}
Do you have any idea of the problem? Does it come from AMP plugin, cobertura
plugin or Maven core?
[1] http://wiki.alfresco.com/wiki/Managing_Alfresco_Lifecyle_with_Maven
[2]
http://maven-alfresco-archetypes.googlecode.com/svn/trunk/plugins/maven-amp-plugin/src/main/resources/META-INF/plexus/components.xml
[3]
http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.3/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4609) AMP packaging type is not seen as java project by cobertura
AMP packaging type is not seen as java project by cobertura
---
Key: MNG-4609
URL: http://jira.codehaus.org/browse/MNG-4609
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
I have a project that is using Maven Alfresco integration [1] to produce AMP
artifacts. There is a new packaging type amp. Looking at the source code of
the plugin the language is java [2].
On cobertura side there is a check [3] to prevent instrumentation in case of
non java artifact:
{code}
ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
if ( !java.equals( artifactHandler.getLanguage() ) )
{
getLog().info(
Not executing cobertura:instrument as the project is not a Java
classpath-capable package );
}
{code}
As AMP is supposed to be a java artifact (and that's actually true) I was
expecting cobertura to perform instrumentation. But in fact it is not:
{code}
[INFO]
[INFO] Building My Project AMP Packaging
[INFO]task-segment: [org.codehaus.mojo:cobertura-maven-plugin:2.3:cobertura]
[INFO]
[INFO] Preparing cobertura:cobertura
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Storing buildNumber: 5 at timestamp: 1268819729587
[INFO] [nosnapshot:strip {execution: default}]
[INFO] Storing noSnapshotVersion: 0.1
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 8 resources to alfresco/module/fr.cirad.contrat
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [cobertura:instrument {execution: default-instrument}]
[INFO] Not executing cobertura:instrument as the project is not a Java
classpath-capable package
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
/var/lib/hudson/workspace/MyProject/trunk/target/surefire-reports
---
T E S T S
---
Running fr.myproject.contrat.CoreTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] [cobertura:cobertura {execution: default-cli}]
[INFO] Not executing cobertura:report as the cobertura data file
(/var/lib/hudson/workspace/MyProject/trunk/target/cobertura/cobertura.ser)
could not be found
[WARN] Cobertura report not found at
/var/lib/hudson/workspace/MyProject/trunk/target/site/cobertura/coverage.xml
{code}
Do you have any idea of the problem? Does it come from AMP plugin, cobertura
plugin or Maven core?
[1] http://wiki.alfresco.com/wiki/Managing_Alfresco_Lifecyle_with_Maven
[2]
http://maven-alfresco-archetypes.googlecode.com/svn/trunk/plugins/maven-amp-plugin/src/main/resources/META-INF/plexus/components.xml
[3]
http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.3/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4609) AMP packaging type is not seen as java project by cobertura
[
http://jira.codehaus.org/browse/MNG-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215473#action_215473
]
Julien HENRY commented on MNG-4609:
---
Maybe a known issue related to plexus and custom packaging type.
To reproduce you can try:
{code}
mvn archetype:generate -DarchetypeGroupId=com.sourcesense.alfresco
-DarchetypeArtifactId=maven-alfresco-amp-archetype -DarchetypeVersion=1.9.1
-DgroupId=com.mycompany \
-DartifactId=myamp -Dversion=1.0-SNAPSHOT
-DarchetypeRepository=http://maven.alfresco.com/nexus/content/repositories/releases
-DinteractiveMode=false
cd myamp/
mvn clean cobertura:cobertura
{code}
AMP packaging type is not seen as java project by cobertura
---
Key: MNG-4609
URL: http://jira.codehaus.org/browse/MNG-4609
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Assignee: Benjamin Bentmann
I have a project that is using Maven Alfresco integration [1] to produce AMP
artifacts. There is a new packaging type amp. Looking at the source code of
the plugin the language is java [2].
On cobertura side there is a check [3] to prevent instrumentation in case of
non java artifact:
{code}
ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
if ( !java.equals( artifactHandler.getLanguage() ) )
{
getLog().info(
Not executing cobertura:instrument as the project is not a Java
classpath-capable package );
}
{code}
As AMP is supposed to be a java artifact (and that's actually true) I was
expecting cobertura to perform instrumentation. But in fact it is not:
{code}
[INFO]
[INFO] Building My Project AMP Packaging
[INFO]task-segment:
[org.codehaus.mojo:cobertura-maven-plugin:2.3:cobertura]
[INFO]
[INFO] Preparing cobertura:cobertura
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Storing buildNumber: 5 at timestamp: 1268819729587
[INFO] [nosnapshot:strip {execution: default}]
[INFO] Storing noSnapshotVersion: 0.1
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 8 resources to alfresco/module/fr.cirad.contrat
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [cobertura:instrument {execution: default-instrument}]
[INFO] Not executing cobertura:instrument as the project is not a Java
classpath-capable package
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
/var/lib/hudson/workspace/MyProject/trunk/target/surefire-reports
---
T E S T S
---
Running fr.myproject.contrat.CoreTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] [cobertura:cobertura {execution: default-cli}]
[INFO] Not executing cobertura:report as the cobertura data file
(/var/lib/hudson/workspace/MyProject/trunk/target/cobertura/cobertura.ser)
could not be found
[WARN] Cobertura report not found at
/var/lib/hudson/workspace/MyProject/trunk/target/site/cobertura/coverage.xml
{code}
Do you have any idea of the problem? Does it come from AMP plugin, cobertura
plugin or Maven core?
[1] http://wiki.alfresco.com/wiki/Managing_Alfresco_Lifecyle_with_Maven
[2]
http://maven-alfresco-archetypes.googlecode.com/svn/trunk/plugins/maven-amp-plugin/src/main/resources/META-INF/plexus/components.xml
[3]
http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.3/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-4609) AMP packaging type is not seen as java project by cobertura
[
http://jira.codehaus.org/browse/MNG-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien HENRY reopened MNG-4609:
---
AMP packaging type is not seen as java project by cobertura
---
Key: MNG-4609
URL: http://jira.codehaus.org/browse/MNG-4609
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Assignee: Benjamin Bentmann
I have a project that is using Maven Alfresco integration [1] to produce AMP
artifacts. There is a new packaging type amp. Looking at the source code of
the plugin the language is java [2].
On cobertura side there is a check [3] to prevent instrumentation in case of
non java artifact:
{code}
ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
if ( !java.equals( artifactHandler.getLanguage() ) )
{
getLog().info(
Not executing cobertura:instrument as the project is not a Java
classpath-capable package );
}
{code}
As AMP is supposed to be a java artifact (and that's actually true) I was
expecting cobertura to perform instrumentation. But in fact it is not:
{code}
[INFO]
[INFO] Building My Project AMP Packaging
[INFO]task-segment:
[org.codehaus.mojo:cobertura-maven-plugin:2.3:cobertura]
[INFO]
[INFO] Preparing cobertura:cobertura
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Storing buildNumber: 5 at timestamp: 1268819729587
[INFO] [nosnapshot:strip {execution: default}]
[INFO] Storing noSnapshotVersion: 0.1
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 8 resources to alfresco/module/fr.cirad.contrat
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [cobertura:instrument {execution: default-instrument}]
[INFO] Not executing cobertura:instrument as the project is not a Java
classpath-capable package
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
/var/lib/hudson/workspace/MyProject/trunk/target/surefire-reports
---
T E S T S
---
Running fr.myproject.contrat.CoreTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] [cobertura:cobertura {execution: default-cli}]
[INFO] Not executing cobertura:report as the cobertura data file
(/var/lib/hudson/workspace/MyProject/trunk/target/cobertura/cobertura.ser)
could not be found
[WARN] Cobertura report not found at
/var/lib/hudson/workspace/MyProject/trunk/target/site/cobertura/coverage.xml
{code}
Do you have any idea of the problem? Does it come from AMP plugin, cobertura
plugin or Maven core?
[1] http://wiki.alfresco.com/wiki/Managing_Alfresco_Lifecyle_with_Maven
[2]
http://maven-alfresco-archetypes.googlecode.com/svn/trunk/plugins/maven-amp-plugin/src/main/resources/META-INF/plexus/components.xml
[3]
http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.3/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2739) Version 2.2-jdk15 of UISpec4J
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215315#action_215315 ] Julien HENRY commented on MAVENUPLOAD-2739: --- In fact there is a mistake in the bundle. uispec4j comes with two classifiers: jdk16 and jdk15 (see previous version 2.1 http://repo2.maven.org/maven2/org/uispec4j/uispec4j/2.1/). As it is no more possible to remove the current JAR in central I suggest to add uispec4j-2.2-jdk16.jar (duplicate of uispec4j-2.2.jar) from MAVENUPLOAD-2740 and to add uispec4j-2.2-jdk15.jar from the bundle attached to the current upload request. Of course the pom must be the same for both classifiers. Concerning -source and -javadoc I don't know what to do as main site (http://www.uispec4j.org/download) offers separate archives for jdk15 and jdk16. Version 2.2-jdk15 of UISpec4J - Key: MAVENUPLOAD-2739 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2739 Project: Maven Upload Requests Issue Type: New Feature Reporter: Pascal Pratmarty UISpec4J is an Open Source functional and/or unit testing library for Swing-based Java applications, built on top of the JUnit and TestNG test harnesses. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4596) [regression] classpath entry is missing in ejb MANIFEST
[regression] classpath entry is missing in ejb MANIFEST --- Key: MNG-4596 URL: http://jira.codehaus.org/browse/MNG-4596 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0-alpha-7 Reporter: Julien HENRY Priority: Critical Attachments: test-bug-maven-ejb-manifest.zip After upgrading from alpha 6 to alpha 7, the classpath entry is missing in the MANIFEST of my ejb module. See the attached project as example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEJB-46) classpath entry is missing in ejb MANIFEST when using Maven 3.0-alpha-7
[ http://jira.codehaus.org/browse/MEJB-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=214247#action_214247 ] Julien HENRY commented on MEJB-46: -- Thanks Benjamin classpath entry is missing in ejb MANIFEST when using Maven 3.0-alpha-7 --- Key: MEJB-46 URL: http://jira.codehaus.org/browse/MEJB-46 Project: Maven 2.x EJB Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Maven 3.0-alpha-7 Reporter: Julien HENRY Assignee: Benjamin Bentmann Priority: Critical Fix For: 2.2.1 Attachments: test-bug-maven-ejb-manifest.zip After upgrading from alpha 6 to alpha 7, the classpath entry is missing in the MANIFEST of my ejb module. See the attached project as example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2877) unable to resolve attached artifacts from reactor that are not in repo. (patch applied in svn and IT tests added)
[
http://jira.codehaus.org/browse/MNG-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=213318#action_213318
]
Julien HENRY commented on MNG-2877:
---
Hi Brett,
I'm using release plugin 2.0 and the problem is still here. During the
release:prepare goal, I believe the forked execution is mvn clean verify.
And this is mvn clean verify that fails (even outside of the release process)
when artifact I want to copy was not previously installed in the local
repository.
The initial description of this issue (comming from MDEP-64) make me think this
is the same issue and it was supposed to be fixed in 2.0.6.
Again it works with Maven 3 so I guess there is no chance it will be fixed in
Maven 2.2.x but I just want to point out that ITs may not be complete.
unable to resolve attached artifacts from reactor that are not in repo.
(patch applied in svn and IT tests added)
-
Key: MNG-2877
URL: http://jira.codehaus.org/browse/MNG-2877
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.2, 2.0.3, 2.0.4, 2.0.5
Reporter: Brian Fox
Assignee: Jason van Zyl
Fix For: 2.0.6
Attachments: test-bug-maven-release.zip
The patch has been applied here:
https://svn.apache.org/repos/asf/maven/components/branches/maven-project-mdep64
and the IT tests are already added to core-it but commented out from the
suite. To enable it, uncomment this line: //suite.addTestSuite(
MavenIT0118AttachedArtifactsInReactor.class );
---
This is from MDEP-64:
We have a project with a few sub-projects. Only one of those subprojects uses
the maven-dependency-plugin, copying the jar file artifact from one of the
sibling sub-projects. The dependency plugin has worked fine in another
multi-project m2 buld and release when the dependency copy was only
referencing projects outside the multi-project's project tree.
But in the present multi-project release, copying that sibling jar file with
the dependency plugin causes the mvn release:prepare step to fail, because it
can't find the released version in the release repository. It doesn't care
about referencing sibling project dependencies from the regular pom
dependencies, it only chokes for the dependency:copy.
Here's a diagram for the issue with three pseudo-poms. I omitted groupId's,
scm, distributionManagement, and other content from the poms that were not
necessary to communicate the basic issue. I've worked around this by using
the antrun plugin, which is unpleasant and untidy. This seems like it might
be related to MDEP-44.
superproject/
A/ - no dependencies
B/ - dependency:copy A
//superproject/pom.xml (abbrieviated)
project
artifactIdsuperproject/artifactId
packagingpom/packaging
version1.0.0.1-SNAPSHOT/version
modules
moduleA/module
moduleB/module
/modules
/project
// superproject/A/pom.xml (abbrievated)
project
parent
artifactIdsuperproject/artifactId
version1.0.0.1-SNAPSHOT/version
/parent
artifactIdA/artifactId
version1.0.0.1-SNAPSHOT/version
/project
// superproject/B/pom.xml (abbreviated)
project
parent
artifactIdsuperproject/artifactId
version1.0.0.1-SNAPSHOT/version
/parent
artifactIdB/artifactId
packagingwar/packaging
version1.0.0.1-SNAPSHOT/version
build
finalNameFooWar/finalName
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy/id
goals
goalcopy/goal
/goals
phasepackage/phase
configuration
artifactItems
artifactItem
artifactIdA/artifactId
version${pom.version}/version
typejar/type
/artifactItem
/artifactItems
outputDirectory${project.build.directory}/${pom.build.finalName}/jars/outputDirectory
/configuration
/execution
/executions
/plugin
/plugins
/build
dependencies
dependency
artifactIdA/artifactId
version${pom.version}/version
/dependency
/dependencies
/project
The error message during mvn release:prepare is basically:
[INFO] Building B
[INFO] task-segment: [clean, integration-test]
[INFO]
[INFO] [clean:clean] skip deleting directories
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: groupId:A:null:1.0.0.1:jar
Downloading: details/1.0.0.1/A-1.0.0.1.jar
[WARNING] Unable to get resource from repository sizzle (our repository
details)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: groupId
ArtifactId: A
Version: 1.0.0.1
Reason: Unable to
[jira] Updated: (MNG-2877) unable to resolve attached artifacts from reactor that are not in repo. (patch applied in svn and IT tests added)
[
http://jira.codehaus.org/browse/MNG-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien HENRY updated MNG-2877:
--
Attachment: test-bug-maven-release.zip
Here is a sample project to reproduce the issue.
unable to resolve attached artifacts from reactor that are not in repo.
(patch applied in svn and IT tests added)
-
Key: MNG-2877
URL: http://jira.codehaus.org/browse/MNG-2877
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.2, 2.0.3, 2.0.4, 2.0.5
Reporter: Brian Fox
Assignee: Jason van Zyl
Fix For: 2.0.6
Attachments: test-bug-maven-release.zip
The patch has been applied here:
https://svn.apache.org/repos/asf/maven/components/branches/maven-project-mdep64
and the IT tests are already added to core-it but commented out from the
suite. To enable it, uncomment this line: //suite.addTestSuite(
MavenIT0118AttachedArtifactsInReactor.class );
---
This is from MDEP-64:
We have a project with a few sub-projects. Only one of those subprojects uses
the maven-dependency-plugin, copying the jar file artifact from one of the
sibling sub-projects. The dependency plugin has worked fine in another
multi-project m2 buld and release when the dependency copy was only
referencing projects outside the multi-project's project tree.
But in the present multi-project release, copying that sibling jar file with
the dependency plugin causes the mvn release:prepare step to fail, because it
can't find the released version in the release repository. It doesn't care
about referencing sibling project dependencies from the regular pom
dependencies, it only chokes for the dependency:copy.
Here's a diagram for the issue with three pseudo-poms. I omitted groupId's,
scm, distributionManagement, and other content from the poms that were not
necessary to communicate the basic issue. I've worked around this by using
the antrun plugin, which is unpleasant and untidy. This seems like it might
be related to MDEP-44.
superproject/
A/ - no dependencies
B/ - dependency:copy A
//superproject/pom.xml (abbrieviated)
project
artifactIdsuperproject/artifactId
packagingpom/packaging
version1.0.0.1-SNAPSHOT/version
modules
moduleA/module
moduleB/module
/modules
/project
// superproject/A/pom.xml (abbrievated)
project
parent
artifactIdsuperproject/artifactId
version1.0.0.1-SNAPSHOT/version
/parent
artifactIdA/artifactId
version1.0.0.1-SNAPSHOT/version
/project
// superproject/B/pom.xml (abbreviated)
project
parent
artifactIdsuperproject/artifactId
version1.0.0.1-SNAPSHOT/version
/parent
artifactIdB/artifactId
packagingwar/packaging
version1.0.0.1-SNAPSHOT/version
build
finalNameFooWar/finalName
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy/id
goals
goalcopy/goal
/goals
phasepackage/phase
configuration
artifactItems
artifactItem
artifactIdA/artifactId
version${pom.version}/version
typejar/type
/artifactItem
/artifactItems
outputDirectory${project.build.directory}/${pom.build.finalName}/jars/outputDirectory
/configuration
/execution
/executions
/plugin
/plugins
/build
dependencies
dependency
artifactIdA/artifactId
version${pom.version}/version
/dependency
/dependencies
/project
The error message during mvn release:prepare is basically:
[INFO] Building B
[INFO] task-segment: [clean, integration-test]
[INFO]
[INFO] [clean:clean] skip deleting directories
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: groupId:A:null:1.0.0.1:jar
Downloading: details/1.0.0.1/A-1.0.0.1.jar
[WARNING] Unable to get resource from repository sizzle (our repository
details)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: groupId
ArtifactId: A
Version: 1.0.0.1
Reason: Unable to download the artifact from any repository
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2877) unable to resolve attached artifacts from reactor that are not in repo. (patch applied in svn and IT tests added)
[
http://jira.codehaus.org/browse/MNG-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=213179#action_213179
]
Julien HENRY commented on MNG-2877:
---
Are you sure this bug is fixed in Maven 2?
I just face it with Maven 2.2.1 when doing a release:prepare.
Here is an attached project to reproduce the issue. Running mvn clean verify
fails to build with Maven 2.2.1.
Note that it is working with Maven 3 alpha 6.
unable to resolve attached artifacts from reactor that are not in repo.
(patch applied in svn and IT tests added)
-
Key: MNG-2877
URL: http://jira.codehaus.org/browse/MNG-2877
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.2, 2.0.3, 2.0.4, 2.0.5
Reporter: Brian Fox
Assignee: Jason van Zyl
Fix For: 2.0.6
Attachments: test-bug-maven-release.zip
The patch has been applied here:
https://svn.apache.org/repos/asf/maven/components/branches/maven-project-mdep64
and the IT tests are already added to core-it but commented out from the
suite. To enable it, uncomment this line: //suite.addTestSuite(
MavenIT0118AttachedArtifactsInReactor.class );
---
This is from MDEP-64:
We have a project with a few sub-projects. Only one of those subprojects uses
the maven-dependency-plugin, copying the jar file artifact from one of the
sibling sub-projects. The dependency plugin has worked fine in another
multi-project m2 buld and release when the dependency copy was only
referencing projects outside the multi-project's project tree.
But in the present multi-project release, copying that sibling jar file with
the dependency plugin causes the mvn release:prepare step to fail, because it
can't find the released version in the release repository. It doesn't care
about referencing sibling project dependencies from the regular pom
dependencies, it only chokes for the dependency:copy.
Here's a diagram for the issue with three pseudo-poms. I omitted groupId's,
scm, distributionManagement, and other content from the poms that were not
necessary to communicate the basic issue. I've worked around this by using
the antrun plugin, which is unpleasant and untidy. This seems like it might
be related to MDEP-44.
superproject/
A/ - no dependencies
B/ - dependency:copy A
//superproject/pom.xml (abbrieviated)
project
artifactIdsuperproject/artifactId
packagingpom/packaging
version1.0.0.1-SNAPSHOT/version
modules
moduleA/module
moduleB/module
/modules
/project
// superproject/A/pom.xml (abbrievated)
project
parent
artifactIdsuperproject/artifactId
version1.0.0.1-SNAPSHOT/version
/parent
artifactIdA/artifactId
version1.0.0.1-SNAPSHOT/version
/project
// superproject/B/pom.xml (abbreviated)
project
parent
artifactIdsuperproject/artifactId
version1.0.0.1-SNAPSHOT/version
/parent
artifactIdB/artifactId
packagingwar/packaging
version1.0.0.1-SNAPSHOT/version
build
finalNameFooWar/finalName
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy/id
goals
goalcopy/goal
/goals
phasepackage/phase
configuration
artifactItems
artifactItem
artifactIdA/artifactId
version${pom.version}/version
typejar/type
/artifactItem
/artifactItems
outputDirectory${project.build.directory}/${pom.build.finalName}/jars/outputDirectory
/configuration
/execution
/executions
/plugin
/plugins
/build
dependencies
dependency
artifactIdA/artifactId
version${pom.version}/version
/dependency
/dependencies
/project
The error message during mvn release:prepare is basically:
[INFO] Building B
[INFO] task-segment: [clean, integration-test]
[INFO]
[INFO] [clean:clean] skip deleting directories
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: groupId:A:null:1.0.0.1:jar
Downloading: details/1.0.0.1/A-1.0.0.1.jar
[WARNING] Unable to get resource from repository sizzle (our repository
details)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: groupId
ArtifactId: A
Version: 1.0.0.1
Reason: Unable to download the artifact from any repository
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4562) [regression] UnsupportedOperationException with Maven AndromMDA plugin
[regression] UnsupportedOperationException with Maven AndromMDA plugin
--
Key: MNG-4562
URL: http://jira.codehaus.org/browse/MNG-4562
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0-alpha-6
Reporter: Julien HENRY
Attachments: test-bug-maven-andromda-sources.zip
Running mvn clean install -DperformRelease=true -e on the attached project
generate the following error:
{code}
[ERROR] Failed to execute goal
org.andromda.maven.plugins:andromda-maven-plugin:3.3:run (default) on project
uml: Error
running AndroMDA: UnsupportedOperationException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.andromda.maven.plugins:andromda-maven
-plugin:3.3:run (default) on project uml: Error running AndroMDA
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:570)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeForkedExecutions(DefaultLifecycleExecutor.java:645)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:247)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:104)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:422)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:157)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error running
AndroMDA
at
org.andromda.maven.plugin.AbstractAndroMDAMojo.execute(AbstractAndroMDAMojo.java:116)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:562)
... 16 more
Caused by: java.lang.UnsupportedOperationException
at
java.util.Collections$UnmodifiableCollection.add(Collections.java:1018)
at
org.andromda.maven.plugin.configuration.AbstractConfigurationMojo.addDependency(AbstractConfigurationMojo.java:259)
at
org.andromda.maven.plugin.configuration.AbstractConfigurationMojo.addPluginDependencies(AbstractConfigurationMojo.java:221)
at
org.andromda.maven.plugin.AbstractAndroMDAMojo.execute(AbstractAndroMDAMojo.java:101)
... 18 more
{code}
mvn clean install (without generating attached sources) works fine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-517) Putting SVN password in settings.xml doesn't support password encryption
Putting SVN password in settings.xml doesn't support password encryption Key: SCM-517 URL: http://jira.codehaus.org/browse/SCM-517 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Reporter: Julien HENRY I'm using maven-release-plugin-2.0-beta-8 and I have encrypted all the password in settings.xml as described here: http://maven.apache.org/guides/mini/guide-encryption.html It works for deployment servers but not for SVN servers (the functionality was provided by SCM-85). I had to revert back to clear passwords for SVN server credentials in settings.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEPLOY-114) Add an option to not fail when remote file already exists and redeploy is forbidden
Add an option to not fail when remote file already exists and redeploy is forbidden --- Key: MDEPLOY-114 URL: http://jira.codehaus.org/browse/MDEPLOY-114 Project: Maven 2.x Deploy Plugin Issue Type: Wish Components: deploy:deploy Affects Versions: 2.4 Reporter: Julien HENRY In my organisation we are using a MRM (Nexus) with redeployment of release that is forbidden. Sometimes the release:perform may fail in the middle of a multi-module release. It means some modules were deployed but other are not. Currently it is not possible to restart the release as it will fail on first deployment (usually the parent pom of the multimodule) because the pom was already deployed during the first attempt. I would like to add an option to the deploy plugin that may deal with this case. Perhaps an option like -Dredeploy=false that may either : 1) check if the remote file already exists before trying to upload 2) try to upload everytime but not fail the build The problem with the second proposal is the error returned by Nexus is authorization error so we may not be able to distinguish real authorization error on a new file and redeploy attempt. Caused by: org.apache.maven.wagon.authorization.AuthorizationException: Access denied to: http://nexus.mycompany.com/ content/repositories/myrepo/com/mycustomer/project/parent/3.2.0/parent-3.2.0.pom at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:360) Other options may be more complicated like implementing an atomic deploy process on multimodule (may need a big change of the deploy protocol). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-114) Add an option to not fail when remote file already exists and redeploy is forbidden
[ http://jira.codehaus.org/browse/MDEPLOY-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=202072#action_202072 ] Julien HENRY commented on MDEPLOY-114: -- We are not using the staging process currently. But you are right, it may certainly be a good thing to investigate. Add an option to not fail when remote file already exists and redeploy is forbidden --- Key: MDEPLOY-114 URL: http://jira.codehaus.org/browse/MDEPLOY-114 Project: Maven 2.x Deploy Plugin Issue Type: Wish Components: deploy:deploy Affects Versions: 2.4 Reporter: Julien HENRY In my organisation we are using a MRM (Nexus) with redeployment of release that is forbidden. Sometimes the release:perform may fail in the middle of a multi-module release. It means some modules were deployed but other are not. Currently it is not possible to restart the release as it will fail on first deployment (usually the parent pom of the multimodule) because the pom was already deployed during the first attempt. I would like to add an option to the deploy plugin that may deal with this case. Perhaps an option like -Dredeploy=false that may either : 1) check if the remote file already exists before trying to upload 2) try to upload everytime but not fail the build The problem with the second proposal is the error returned by Nexus is authorization error so we may not be able to distinguish real authorization error on a new file and redeploy attempt. Caused by: org.apache.maven.wagon.authorization.AuthorizationException: Access denied to: http://nexus.mycompany.com/ content/repositories/myrepo/com/mycustomer/project/parent/3.2.0/parent-3.2.0.pom at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:360) Other options may be more complicated like implementing an atomic deploy process on multimodule (may need a big change of the deploy protocol). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2258) Wrong execution order of plugins in same phase
[
http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=200327#action_200327
]
Julien HENRY commented on MNG-2258:
---
In my corporate parent pom I have the following in reporting section:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jxr-plugin/artifactId
version2.1/version
/plugin
...
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdtaglist-maven-plugin/artifactId
version2.4/version
/plugin
{code}
(in this order)
Then I have create a sample test project from Maven quickstart archetype but:
{noformat}
mvn clean install site dependency:tree
...
[INFO] Generating Tag List report.
[ERROR] Taglist plugin MUST be executed after the JXR plugin. No links to xref
were generated.
[WARNING] Unable to locate Source XRef to link to - DISABLED
{noformat}
Looking at the log I can see reporting plugins are generated in an order
completely different of the reporting section order.
Wrong execution order of plugins in same phase
--
Key: MNG-2258
URL: http://jira.codehaus.org/browse/MNG-2258
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.4
Environment: N/A
Reporter: David J. M. Karlsen
Priority: Blocker
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 contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2258) Wrong execution order of plugins in same phase
[
http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=200327#action_200327
]
Julien HENRY edited comment on MNG-2258 at 12/2/09 10:39 AM:
-
In my corporate parent pom I have the following in reporting section:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jxr-plugin/artifactId
version2.1/version
/plugin
...
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdtaglist-maven-plugin/artifactId
version2.4/version
/plugin
{code}
(in this order)
Then I have create a sample test project from Maven quickstart archetype but:
{noformat}
mvn clean install site
...
[INFO] Generating Tag List report.
[ERROR] Taglist plugin MUST be executed after the JXR plugin. No links to xref
were generated.
[WARNING] Unable to locate Source XRef to link to - DISABLED
{noformat}
Looking at the log I can see reporting plugins are generated in an order
completely different of the reporting section order.
was (Author: henryju):
In my corporate parent pom I have the following in reporting section:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jxr-plugin/artifactId
version2.1/version
/plugin
...
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdtaglist-maven-plugin/artifactId
version2.4/version
/plugin
{code}
(in this order)
Then I have create a sample test project from Maven quickstart archetype but:
{noformat}
mvn clean install site dependency:tree
...
[INFO] Generating Tag List report.
[ERROR] Taglist plugin MUST be executed after the JXR plugin. No links to xref
were generated.
[WARNING] Unable to locate Source XRef to link to - DISABLED
{noformat}
Looking at the log I can see reporting plugins are generated in an order
completely different of the reporting section order.
Wrong execution order of plugins in same phase
--
Key: MNG-2258
URL: http://jira.codehaus.org/browse/MNG-2258
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.4
Environment: N/A
Reporter: David J. M. Karlsen
Priority: Blocker
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 contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-275) Creation of Javadoc attachments fails in multi-module project where modules have never been installed/deployed
[
http://jira.codehaus.org/browse/MJAVADOC-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198314#action_198314
]
Julien HENRY commented on MJAVADOC-275:
---
I agree I think this is the same issue.
Creation of Javadoc attachments fails in multi-module project where modules
have never been installed/deployed
--
Key: MJAVADOC-275
URL: http://jira.codehaus.org/browse/MJAVADOC-275
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.6.1
Reporter: Benjamin Bentmann
Priority: Critical
Attachments: MJAVADOC-275.zip
Running the commands
{noformat}
mvn clean
mvn verify
{noformat}
will fail on the attached demo project with
{noformat}
[INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc'
has not be previously called for the project:
'org.apache.maven.its.javadoc:mod-b:jar:0.1'.
Trying to invoke it...
[ERROR] MavenInvocationException: Error when invoking Maven, consult the
invoker log file:
M:\MJAVADOC\mod-a\target\invoker\maven-javadoc-plugin625147587.txt
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] MavenReportException: Error while creating archive:
Error when invoking Maven, consult the invoker log file:
M:\MJAVADOC\mod-a\target\invoker\maven-javadoc-plugin625147587.txt
{noformat}
The command {{mvn clean verify}} as usually used during releases will also
fail, but starts working after repeated invocations.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-442) scm tag phase ignores custom message (need to use scm 1.3)
[ http://jira.codehaus.org/browse/MRELEASE-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198117#action_198117 ] Julien HENRY commented on MRELEASE-442: --- Is it possible to release a new version of release plugin? Maven 3 seems to use 2.0-beta-9 as a default and this bug block the release process (I have to force version of release plugin to 2.0-beta-8) Thanks scm tag phase ignores custom message (need to use scm 1.3) -- Key: MRELEASE-442 URL: http://jira.codehaus.org/browse/MRELEASE-442 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-9 Reporter: Stas Garifulin Assignee: Olivier Lamy Fix For: 2.0-beta-10 [http://jira.codehaus.org/browse/SCM-460] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2483) Version jdk6-2.0 of UISpec4J
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=191674#action_191674 ] Julien HENRY commented on MAVENUPLOAD-2483: --- Is it possible to sort out this issue as I would like to use uispec4j 2.0 from Maven. Thanks. Version jdk6-2.0 of UISpec4J Key: MAVENUPLOAD-2483 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2483 Project: Maven Upload Requests Issue Type: New Feature Reporter: Pascal Pratmarty Assignee: Carlos Sanchez Attachments: uispec4j-jdk6-2.0-bundle.jar UISpec4J is an Open Source functional and/or unit testing library for Swing-based Java applications, built on top of the JUnit and TestNG test harnesses. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-519) Timestamps on messages
[ http://jira.codehaus.org/browse/MNG-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=187084#action_187084 ] Julien HENRY commented on MNG-519: -- I second this request. I want to find what part of the build is consuming time. And the work-around seems not possible with Continuum. Timestamps on messages -- Key: MNG-519 URL: http://jira.codehaus.org/browse/MNG-519 Project: Maven 2 Issue Type: Wish Components: Logging, Plugins and Lifecycle Reporter: Jeff Jensen Priority: Minor Fix For: 3.x With current and/or moving forward with M2, I would like an option for timestamped messages. We have a somewhat long nightly process. I regularly wish for timestamps on the log messages from the Maven build. The two primary reasons for this are duration calculation - how long did something take, and an occasional correlation with an outside event. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-519) Timestamps on messages
[
http://jira.codehaus.org/browse/MNG-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=187095#action_187095
]
Julien HENRY commented on MNG-519:
--
I think I have a better workaround.
1) Edit
$MAVEN_HOME/lib/maven-2.2.1-uber.jar!org/codehaus/plexus/plexus-bootstrap.xml
Replace:
{code}
component
roleorg.codehaus.plexus.logging.LoggerManager/role
implementationorg.codehaus.plexus.logging.console.ConsoleLoggerManager/implementation
lifecycle-handlerbasic/lifecycle-handler
configuration
thresholdinfo/threshold
/configuration
/component
{code}
by
{code}
component
roleorg.codehaus.plexus.logging.LoggerManager/role
implementation
org.codehaus.plexus.logging.slf4j.Slf4jLoggerManager
/implementation
/component
{code}
2) Download and move into $MAVEN_HOME/lib:
plexus-slf4j-logging-1.1-alpha-1.jar
slf4j-api-1.5.8.jar
And also the slf4j implementation you want to use (in my case it is logback):
logback-core-0.9.15.jar
logback-classic-0.9.15.jar
3) To configure logback you can use a logback.xml file. The only trick is that
Maven loader will only pick JAR file in /lib folder so you can simply create a
new JAR containing only logback.xml
For example here is my logback.xml:
{code}
?xml version=1.0 encoding=UTF-8 ?
!-- Logback configuration file --
configuration
appender name=STDOUT class=ch.qos.logback.core.ConsoleAppender
layout class=ch.qos.logback.classic.PatternLayout
!--Pattern%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -
%msg%n/Pattern--
Pattern%-5level %d{HH:mm:ss.SSS} %msg%n/Pattern
/layout
/appender
root
level value=INFO /
appender-ref ref=STDOUT /
/root
/configuration
{code}
And finally:
{code}
mvn clean
INFO 15:01:32.785 Scanning for projects...
INFO 15:01:32.972 Reactor build order:
...
...
INFO 15:01:34.082
INFO 15:01:34.082 BUILD SUCCESSFUL
INFO 15:01:34.082
INFO 15:01:34.097 Total time: 1 second
INFO 15:01:34.097 Finished at: Fri Aug 14 15:01:34 CEST 2009
INFO 15:01:34.160 Final Memory: 7M/13M
INFO 15:01:34.160
There was no such logger
'org.apache.maven.artifact.metadata.ArtifactMetadataSource:maven' 18061339.
There was no such logger 'org.apache.maven.plugin.PluginMappingManager'
18061339.
There was no such logger 'org.apache.maven.artifact.resolver.ArtifactResolver'
18061339.
There was no such logger
'org.apache.maven.artifact.transform.ArtifactTransformation:snapshot' 18061339.
There was no such logger 'org.apache.maven.profiles.MavenProfilesBuilder'
18061339.
{code}
There are two issues with this solution:
1) The -X flag does nothing. You have to manually update logback.xml to change
INFO to DEBUG.
2) I don't know why there is the lines:
{code}
There was no such logger 'org.apache.maven.profiles.MavenProfilesBuilder'
18061339.
{code}
at the end...
Hope that help.
Timestamps on messages
--
Key: MNG-519
URL: http://jira.codehaus.org/browse/MNG-519
Project: Maven 2
Issue Type: Wish
Components: Logging, Plugins and Lifecycle
Reporter: Jeff Jensen
Priority: Minor
Fix For: 3.x
With current and/or moving forward with M2, I would like an option for
timestamped messages.
We have a somewhat long nightly process. I regularly wish for timestamps on
the log messages from the Maven build. The two primary reasons for this are
duration calculation - how long did something take, and an occasional
correlation with an outside event.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4278) Allow wildcard in server id in settings.xml
Allow wildcard in server id in settings.xml
---
Key: MNG-4278
URL: http://jira.codehaus.org/browse/MNG-4278
Project: Maven 2
Issue Type: New Feature
Components: Settings
Affects Versions: 2.2.0
Reporter: Julien HENRY
In my company each project has a separate repository for deploying their
artifacts (we are using Archiva).
One developer may work on several projects, and also the integration platform
(Continuum) must be able to deploy on all repositories.
Currently I have to add in settings.xml
{code}
server
idmycompany.project1Id.release/id
usernameuserId/username
passwordxxx/password
/server
server
idmycompany.project2Id.release/id
usernameuserId/username
passwordxxx/password
/server
server
idmycompany.project1Id.snapshots/id
usernameuserId/username
passwordxxx/password
/server
server
idmycompany.project2Id.snapshots/id
usernameuserId/username
passwordxxx/password
/server
... (repeat for every projects)
{code}
Where userId and password are always the same.
It would be great to allow:
{code}
server
idmycompany.*.*/id
usernameuserId/username
passwordxxx/password
/server
{code}
in settings.xml.
In case there are several matches for a repositoryId, I think it is better to
raise an error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-150) the dependency report ignores mirrors
[ http://jira.codehaus.org/browse/MPIR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=184735#action_184735 ] Julien HENRY commented on MPIR-150: --- Is this bug a duplicate of (now resolved) MPIR-160? the dependency report ignores mirrors - Key: MPIR-150 URL: http://jira.codehaus.org/browse/MPIR-150 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1.1 Reporter: Brian Fox The dependencies report takes forever and running debug i can see it's hitting the same repos over and over and bypassing my repository manager. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2553) Maven Local Settings Model should allow configuration of distributions (distributionManagement)
[ http://jira.codehaus.org/browse/MNG-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=184788#action_184788 ] Julien HENRY commented on MNG-2553: --- The hack provided by Brian doesn't work with site deployment location. On my CI platform I would like to be able to override distributionManagement of all projects whatever is the value in pom.xml. Maven Local Settings Model should allow configuration of distributions (distributionManagement) --- Key: MNG-2553 URL: http://jira.codehaus.org/browse/MNG-2553 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.0.4 Reporter: Jimisola Laursen Fix For: 3.x There is a good use case where this would be very useful. E.g. I develop a plugin in mojo-sandbox and want to test it in an environment other than the one that I developed it on (e.g. a computer at work). I check out the plugin to this, build and then want to deploy to another repository (e..g a company's internal repository). I don't want to fiddle with the pom.xml of the plugin, just refer to a profile in settings.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2739) Repository entries are not validated and NPE will occur
[
http://jira.codehaus.org/browse/MNG-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=176373#action_176373
]
Julien HENRY commented on MNG-2739:
---
Hi,
It seems I have the same issue with one of my projects. It occurs during site
creation (mvn clean install works fine).
{code}
mvn site -X
+ Error stacktraces are turned on.
Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_12
Java home: C:\Program Files\Java\jdk1.6.0_12\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
[DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and
Settings\jhenry\.m2\plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'D:\apache-maven-2.1.0\bin\..\conf\plugin-registry.xml'
[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM: com.mycompany.sud:parent:pom:1.0.3-SNAPSHOT
of project: mycompany.cust.project:project:jar:1.0-SNAPSHOT in relative path:
../pom.xml
[DEBUG] Parent-POM: com.mycompany.sud:parent:pom:1.0.3-SNAPSHOT not found in
relative path: ../pom.xml
[DEBUG] Retrieving parent-POM: com.mycompany.sud:parent:pom:1.0.3-SNAPSHOT for
project: mycompany.cust.project:project:jar:1.0-SNAPSHOT from the repository.
[DEBUG] Skipping disabled repository central
[DEBUG] parent: using locally installed snapshot
[DEBUG] Wagons could not be registered as the extension container was never
created
[INFO]
[INFO] Building project
[INFO]task-segment: [site]
[INFO]
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:11
for project: null:maven-site-plugin:maven-plugin:2.0-beta-7 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:8 for project:
org.apache.maven.plugins:maven-plugins:pom:11 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project:
org.apache.maven:maven-parent:pom:8 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:8 for
project: null:maven-compiler-plugin:maven-plugin:2.0.2 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:5 for project:
org.apache.maven.plugins:maven-plugins:pom:8 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache:pom:3 for project:
org.apache.maven:maven-parent:pom:5 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:7 for
project: org.apache.maven.plugins:maven-eclipse-plugin:maven-plugin:2.3 from
the repository.
[DEBUG] Retrieving parent-POM:
org.apache.maven:maven-plugin-surrogate-parent:pom:5 for project:
org.apache.maven.plugin
s:maven-plugins:pom:7 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven.surefire:surefire:pom:2.3 for
project: org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.3 from
the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:4 for
project: null:maven-javadoc-plugin:maven-plugin:2.2 from the repository.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] id can not be null
[INFO]
[DEBUG] Trace
java.lang.NullPointerException: id can not be null
at
org.apache.maven.wagon.repository.Repository.init(Repository.java:81)
at
org.apache.maven.artifact.repository.DefaultArtifactRepository.init(DefaultArtifactRepository.java:70)
at
org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:44)
at
org.apache.maven.project.ProjectUtils.buildDeploymentArtifactRepository(ProjectUtils.java:80)
at
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1038)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:880)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:255)
at
org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:270)
at
org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:198)
at
org.apache.maven.plugin.DefaultPluginManager.verifyReportPlugin(DefaultPluginManager.java:605)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyReportPlugin(DefaultLifecycleExecutor.java:1557)
at
[jira] Created: (MASSEMBLY-404) Different behavior on Linux and Windows
Different behavior on Linux and Windows --- Key: MASSEMBLY-404 URL: http://jira.codehaus.org/browse/MASSEMBLY-404 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Reporter: Julien HENRY Priority: Minor Attachments: test.zip Hi, The assembly created with the given test project produces different results depending on the OS. On Linux, the main JAR is present only once: htmlunit-XX.jar On Windows, this JAR is present 2 times in the ZIP: htmlunit-XX.jar htmlunit-XX.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-549) Generated source folder is not added as eclipse source folder (using xmlbeans)
Generated source folder is not added as eclipse source folder (using xmlbeans) -- Key: MECLIPSE-549 URL: http://jira.codehaus.org/browse/MECLIPSE-549 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.6 Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100) Java version: 1.6.0_12 Java home: C:\Program Files\Java\jdk1.6.0_12\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Julien HENRY Priority: Critical My build use xmlbeans to generate Java sources and .class from XSD. With previous version of the plugin it mostly worked (I only had a problem because .class generated by xmlbeans were overriden by Eclipse automatic recompilation). With latest plugin version, generated source folder is not added anymore to the eclipse classpath. I've tested with another build using the exec-maven-plugin with a sourceRoot element and this additional source is correctly added. So the problem may be specific to xmlbeans plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-549) Generated source folder is not added as eclipse source folder (using xmlbeans)
[ http://jira.codehaus.org/browse/MECLIPSE-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien HENRY closed MECLIPSE-549. - Resolution: Not A Bug After looking at xmlbeans-maven-plugin code I understand it is not an eclipse plugin bug. I've opened an issue on xmlbeans plugin side: http://jira.codehaus.org/browse/MXMLBEANS-54 Generated source folder is not added as eclipse source folder (using xmlbeans) -- Key: MECLIPSE-549 URL: http://jira.codehaus.org/browse/MECLIPSE-549 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.6 Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100) Java version: 1.6.0_12 Java home: C:\Program Files\Java\jdk1.6.0_12\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Julien HENRY Priority: Critical Attachments: test-eclipse-xmlbeans.zip My build use xmlbeans to generate Java sources and .class from XSD. With previous version of the plugin it mostly worked (I only had a problem because .class generated by xmlbeans were overriden by Eclipse automatic recompilation). With latest plugin version, generated source folder is not added anymore to the eclipse classpath. I've tested with another build using the exec-maven-plugin with a sourceRoot element and this additional source is correctly added. So the problem may be specific to xmlbeans plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-549) Generated source folder is not added as eclipse source folder (using xmlbeans)
[
http://jira.codehaus.org/browse/MECLIPSE-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien HENRY updated MECLIPSE-549:
--
Attachment: test-eclipse-xmlbeans.zip
This is a small test project to reproduce the issue.
Step to reproduce:
1) mvn clean install eclipse:clean
2) mvn eclipse:eclipse
I suspect the bug is not on the eclipse plugin side but instead on the xmlbeans
side. When step 1) is executed, xmlbeans generates sources in generated-source
folder. But when step 2 is executed, I can see:
{code}
[INFO] Preparing eclipse:eclipse
[INFO] [xmlbeans:xmlbeans {execution: default}]
[INFO] All schema objects are up to date.
[INFO] [eclipse:eclipse]
...
{code}
The All schema objects are up to date. makes me think that because sources
were already generated during step 1, xmlbeans doesn't generate them again, but
probably also forgot to register generated-source folder as a maven source
folder.
Generated source folder is not added as eclipse source folder (using xmlbeans)
--
Key: MECLIPSE-549
URL: http://jira.codehaus.org/browse/MECLIPSE-549
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.6
Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_12
Java home: C:\Program Files\Java\jdk1.6.0_12\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Julien HENRY
Priority: Critical
Attachments: test-eclipse-xmlbeans.zip
My build use xmlbeans to generate Java sources and .class from XSD.
With previous version of the plugin it mostly worked (I only had a problem
because .class generated by xmlbeans were overriden by Eclipse automatic
recompilation).
With latest plugin version, generated source folder is not added anymore to
the eclipse classpath.
I've tested with another build using the exec-maven-plugin with a
sourceRoot element and this additional source is correctly added. So the
problem may be specific to xmlbeans plugin.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-150) the dependency report ignores mirrors
[
http://jira.codehaus.org/browse/MPIR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171522#action_171522
]
Julien HENRY commented on MPIR-150:
---
I have the same problem.
I have a corporate archiva mirror for central:
{code}
mirror
idcentral/id
mirrorOfcentral/mirrorOf
nameCentral Mirror/name
urlhttp://pic-java-nce.sud.mycompany.fr:8090/archiva/repository/central/url
/mirror
{code}
And also 2 additional repos declared in my pom.xml:
{code}
repositories
!-- Repositories Corporate --
repository
idmycompany.corporate.release/id
namemycompany Corporate Release Repository/name
urlhttp://pic-java-nce.sud.mycompany.fr:8090/archiva/repository/mycompany.corporate.release/url
releases
enabledtrue/enabled
/releases
snapshots
enabledfalse/enabled
/snapshots
/repository
repository
idmycompany.local.release/id
namemycompany Local Release Repository/name
urlhttp://pic-java-nce.sud.mycompany.fr:8090/archiva/repository/release/url
releases
enabledtrue/enabled
/releases
snapshots
enabledfalse/enabled
/snapshots
/repository
/repositories
{code}
Running:
{code}
mvn
org.apache.maven.plugins:maven-project-info-reports-plugin:2.1.1:dependencies -X
{code}
Takes 3 minutes 37 seconds with lots of:
{code}
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://repo1.maven.org/maven/ - Session: Opened
http://repo1.maven.org/maven/ - Session: Disconnecting
http://repo1.maven.org/maven/ - Session: Disconnected
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://people.apache.org/repo/m2-incubating-repository/ - Session: Opened
http://people.apache.org/repo/m2-incubating-repository/ - Session: Disconnecting
http://people.apache.org/repo/m2-incubating-repository/ - Session: Disconnected
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://repository.codehaus.org - Session: Opened
http://repository.codehaus.org - Session: Disconnecting
http://repository.codehaus.org - Session: Disconnected
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://repo1.maven.org/eclipse - Session: Opened
http://repo1.maven.org/eclipse - Session: Disconnecting
http://repo1.maven.org/eclipse - Session: Disconnected
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://repo1.maven.org/maven2 - Session: Opened
http://repo1.maven.org/maven2 - Session: Disconnecting
http://repo1.maven.org/maven2 - Session: Disconnected
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://ws.zones.apache.org/repository2 - Session: Opened
http://ws.zones.apache.org/repository2 - Session: Disconnecting
http://ws.zones.apache.org/repository2 - Session: Disconnected
{code}
Very blocking for me because some projects that use a lot of additional
repositories have their build taking more than 1 hour instead of less than 2
minutes after disabling dependency report.
The only workaround for my IC platform is to lock down plugin version to 2.0.1.
If you need more debug informations, fell free to ask.
the dependency report ignores mirrors
-
Key: MPIR-150
URL: http://jira.codehaus.org/browse/MPIR-150
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 2.1.1
Reporter: Brian Fox
The dependencies report takes forever and running debug i can see it's
hitting the same repos over and over and bypassing my repository manager.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-85) excludeScope=test doesn't work
[ http://jira.codehaus.org/browse/MDEP-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171390#action_171390 ] Julien HENRY commented on MDEP-85: -- Same proble here. I want all scopes but test and non of the given choices do what I want. excludeScope=test doesn't work -- Key: MDEP-85 URL: http://jira.codehaus.org/browse/MDEP-85 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies Affects Versions: 2.0-alpha-4 Reporter: Dominique Jean-Prost Assignee: Brian Fox mvn dependency:copy-dependencies -DexcludeScope=test doesn't seem to work correctly : I get a [INFO] [dependency:copy-dependencies] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Can't exclude Test scope, this will exclude everything. [INFO] If I use mvn dependency:copy-dependencies -DincludeScope=provided, I do get only provided scope artifact, that is the test scope is exluded indeed. --- To my mind, excludeScope=test should work then. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-536) Unable to test staged release (pom is not downloaded)
[
http://jira.codehaus.org/browse/MECLIPSE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=170894#action_170894
]
Julien HENRY commented on MECLIPSE-536:
---
I don't understand why I have to tweak my corporate Archiva to be able to test
a staged release??? I have a direct internet connection, so no need for a
mirror.
BTW Maven is able to download the JAR, why not the pom?
Unable to test staged release (pom is not downloaded)
-
Key: MECLIPSE-536
URL: http://jira.codehaus.org/browse/MECLIPSE-536
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.6
Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_12
Java home: C:\Program Files\Java\jdk1.6.0_12\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Julien HENRY
I tried to use the staged 2.6 version but it seems the pom is not downloaded.
{code}
mvn -Pstaged-releases clean install eclipse:eclipse -cpu -X
+ Error stacktraces are turned on.
Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_12
Java home: C:\Program Files\Java\jdk1.6.0_12\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
[DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and
Settings\jhenry\.m2\plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'D:\apache-maven-2.1.0\bin\..\conf\plugin-registry.xml'
[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM:
com.X.itdemand:XX-itdemand:pom:1.0.2-SNAPSHOT of project:
null:XX-itdemand-webapp:war:null in relative path: ../pom.xml
[DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for
project: null:XXX-itdemand-webapp:war:null
[DEBUG] Adding managed dependencies for unknown:XXX-itdemand-webapp
[DEBUG] com.XXX.itdemand:XXX-itdemand-webapp:war:1.0.2-SNAPSHOT
[DEBUG] com..itdemand:XXX-itdemand-ear:ejb:1.0.2-SNAPSHOT
[DEBUG] Retrieving parent-POM: org.apache.maven.release:maven-release:pom:5
for project:
org.apache.maven.plugins:maven-release-plugin:maven-plugin:2.0-beta-8 from
the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:9 for
project: org.apache.maven.release:maven-release:pom:5 from the repository..
[DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project:
org..apache.maven:maven-parent:pom:9 from the repository.
[DEBUG] Adding managed dependencies for
org.apache.maven.plugins:maven-release-plugin
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.6
[DEBUG] maven-enforcer-plugin: resolved to version 1.0-alpha-3 from
repository central
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:8
for project:
org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0-alpha-3 from
the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:5 for
project: org.apache.maven.plugins:maven-plugins:pom:8 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache:pom:3 for project:
org.apache.maven:maven-parent:pom:5 from the repository.
[DEBUG] Retrieving parent-POM:
org.codehaus.mojo.hibernate3:maven-hibernate3:pom:2.2 for project:
org.codehaus.mojo:hibernate3-maven-plugin:maven-plugin:null from the
repository.
[DEBUG] Retrieving parent-POM: org.codehaus.mojo:mojo-parent:pom:20 for
project: org.codehaus.mojo.hibernate3:maven-hibernate3:pom:2.2 from the
repository.
[DEBUG] Adding managed dependencies for
org.codehaus.mojo:hibernate3-maven-plugin
[DEBUG] hsqldb:hsqldb:jar:1.8.0.7:test
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.6
[DEBUG] org.apache.maven:maven-project:jar:2.0.6
[DEBUG] org.apache.maven:maven-model:jar:2.0.6
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.6
[DEBUG] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.1
[DEBUG] org.hibernate:hibernate-core:jar:3.3.1.GA
[DEBUG] org.hibernate:ejb3-persistence:jar:1.0.2.GA
[DEBUG] org.hibernate:hibernate-entitymanager:jar:3.4.0.GA
[DEBUG] org.hibernate:hibernate-tools:jar:3.2.3..GA
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.6
[DEBUG] org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.1.1:runtime
[DEBUG] log4j:log4j:jar:1.2.14:runtime
[DEBUG] org.slf4j:slf4j-log4j12:jar:1.5.6:runtime
[DEBUG] org.slf4j:slf4j-api:jar:1.5.6:runtime
[DEBUG] org.slf4j:jcl-over-slf4j:jar:1.5.6:runtime
[DEBUG] junit:junit:jar:3.8.2:test
[DEBUG] cobertura-maven-plugin: resolved to version 2.2 from repository
central
[DEBUG] Retrieving parent-POM: org.codehaus.mojo:mojo:pom:16 for project:
null:cobertura-maven-plugin:maven-plugin:2.2 from the
[jira] Created: (MECLIPSE-536) Unable to test staged release (pom is not downloaded)
Unable to test staged release (pom is not downloaded)
-
Key: MECLIPSE-536
URL: http://jira.codehaus.org/browse/MECLIPSE-536
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.6
Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_12
Java home: C:\Program Files\Java\jdk1.6.0_12\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Julien HENRY
I tried to use the staged 2.6 version but it seems the pom is not downloaded.
{code}
mvn -Pstaged-releases clean install eclipse:eclipse -cpu -X
+ Error stacktraces are turned on.
Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_12
Java home: C:\Program Files\Java\jdk1.6.0_12\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
[DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and
Settings\jhenry\.m2\plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'D:\apache-maven-2.1.0\bin\..\conf\plugin-registry.xml'
[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM:
com.X.itdemand:XX-itdemand:pom:1.0.2-SNAPSHOT of project:
null:XX-itdemand-webapp:war:null in relative path: ../pom.xml
[DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for
project: null:XXX-itdemand-webapp:war:null
[DEBUG] Adding managed dependencies for unknown:XXX-itdemand-webapp
[DEBUG] com.XXX.itdemand:XXX-itdemand-webapp:war:1.0.2-SNAPSHOT
[DEBUG] com..itdemand:XXX-itdemand-ear:ejb:1.0.2-SNAPSHOT
[DEBUG] Retrieving parent-POM: org.apache.maven.release:maven-release:pom:5 for
project: org.apache.maven.plugins:maven-release-plugin:maven-plugin:2.0-beta-8
from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:9 for project:
org.apache.maven.release:maven-release:pom:5 from the repository..
[DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project:
org..apache.maven:maven-parent:pom:9 from the repository.
[DEBUG] Adding managed dependencies for
org.apache.maven.plugins:maven-release-plugin
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.6
[DEBUG] maven-enforcer-plugin: resolved to version 1.0-alpha-3 from repository
central
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:8 for
project:
org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0-alpha-3 from
the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:5 for project:
org.apache.maven.plugins:maven-plugins:pom:8 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache:pom:3 for project:
org.apache.maven:maven-parent:pom:5 from the repository.
[DEBUG] Retrieving parent-POM:
org.codehaus.mojo.hibernate3:maven-hibernate3:pom:2.2 for project:
org.codehaus.mojo:hibernate3-maven-plugin:maven-plugin:null from the repository.
[DEBUG] Retrieving parent-POM: org.codehaus.mojo:mojo-parent:pom:20 for
project: org.codehaus.mojo.hibernate3:maven-hibernate3:pom:2.2 from the
repository.
[DEBUG] Adding managed dependencies for
org.codehaus.mojo:hibernate3-maven-plugin
[DEBUG] hsqldb:hsqldb:jar:1.8.0.7:test
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.6
[DEBUG] org.apache.maven:maven-project:jar:2.0.6
[DEBUG] org.apache.maven:maven-model:jar:2.0.6
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.6
[DEBUG] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.1
[DEBUG] org.hibernate:hibernate-core:jar:3.3.1.GA
[DEBUG] org.hibernate:ejb3-persistence:jar:1.0.2.GA
[DEBUG] org.hibernate:hibernate-entitymanager:jar:3.4.0.GA
[DEBUG] org.hibernate:hibernate-tools:jar:3.2.3..GA
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.6
[DEBUG] org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.1.1:runtime
[DEBUG] log4j:log4j:jar:1.2.14:runtime
[DEBUG] org.slf4j:slf4j-log4j12:jar:1.5.6:runtime
[DEBUG] org.slf4j:slf4j-api:jar:1.5.6:runtime
[DEBUG] org.slf4j:jcl-over-slf4j:jar:1.5.6:runtime
[DEBUG] junit:junit:jar:3.8.2:test
[DEBUG] cobertura-maven-plugin: resolved to version 2.2 from repository central
[DEBUG] Retrieving parent-POM: org.codehaus.mojo:mojo:pom:16 for project:
null:cobertura-maven-plugin:maven-plugin:2.2 from the repository.
[DEBUG] Adding managed dependencies for unknown:cobertura-maven-plugin
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0
[DEBUG] junit:junit:jar:3.8.1:test
[DEBUG] Retrieving parent-POM: org.codehaus.mojo:mojo-parent:pom:18 for
project: null:xmlbeans-maven-plugin:maven-plugin:2.3.2 from the repository.
[DEBUG] Adding managed dependencies for unknown:xmlbeans-maven-plugin
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0
[DEBUG] junit:junit:jar:3.8.2:test
[INFO] Searching repository for plugin with prefix: 'eclipse'.
[DEBUG]
[jira] Commented: (MECLIPSE-536) Unable to test staged release (pom is not downloaded)
[
http://jira.codehaus.org/browse/MECLIPSE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=170824#action_170824
]
Julien HENRY commented on MECLIPSE-536:
---
In fact this one is the proxy of the central. It is normal that the 2.6 plugin
is not found.
I don't understand why it is not looking at the staged repo for the pom (only
for the jar)?
Here is a snippet of my settings.xml:
{code}
mirror
idcentral/id
mirrorOfcentral/mirrorOf
nameCentral Mirror on Nice/name
urlhttp://pic-java-nce.sud.capgemini.fr:8090/archiva/repository/central/url
/mirror
...
profile
idstaged-releases/id
pluginRepositories
pluginRepository
idstaged-releases/id
urlhttps://repository.apache.org/content/repositories/maven-staging-52acfb2f215fcf//url
/pluginRepository
/pluginRepositories
/profile
{code}
Unable to test staged release (pom is not downloaded)
-
Key: MECLIPSE-536
URL: http://jira.codehaus.org/browse/MECLIPSE-536
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.6
Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_12
Java home: C:\Program Files\Java\jdk1.6.0_12\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Julien HENRY
I tried to use the staged 2.6 version but it seems the pom is not downloaded.
{code}
mvn -Pstaged-releases clean install eclipse:eclipse -cpu -X
+ Error stacktraces are turned on.
Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_12
Java home: C:\Program Files\Java\jdk1.6.0_12\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
[DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and
Settings\jhenry\.m2\plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'D:\apache-maven-2.1.0\bin\..\conf\plugin-registry.xml'
[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM:
com.X.itdemand:XX-itdemand:pom:1.0.2-SNAPSHOT of project:
null:XX-itdemand-webapp:war:null in relative path: ../pom.xml
[DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for
project: null:XXX-itdemand-webapp:war:null
[DEBUG] Adding managed dependencies for unknown:XXX-itdemand-webapp
[DEBUG] com.XXX.itdemand:XXX-itdemand-webapp:war:1.0.2-SNAPSHOT
[DEBUG] com..itdemand:XXX-itdemand-ear:ejb:1.0.2-SNAPSHOT
[DEBUG] Retrieving parent-POM: org.apache.maven.release:maven-release:pom:5
for project:
org.apache.maven.plugins:maven-release-plugin:maven-plugin:2.0-beta-8 from
the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:9 for
project: org.apache.maven.release:maven-release:pom:5 from the repository..
[DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project:
org..apache.maven:maven-parent:pom:9 from the repository.
[DEBUG] Adding managed dependencies for
org.apache.maven.plugins:maven-release-plugin
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.6
[DEBUG] maven-enforcer-plugin: resolved to version 1.0-alpha-3 from
repository central
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:8
for project:
org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0-alpha-3 from
the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:5 for
project: org.apache.maven.plugins:maven-plugins:pom:8 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache:pom:3 for project:
org.apache.maven:maven-parent:pom:5 from the repository.
[DEBUG] Retrieving parent-POM:
org.codehaus.mojo.hibernate3:maven-hibernate3:pom:2.2 for project:
org.codehaus.mojo:hibernate3-maven-plugin:maven-plugin:null from the
repository.
[DEBUG] Retrieving parent-POM: org.codehaus.mojo:mojo-parent:pom:20 for
project: org.codehaus.mojo.hibernate3:maven-hibernate3:pom:2.2 from the
repository.
[DEBUG] Adding managed dependencies for
org.codehaus.mojo:hibernate3-maven-plugin
[DEBUG] hsqldb:hsqldb:jar:1.8.0.7:test
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.6
[DEBUG] org.apache.maven:maven-project:jar:2.0.6
[DEBUG] org.apache.maven:maven-model:jar:2.0.6
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.6
[DEBUG] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.1
[DEBUG] org.hibernate:hibernate-core:jar:3.3.1.GA
[DEBUG] org.hibernate:ejb3-persistence:jar:1.0.2.GA
[DEBUG] org.hibernate:hibernate-entitymanager:jar:3.4.0.GA
[DEBUG] org.hibernate:hibernate-tools:jar:3.2.3..GA
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.6
[DEBUG]
[jira] Commented: (MECLIPSE-536) Unable to test staged release (pom is not downloaded)
[
http://jira.codehaus.org/browse/MECLIPSE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=170832#action_170832
]
Julien HENRY commented on MECLIPSE-536:
---
I've added:
{code}
repositories
repository
idstaged-releases-repo/id
urlhttps://repository.apache.org/content/repositories/maven-staging-52acfb2f215fcf//url
/repository
/repositories
{code}
but still same issue even after cleaning local repo from any eclipse plugin.
Unable to test staged release (pom is not downloaded)
-
Key: MECLIPSE-536
URL: http://jira.codehaus.org/browse/MECLIPSE-536
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.6
Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_12
Java home: C:\Program Files\Java\jdk1.6.0_12\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Julien HENRY
I tried to use the staged 2.6 version but it seems the pom is not downloaded.
{code}
mvn -Pstaged-releases clean install eclipse:eclipse -cpu -X
+ Error stacktraces are turned on.
Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_12
Java home: C:\Program Files\Java\jdk1.6.0_12\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
[DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and
Settings\jhenry\.m2\plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'D:\apache-maven-2.1.0\bin\..\conf\plugin-registry.xml'
[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM:
com.X.itdemand:XX-itdemand:pom:1.0.2-SNAPSHOT of project:
null:XX-itdemand-webapp:war:null in relative path: ../pom.xml
[DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for
project: null:XXX-itdemand-webapp:war:null
[DEBUG] Adding managed dependencies for unknown:XXX-itdemand-webapp
[DEBUG] com.XXX.itdemand:XXX-itdemand-webapp:war:1.0.2-SNAPSHOT
[DEBUG] com..itdemand:XXX-itdemand-ear:ejb:1.0.2-SNAPSHOT
[DEBUG] Retrieving parent-POM: org.apache.maven.release:maven-release:pom:5
for project:
org.apache.maven.plugins:maven-release-plugin:maven-plugin:2.0-beta-8 from
the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:9 for
project: org.apache.maven.release:maven-release:pom:5 from the repository..
[DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project:
org..apache.maven:maven-parent:pom:9 from the repository.
[DEBUG] Adding managed dependencies for
org.apache.maven.plugins:maven-release-plugin
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.6
[DEBUG] maven-enforcer-plugin: resolved to version 1.0-alpha-3 from
repository central
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:8
for project:
org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0-alpha-3 from
the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:5 for
project: org.apache.maven.plugins:maven-plugins:pom:8 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache:pom:3 for project:
org.apache.maven:maven-parent:pom:5 from the repository.
[DEBUG] Retrieving parent-POM:
org.codehaus.mojo.hibernate3:maven-hibernate3:pom:2.2 for project:
org.codehaus.mojo:hibernate3-maven-plugin:maven-plugin:null from the
repository.
[DEBUG] Retrieving parent-POM: org.codehaus.mojo:mojo-parent:pom:20 for
project: org.codehaus.mojo.hibernate3:maven-hibernate3:pom:2.2 from the
repository.
[DEBUG] Adding managed dependencies for
org.codehaus.mojo:hibernate3-maven-plugin
[DEBUG] hsqldb:hsqldb:jar:1.8.0.7:test
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.6
[DEBUG] org.apache.maven:maven-project:jar:2.0.6
[DEBUG] org.apache.maven:maven-model:jar:2.0.6
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.6
[DEBUG] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.1
[DEBUG] org.hibernate:hibernate-core:jar:3.3.1.GA
[DEBUG] org.hibernate:ejb3-persistence:jar:1.0.2.GA
[DEBUG] org.hibernate:hibernate-entitymanager:jar:3.4.0.GA
[DEBUG] org.hibernate:hibernate-tools:jar:3.2.3..GA
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.6
[DEBUG] org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.1.1:runtime
[DEBUG] log4j:log4j:jar:1.2.14:runtime
[DEBUG] org.slf4j:slf4j-log4j12:jar:1.5.6:runtime
[DEBUG] org.slf4j:slf4j-api:jar:1.5.6:runtime
[DEBUG] org.slf4j:jcl-over-slf4j:jar:1.5.6:runtime
[DEBUG] junit:junit:jar:3.8.2:test
[DEBUG] cobertura-maven-plugin: resolved to version 2.2 from repository
central
[DEBUG] Retrieving parent-POM:
[jira] Created: (MECLIPSE-534) Tycho: IOException
Tycho: IOException
--
Key: MECLIPSE-534
URL: http://jira.codehaus.org/browse/MECLIPSE-534
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: PDE support
Environment: Maven version: 3.0-TYCHO-733848 built on unknown
Java version: 1.6.0_12
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 family: windows
Eclipse 3.4.1
Reporter: Julien HENRY
I'm testing latest build of Tycho and I get the following error:
{code}
mvn -X org.codehaus.tycho:maven-tycho-plugin:generate-poms
-DgroupId=tycho.demo -Dtycho.targetPlatform=d:\eclipse
+ Error stacktraces are turned on.
Maven version: 3.0-TYCHO-733848 built on unknown
Java version: 1.6.0_12
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 family: windows
[INFO] Build target platform tycho.targetPlatform=d:\eclipse
. This overrides target platform specified in pom.xml files, if any.
---
constituent[0]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../tycho/org.eclipse.osgi-3.4.0.v20080605-1900.jar
constituent[1]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../tycho/tycho-osgi-components-0.3.0-DEV-2146.jar
constituent[2]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/apache-maven-3.0-TYCHO-733848.jar
constituent[3]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/bcpg-jdk15-140.jar
constituent[4]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/bcprov-jdk15-140.jar
constituent[5]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/commons-cli-1.0.jar
constituent[6]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/commons-logging-api-1.1.jar
constituent[7]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/doxia-sink-api-1.0-alpha-9.jar
constituent[8]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/google-collect-snapshot-20080530.jar
constituent[9]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/jsch-0.1.38.jar
constituent[10]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/log4j-1.2.12.jar
constituent[11]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-compat-3.0-TYCHO-733848.jar
constituent[12]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-core-3.0-TYCHO-733848.jar
constituent[13]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-embedder-3.0-TYCHO-733848.jar
constituent[14]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-lifecycle-3.0-TYCHO-733848.jar
constituent[15]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-mercury-3.0-TYCHO-733848.jar
constituent[16]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-model-3.0-TYCHO-733848.jar
constituent[17]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-plugin-api-3.0-TYCHO-733848.jar
constituent[18]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-project-3.0-TYCHO-733848.jar
constituent[19]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-project-builder-3.0-TYCHO-733848.jar
constituent[20]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-reporting-api-3.0-TYCHO-733848.jar
constituent[21]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-toolchain-3.0-TYCHO-733848.jar
constituent[22]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-artifact-1.0.0-alpha-2.jar
constituent[23]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-crypto-api-1.0.0-alpha-2.jar
constituent[24]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-crypto-basic-1.0.0-alpha-2.jar
constituent[25]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-event-1.0.0-alpha-2.jar
constituent[26]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-external-1.0.0-alpha-2.jar
constituent[27]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-logging-1.0.0-alpha-2.jar
constituent[28]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-md-shared-1.0.0-alpha-2.jar
constituent[29]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-plexus-1.0.0-alpha-2.jar
constituent[30]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-repo-api-1.0.0-alpha-2.jar
constituent[31]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-repo-cache-fs-1.0.0-alpha-2.jar
constituent[32]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-repo-virtual-1.0.0-alpha-2.jar
constituent[33]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-transport-api-1.0.0-alpha-2.jar
constituent[34]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/model-builder-1.0.jar
constituent[35]:
[jira] Closed: (MECLIPSE-534) Tycho: IOException
[
http://jira.codehaus.org/browse/MECLIPSE-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien HENRY closed MECLIPSE-534.
-
Resolution: Won't Fix
Sorry, this is not the correct place for Tycho.
Tycho: IOException
--
Key: MECLIPSE-534
URL: http://jira.codehaus.org/browse/MECLIPSE-534
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: PDE support
Environment: Maven version: 3.0-TYCHO-733848 built on unknown
Java version: 1.6.0_12
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 family: windows
Eclipse 3.4.1
Reporter: Julien HENRY
I'm testing latest build of Tycho and I get the following error:
{code}
mvn -X org.codehaus.tycho:maven-tycho-plugin:generate-poms
-DgroupId=tycho.demo -Dtycho.targetPlatform=d:\eclipse
+ Error stacktraces are turned on.
Maven version: 3.0-TYCHO-733848 built on unknown
Java version: 1.6.0_12
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 family: windows
[INFO] Build target platform tycho.targetPlatform=d:\eclipse
. This overrides target platform specified in pom.xml files, if any.
---
constituent[0]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../tycho/org.eclipse.osgi-3.4.0.v20080605-1900.jar
constituent[1]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../tycho/tycho-osgi-components-0.3.0-DEV-2146.jar
constituent[2]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/apache-maven-3.0-TYCHO-733848.jar
constituent[3]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/bcpg-jdk15-140.jar
constituent[4]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/bcprov-jdk15-140.jar
constituent[5]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/commons-cli-1.0.jar
constituent[6]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/commons-logging-api-1.1.jar
constituent[7]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/doxia-sink-api-1.0-alpha-9.jar
constituent[8]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/google-collect-snapshot-20080530.jar
constituent[9]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/jsch-0.1.38.jar
constituent[10]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/log4j-1.2.12.jar
constituent[11]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-compat-3.0-TYCHO-733848.jar
constituent[12]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-core-3.0-TYCHO-733848.jar
constituent[13]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-embedder-3.0-TYCHO-733848.jar
constituent[14]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-lifecycle-3.0-TYCHO-733848.jar
constituent[15]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-mercury-3.0-TYCHO-733848.jar
constituent[16]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-model-3.0-TYCHO-733848.jar
constituent[17]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-plugin-api-3.0-TYCHO-733848.jar
constituent[18]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-project-3.0-TYCHO-733848.jar
constituent[19]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-project-builder-3.0-TYCHO-733848.jar
constituent[20]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-reporting-api-3.0-TYCHO-733848.jar
constituent[21]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/maven-toolchain-3.0-TYCHO-733848.jar
constituent[22]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-artifact-1.0.0-alpha-2.jar
constituent[23]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-crypto-api-1.0.0-alpha-2.jar
constituent[24]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-crypto-basic-1.0.0-alpha-2.jar
constituent[25]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-event-1.0.0-alpha-2.jar
constituent[26]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-external-1.0.0-alpha-2.jar
constituent[27]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-logging-1.0.0-alpha-2.jar
constituent[28]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-md-shared-1.0.0-alpha-2.jar
constituent[29]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-plexus-1.0.0-alpha-2.jar
constituent[30]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-repo-api-1.0.0-alpha-2.jar
constituent[31]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/mercury-repo-cache-fs-1.0.0-alpha-2.jar
constituent[32]:
[jira] Reopened: (MNG-4079) Duplicate error messages
[ http://jira.codehaus.org/browse/MNG-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien HENRY reopened MNG-4079: --- Duplicate error messages Key: MNG-4079 URL: http://jira.codehaus.org/browse/MNG-4079 Project: Maven 2 Issue Type: Bug Affects Versions: 2.1.0 Environment: Apache Maven 2.1.0 (r751709; 2009-03-09 16:35:14+0100) Java version: 1.4.2_17 Java home: C:\j2sdk1.4.2_17\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Julien HENRY Assignee: John Casey Priority: Minor Fix For: 2.1.0 Attachments: output.txt Very often with Maven the error messages are duplicated. For example deprecation warnings and compilation issues. I've attached an example with -e option. In my case I'm trying to build a project that requires JDK 1.5+ with JDK 1.4. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4079) Duplicate error messages
[ http://jira.codehaus.org/browse/MNG-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=169083#action_169083 ] Julien HENRY commented on MNG-4079: --- Hi John, Is it supposed to be fixed in RC2? I see no change with my test: mvn -v Apache Maven 2.1.0-RC2 (r752688; 2009-03-12 00:26:25+0100) Java version: 1.4.2_17 Java home: C:\j2sdk1.4.2_17\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Duplicate error messages Key: MNG-4079 URL: http://jira.codehaus.org/browse/MNG-4079 Project: Maven 2 Issue Type: Bug Affects Versions: 2.1.0 Environment: Apache Maven 2.1.0 (r751709; 2009-03-09 16:35:14+0100) Java version: 1.4.2_17 Java home: C:\j2sdk1.4.2_17\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Julien HENRY Assignee: John Casey Priority: Minor Fix For: 2.1.0 Attachments: output.txt Very often with Maven the error messages are duplicated. For example deprecation warnings and compilation issues. I've attached an example with -e option. In my case I'm trying to build a project that requires JDK 1.5+ with JDK 1.4. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4079) Duplicate error messages
Duplicate error messages Key: MNG-4079 URL: http://jira.codehaus.org/browse/MNG-4079 Project: Maven 2 Issue Type: Bug Affects Versions: 2.1.0-RC1 Environment: Apache Maven 2.1.0 (r751709; 2009-03-09 16:35:14+0100) Java version: 1.4.2_17 Java home: C:\j2sdk1.4.2_17\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Julien HENRY Priority: Minor Attachments: output.txt Very often with Maven the error messages are duplicated. For example deprecation warnings and compilation issues. I've attached an example with -e option. In my case I'm trying to build a project that requires JDK 1.5+ with JDK 1.4. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2346) Upload appframework and swinghelper-debug
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163972#action_163972 ] Julien HENRY commented on MAVENUPLOAD-2346: --- Could you please join the Javadoc and the sources for appframework. Thanks Upload appframework and swinghelper-debug - Key: MAVENUPLOAD-2346 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2346 Project: Maven Upload Requests Issue Type: Wish Reporter: Alexandre Navarro Attachments: appframework-1.03-bundle.jar, swinghelper-debug-1.0-bundle.jar Alexandre Navarro a contributor of theses 2 projects, contributor on fest and developer on JavaBuilder and SwingJavaBuilder where we need theses jars. Alexander Potochkin and Hans Muller (https://swinghelper.dev.java.net/ and https://appframework.dev.java.net/), main developers on theses 2 projects. Thanks, upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MAVENUPLOAD-2346) Upload appframework and swinghelper-debug
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163972#action_163972 ] Julien HENRY edited comment on MAVENUPLOAD-2346 at 2/4/09 1:47 PM: --- Could you please join the Javadoc and the sources for appframework. Also I get the following exception when using this class (JDK 1.6): java.lang.ClassNotFoundException: org.jdesktop.swingworker.SwingWorker I know there is a SwingWorker since JDK 1.6 but if you are using an other one, you should add it as a dependency in your pom and ask to upload it also. Thanks was (Author: henryju): Could you please join the Javadoc and the sources for appframework. Thanks Upload appframework and swinghelper-debug - Key: MAVENUPLOAD-2346 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2346 Project: Maven Upload Requests Issue Type: Wish Reporter: Alexandre Navarro Attachments: appframework-1.03-bundle.jar, swinghelper-debug-1.0-bundle.jar Alexandre Navarro a contributor of theses 2 projects, contributor on fest and developer on JavaBuilder and SwingJavaBuilder where we need theses jars. Alexander Potochkin and Hans Muller (https://swinghelper.dev.java.net/ and https://appframework.dev.java.net/), main developers on theses 2 projects. Thanks, upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3991) POM validator allows scopeoptional/scope but it is not valid.
POM validator allows scopeoptional/scope but it is not valid.
-
Key: MNG-3991
URL: http://jira.codehaus.org/browse/MNG-3991
Project: Maven 2
Issue Type: Bug
Components: POM
Reporter: Julien HENRY
Priority: Minor
In my project I did a mistake and I wrote
{code}
dependency
groupIdorg.slf4j/groupId
artifactIdslf4j-log4j12/artifactId
version1.5.0/version
scopeoptional/scope
/dependency
{code}
but in fact I intended to write
{code}
dependency
groupIdorg.slf4j/groupId
artifactIdslf4j-log4j12/artifactId
version1.5.0/version
optionaltrue/optional
/dependency
{code}
I'm very surprised that Maven doesn't detect such a mistake during the validate
phase. Could it be possible to add a check to allow only valid scopes.
Thanks
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-181) Javadoc report not generated for multi-module project if run from parent level.
[ http://jira.codehaus.org/browse/MJAVADOC-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=153658#action_153658 ] Julien HENRY commented on MJAVADOC-181: --- It is a blocker issue for me. I can't use the old way because my generated source files are not taken into account. The new way is working when running mvn javadoc:aggregate but not when running mvn site. Please apply the patch and release a new version! Javadoc report not generated for multi-module project if run from parent level. --- Key: MJAVADOC-181 URL: http://jira.codehaus.org/browse/MJAVADOC-181 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Environment: W2K, JDK 6u5, Maven 2.0.8 Reporter: André Fügenschuh Attachments: maven-site-javadoc-testcase.zip, MJAVADOC-181-1.patch, MJAVADOC-181.patch For the following project design (s. attached testcase): parent \- library// javadoc:aggregate! \- module-a \- module-b \- application javadoc report for 'library' is *not* generated (not invoked), if 'mvn site' is called at 'parent' level (but is properly done if run at 'library' level itself). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3687) Invalid links on Maven web site (Continuous Integration)
Invalid links on Maven web site (Continuous Integration) Key: MNG-3687 URL: http://jira.codehaus.org/browse/MNG-3687 Project: Maven 2 Issue Type: Bug Components: Documentation: General Reporter: Julien HENRY On this page: http://maven.apache.org/integration.html The two links are invalid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3678) Maven downloads from snapshot repos even when no snapshot repository is in the pom
[ http://jira.codehaus.org/browse/MNG-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=143214#action_143214 ] Julien HENRY commented on MNG-3678: --- I understand the concept but I think it is an error that some released plugins or dependencies (especially Maven default one) are still referencing a snapshot repository. Also I thought Ibilio policy was to be self-containing. So I think no external repository should be allowed in pom.xml in Ibiblio. Maven downloads from snapshot repos even when no snapshot repository is in the pom -- Key: MNG-3678 URL: http://jira.codehaus.org/browse/MNG-3678 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Environment: Win XP Reporter: Julien HENRY Fix For: 2.0.11 Attachments: pom.xml, stack.txt Easy to reproduce. Start with an empty local repository (rename ~/.m2/repository) and use a very simple pom.xml. The tips is to use a pom project instead of a jar project. Now run mvn clean install. In the log, you will see: ... Downloading: http://snapshots.repository.codehaus.org/org/mortbay/jetty/servlet-api-2.5/6.1.5/servlet-api-2.5-6.1.5.jar Downloading: http://people.apache.org/repo/m2-snapshot-repository//org/mortbay/jetty/servlet-api-2.5/6.1.5/servlet-api-2.5-6.1.5.jar ... I think there are some repository sections in some pom.xml on Ibiblio that still contain snapshot repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3678) Maven downloads from snapshot repos even when no snapshot repository is in the pom
Maven downloads from snapshot repos even when no snapshot repository is in the pom -- Key: MNG-3678 URL: http://jira.codehaus.org/browse/MNG-3678 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Environment: Win XP Reporter: Julien HENRY Attachments: pom.xml, stack.txt Easy to reproduce. Start with an empty local repository (rename ~/.m2/repository) and use a very simple pom.xml. The tips is to use a pom project instead of a jar project. Now run mvn clean install. In the log, you will see: ... Downloading: http://snapshots.repository.codehaus.org/org/mortbay/jetty/servlet-api-2.5/6.1.5/servlet-api-2.5-6.1.5.jar Downloading: http://people.apache.org/repo/m2-snapshot-repository//org/mortbay/jetty/servlet-api-2.5/6.1.5/servlet-api-2.5-6.1.5.jar ... I think there are some repository sections in some pom.xml on Ibiblio that still contain snapshot repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-229) AbstractMethodError when deploying with Continuum
[ http://jira.codehaus.org/browse/WAGON-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=142708#action_142708 ] Julien HENRY commented on WAGON-229: OK, thanks for the information. I will try to migrate to Maven 2.0.9. AbstractMethodError when deploying with Continuum - Key: WAGON-229 URL: http://jira.codehaus.org/browse/WAGON-229 Project: Maven Wagon Issue Type: Bug Components: wagon-webdav Affects Versions: 1.0-beta-3 Environment: Continuum 1.1-alpha-2 Reporter: Julien HENRY I try to deploy my parent pom.xml with Continuum. I'm using Maven 2.0.7 and I added a build extension in the pom : wagon-webdav-jackrabbit:1.0-beta-3 [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-deploy-plugin:2.3:deploy' -- [DEBUG] (f) artifact = com.mycompany:parent:pom:1.1.0-SNAPSHOT [DEBUG] (f) attachedArtifacts = [] [DEBUG] (f) deploymentRepository = [mycompany.corporate.snapshots] - dav:http://archiva-bu.mycompany.fr:8090/archiva/repository/mycompany.corporate.snapshots [DEBUG] (s) localRepository = [local] - file:///home/continuum/.m2/repository [DEBUG] (f) packaging = pom [DEBUG] (f) pomFile = /var/lib/continuum/working-directory/66/pom.xml [DEBUG] (f) updateReleaseInfo = false [DEBUG] -- end configuration -- [INFO] [deploy:deploy] altDeploymentRepository = null [INFO] Retrieving previous build number from mycompany.corporate.snapshots [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [DEBUG] Trace java.lang.AbstractMethodError at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:235) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:152) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 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:280) 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-229) AbstractMethodError when deploying with Continuum
[ http://jira.codehaus.org/browse/WAGON-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=142711#action_142711 ] Julien HENRY commented on WAGON-229: Here is the full story: First my build failed with: [INFO] [deploy:deploy] altDeploymentRepository = null [INFO] Retrieving previous build number from mycompany.corporate.snapshots [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagondav. So I added the wagon-webdav:1.0-beta-2 to my pom. Then I got: [INFO] [deploy:deploy] altDeploymentRepository = null [INFO] Retrieving previous build number from mycompany.corporate.snapshots Uploading: http://archiva-bu.mycompany.fr:8090/archiva/repository/mycompany.corporate.snapshots/com/mycompany/parent/1.1.0-SNAPSHOT/parent-1.1.0-20080721.132243-3.pom 21 juil. 2008 15:22:44 org.apache.commons.httpclient.HttpMethodBase processAuthenticationResponse INFO: Already tried to authenticate with 'Repository Repository mycompany Snapshots' authentication realm at archiva-bu.mycompany.fr, but still receiving: HTTP/1.1 401 User+Credentials+Invalid 21 juil. 2008 15:22:44 org.apache.commons.httpclient.HttpMethodBase processAuthenticationResponse INFO: Already tried to authenticate with 'Repository Repository mycompany Snapshots' authentication realm at archiva-bu.mycompany, but still receiving: HTTP/1.1 401 User+Credentials+Invalid 21 juil. 2008 15:22:44 org.apache.commons.httpclient.HttpMethodBase processAuthenticationResponse INFO: Already tried to authenticate with 'Repository Repository mycompany Snapshots' authentication realm at archiva-bu.mycompany.fr, but still receiving: HTTP/1.1 401 User+Credentials+Invalid 21 juil. 2008 15:22:44 org.apache.commons.httpclient.HttpMethodBase processAuthenticationResponse INFO: Already tried to authenticate with 'Repository Repository mycompany Snapshots' authentication realm at archiva-bu.mycompany.fr, but still receiving: HTTP/1.1 401 User+Credentials+Invalid 21 juil. 2008 15:22:45 org.apache.commons.httpclient.HttpMethodBase processAuthenticationResponse INFO: Already tried to authenticate with 'Repository Repository mycompany Snapshots' authentication realm at archiva-bu.mycompany.fr, but still receiving: HTTP/1.1 401 User+account+is+locked 21 juil. 2008 15:22:45 org.apache.commons.httpclient.HttpMethodBase processRequest INFO: Recoverable exception caught when processing request 21 juil. 2008 15:22:45 org.apache.commons.httpclient.HttpMethodBase processRequest ATTENTION: Recoverable exception caught but MethodRetryHandler.retryMethod() returned false, rethrowing exception [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Failed to create destination WebDAV collection (directory): /archiva/repository/mycompany.corporate.snapshots/com/capgemini/sud/parent/1.1.0-SNAPSHOT java.net.SocketException: Connection reset So I decided to try to update to latest available wagon. But now I read the log carefully I think there is an authentification issue. AbstractMethodError when deploying with Continuum - Key: WAGON-229 URL: http://jira.codehaus.org/browse/WAGON-229 Project: Maven Wagon Issue Type: Bug Components: wagon-webdav Affects Versions: 1.0-beta-3 Environment: Continuum 1.1-alpha-2 Reporter: Julien HENRY I try to deploy my parent pom.xml with Continuum. I'm using Maven 2.0.7 and I added a build extension in the pom : wagon-webdav-jackrabbit:1.0-beta-3 [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-deploy-plugin:2.3:deploy' -- [DEBUG] (f) artifact = com.mycompany:parent:pom:1.1.0-SNAPSHOT [DEBUG] (f) attachedArtifacts = [] [DEBUG] (f) deploymentRepository = [mycompany.corporate.snapshots] - dav:http://archiva-bu.mycompany.fr:8090/archiva/repository/mycompany.corporate.snapshots [DEBUG] (s) localRepository = [local] - file:///home/continuum/.m2/repository [DEBUG] (f) packaging = pom [DEBUG] (f) pomFile = /var/lib/continuum/working-directory/66/pom.xml [DEBUG] (f) updateReleaseInfo = false [DEBUG] -- end configuration -- [INFO] [deploy:deploy] altDeploymentRepository = null [INFO] Retrieving previous build number from mycompany.corporate.snapshots [INFO] [ERROR] FATAL ERROR [INFO]
[jira] Created: (WAGON-229) AbstractMethodError when deploying with Continuum
AbstractMethodError when deploying with Continuum - Key: WAGON-229 URL: http://jira.codehaus.org/browse/WAGON-229 Project: Maven Wagon Issue Type: Bug Components: wagon-webdav Affects Versions: 1.0-beta-3 Environment: Continuum 1.1-alpha-2 Reporter: Julien HENRY I try to deploy my parent pom.xml with Continuum. I'm using Maven 2.0.7 and I added a build extension in the pom : wagon-webdav-jackrabbit:1.0-beta-3 [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-deploy-plugin:2.3:deploy' -- [DEBUG] (f) artifact = com.mycompany:parent:pom:1.1.0-SNAPSHOT [DEBUG] (f) attachedArtifacts = [] [DEBUG] (f) deploymentRepository = [mycompany.corporate.snapshots] - dav:http://archiva-bu.mycompany.fr:8090/archiva/repository/mycompany.corporate.snapshots [DEBUG] (s) localRepository = [local] - file:///home/continuum/.m2/repository [DEBUG] (f) packaging = pom [DEBUG] (f) pomFile = /var/lib/continuum/working-directory/66/pom.xml [DEBUG] (f) updateReleaseInfo = false [DEBUG] -- end configuration -- [INFO] [deploy:deploy] altDeploymentRepository = null [INFO] Retrieving previous build number from mycompany.corporate.snapshots [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [DEBUG] Trace java.lang.AbstractMethodError at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:235) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:152) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 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:280) 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-35) Generate id for modules in application.xml
[
http://jira.codehaus.org/browse/MEAR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133100#action_133100
]
Julien HENRY commented on MEAR-35:
--
I'm new to EAR and WebSphere but it seems I will need an ID on the application
tag also. Here is an existing application.xml used by the old Ant build:
{code:xml}
?xml version=1.0 encoding=ISO-8859-15?
!DOCTYPE application PUBLIC -//Sun Microsystems, Inc.//DTD J2EE Application
1.3//EN http://java.sun.com/dtd/application_1_3.dtd;
application id=Application_ID
display-nameMyApp/display-name
module id=WebModule_1102675755495
web
web-uriapp.war/web-uri
context-root/app/context-root
/web
/module
security-role id=SecurityRole_1102689931785
description/description
role-nameappuser/role-name
/security-role
/application
{code}
Generate id for modules in application.xml
--
Key: MEAR-35
URL: http://jira.codehaus.org/browse/MEAR-35
Project: Maven 2.x Ear Plugin
Issue Type: Improvement
Reporter: Manikandan Balasubramanian
Priority: Minor
Fix For: 2.3.2
Attachments: ear-module-id.patch, MEAR-35-maven-ear-plugin-2.patch,
MEAR-35-maven-ear-plugin.patch
When the ear plugin generates application.xml, it should generate an id
with each module. This id is according to application.xml schema.
This would help eclipse plugin to generate correct eclipse metedata.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGSITE-44) Wrong informations in Guide to Working with Manifests
Wrong informations in Guide to Working with Manifests - Key: MNGSITE-44 URL: http://jira.codehaus.org/browse/MNGSITE-44 Project: Maven 2 Project Web Site Issue Type: Bug Environment: Windows XP Jar plugin 2.2 Reporter: Julien HENRY Priority: Minor Hi, In the guide, it is said that you should add manifest mainClasscom.mycompany.app.App/mainClass ... to have your JAR running fine. But for me it was wrong. I had to add: manifest Main-Classcom.mycompany.app.App/Main-Class -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1887) Upload HtmlUnit-1.14
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120668 ] Julien HENRY commented on MAVENUPLOAD-1887: --- You're right. Sorry for the bad example. Only stay the last point: clover2 plugin. Should HtmlUnit project doesn't use it because it is not on ibiblio? Thanks Upload HtmlUnit-1.14 Key: MAVENUPLOAD-1887 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1887 Project: maven-upload-requests Issue Type: Task Reporter: Marc Guillemot http://htmlunit.sourceforge.net/tmp/htmlunit-1.14-bundle.jar http://htmlunit.sourceforge.net/ http://htmlunit.sourceforge.net/team-list.html I'm a developer of HtmlUnit, please upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1887) Upload HtmlUnit-1.14
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120597 ] Julien HENRY commented on MAVENUPLOAD-1887: --- OK. This mean you can't release on ibiblio a software that is using Codehaus reporting plugin? In the case of HtmlUnit, there is also Clover2 maven plugin that is hosted on Atlassian servers. Could you please explain what is the best practice in this case? (AFAIR, some maven plugin are using codehaus dependencies, right?) Regards Upload HtmlUnit-1.14 Key: MAVENUPLOAD-1887 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1887 Project: maven-upload-requests Issue Type: Task Reporter: Marc Guillemot http://htmlunit.sourceforge.net/tmp/htmlunit-1.14-bundle.jar http://htmlunit.sourceforge.net/ http://htmlunit.sourceforge.net/team-list.html I'm a developer of HtmlUnit, please upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MAVENUPLOAD-1887) Upload HtmlUnit-1.14
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120597 ] henryju edited comment on MAVENUPLOAD-1887 at 1/19/08 1:10 PM: OK. This mean you can't release on ibiblio a software that is using for instance some Codehaus reporting plugin? In the case of HtmlUnit, there is also Clover2 maven plugin that is hosted on Atlassian servers. Could you please explain what is the best practice in this case (remove plugin? use a different pom for the release than the one usually used)? (AFAIR, some maven plugin are using codehaus dependencies) Regards was (Author: henryju): OK. This mean you can't release on ibiblio a software that is using Codehaus reporting plugin? In the case of HtmlUnit, there is also Clover2 maven plugin that is hosted on Atlassian servers. Could you please explain what is the best practice in this case? (AFAIR, some maven plugin are using codehaus dependencies, right?) Regards Upload HtmlUnit-1.14 Key: MAVENUPLOAD-1887 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1887 Project: maven-upload-requests Issue Type: Task Reporter: Marc Guillemot http://htmlunit.sourceforge.net/tmp/htmlunit-1.14-bundle.jar http://htmlunit.sourceforge.net/ http://htmlunit.sourceforge.net/team-list.html I'm a developer of HtmlUnit, please upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1887) Upload HtmlUnit-1.14
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120448 ] Julien HENRY commented on MAVENUPLOAD-1887: --- Hi Carlos, Just to know: why should the pluginRepositories section be removed? Regards Upload HtmlUnit-1.14 Key: MAVENUPLOAD-1887 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1887 Project: maven-upload-requests Issue Type: Task Reporter: Marc Guillemot http://htmlunit.sourceforge.net/tmp/htmlunit-1.14-bundle.jar http://htmlunit.sourceforge.net/ http://htmlunit.sourceforge.net/team-list.html I'm a developer of HtmlUnit, please upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1817) Upload JFreeChart 1.0.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114008 ] Julien HENRY commented on MAVENUPLOAD-1817: --- Thanks. Upload JFreeChart 1.0.7 --- Key: MAVENUPLOAD-1817 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1817 Project: maven-upload-requests Issue Type: Task Reporter: Julien HENRY Assignee: Carlos Sanchez Attachments: jcommon-1.0.12-bundle.jar, jfreechart-1.0.7-bundle.jar Bundles here: http://www.artofsolving.com/files/m2/jcommon-1.0.9-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-1.0.5-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-experimental-1.0.5-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-swt-1.0.5-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-1817) Upload JFreeChart 1.0.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien HENRY updated MAVENUPLOAD-1817: -- Attachment: jcommon-1.0.12-bundle.jar JCommon 1.0.12 Upload JFreeChart 1.0.7 --- Key: MAVENUPLOAD-1817 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1817 Project: maven-upload-requests Issue Type: Task Reporter: Julien HENRY Assignee: Carlos Sanchez Attachments: jcommon-1.0.12-bundle.jar Bundles here: http://www.artofsolving.com/files/m2/jcommon-1.0.9-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-1.0.5-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-experimental-1.0.5-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-swt-1.0.5-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-1817) Upload JFreeChart 1.0.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien HENRY updated MAVENUPLOAD-1817: -- Attachment: jfreechart-1.0.7-bundle.jar JFreechart 1.0.7 Upload JFreeChart 1.0.7 --- Key: MAVENUPLOAD-1817 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1817 Project: maven-upload-requests Issue Type: Task Reporter: Julien HENRY Assignee: Carlos Sanchez Attachments: jcommon-1.0.12-bundle.jar, jfreechart-1.0.7-bundle.jar Bundles here: http://www.artofsolving.com/files/m2/jcommon-1.0.9-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-1.0.5-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-experimental-1.0.5-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-swt-1.0.5-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1817) Upload JFreeChart 1.0.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113906 ] Julien HENRY commented on MAVENUPLOAD-1817: --- Hi, Please find upload bundle for JFreechart 1.0.7. I'm not a developer. See the thread here: http://www.jfree.org/phpBB2/viewtopic.php?p=65746 And sorry for the bad description: I have cloned a previous issue thinking I could then change the content. Upload JFreeChart 1.0.7 --- Key: MAVENUPLOAD-1817 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1817 Project: maven-upload-requests Issue Type: Task Reporter: Julien HENRY Assignee: Carlos Sanchez Attachments: jcommon-1.0.12-bundle.jar, jfreechart-1.0.7-bundle.jar Bundles here: http://www.artofsolving.com/files/m2/jcommon-1.0.9-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-1.0.5-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-experimental-1.0.5-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-swt-1.0.5-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1817) Upload JFreeChart 1.0.7
Upload JFreeChart 1.0.7 --- Key: MAVENUPLOAD-1817 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1817 Project: maven-upload-requests Issue Type: Task Reporter: Julien HENRY Assignee: Carlos Sanchez Bundles here: http://www.artofsolving.com/files/m2/jcommon-1.0.9-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-1.0.5-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-experimental-1.0.5-bundle.jar http://www.artofsolving.com/files/m2/jfreechart-swt-1.0.5-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3171) performRelease=true breaks install/deploy with multimodule projects
performRelease=true breaks install/deploy with multimodule projects
---
Key: MNG-3171
URL: http://jira.codehaus.org/browse/MNG-3171
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.7
Reporter: Julien HENRY
Attachments: unTest.zip
Hi,
To build my project, I use:
mvn clean install -DperformRelease=true
In a multimodule project, it doesn't work if all dependencies are not already
in the local repository.
Step to reproduce:
1) create a multimodule project with moduleA and moduleB. moduleA depends on
moduleB.
2) Hit mvn clean install: should work
3) Clean your local repository (remove moduleA and moduleB)
4) Hit mvn clean install -DperformRelease=true:
{quote}
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
[INFO] Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
[INFO] Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
[INFO]
[INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory D:\test\unTest\target
[INFO] Deleting directory D:\test\unTest\target\classes
[INFO] Deleting directory D:\test\unTest\target\test-classes
[INFO] Deleting directory D:\test\unTest\target\site
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] Preparing javadoc:jar
[INFO]
[INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
[INFO]
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO]
[INFO] Building Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
[INFO]
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO]
[INFO] Building Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
[INFO]
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO] snapshot com.capgemini:moduleB:1.0-SNAPSHOT: checking for updates from
illiade-maven-repository-snapshots
Downloading:
http://illiade.sud.capgemini.fr/maven2-snapshots/com/capgemini/moduleB/1.0-SNAPSHOT/moduleB-1.0-SNAPSHOT.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) com.capgemini:moduleB:jar:1.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.capgemini -DartifactId=moduleB \
-Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) com.capgemini:moduleA:jar:1.0-SNAPSHOT
2) com.capgemini:moduleB:jar:1.0-SNAPSHOT
--
1 required artifact is missing.
for artifact:
com.capgemini:moduleA:jar:1.0-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
illiade-maven-repository-snapshots
(http://illiade.sud.capgemini.fr/maven2-snapshots)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Fri Aug 31 12:08:24 CEST 2007
[INFO] Final Memory: 6M/254M
[INFO]
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1668) HtmlUnit 1.12 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104983 ] Julien HENRY commented on MAVENUPLOAD-1668: --- There is no POM on Ibiblio... HtmlUnit 1.12 upload request Key: MAVENUPLOAD-1668 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1668 Project: maven-upload-requests Issue Type: Task Reporter: Marc Guillemot Assignee: Carlos Sanchez http://htmlunit.sourceforge.net/htmlunit-1.12-bundle.jar Team members, including myself: http://htmlunit.sourceforge.net/team-list.html http://sourceforge.net/project/memberlist.php?group_id=47038 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGONFTP-7) site:deploy (deploying with FTP) Wagon protocol 'ftp' doesn't support directory copying
[ http://jira.codehaus.org/browse/WAGONFTP-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100856 ] Julien HENRY commented on WAGONFTP-7: - Please release a new version, because the bug is still there in 1.0-beta-2. site:deploy (deploying with FTP) Wagon protocol 'ftp' doesn't support directory copying Key: WAGONFTP-7 URL: http://jira.codehaus.org/browse/WAGONFTP-7 Project: wagon-ftp Issue Type: Improvement Affects Versions: 1.0-alpha-4 Environment: windows Reporter: pinghe Assignee: Carlos Sanchez Fix For: 1.0 Attachments: putDirectory-impl.patch, putDirectory-impl.patch Wagon protocol 'ftp' doesn't support directory copying -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPNATIVE-21) JDK version mismatch
JDK version mismatch Key: MPNATIVE-21 URL: http://jira.codehaus.org/browse/MPNATIVE-21 Project: maven-native-plugin Issue Type: Bug Affects Versions: 1.2.1 Environment: Windows XP JDK 1.4 Reporter: Julien HENRY Hi, I'm trying to use latest SNAPSHOT of native-maven-plugin (1.0-alpha-3-SNAPSHOT), and I get the following error : [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.codehaus.mojo:native-maven-plugin:1.0-alpha-3-SNAPSHOT:initialize': Unable to find the mojo 'org.codehaus.mojo:native-maven-plugin:1.0-alpha-3-SNAPSHOT:initialize' in the plugin 'org.codehaus.mojo:native-maven-plugin' org/codehaus/mojo/natives/plugin/NativeInitializeMojo (Unsupported major.minor version 49.0) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLOVER-37) clover does not work with site:run
[ http://jira.codehaus.org/browse/MCLOVER-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91684 ] Julien HENRY commented on MCLOVER-37: - Can you please give me the link to the related maven-site-plugin issue? I still have the problem with site:stage. clover does not work with site:run -- Key: MCLOVER-37 URL: http://jira.codehaus.org/browse/MCLOVER-37 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: John Allen Assigned To: Vincent Massol Priority: Minor Don't know if this is by design or a known issue and it's probably a big ask but i thought i'd mention it -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-180) Rewritten poms loose comments
[ http://jira.codehaus.org/browse/MRELEASE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85869 ] Julien HENRY commented on MRELEASE-180: --- I can confirm this bug. Rewritten poms loose comments -- Key: MRELEASE-180 URL: http://jira.codehaus.org/browse/MRELEASE-180 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Reporter: Guillaume Nodet When releasing ServiceMix, the following file was used before running the release plugin: http://svn.apache.org/viewvc/incubator/servicemix/branches/servicemix-3.0/pom.xml?revision=470027view=markup But when actually releasing, the modified pom has lost the comments: http://svn.apache.org/viewvc/incubator/servicemix/branches/servicemix-3.0/pom.xml?revision=470031view=markup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-47) Add support for multiple issue and due-to tags in changes.xml
[ http://jira.codehaus.org/browse/MCHANGES-47?page=all ] Julien HENRY updated MCHANGES-47: - Attachment: maven-change-multiple-issue.patch This patch simply add suport for multiple issues (comma separated). Add support for multiple issue and due-to tags in changes.xml - Key: MCHANGES-47 URL: http://jira.codehaus.org/browse/MCHANGES-47 Project: Maven 2.x Changes Plugin Issue Type: New Feature Reporter: Dennis Lundberg Attachments: maven-change-multiple-issue.patch, MCHANGES-47-maven-changes-plugin.patch This is to improve the compatibility with changes.xml files used by the Maven 1 version of the plugin. See MPCHANGES-15 and MPCHANGES-16 for more info. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1241) JWebUnit 1.4 RC1 available.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1241?page=comments#action_80967 ] Julien HENRY commented on MAVENUPLOAD-1241: --- Thanks ! JWebUnit 1.4 RC1 available. --- Key: MAVENUPLOAD-1241 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1241 Project: maven-upload-requests Issue Type: New Feature Reporter: Julien HENRY Assigned To: Carlos Sanchez Hi, Please sync from http://jwebunit.sourceforge.net/m2-repo to get the JWebUnit 1.4 RC1 release. Thanks Julien -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-104) Javadoc of generated sources is not generated when aggregate=true
Javadoc of generated sources is not generated when aggregate=true - Key: MJAVADOC-104 URL: http://jira.codehaus.org/browse/MJAVADOC-104 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Julien HENRY Hi, If have a multi-module project : pom.xml |--moduleA |--moduleB I generate source in moduleB. 1) If I run mvn javadoc:javadoc in moduleB directory, it works (javadoc of the generated class is created) 2) If I run mvn javadoc:javadoc from the root directory, with aggregate=false, it works (javadoc is in moduleB/target/site/apidocs) 3) If I run mvn javadoc:javadoc from the root directory, with aggregate=true, it doesn't works (javadoc is in target/site/apidocs but not for the generated class) Thanks for any help. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-105) Excluded package is generated (should not) because of wrong file separator.
Excluded package is generated (should not) because of wrong file separator.
---
Key: MJAVADOC-105
URL: http://jira.codehaus.org/browse/MJAVADOC-105
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows
Reporter: Julien HENRY
I'm using javacc plugin to generate source. By default, sources are generated
in ${project.build.directory}/generated-sources/javacc
I set Javacc to generate sources in package net.sourceforge.jwebunit.javacc
As I don't want Javadoc to be generated for the parser, I set
excludePackageNames to net.sourceforge.jwebunit.javacc in my POM.
With my configuration, the full path of Javacc generated sources is :
D:\jhenry\jwebunit-1.x\jwebunit-webtestcase-generator\target/generated-sources/javacc
(note that there is / and \ in the same path).
Now, in the function AbstractJavadocMojo.getIncludedFiles, you are trying to
exclude package by comparing string
D:\jhenry\jwebunit-1.x\jwebunit-webtestcase-generator\target\generated-sources\javacc\net\sourceforge\jwebunit\javacc\
and
D:\jhenry\jwebunit-1.x\jwebunit-webtestcase-generator\target/generated-sources/javacc
+ \net\sourceforge\jwebunit\javacc\
and the two Strings are not equal because of / and \
Perhaps it's a bug of javacc, but this method should be more robust (for
example by using File comparisons instead of String comparisons).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
