[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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}ISO-8859-1{code}
> I have written a custom assembly file and I am using resource filtering.
> {code}...
>
> ${project.basedir}/src/main/resources/
> /
> true
>
> ...{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 fail 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 strict_if_exists 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] 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-tabpanel&focusedCommentId=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}ISO-8859-1{code}
> I have written a custom assembly file and I am using resource filtering.
> {code}...
>
> ${project.basedir}/src/main/resources/
> /
> true
>
> ...{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: (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}
src/main/filters/filter.properties
{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}
${basedir}/src/main/filters/filter.properties
{code}
What is confusing is that the first configuration works fine in the global
filter definition:
{code:xml}
src/main/filters/filter.properties
{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-tabpanel&focusedCommentId=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}ISO-8859-1{code}
> I have written a custom assembly file and I am using resource filtering.
> {code}...
>
> ${project.basedir}/src/main/resources/
> /
> true
>
> ...{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-tabpanel&focusedCommentId=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}ISO-8859-1{code}
> I have written a custom assembly file and I am using resource filtering.
> {code}...
>
> ${project.basedir}/src/main/resources/
> /
> true
>
> ...{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}ISO-8859-1{code}
> I have written a custom assembly file and I am using resource filtering.
> {code}...
>
> ${project.basedir}/src/main/resources/
> /
> true
>
> ...{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-tabpanel&focusedCommentId=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}ISO-8859-1{code}
I have written a custom assembly file and I am using resource filtering.
{code}...
${project.basedir}/src/main/resources/
/
true
...{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-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: (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] Created: (SUREFIRE-682) cannot be overridden by commandline param
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 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.(ZipFile.java:114)
> at java.util.jar.JarFile.(JarFile.java:135)
> at java.util.jar.JarFile.(JarFile.java:99)
> at
> org.apache.maven.shared.jar.JarAnalyzer.(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.(ZipFile.java:114)
at java.util.jar.JarFile.(JarFile.java:135)
at java.util.jar.JarFile.(JarFile.java:99)
at org.apache.maven.shared.jar.JarAnalyzer.(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: (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-tabpanel&focusedCommentId=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 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}
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.7
>
>
>
>
>
> aggregate
>
>
>
>
> aggregate
>
>
>
>
>
>
> {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] 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 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}
org.apache.maven.plugins
maven-javadoc-plugin
2.7
aggregate
aggregate
{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: (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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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}
...
org.apache.maven.plugins
maven-war-plugin
2.1-beta-1
...
{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] 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] 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] 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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 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 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 value as:
> {quote}
> $[pom.parent.groupId].$[pom.parent.artifactId]
> {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\parent>mvn 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
> sun.reflect.DelegatingMethodAccessorImpl.invoke(De
[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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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}
org.apache.maven.artifact.handler.ArtifactHandler
amp
org.apache.maven.artifact.handler.DefaultArtifactHandler
amp
amp
amp
java
true
true
{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-tabpanel&focusedCommentId=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] 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: (MAVENUPLOAD-2739) Version 2.2-jdk15 of UISpec4J
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] 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: (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-tabpanel&focusedCommentId=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)
>
> superproject
> pom
> 1.0.0.1-SNAPSHOT
>
> A
> B
>
>
> // superproject/A/pom.xml (abbrievated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> A
> 1.0.0.1-SNAPSHOT
>
> // superproject/B/pom.xml (abbreviated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> B
> war
> 1.0.0.1-SNAPSHOT
>
> FooWar
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> copy
>
> copy
>
> package
>
>
>
> A
> ${pom.version}
> jar
>
>
> ${project.build.directory}/${pom.build.finalName}/jars
>
>
>
>
>
>
>
>
> A
> ${pom.version}
>
>
>
> The error message during mvn release:prepare is basically:
> [INFO] Building B
> [INFO] task-segment: [clean, integration-test]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] [dependency:copy {execution: copy}]
> [INFO] Configured Artifact: :A:null:1.0.0.1:jar
> Downloading: /1.0.0.1/A-1.0.0.1.jar
> [WARNING] Unable to get resource from repository sizzle ( details>)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> 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] 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)
>
> superproject
> pom
> 1.0.0.1-SNAPSHOT
>
> A
> B
>
>
> // superproject/A/pom.xml (abbrievated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> A
> 1.0.0.1-SNAPSHOT
>
> // superproject/B/pom.xml (abbreviated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> B
> war
> 1.0.0.1-SNAPSHOT
>
> FooWar
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> copy
>
> copy
>
> package
>
>
>
> A
> ${pom.version}
> jar
>
>
> ${project.build.directory}/${pom.build.finalName}/jars
>
>
>
>
>
>
>
>
> A
> ${pom.version}
>
>
>
> The error message during mvn release:prepare is basically:
> [INFO] Building B
> [INFO] task-segment: [clean, integration-test]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] [dependency:copy {execution: copy}]
> [INFO] Configured Artifact: :A:null:1.0.0.1:jar
> Downloading: /1.0.0.1/A-1.0.0.1.jar
> [WARNING] Unable to get resource from repository sizzle ( details>)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> 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-tabpanel&focusedCommentId=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)
>
> superproject
> pom
> 1.0.0.1-SNAPSHOT
>
> A
> B
>
>
> // superproject/A/pom.xml (abbrievated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> A
> 1.0.0.1-SNAPSHOT
>
> // superproject/B/pom.xml (abbreviated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> B
> war
> 1.0.0.1-SNAPSHOT
>
> FooWar
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> copy
>
> copy
>
> package
>
>
>
> A
> ${pom.version}
> jar
>
>
> ${project.build.directory}/${pom.build.finalName}/jars
>
>
>
>
>
>
>
>
> A
> ${pom.version}
>
>
>
> The error message during mvn release:prepare is basically:
> [INFO] Building B
> [INFO] task-segment: [clean, integration-test]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] [dependency:copy {execution: copy}]
> [INFO] Configured Artifact: :A:null:1.0.0.1:jar
> Downloading: /1.0.0.1/A-1.0.0.1.jar
> [WARNING] Unable to get resource from repository sizzle ( details>)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> 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] 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-tabpanel&focusedCommentId=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] 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] 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-tabpanel&focusedCommentId=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}
org.apache.maven.plugins
maven-jxr-plugin
2.1
...
org.codehaus.mojo
taglist-maven-plugin
2.4
{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}
org.apache.maven.plugins
maven-jxr-plugin
2.1
...
org.codehaus.mojo
taglist-maven-plugin
2.4
{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: (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-tabpanel&focusedCommentId=200327#action_200327
]
Julien HENRY commented on MNG-2258:
---
In my corporate parent pom I have the following in reporting section:
{code:xml}
org.apache.maven.plugins
maven-jxr-plugin
2.1
...
org.codehaus.mojo
taglist-maven-plugin
2.4
{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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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: (MNG-4417) Exception using release:clean with Maven 3 snapshot
[
http://jira.codehaus.org/browse/MNG-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=196676#action_196676
]
Julien HENRY commented on MNG-4417:
---
Hi Benjamin,
I can send you the pom file to reproduce the first issue. But I prefer to not
upload publicly because it is from my organisation.
What is your email adress?
> Exception using release:clean with Maven 3 snapshot
> ---
>
> Key: MNG-4417
> URL: http://jira.codehaus.org/browse/MNG-4417
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 3.x
> Environment: Apache Maven 3.0-SNAPSHOT (r829653; 2009-10-25
> 23:43:04+0100)
> Java version: 1.6.0_14
> Java home: C:\Program Files\Java\jdk1.6.0_14\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> Release plugin version 2.0-beta-8
>Reporter: Julien HENRY
>Assignee: Benjamin Bentmann
> Attachments: MNG-4417.zip
>
>
> Running mvn release:clean on my project, I get the following exception:
> {code}
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> Unable to lookup component
> 'org.apache.maven.shared.release.phase.ReleasePhase', it could not be started.
> role: org.apache.maven.shared.release.phase.ReleasePhase
> roleHint: map-release-versions
> classRealm: plugin>org.apache.maven.plugins:maven-release-plugin:2.0-beta-8
> at
> org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:373)
> at
> org.codehaus.plexus.DefaultComponentRegistry.lookup(DefaultComponentRegistry.java:184)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:399)
> at
> org.codehaus.plexus.component.collections.AbstractComponentCollection.lookup(AbstractComponentCollection.java:149)
> at
> org.codehaus.plexus.component.collections.ComponentMap.getComponentMap(ComponentMap.java:189)
> at
> org.codehaus.plexus.component.collections.ComponentMap.getMap(ComponentMap.java:148)
> at
> org.codehaus.plexus.component.collections.ComponentMap.get(ComponentMap.java:68)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.clean(DefaultReleaseManager.java:443)
> at
> org.apache.maven.plugins.release.CleanReleaseMojo.execute(CleanReleaseMojo.java:48)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:547)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:224)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:97)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:453)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:105)
> 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.codehaus.plexus.component.repository.exception.ComponentLifecycleException:
> Error constructing component
> role: 'org.apache.maven.shared.release.phase.ReleasePhase', implementation:
> 'org.apache.maven.shared.release.phase.MapVersionsPhase', role hint:
> 'map-release-versions'
> at
> org.codehaus.plexus.component.builder.XBeanComponentBuilder.createComponentInstance(XBeanComponentBuilder.java:178)
> at
> org.codehaus.plexus.component.builder.XBeanComponentBuilder.build(XBeanComponentBuilder.java:123)
> at
> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:181)
> at
> org.codehaus.plexus.component.manager.SingletonComponentManager.getComponent(SingletonComponentManager.java:67)
> at
> org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:358)
> ... 23 more
> Caused by: java.lang.NoClassDefFoundError:
> org/codehaus/plexus/components/interactivity/PrompterException
> at java.lang.Class.getDeclaredConstructors0(Nati
[jira] Commented: (MNG-4417) Exception using release:clean with Maven 3 snapshot
[
http://jira.codehaus.org/browse/MNG-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=196657#action_196657
]
Julien HENRY commented on MNG-4417:
---
I also have an error using mvn release:prepare:
{code}
D:\super-pom>mvn release:prepare -DscmCommentPrefix=[artfxxx]
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building MyCompany Sud Super POM 2.0.2-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.0-beta-8:prepare (default-cli) @
mycompany-sud-super-pom ---
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C "svn --non-interactive status"
[INFO] Working directory: D:\super-pom
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.875s
[INFO] Finished at: Fri Oct 30 14:48:36 CET 2009
[INFO] Final Memory: 5M/13M
[INFO]
[ERROR] Unable to find phase 'check-dependency-snapshots' to execute [0]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [0]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
{code}
> Exception using release:clean with Maven 3 snapshot
> ---
>
> Key: MNG-4417
> URL: http://jira.codehaus.org/browse/MNG-4417
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 3.x
> Environment: Apache Maven 3.0-SNAPSHOT (r829653; 2009-10-25
> 23:43:04+0100)
> Java version: 1.6.0_14
> Java home: C:\Program Files\Java\jdk1.6.0_14\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> Release plugin version 2.0-beta-8
>Reporter: Julien HENRY
>
> Running mvn release:clean on my project, I get the following exception:
> {code}
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> Unable to lookup component
> 'org.apache.maven.shared.release.phase.ReleasePhase', it could not be started.
> role: org.apache.maven.shared.release.phase.ReleasePhase
> roleHint: map-release-versions
> classRealm: plugin>org.apache.maven.plugins:maven-release-plugin:2.0-beta-8
> at
> org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:373)
> at
> org.codehaus.plexus.DefaultComponentRegistry.lookup(DefaultComponentRegistry.java:184)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:399)
> at
> org.codehaus.plexus.component.collections.AbstractComponentCollection.lookup(AbstractComponentCollection.java:149)
> at
> org.codehaus.plexus.component.collections.ComponentMap.getComponentMap(ComponentMap.java:189)
> at
> org.codehaus.plexus.component.collections.ComponentMap.getMap(ComponentMap.java:148)
> at
> org.codehaus.plexus.component.collections.ComponentMap.get(ComponentMap.java:68)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.clean(DefaultReleaseManager.java:443)
> at
> org.apache.maven.plugins.release.CleanReleaseMojo.execute(CleanReleaseMojo.java:48)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:547)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:224)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:97)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:453)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:105)
> 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)
> a
[jira] Created: (MNG-4417) Exception using release:clean with Maven 3 snapshot
Exception using release:clean with Maven 3 snapshot
---
Key: MNG-4417
URL: http://jira.codehaus.org/browse/MNG-4417
Project: Maven 2
Issue Type: Bug
Affects Versions: 3.x
Environment: Apache Maven 3.0-SNAPSHOT (r829653; 2009-10-25
23:43:04+0100)
Java version: 1.6.0_14
Java home: C:\Program Files\Java\jdk1.6.0_14\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Release plugin version 2.0-beta-8
Reporter: Julien HENRY
Running mvn release:clean on my project, I get the following exception:
{code}
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Unable to lookup component
'org.apache.maven.shared.release.phase.ReleasePhase', it could not be started.
role: org.apache.maven.shared.release.phase.ReleasePhase
roleHint: map-release-versions
classRealm: plugin>org.apache.maven.plugins:maven-release-plugin:2.0-beta-8
at
org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:373)
at
org.codehaus.plexus.DefaultComponentRegistry.lookup(DefaultComponentRegistry.java:184)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:399)
at
org.codehaus.plexus.component.collections.AbstractComponentCollection.lookup(AbstractComponentCollection.java:149)
at
org.codehaus.plexus.component.collections.ComponentMap.getComponentMap(ComponentMap.java:189)
at
org.codehaus.plexus.component.collections.ComponentMap.getMap(ComponentMap.java:148)
at
org.codehaus.plexus.component.collections.ComponentMap.get(ComponentMap.java:68)
at
org.apache.maven.shared.release.DefaultReleaseManager.clean(DefaultReleaseManager.java:443)
at
org.apache.maven.plugins.release.CleanReleaseMojo.execute(CleanReleaseMojo.java:48)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:547)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:224)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:97)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:453)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:105)
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.codehaus.plexus.component.repository.exception.ComponentLifecycleException:
Error constructing component
role: 'org.apache.maven.shared.release.phase.ReleasePhase', implementation:
'org.apache.maven.shared.release.phase.MapVersionsPhase', role hint:
'map-release-versions'
at
org.codehaus.plexus.component.builder.XBeanComponentBuilder.createComponentInstance(XBeanComponentBuilder.java:178)
at
org.codehaus.plexus.component.builder.XBeanComponentBuilder.build(XBeanComponentBuilder.java:123)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:181)
at
org.codehaus.plexus.component.manager.SingletonComponentManager.getComponent(SingletonComponentManager.java:67)
at
org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:358)
... 23 more
Caused by: java.lang.NoClassDefFoundError:
org/codehaus/plexus/components/interactivity/PrompterException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructors(Class.java:1459)
at
org.apache.xbean.recipe.ReflectionUtil.findConstructor(ReflectionUtil.java:527)
at
org.apache.xbean.recipe.ObjectRecipe.findFactory(ObjectRecipe.java:532)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:270)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:49
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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}
org.codehaus.plexus.logging.LoggerManager
org.codehaus.plexus.logging.console.ConsoleLoggerManager
basic
info
{code}
by
{code}
org.codehaus.plexus.logging.LoggerManager
org.codehaus.plexus.logging.slf4j.Slf4jLoggerManager
{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}
%-5level %d{HH:mm:ss.SSS} %msg%n
{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] Commented: (MNG-519) Timestamps on messages
[ http://jira.codehaus.org/browse/MNG-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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}
mycompany.project1Id.release
userId
xxx
mycompany.project2Id.release
userId
xxx
mycompany.project1Id.snapshots
userId
xxx
mycompany.project2Id.snapshots
userId
xxx
... (repeat for every projects)
{code}
Where userId and password are always the same.
It would be great to allow:
{code}
mycompany.*.*
userId
xxx
{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: (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-tabpanel&focusedCommentId=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: (MPIR-150) the dependency report ignores mirrors
[ http://jira.codehaus.org/browse/MPIR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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.(Repository.java:81)
at
org.apache.maven.artifact.repository.DefaultArtifactRepository.(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
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReportExecutions(DefaultLifecycleExecut
[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] 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 > 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
> 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] 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 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-tabpanel&focusedCommentId=171522#action_171522
]
Julien HENRY commented on MPIR-150:
---
I have the same problem.
I have a corporate archiva mirror for central:
{code}
central
central
Central Mirror
http://pic-java-nce.sud.mycompany.fr:8090/archiva/repository/central
{code}
And also 2 additional repos declared in my pom.xml:
{code}
mycompany.corporate.release
mycompany Corporate Release Repository
http://pic-java-nce.sud.mycompany.fr:8090/archiva/repository/mycompany.corporate.release
true
false
mycompany.local.release
mycompany Local Release Repository
http://pic-java-nce.sud.mycompany.fr:8090/archiva/repository/release
true
false
{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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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:
[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-tabpanel&focusedCommentId=170832#action_170832
]
Julien HENRY commented on MECLIPSE-536:
---
I've added:
{code}
staged-releases-repo
https://repository.apache.org/content/repositories/maven-staging-52acfb2f215fcf/
{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
> cent
[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-tabpanel&focusedCommentId=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}
central
central
Central Mirror on Nice
http://pic-java-nce.sud.capgemini.fr:8090/archiva/repository/central
...
staged-releases
staged-releases
https://repository.apache.org/content/repositories/maven-staging-52acfb2f215fcf/
{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] org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.1.1:runtime
> [DEBUG]
[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
[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/mercur
[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]:
file:/D:/CSO/tycho-distribution-0.3.0-DEV-2146/bin/../lib/
[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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] Commented: (MAVENUPLOAD-2346) Upload appframework and swinghelper-debug
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Created: (MNG-3991) POM validator allows optional but it is not valid.
POM validator allows optional 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}
org.slf4j
slf4j-log4j12
1.5.0
optional
{code}
but in fact I intended to write
{code}
org.slf4j
slf4j-log4j12
1.5.0
true
{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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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 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 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-tabpanel&focusedCommentId=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] Commented: (WAGON-229) AbstractMethodError when deploying with Continuum
[ http://jira.codehaus.org/browse/WAGON-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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}
http://java.sun.com/dtd/application_1_3.dtd";>
MyApp
app.war
/app
appuser
{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] Commented: (MNGSITE-44) Wrong informations in Guide to Working with Manifests
[
http://jira.codehaus.org/browse/MNGSITE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129422#action_129422
]
Julien HENRY commented on MNGSITE-44:
-
Looking at your sample project I understand my error.
I was using:
{code:xml}
com.sample.Main
{code}
instead of:
{code:xml}
com.sample.Main
{code}
So the userguide is correct. Sorry for the inconvenience.
> 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
>Assignee: Benjamin Bentmann
>Priority: Minor
> Attachments: MNGSITE-44.zip, test-jar.zip
>
>
> Hi,
> In the guide, it is said that you should add
>
> com.mycompany.app.App
> ...
> to have your JAR running fine.
> But for me it was wrong. I had to add:
>
> com.mycompany.app.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: (MNGSITE-44) Wrong informations in Guide to Working with Manifests
[ http://jira.codehaus.org/browse/MNGSITE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien HENRY updated MNGSITE-44: Attachment: test-jar.zip A test project to reproduce the problem. > 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 >Assignee: Benjamin Bentmann >Priority: Minor > Attachments: MNGSITE-44.zip, test-jar.zip > > > Hi, > In the guide, it is said that you should add > > com.mycompany.app.App > ... > to have your JAR running fine. > But for me it was wrong. I had to add: > > com.mycompany.app.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: (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 com.mycompany.app.App ... to have your JAR running fine. But for me it was wrong. I had to add: com.mycompany.app.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: (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] 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_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] 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] 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] 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] 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] 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] Created: (MREPOSITORY-11) Javadoc not included in the bundle
Javadoc not included in the bundle -- Key: MREPOSITORY-11 URL: http://jira.codehaus.org/browse/MREPOSITORY-11 Project: Maven 2.x Repository Plugin Issue Type: Bug Affects Versions: 2.0 Environment: Maven version: 2.0.7 Java version: 1.4.2_13 OS name: "windows xp" version: "5.1" arch: "x86" Reporter: Julien HENRY On a simple project, I run: mvn clean source:jar javadoc:jar repository:bundle-create As a result in target I get: artifact-version.jar artifact-version-bundle.jar artifact-version-javadoc.jar artifact-version-sources.jar But in artifact-version-bundle.jar there are only: META-INF pom.xml LICENSE.txt artifact-version.jar artifact-version-sources.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: (MRELEASE-270) release:prepare doesn't fail when the project it is building fails to compile
[ http://jira.codehaus.org/browse/MRELEASE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103580 ] Julien HENRY commented on MRELEASE-270: --- I can confirm. I ask on the mailing list, and someone said there was a modification of mvn.bat (since 2.0.7) under Windows, which will prevent forked mvn errors to be propagated. In fact, it should be a maven core bug, not a release plugin bug, but I don't know where it could be reported. > release:prepare doesn't fail when the project it is building fails to compile > - > > Key: MRELEASE-270 > URL: http://jira.codehaus.org/browse/MRELEASE-270 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson > Attachments: MRELEASE-XXX.zip > > > Unusual situation on our build server, where one of the dependent libraries > had been corrupted in its local repository. > 'mvn compile' would fail with compilation errors - it couldn't find the > classes from the corrupt jar. > 'mvn release:prepare' would note compilation errors and indicate build > failure, but would continue on with the release, modify the POMs, tag the > source and finally complete indicating success. > I noted that the same thing can happen if uncompilable source is checked in, > though at least then you would get the compilation failure on your local > machine too. > I think release:prepare should clearly fail (it wasn't clear in this instance > unless you scrolled back through the build output) if any part of the > release:prepare fails. > To replicate either > a) Attempt top release uncompilable code. > b) Replace a dependent jar with a renamed text file and attempt to release. -- 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
