[jira] [Commented] (SUREFIRE-1262) Add modulepath support
[
https://issues.apache.org/jira/browse/SUREFIRE-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664853#comment-16664853
]
Andrea Aime commented on SUREFIRE-1262:
---
Hi, I'm trying to understand how does one set up dependencies either in the
modulepath and in the classpath (I'd need to do a mix, some in one, others in
the other) but in the documentation of the "test" goal I don't see anything
related to modulepath. Maybe I'm misunderstanding what this ticket was about,
or it's just there and I'm missing it?
> Add modulepath support
> --
>
> Key: SUREFIRE-1262
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1262
> Project: Maven Surefire
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> With the Jigsaw project Java9 is extended with a modulepath. This means that
> surefire should be executed in a different way.
> When working with a modulepath, the Classpath in the MANIFEST of the
> executable jar will be ignored, you need need to add everything on
> commandline.
> Just like javadoc, the java executable has an {{@}} option, where you
> can add arguments per line. So this is the new preferred way to build the
> module-path.
> IIUC for surefire it is important to add {{--patch-module
> target/test-classes}} (was: -Xpatch) which makes it possible to use the same
> packages as target/classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SUREFIRE-1586) Surefire eating away Java 11 illegal reflective access warnings
Andrea Aime created SUREFIRE-1586: - Summary: Surefire eating away Java 11 illegal reflective access warnings Key: SUREFIRE-1586 URL: https://issues.apache.org/jira/browse/SUREFIRE-1586 Project: Maven Surefire Issue Type: Bug Reporter: Andrea Aime Java 11 is emitting a number of warnings about "Illegal Reflective Access", which, I believe, are written on the standard error. We upgraded surefire from 2.12.3, where the warnings were visible, to 2.22.1, and the warnings just disappeared from the build output, while they are still visible in target/surefire-reports/.dumpstream files. Surefire is configured with false The last version of surefire that emits the warnings on console is 2.19.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] (MNG-4838) Permament move (error 301) not handled properly by Maven
[ https://jira.codehaus.org/browse/MNG-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=330983#comment-330983 ] Andrea Aime commented on MNG-4838: -- The wagon issue has been fixed. What about this one? > Permament move (error 301) not handled properly by Maven > > > Key: MNG-4838 > URL: https://jira.codehaus.org/browse/MNG-4838 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.11, 2.2.1, 3.0-beta-3 >Reporter: Grzegorz Slowikowski >Priority: Minor > Fix For: 3.x / Backlog > > > Artifact cannot be downloaded by http-lightweight-wagon used (as default) in > all Maven versions except 2.2.0, which uses http-wagon by default. > Instead of pom and jar files html files appear in the local repo with content > like: > > > 301 Moved Permanently > > Moved Permanently > The document has moved href="http://download.java.net/maven/2/org/codehaus/castor/castor-xml-schema/1.2/castor-xml-schema-1.2.pom";>here. > > Apache Server at maven2-repository.dev.java.net Port 443 > > Only Maven 2.2.0 handles 301 properly. > By the way, I haven't expected such Apache configuration (permament move) in > central Maven repo. > As you can see this is not handled properly by almost all versions of Maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-882) Fork x parallel JVMs once
[ https://jira.codehaus.org/browse/SUREFIRE-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311917#comment-311917 ] Andrea Aime commented on SUREFIRE-882: -- Agreed this would be very useful, the current setup is unusable if the tests have to load a lot of classes each time (a case we're seeing with the GeoServer integration tests, geoserver.org) > Fork x parallel JVMs once > - > > Key: SUREFIRE-882 > URL: https://jira.codehaus.org/browse/SUREFIRE-882 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.12 >Reporter: Falko Modler > > In 2.12 a new forkMode "perthread" was introduced, which (in conjunction with > parallel!=none) behaves like a parallel "always"-forkMode. > So for instance parallel=classes and forkMode=perthread fork x JVMs in > parallel, whereas each JVM executes just one(!) test class and then > terminates. > It would come in handy if there was another new forkMode (like > "perthreadOnce" or similar) which forks x JVMs that keep on executing test > classes (parallel=classes) until there are no more test-classes left to > execute. > Example (all with parallel=classes and threadCount=2) with 4 test classes > (Test1-4): > perthread: > JVM1 is forked for Test1 > JVM2 is forked for Test2 > JVM1 for Test1 terminates > JVM2 for Test2 terminates > JVM3 is forked for Test3 > JVM4 is forked for Test4 > JVM4 for Test3 terminates > JVM3 for Test3 terminates > perthreadOnce (or the like): > JVM1 is forked, executes Test1 > JVM2 is forked, executes Test2 > JVM1 executes Test3 > JVM2 executes Test4 > JVM1 terminates > JVM2 terminates > In reality, the order of events can differ of course. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-158) Artifact ###### has no file error.
[ http://jira.codehaus.org/browse/MPIR-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189958#action_189958 ] Andrea Aime commented on MPIR-158: -- I am seeing the same in my project, similar configuration, using Maven 2.1.0 I also have the same config, having the plugin check on the internet for all those small files just makes the build take forever (high latency connection) > Artifact ## has no file error. > -- > > Key: MPIR-158 > URL: http://jira.codehaus.org/browse/MPIR-158 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 2.1.1 > Environment: Windows xp, tomcat 5.5 server >Reporter: Damian Sinczak >Priority: Minor > > During 'mvn site' command on project i receive some strange errors. Their are > no critical, but they are still errors. > Console dump: > [ERROR] Artifact: org.apache.abdera:abdera-core:jar:0.4.0-incubating has no > file > . > [ERROR] Artifact: > org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating > has no file. > [ERROR] Artifact: > org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating > has no file. > [ERROR] Artifact: org.apache.abdera:abdera-i18n:jar:0.4.0-incubating has no > file > . > [ERROR] Artifact: org.apache.abdera:abdera-parser:jar:0.4.0-incubating has no > fi > le. > [ERROR] Artifact: org.apache.cxf:cxf-api:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-common-schemas:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-common-utilities:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-soap:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-xml:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-core:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-frontend-simple:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-ws-addr:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-tools-common:jar:2.2 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0 > .2 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1 > .1 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.5 h > as no file. > [ERROR] Artifact: org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0 > has > no file. > [ERROR] Artifact: org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.2 > ha > s no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1 > has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1. > 1.2 has no file. > [ERROR] Artifact: org.apache.neethi:neethi:jar:2.0.4 has no file. > [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-api:jar:1.2.7 has no file. > [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-impl:jar:1.2.7 has no > file. > [ERROR] Artifact: org.apache.ws.commons.schema:XmlSchema:jar:1.4.4 has no > file. > [ERROR] Artifact: org.apache.xmlbeans:xmlbeans:jar:2.3.0 has no file. > [ERROR] Artifact: org.codehaus.jettison:jettison:jar:1.0.1 has no file. > [ERROR] Artifact: org.codehaus.woodstox:wstx-asl:jar:3.2.6 has no file. > [ERROR] Artifact: org.hibernate:ejb3-persistence:jar:1.0.1.GA has no file. > [ERROR] Artifact: org.hibernate:hibernate-commons-annotations:jar:3.0.0.ga > has n > o file. > [ERROR] Artifact: org.mortbay.jetty:jetty:jar:6.1.15 has no file. > [ERROR] Artifact: org.mortbay.jetty:jetty-util:jar:6.1.15 has no file. > [ERROR] Artifact: org.slf4j:slf4j-api:jar:1.3.1 has no file. > [ERROR] Artifact: org.slf4j:slf4j-jdk14:jar:1.3.1 has no file. > [ERROR] Artifact: org.springframework:spring-beans:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-context:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-core:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-web:jar:2.5.5 has no file. > [ERROR] Artifact: wsdl4j:wsdl4j:jar:1.6.2 has no file. > [ERROR] Artifact: xalan:xalan:jar:2.6.0 has no file. > [ERROR] Artifact: xerces:xercesImpl:jar:2.6.2 has no file. > [ERROR] Artifact: xerces:xmlParserAPIs:jar:2.6.2 has no file. > [ERROR] Artifact: xml-apis:xml-apis:jar:1.3.02 has no file. > [ERROR] Artifact: xml-resolver:xml-resolver:jar:1.2 has no file. > [ERROR] Artifact: xom:xom:jar:1.0 has no file. > [INFO] Generating "Project Team" report. > [INFO] Generating "Project License" report. > [INFO] Generating "Project Plugins" report. > [INFO] Generating "Maven Surefire Report" report. > [INFO] Generating "FindBugs Report" report. > [INFO] Using source root: > [INFO] C:\edys_workspace\edystok\target\classes > [INFO]
[jira] Commented: (MECLIPSE-581) Test source directories appear before Main source directories
[ http://jira.codehaus.org/browse/MECLIPSE-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182723#action_182723 ] Andrea Aime commented on MECLIPSE-581: -- It actually does, building projects with the eclipse plugin < 2.6 does not create problems. > Test source directories appear before Main source directories > - > > Key: MECLIPSE-581 > URL: http://jira.codehaus.org/browse/MECLIPSE-581 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : .project >Affects Versions: 2.6 > Environment: Maven 2.0.10 >Reporter: Paul Benedict > > This is either a bug or a questionable feature. When I run eclipse:eclipse on > a project that has siblings in its parent POM, two things happen: > (1) the sibling projects become a dependent project, not jar dependencies > (2) src/test appears before src/main in the package explorer. > I can handle #1, but #2 really is a tough adjustment. -- 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-581) Test source directories appear before Main source directories
[
http://jira.codehaus.org/browse/MECLIPSE-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182611#action_182611
]
Andrea Aime commented on MECLIPSE-581:
--
I was cooking up a patch for another issue when I noticed the block of code
responsible for this:
{code}
// NOTE: Since MNG-3118, test classes come before main classes
boolean testBeforeMain = isMavenVersion( "[2.0.8,)" );
if ( testBeforeMain )
{
directories.addAll( testDirectories );
directories.removeAll( mainDirectories );
directories.addAll( mainDirectories );
}
else
{
directories.addAll( mainDirectories );
directories.addAll( testDirectories );
}
{code}
So it would seem it's a maven wide change. I too find having the test
directories first very annoying, it should be possible to have an option to get
back the old order. It could simply be false
in the eclipse configuration. Not hard to make a patch for this too, provided
the plugin developers are interested in merging it. I can cook up a patch if
the devs provide directions on how they would like the option to be exposed.
> Test source directories appear before Main source directories
> -
>
> Key: MECLIPSE-581
> URL: http://jira.codehaus.org/browse/MECLIPSE-581
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : .project
>Affects Versions: 2.6
> Environment: Maven 2.0.10
>Reporter: Paul Benedict
>
> This is either a bug or a questionable feature. When I run eclipse:eclipse on
> a project that has siblings in its parent POM, two things happen:
> (1) the sibling projects become a dependent project, not jar dependencies
> (2) src/test appears before src/main in the package explorer.
> I can handle #1, but #2 really is a tough adjustment.
--
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: (MECLIPSE-422) Cannot specify a separate output directory for test classes when custom buildOutputDirectory set
[
http://jira.codehaus.org/browse/MECLIPSE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182609#action_182609
]
Andrea Aime edited comment on MECLIPSE-422 at 7/4/09 8:56 AM:
--
Ok, second attempt (testOutputDirectory.patch), this time tested with the
GeoTools and GeoServer projects. Seems to work fine there. It would be nice to
get confirmation from other people affected by this issue.
In this one I've added an explicit testOutputDirectory configuration option. It
defaults to the project one, and can be overridden like this:
{code:xml}
org.apache.maven.plugins
maven-eclipse-plugin
bin/classes
bin/test-classes
{code}
If the developers think this patch is good for inclusion I'll extend it to the
documentation as well.
was (Author: aaime):
Ok, second attempt (testOutputDirectory.patch), this time tested with the
GeoTools and GeoServer projects. Seems to work fine there. It would be nice to
get confirmation from other people affected by this issue.
In this one I've added an explicit testOutputDirectory configuration option. It
defaults to the project one, and can be overridden like this:
{code:xml}
org.apache.maven.plugins
maven-eclipse-plugin
bin/classes
bin/test-classes
{code:xml}
If the developers think this patch is good for inclusion I'll extend it to the
documentation as well.
> Cannot specify a separate output directory for test classes when custom
> buildOutputDirectory set
>
>
> Key: MECLIPSE-422
> URL: http://jira.codehaus.org/browse/MECLIPSE-422
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.5
>Reporter: Mark Hobson
> Attachments: separateOutputs.patch, testOutputDirectory.patch
>
>
> As soon as buildOutputDirectory is set to a non-default value the output
> directories for all source folders are the same. It should be possible to
> specify a buildTestOutputDirectory to separate main and test classes, as is
> the default behaviour when buildOutputDirectory is not set.
--
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: (MECLIPSE-422) Cannot specify a separate output directory for test classes when custom buildOutputDirectory set
[
http://jira.codehaus.org/browse/MECLIPSE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182609#action_182609
]
Andrea Aime edited comment on MECLIPSE-422 at 7/4/09 8:56 AM:
--
Ok, second attempt (testOutputDirectory.patch), this time tested with the
GeoTools and GeoServer projects. Seems to work fine there. It would be nice to
get confirmation from other people affected by this issue.
In this one I've added an explicit testOutputDirectory configuration option. It
defaults to the project one, and can be overridden like this:
{code:xml}
org.apache.maven.plugins
maven-eclipse-plugin
bin/classes
bin/test-classes
{code:xml}
If the developers think this patch is good for inclusion I'll extend it to the
documentation as well.
was (Author: aaime):
Ok, second attempt, this time tested with the GeoTools and GeoServer
projects. Seems to work fine there. It would be nice to get confirmation from
other people affected by this issue.
> Cannot specify a separate output directory for test classes when custom
> buildOutputDirectory set
>
>
> Key: MECLIPSE-422
> URL: http://jira.codehaus.org/browse/MECLIPSE-422
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.5
>Reporter: Mark Hobson
> Attachments: separateOutputs.patch, testOutputDirectory.patch
>
>
> As soon as buildOutputDirectory is set to a non-default value the output
> directories for all source folders are the same. It should be possible to
> specify a buildTestOutputDirectory to separate main and test classes, as is
> the default behaviour when buildOutputDirectory is not set.
--
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-422) Cannot specify a separate output directory for test classes when custom buildOutputDirectory set
[ http://jira.codehaus.org/browse/MECLIPSE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Aime updated MECLIPSE-422: - Attachment: testOutputDirectory.patch Ok, second attempt, this time tested with the GeoTools and GeoServer projects. Seems to work fine there. It would be nice to get confirmation from other people affected by this issue. > Cannot specify a separate output directory for test classes when custom > buildOutputDirectory set > > > Key: MECLIPSE-422 > URL: http://jira.codehaus.org/browse/MECLIPSE-422 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.5 >Reporter: Mark Hobson > Attachments: separateOutputs.patch, testOutputDirectory.patch > > > As soon as buildOutputDirectory is set to a non-default value the output > directories for all source folders are the same. It should be possible to > specify a buildTestOutputDirectory to separate main and test classes, as is > the default behaviour when buildOutputDirectory is not set. -- 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-422) Cannot specify a separate output directory for test classes when custom buildOutputDirectory set
[ http://jira.codehaus.org/browse/MECLIPSE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182608#action_182608 ] Andrea Aime commented on MECLIPSE-422: -- Doh, I should have tested the patch a bit, the .classpath file looked good but the result is that the per entry output are nested with the default output and Eclipse does not like the result. Will work on a better solution. > Cannot specify a separate output directory for test classes when custom > buildOutputDirectory set > > > Key: MECLIPSE-422 > URL: http://jira.codehaus.org/browse/MECLIPSE-422 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.5 >Reporter: Mark Hobson > Attachments: separateOutputs.patch > > > As soon as buildOutputDirectory is set to a non-default value the output > directories for all source folders are the same. It should be possible to > specify a buildTestOutputDirectory to separate main and test classes, as is > the default behaviour when buildOutputDirectory is not set. -- 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-422) Cannot specify a separate output directory for test classes when custom buildOutputDirectory set
[ http://jira.codehaus.org/browse/MECLIPSE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Aime updated MECLIPSE-422: - Attachment: separateOutputs.patch Very much agreed. In GeoTools and GeoServer projects we would like to use a separate Eclipse output directory but at the moment it's not possible due to this very issue, as we have test resources that do overwrite main resources with the same name. Both are related to the respective plugin systems, which look for a certain file in the jars, and the tests, that in order to double check the plugin system itself, use files with the same name to install test plugins. The separateOutputs.patch file is a trivial patch that makes it so the output of src and test end up in different directories fixing the problem for us. The intent is to consider the outputDirectory not as the directory where the classes will be put, but as the root for the main and source output directories, which will be kept separate. When the outputDirectory is set to $OUTPUT, the main sources and resources will be targeted to $OUTPUT/classes, whilst the test ones to $OUTPUT/test-classes. If this behaviour change is not acceptable I'm ready to prepare a patch that will add a testOutputDirectory parameter instead. > Cannot specify a separate output directory for test classes when custom > buildOutputDirectory set > > > Key: MECLIPSE-422 > URL: http://jira.codehaus.org/browse/MECLIPSE-422 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.5 >Reporter: Mark Hobson > Attachments: separateOutputs.patch > > > As soon as buildOutputDirectory is set to a non-default value the output > directories for all source folders are the same. It should be possible to > specify a buildTestOutputDirectory to separate main and test classes, as is > the default behaviour when buildOutputDirectory is not set. -- 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: (MECLIPSE-422) Cannot specify a separate output directory for test classes when custom buildOutputDirectory set
[ http://jira.codehaus.org/browse/MECLIPSE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182607#action_182607 ] Andrea Aime edited comment on MECLIPSE-422 at 7/4/09 8:07 AM: -- Very much agreed. In GeoTools and GeoServer projects we would like to use a separate Eclipse output directory but at the moment it's not possible due to this very issue, as we have test resources that do overwrite main resources with the same name. Both are related to the respective plugin systems, which look for a certain file in the jars, and the tests, that in order to double check the plugin system itself, use files with the same name to install test plugins. The separateOutputs.patch file is a trivial patch that makes it so the output of src and test end up in different directories fixing the problem for us. The intent is to consider the outputDirectory not as the directory where the classes will be put, but as the root for the main and source output directories, which will be kept separate. When the outputDirectory is set to $OUTPUT, the main sources and resources will be targeted to $OUTPUT/classes, whilst the test ones to $OUTPUT/test-classes. If this behaviour change is not acceptable I'm ready to prepare a patch that will add a testOutputDirectory parameter instead. Oh, I coded the patch against the 2.7 releases sources. was (Author: aaime): Very much agreed. In GeoTools and GeoServer projects we would like to use a separate Eclipse output directory but at the moment it's not possible due to this very issue, as we have test resources that do overwrite main resources with the same name. Both are related to the respective plugin systems, which look for a certain file in the jars, and the tests, that in order to double check the plugin system itself, use files with the same name to install test plugins. The separateOutputs.patch file is a trivial patch that makes it so the output of src and test end up in different directories fixing the problem for us. The intent is to consider the outputDirectory not as the directory where the classes will be put, but as the root for the main and source output directories, which will be kept separate. When the outputDirectory is set to $OUTPUT, the main sources and resources will be targeted to $OUTPUT/classes, whilst the test ones to $OUTPUT/test-classes. If this behaviour change is not acceptable I'm ready to prepare a patch that will add a testOutputDirectory parameter instead. > Cannot specify a separate output directory for test classes when custom > buildOutputDirectory set > > > Key: MECLIPSE-422 > URL: http://jira.codehaus.org/browse/MECLIPSE-422 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.5 >Reporter: Mark Hobson > Attachments: separateOutputs.patch > > > As soon as buildOutputDirectory is set to a non-default value the output > directories for all source folders are the same. It should be possible to > specify a buildTestOutputDirectory to separate main and test classes, as is > the default behaviour when buildOutputDirectory is not set. -- 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: (MJAR-111) Index creation fails when classpath is set in manifest
[ http://jira.codehaus.org/browse/MJAR-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176749#action_176749 ] Andrea Aime commented on MJAR-111: -- The same problems occurs using Maven 2.1.0, with the same configuration, in some of the GeoTools modules, using JDK 1.5.0_18 on Ubuntu 9.04. Strange enough, it seems to be happening only on those modules that do not have no dependencies that should be registered in the manifest (e.g., no dependencies at all, or provided dependencies). The moment I add a single external dependency that will result in the classpath entry to be written in the manifest file the bug disappears. > Index creation fails when classpath is set in manifest > -- > > Key: MJAR-111 > URL: http://jira.codehaus.org/browse/MJAR-111 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP, IBM SDK 1.5.0 >Reporter: Karsten Tinnefeld >Priority: Critical > Attachments: index-test.tar.gz > > > The following plugin configuration fails deterministically, as JarArchiver > tries to open a directory folder as a RandomAccessFile, which fails (at least > on Windows): > > maven-jar-plugin > > > true > > > true > > > > > The error is: > $ mvn clean package -e > [...] > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error assembling JAR > Embedded error: Problem creating jar: > d:\adesso\eclipse-Arbeitsbereiche\Portale2-Test1\indextest\target\classes > (Zugriff > verweigert) > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling JAR > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:49 > 9) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:618) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error assembling > JAR > at > org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:225) > at > org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:237) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > ... 16 more > Caused by: org.codehaus.plexus.archiver.ArchiverException: Problem creating > jar: d:\adesso\eclipse-Arbeitsbereiche\Porta > le2-Test1\indextest\target\classes (Zugriff verweigert) > at > org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:690) > at > org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:421) > at > org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(Abstract
[jira] Created: (MAVENUPLOAD-2444) Upload JFreeChart 1.0.10 and JCommon 1.0.13
Upload JFreeChart 1.0.10 and JCommon 1.0.13 --- Key: MAVENUPLOAD-2444 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2444 Project: Maven Upload Requests Issue Type: Wish Reporter: Andrea Aime The two go hand in hand, so I'm putting both in this report. While I'm not a developer of either, I'm working on an companion project of them, Eastwood: https://sourceforge.net/projects/eastwood/ https://sourceforge.net/project/memberlist.php?group_id=212556 The url of the bundles can be found here: http://atlas.openplans.org/~aaime/jcommon-1.0.13-bundle.jar http://atlas.openplans.org/~aaime/jfreechart-1.0.10-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: (MNG-3627) Maven complains for the lack of a test dependency even when skipping tests
[
http://jira.codehaus.org/browse/MNG-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139314#action_139314
]
Andrea Aime commented on MNG-3627:
--
This makes lots of sense considering how Maven is implemented, a bit less from
the point of view of the unaware user trying to build without building tests
for the first time ;)
> Maven complains for the lack of a test dependency even when skipping tests
> --
>
> Key: MNG-3627
> URL: http://jira.codehaus.org/browse/MNG-3627
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9
>Reporter: Andrea Aime
>
> Trying to build GeoServer trunk without tests (-Dmaven.test.skip=true) we're
> getting an error message stating that some jars marked as test dependencies
> are not found. In particular, these are the tests jar of another module in
> the build, which is not getting built because of the test.skip setting and
> it's not already available on the repository.
> Yet mvn dependency:tree does report the following:
> {panel}
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'dependency'.
> [INFO]
>
> [INFO] Building Web Coverage Service 1.1.1 Module
> [INFO]task-segment: [dependency:tree]
> [INFO]
>
> [INFO] [dependency:tree]
> [INFO] org.geoserver:wcs1_1:jar:1.8.0-SNAPSHOT
> [INFO] +- org.geoserver:main:jar:1.8.0-SNAPSHOT:compile
> [INFO] | +- org.geoserver:data:jar:1.8.0-SNAPSHOT:compile
> [INFO] | | +- org.geoserver:platform:jar:1.8.0-SNAPSHOT:compile
> [INFO] | | | +- javax.media:jai_core:jar:1.1.3:compile
> [INFO] | | | +- javax.media:jai_codec:jar:1.1.3:compile
> [INFO] | | | \- javax.media:jai_imageio:jar:1.1:compile
> [INFO] | | +- org.geotools:gt-epsg-hsql:jar:2.5-SNAPSHOT:compile
> [INFO] | | +- org.geotools:gt-h2:jar:2.5-SNAPSHOT:compile
> [INFO] | | | +- org.h2database:h2:jar:1.0-SNAPSHOT:compile
> [INFO] | | | +- org.openplans:spatialdbbox:jar:1.0-SNAPSHOT:compile
> [INFO] | | | \- mysql:mysql-connector-java:jar:5.1.5:compile
> [INFO] | | +- org.geotools:gt-property:jar:2.5-SNAPSHOT:compile
> [INFO] | | +- org.geotools.xsd:gt-xsd-gml2:jar:2.5-SNAPSHOT:compile
> [INFO] | | \- xml-apis:xml-apis-xerces:jar:2.7.1:compile
> [INFO] | +- org.geoserver:ows:jar:1.8.0-SNAPSHOT:compile
> [INFO] | | +- org.acegisecurity:acegi-security:jar:1.0.3:compile
> [INFO] | | | +- org.springframework:spring-jdbc:jar:2.5.2:compile (version
> managed from 1.2.8)
> [INFO] | | | | \- org.springframework:spring-tx:jar:2.5.2:compile
> [INFO] | | | \- commons-codec:commons-codec:jar:1.3:compile
> [INFO] | | +- commons-lang:commons-lang:jar:2.1:compile
> [INFO] | | +- org.geotools.xsd:gt-xsd-core:jar:2.5-SNAPSHOT:compile
> [INFO] | | \- xpp3:xpp3:jar:1.1.3.4.O:compile
> [INFO] | +- javax.servlet:servlet-api:jar:2.4:compile
> [INFO] | +- org.restlet:org.restlet:jar:1.0.8:compile (version managed from
> 1.0.5)
> [INFO] | +- org.restlet:org.restlet.ext.freemarker:jar:1.0.8:compile
> (version managed from 1.0.5)
> [INFO] | +-
> com.noelios.restlet:com.noelios.restlet.ext.servlet:jar:1.0.8:compile
> (version managed from 1.0.5)
> [INFO] | | \- com.noelios.restlet:com.noelios.restlet:jar:1.0.8:compile
> [INFO] | +- net.sf.json-lib:json-lib:jar:jdk13:2.1:compile
> [INFO] | | +- commons-collections:commons-collections:jar:3.1:compile
> [INFO] | | \- net.sf.ezmorph:ezmorph:jar:1.0.3:compile
> [INFO] | +- struts:struts:jar:1.2.9:compile
> [INFO] | | \- antlr:antlr:jar:2.7.2:compile
> [INFO] | +- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO] | +- xerces:xercesImpl:jar:2.6.2:compile
> [INFO] | +- xalan:xalan:jar:2.7.0:compile
> [INFO] | +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] | +- commons-digester:commons-digester:jar:1.7:compile
> [INFO] | +- commons-fileupload:commons-fileupload:jar:1.2.1:compile
> [INFO] | +- commons-io:commons-io:jar:1.3.2:compile
> [INFO] | +- commons-httpclient:commons-httpclient:jar:2.0:compile
> [INFO] | +- commons-validator:commons-validator:jar:1.1.4:compile
> [INFO] | +- org.freemarker:freemarker:jar:2.3.13:compile
> [INFO] | +- oro:oro:jar:2.0.8:compile
> [INFO] | +- org.geotools:gt-cql:jar:2.5-SNAPSHOT:compile
> [INFO] | +- log4j:log4j:jar:1.2.14:compile
> [INFO] | +- org.geotools:gt-coverage:jar:2.5-SNAPSHOT:compile
> [INFO] | +- org.geotools:gt-validation:jar:2.5-SNAPSHOT:compile
> [INFO] | | \- org.geotools:gt-graph:jar:2.5-SNAPSHOT:compile
> [INFO] | +- org.geotools:gt-data:jar:2.5-SNAPSHOT:compile
> [INFO] | +- org.geotools:gt-jdbc:jar:2.5-SNAPSHOT:compile
> [INFO] | | \- commons-dbcp:commons-d
[jira] Created: (MNG-3627) Maven complains for the lack of a test dependency even when skipping tests
Maven complains for the lack of a test dependency even when skipping tests
--
Key: MNG-3627
URL: http://jira.codehaus.org/browse/MNG-3627
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.9
Reporter: Andrea Aime
Trying to build GeoServer trunk without tests (-Dmaven.test.skip=true) we're
getting an error message stating that some jars marked as test dependencies are
not found. In particular, these are the tests jar of another module in the
build, which is not getting built because of the test.skip setting and it's not
already available on the repository.
Yet mvn dependency:tree does report the following:
{panel}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO]
[INFO] Building Web Coverage Service 1.1.1 Module
[INFO]task-segment: [dependency:tree]
[INFO]
[INFO] [dependency:tree]
[INFO] org.geoserver:wcs1_1:jar:1.8.0-SNAPSHOT
[INFO] +- org.geoserver:main:jar:1.8.0-SNAPSHOT:compile
[INFO] | +- org.geoserver:data:jar:1.8.0-SNAPSHOT:compile
[INFO] | | +- org.geoserver:platform:jar:1.8.0-SNAPSHOT:compile
[INFO] | | | +- javax.media:jai_core:jar:1.1.3:compile
[INFO] | | | +- javax.media:jai_codec:jar:1.1.3:compile
[INFO] | | | \- javax.media:jai_imageio:jar:1.1:compile
[INFO] | | +- org.geotools:gt-epsg-hsql:jar:2.5-SNAPSHOT:compile
[INFO] | | +- org.geotools:gt-h2:jar:2.5-SNAPSHOT:compile
[INFO] | | | +- org.h2database:h2:jar:1.0-SNAPSHOT:compile
[INFO] | | | +- org.openplans:spatialdbbox:jar:1.0-SNAPSHOT:compile
[INFO] | | | \- mysql:mysql-connector-java:jar:5.1.5:compile
[INFO] | | +- org.geotools:gt-property:jar:2.5-SNAPSHOT:compile
[INFO] | | +- org.geotools.xsd:gt-xsd-gml2:jar:2.5-SNAPSHOT:compile
[INFO] | | \- xml-apis:xml-apis-xerces:jar:2.7.1:compile
[INFO] | +- org.geoserver:ows:jar:1.8.0-SNAPSHOT:compile
[INFO] | | +- org.acegisecurity:acegi-security:jar:1.0.3:compile
[INFO] | | | +- org.springframework:spring-jdbc:jar:2.5.2:compile (version
managed from 1.2.8)
[INFO] | | | | \- org.springframework:spring-tx:jar:2.5.2:compile
[INFO] | | | \- commons-codec:commons-codec:jar:1.3:compile
[INFO] | | +- commons-lang:commons-lang:jar:2.1:compile
[INFO] | | +- org.geotools.xsd:gt-xsd-core:jar:2.5-SNAPSHOT:compile
[INFO] | | \- xpp3:xpp3:jar:1.1.3.4.O:compile
[INFO] | +- javax.servlet:servlet-api:jar:2.4:compile
[INFO] | +- org.restlet:org.restlet:jar:1.0.8:compile (version managed from
1.0.5)
[INFO] | +- org.restlet:org.restlet.ext.freemarker:jar:1.0.8:compile (version
managed from 1.0.5)
[INFO] | +-
com.noelios.restlet:com.noelios.restlet.ext.servlet:jar:1.0.8:compile (version
managed from 1.0.5)
[INFO] | | \- com.noelios.restlet:com.noelios.restlet:jar:1.0.8:compile
[INFO] | +- net.sf.json-lib:json-lib:jar:jdk13:2.1:compile
[INFO] | | +- commons-collections:commons-collections:jar:3.1:compile
[INFO] | | \- net.sf.ezmorph:ezmorph:jar:1.0.3:compile
[INFO] | +- struts:struts:jar:1.2.9:compile
[INFO] | | \- antlr:antlr:jar:2.7.2:compile
[INFO] | +- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] | +- xerces:xercesImpl:jar:2.6.2:compile
[INFO] | +- xalan:xalan:jar:2.7.0:compile
[INFO] | +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
[INFO] | +- commons-digester:commons-digester:jar:1.7:compile
[INFO] | +- commons-fileupload:commons-fileupload:jar:1.2.1:compile
[INFO] | +- commons-io:commons-io:jar:1.3.2:compile
[INFO] | +- commons-httpclient:commons-httpclient:jar:2.0:compile
[INFO] | +- commons-validator:commons-validator:jar:1.1.4:compile
[INFO] | +- org.freemarker:freemarker:jar:2.3.13:compile
[INFO] | +- oro:oro:jar:2.0.8:compile
[INFO] | +- org.geotools:gt-cql:jar:2.5-SNAPSHOT:compile
[INFO] | +- log4j:log4j:jar:1.2.14:compile
[INFO] | +- org.geotools:gt-coverage:jar:2.5-SNAPSHOT:compile
[INFO] | +- org.geotools:gt-validation:jar:2.5-SNAPSHOT:compile
[INFO] | | \- org.geotools:gt-graph:jar:2.5-SNAPSHOT:compile
[INFO] | +- org.geotools:gt-data:jar:2.5-SNAPSHOT:compile
[INFO] | +- org.geotools:gt-jdbc:jar:2.5-SNAPSHOT:compile
[INFO] | | \- commons-dbcp:commons-dbcp:jar:1.2.2:compile
[INFO] | +- org.geotools:gt-metadata:jar:2.5-SNAPSHOT:compile
[INFO] | | +- java3d:vecmath:jar:1.3.1:compile
[INFO] | | +- org.opengis:geoapi:jar:2.2-SNAPSHOT:compile
[INFO] | | \- net.java.dev.jsr-275:jsr-275:jar:1.0-beta-2:compile
[INFO] | +- org.springframework:spring-aop:jar:2.5.2:compile
[INFO] | \- com.thoughtworks.xstream:xstream:jar:1.3:compile
[INFO] | \- xpp3:xpp3_min:jar:1.1.4c:compile
[INFO] +- org.geotools.ogc:net.opengis.wcs:jar:2.5-SNAPSHOT:compile
[INFO] | +- org.geotools.ogc:net.opengis.ows:jar:2.5-SNAPSHOT:compil
[jira] Updated: (MJAVADOC-78) Add a flag to provide standard doclet parameters to custom ones too
[ http://jira.codehaus.org/browse/MJAVADOC-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Aime updated MJAVADOC-78: Attachment: pom.xml > Add a flag to provide standard doclet parameters to custom ones too > --- > > Key: MJAVADOC-78 > URL: http://jira.codehaus.org/browse/MJAVADOC-78 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Andrea Aime > Attachments: JAVADOC-78.patch, pom.xml > > > I'm working on a custom doclet that wraps the standard doclet and add extra > behaviour (automated class diagram generation in class javadocs and package > javadocs). I want to run it under maven 2, but I've stumbled against the > default behaviour: standard doclet parameters such as -link are provided only > if the javadoc is the standard one (in AbstractJavadocMojo.java, the check is > "if ( StringUtils.isEmpty( doclet ) ) ..."). > A generally good behaviour would be not perform assumptions, but to call > XXXDoclet.optionLength for each parameter, and see if the doclet accepts them > or not (and thus provide only the one accepted). As an alternative, add at > least a flag to allow the provision of the standard doclet parameters to the > custom ones as well. -- 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-78) Add a flag to provide standard doclet parameters to custom ones too
[ http://jira.codehaus.org/browse/MJAVADOC-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137908#action_137908 ] Andrea Aime commented on MJAVADOC-78: - I don't have exactly a test case, but I can attach the pom that we had to make to make things work, as you can see there is a profile that activates the usage of the special doclet and reconfigures the javadoc plugin accordinly (see the javadoc config in build and then the "uml" profile near the end). > Add a flag to provide standard doclet parameters to custom ones too > --- > > Key: MJAVADOC-78 > URL: http://jira.codehaus.org/browse/MJAVADOC-78 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Andrea Aime > Attachments: JAVADOC-78.patch, pom.xml > > > I'm working on a custom doclet that wraps the standard doclet and add extra > behaviour (automated class diagram generation in class javadocs and package > javadocs). I want to run it under maven 2, but I've stumbled against the > default behaviour: standard doclet parameters such as -link are provided only > if the javadoc is the standard one (in AbstractJavadocMojo.java, the check is > "if ( StringUtils.isEmpty( doclet ) ) ..."). > A generally good behaviour would be not perform assumptions, but to call > XXXDoclet.optionLength for each parameter, and see if the doclet accepts them > or not (and thus provide only the one accepted). As an alternative, add at > least a flag to allow the provision of the standard doclet parameters to the > custom ones as well. -- 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: (MJAR-69) When 'index' and 'addClasspath' are both true, plugin fails.
[
http://jira.codehaus.org/browse/MJAR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Aime updated MJAR-69:
Attachment: trace.log
Don't know if this is of any help, this is the full trace of the problem. The
module has no dependencies, besides one on junit marked as "provided", but it's
part of a large multimodule build where most of the other modules would enjoy
having an index
> When 'index' and 'addClasspath' are both true, plugin fails.
>
>
> Key: MJAR-69
> URL: http://jira.codehaus.org/browse/MJAR-69
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Anagnostopoulos Kostis
>Assignee: Olivier Lamy
> Attachments: trace.log
>
>
> When both the 'index' and 'addClasspath' are true, the plugin fails to create
> jar with the following msg:
> Embedded error: Problem creating jar: **/target/classes (Is a directory)
> A typical configuration to produce the error would be:
> {code:xml}
>
> maven-jar-plugin
>
>
> true
>
> true
>
>
>
> {code}
> The issue below (about including dependency files in index) claims that it
> introduced this bug:
> http://jira.codehaus.org/browse/MJAR-40
> I'm posting this issue so that to ensure that version 2.2-SNAPSHOT does not
> suffer from the same problem.
--
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: (MJAR-69) When 'index' and 'addClasspath' are both true, plugin fails.
[
http://jira.codehaus.org/browse/MJAR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126862
]
Andrea Aime commented on MJAR-69:
-
I'm trying to add index support to GeoTools build, using maven 2, and I'm
facing exactly the same problem.
> When 'index' and 'addClasspath' are both true, plugin fails.
>
>
> Key: MJAR-69
> URL: http://jira.codehaus.org/browse/MJAR-69
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Anagnostopoulos Kostis
>Assignee: Olivier Lamy
>
> When both the 'index' and 'addClasspath' are true, the plugin fails to create
> jar with the following msg:
> Embedded error: Problem creating jar: **/target/classes (Is a directory)
> A typical configuration to produce the error would be:
> {code:xml}
>
> maven-jar-plugin
>
>
> true
>
> true
>
>
>
> {code}
> The issue below (about including dependency files in index) claims that it
> introduced this bug:
> http://jira.codehaus.org/browse/MJAR-40
> I'm posting this issue so that to ensure that version 2.2-SNAPSHOT does not
> suffer from the same problem.
--
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-1793) Upload iText 2.0.6
Upload iText 2.0.6 -- Key: MAVENUPLOAD-1793 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1793 Project: maven-upload-requests Issue Type: Bug Reporter: Andrea Aime iText version 2.0.6 The repository contains up to 1.4.8. I'm not one of the developers, just need to upgrade iText dependencies in my project. The pom has been created by modifying the 1.4.8 one. -- 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-197) Automatic reference of dependee projects
[ http://jira.codehaus.org/browse/MECLIPSE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106299 ] Andrea Aime commented on MECLIPSE-197: -- Oh, an easier way would be to just be able to specify groups whose artifact references should be generated as project names, assuming something or someone already loaded those projects in the workspace. Something like: org.geotools or like: org.geotools commons-beanutils commons-beanutils-core > Automatic reference of dependee projects > > > Key: MECLIPSE-197 > URL: http://jira.codehaus.org/browse/MECLIPSE-197 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: dependency resolution >Reporter: Alessandro Evangelista >Assignee: fabrizio giustina > Attachments: referenceDependeeProjects-patch.txt > > Original Estimate: 1 day > Remaining Estimate: 1 day > > It would very useful to have the ability to automatically reference dependee > project for which the project source code is locally found. > Let's assume that module y depends on module x. The project description of > module y will contain directly or indirectly - i.e. transitively - a > dependency to module x. > The execution of the goal "eclipse:eclipse" on the module y would normally > generate an eclipse project with a jar dependency to module x. > Often it is convenient to directly reference the module x as eclipse project > to allow concurrent modification and compilation of both module x and y. > The attached patch allows to automatically reference projects if the dependee > project's source code is found in same directory as the dependent project. A > project is a candidate match if the group-id and artifact-id properties of > the two project equal and the two version equal or the dependee's version is > the requested version but SNAPSHOT tagged. > Example of directory structure: > /usr/src/product/com.company.product.x/pom.xml > /usr/src/product/com.company.product.y/pom.xml > The feature can be enabled via the maven's boolean property > eclipse.referenceDependeeProjects > The property default value is false and therefore the feature is disabled per > default. > The following is an example of execution with the feature enabled: > # mvn eclipse:eclipse -Declipse.referenceDependeeProjects=true > > Currently it is assumed that the dependee project sources are within a > directory named after the project's artifact-id. > Future extensions could consider the more general maven's version matching > strategy - is this coded anywhere specific in maven's source code? - and > possibly allowing for locating the dependee source in directories with > generic names or paths. -- 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-197) Automatic reference of dependee projects
[ http://jira.codehaus.org/browse/MECLIPSE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106296 ] Andrea Aime commented on MECLIPSE-197: -- I would be very interested in a behaviour that's quite similar to this. I have two open source projects, GeoTools and GeoServer, both using maven, and GeoServer depending on GeoTools. Now, what I would like very much would be the ability to load both project modules into Eclipse so that GeoServer project refer directly GeoTools modules, instead of depending on the jars. GeoTools is a complex library made up of 90+ modules, organised in a tree hierarchy, so I guess to make this possible mvn eclipse:eclipse would have to actually scan the GeoTools poms. > Automatic reference of dependee projects > > > Key: MECLIPSE-197 > URL: http://jira.codehaus.org/browse/MECLIPSE-197 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: dependency resolution >Reporter: Alessandro Evangelista >Assignee: fabrizio giustina > Attachments: referenceDependeeProjects-patch.txt > > Original Estimate: 1 day > Remaining Estimate: 1 day > > It would very useful to have the ability to automatically reference dependee > project for which the project source code is locally found. > Let's assume that module y depends on module x. The project description of > module y will contain directly or indirectly - i.e. transitively - a > dependency to module x. > The execution of the goal "eclipse:eclipse" on the module y would normally > generate an eclipse project with a jar dependency to module x. > Often it is convenient to directly reference the module x as eclipse project > to allow concurrent modification and compilation of both module x and y. > The attached patch allows to automatically reference projects if the dependee > project's source code is found in same directory as the dependent project. A > project is a candidate match if the group-id and artifact-id properties of > the two project equal and the two version equal or the dependee's version is > the requested version but SNAPSHOT tagged. > Example of directory structure: > /usr/src/product/com.company.product.x/pom.xml > /usr/src/product/com.company.product.y/pom.xml > The feature can be enabled via the maven's boolean property > eclipse.referenceDependeeProjects > The property default value is false and therefore the feature is disabled per > default. > The following is an example of execution with the feature enabled: > # mvn eclipse:eclipse -Declipse.referenceDependeeProjects=true > > Currently it is assumed that the dependee project sources are within a > directory named after the project's artifact-id. > Future extensions could consider the more general maven's version matching > strategy - is this coded anywhere specific in maven's source code? - and > possibly allowing for locating the dependee source in directories with > generic names or paths. -- 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-119) Allow custom project name for eclipse projects
[ http://jira.codehaus.org/browse/MECLIPSE-119?page=comments#action_78208 ]
Andrea Aime commented on MECLIPSE-119:
--
This inability to customize the project is byting us (Geotools/Geoserver
projects) as well... we do have a "main" module in both projects, and at the
same time maven works better if you have directory name=module name (see scm
tags handling) even having the ability to just write to the "project"
property would be nice, it would allow for a customisation like:
org.apache.maven.plugins
maven-eclipse-plugin
gt2-${project}
> Allow custom project name for eclipse projects
> --
>
> Key: MECLIPSE-119
> URL: http://jira.codehaus.org/browse/MECLIPSE-119
> Project: Maven 2.x Eclipse Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: David Rice
> Attachments: MNG-1920-maven-eclipse-plugin.patch
>
>
> If you download 2 versions of the same artifact, or 2 artifacts with the same
> artifactId then when you create eclipse the projects you have to load them
> into different workspaces because the eclipse project name is the same (ie.
> based on artifactId). I added a parameter eclipse.projectName to allow you
> to specify an alternate name to artifactId to get around this problem.
> Example uses:
> -Declipse.projectName='${project.artifactId}:${project.version}'
> -Declipse.projectName='${project.groupId}:${project.artifactId}:${project.version}'
> -Declipse.projectName=my-different-project-name
--
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-48) eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin
[ http://jira.codehaus.org/browse/MECLIPSE-48?page=comments#action_72788 ] Andrea Aime commented on MECLIPSE-48: - Having eclipse copying over .svn folder for projects that are not shared with subversive or subclipse is cause big slowdowns here. Please do add the ability to filter out unwanted resources. > eclipse:eclipse goal should handle includes and excludes of the > maven-compiler-plugin > - > > Key: MECLIPSE-48 > URL: http://jira.codehaus.org/browse/MECLIPSE-48 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Mark Donszelmann > > The maven-compiler-plugin allows a configuration such as: > > maven-compiler-plugin > > > **/idl/*Factory.java > > > > the generated .classpath file currently does not mention the excluded part: > > > which should be: >path="src/main/java"/> >path="target/generated-sources/idl"/> -- 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-134) target/classes not acceptable for eclipse
[ http://jira.codehaus.org/browse/MECLIPSE-134?page=comments#action_72058 ] Andrea Aime commented on MECLIPSE-134: -- I totally agree on this one. There is another way to break things: enable workspace automated refresh, then do a "mvn clean install", and you'll see maven and eclipse try to concurrently compile the same sources, with ugly results (usually an error on the maven side and the need to do a "clean all projects" on the Eclipse side). At least provide this as an option. > target/classes not acceptable for eclipse > - > > Key: MECLIPSE-134 > URL: http://jira.codehaus.org/browse/MECLIPSE-134 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.0, 2.1, 2.2 >Reporter: Jörg Hohwiller >Priority: Minor > > "mvn eclipse:eclipse" causes an eclipse configuration where the classfiles > generated by eclipse go to the same directory as the classes generated by > maven. This is extremly evil! Eclipse and maven are independent tools and > should therefore not compile to the same target folder causing side effects. > Especially when "mvn clean" is called and you re-run an existing application > inside eclipse, and get a NoClassDefFoundError you can get slightly confused. > Please use anything else than "target/...". My suggestion would be > ".eclipse-build". -- 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-1020) Upload UmlGraph 4.4
Upload UmlGraph 4.4 --- Key: MAVENUPLOAD-1020 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1020 Project: maven-upload-requests Issue Type: Task Reporter: Andrea Aime http://www.andrea-aime.name/static/UmlGraph-bundle-4.4.jar http://www.spinellis.gr/sw/umlgraph/ http://www.spinellis.gr/sw/umlgraph/doc/ver.html Upload so that everyone running maven can easily generate javadocs annotated with uml diagrams like in: http://www.andrea-aime.name/static/gt2-api/ -- 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: (MPH-19) Provide just a list of the mojos
Provide just a list of the mojos Key: MPH-19 URL: http://jira.codehaus.org/browse/MPH-19 Project: Maven 2.x Help Plugin Issue Type: Improvement Affects Versions: 2.0.1 Reporter: Andrea Aime In my opinion the describe mojo would be a little more easy to use if mvn help:describe -Dplugin=help would also return a list of the mojo, undescribed. The output of: mvn help:describe -Dplugin=help -Dfull=true is way too verbose in plugins that have many mojos. It would be nice to be able and locate the mojo first, explore its parameters later. -- 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: (MPH-18) Plugin site out of date?
Plugin site out of date? Key: MPH-18 URL: http://jira.codehaus.org/browse/MPH-18 Project: Maven 2.x Help Plugin Issue Type: Improvement Affects Versions: 2.0.1 Reporter: Andrea Aime The site speaks about a prefix parameter here: http://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html but it doesn't seem to work, whilst the following: mvn help:describe -Dplugin=help Does work fine (happily the eror message when using prefix gave me an hint on the right parameter name) -- 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: (MPH-15) help:describe should accept plugin prefix or prefix:goal
[ http://jira.codehaus.org/browse/MPH-15?page=comments#action_70438 ] Andrea Aime commented on MPH-15: Well, apparently the current version of the help plugin allows for that, even if the help plugin site does not seem up to date. The following works: mvn help:describe -Dplugin=site -Dfull=true (althought the output is a bit too verbose i my opinon) > help:describe should accept plugin prefix or prefix:goal > > > Key: MPH-15 > URL: http://jira.codehaus.org/browse/MPH-15 > Project: Maven 2.x Help Plugin > Issue Type: Improvement >Reporter: Kenney Westerhof >Priority: Minor > > It's tedious and unnecessary to type the entire groupId and artifactId since > plugin:goal also works > when specified on the commandline. > Add a new parameter -Dgoal=plugin:goal or -Dprefix=plugin and let m2 resolve > the plugin > in the normal fashion; > mvn help:describe -Dprefix=help -> show Mojo's for maven-help-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: (MAVENUPLOAD-978) Upload ejb-3.0-public-draft-20060502 (needed for hibernate)
[ http://jira.codehaus.org/browse/MAVENUPLOAD-978?page=all ] Andrea Aime updated MAVENUPLOAD-978: Attachment: license.txt > Upload ejb-3.0-public-draft-20060502 (needed for hibernate) > --- > > Key: MAVENUPLOAD-978 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-978 > Project: maven-upload-requests > Type: Task > Reporter: Andrea Aime > Attachments: license.txt > > > http://www.webalice.it/andrea.aime/ejb-3.0-public-draft-20060502-bundle.jar > http://www.hibernate.org > The hibernate annotations 3.2cr1 needs this dependency, but it's not > published onto ibiblio, so build is not possible. -- 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-978) Upload ejb-3.0-public-draft-20060502 (needed for hibernate)
Upload ejb-3.0-public-draft-20060502 (needed for hibernate) --- Key: MAVENUPLOAD-978 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-978 Project: maven-upload-requests Type: Task Reporter: Andrea Aime http://www.webalice.it/andrea.aime/ejb-3.0-public-draft-20060502-bundle.jar http://www.hibernate.org The hibernate annotations 3.2cr1 needs this dependency, but it's not published onto ibiblio, so build is not possible. -- 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-970) Upload Jalopy 1.5rc3
Upload Jalopy 1.5rc3 Key: MAVENUPLOAD-970 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-970 Project: maven-upload-requests Type: Task Reporter: Andrea Aime http://www.andrea-aime.name/static/jalopy-1.5rc3-bundle.jar http://jalopy.sourceforge.net/ NOT A DEVELOPER Btw, I'm not a developer of jalopy, I'm just patching the maven 2 jalopy plugin and I'd like to use the latest available version of the jalopy plugin. On a second note, it seems to me the mini tutorial at http://maven.apache.org/guides/mini/guide-ibiblio-upload.html should be updated to consider the explicit fields available here, that is, Bundle URL, project URL and contributor URL. -- 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-72) Aggregating javadocs doesn't work
[ http://jira.codehaus.org/browse/MJAVADOC-72?page=comments#action_67815 ] Andrea Aime commented on MJAVADOC-72: - I already updated to 2.0 final, yet the problem is still there... > Aggregating javadocs doesn't work > - > > Key: MJAVADOC-72 > URL: http://jira.codehaus.org/browse/MJAVADOC-72 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Versions: 2.0 > Environment: WinXP SP2 > cygwin 1.5.19 > maven 2.0.4 > jdk 1.5.0_06 > javadoc-plugin 2.0 final > latest released plugins > Reporter: Bugittaa Pahasti > > > When I define true to javadoc plugin configuration in > parent pom, javadoc generation doesn't work from the parent (all other > configuration options are default). If run under individual components, > javadoc is generated without problems. It seems that the child dependencies > aren't resolved: > Embedded error: Exit code: 1 - > c:/code/apps/project/common/src/main/java/com/company/AbstractLogEnabled.java:3: > package org.apache.log4j does not exist > import org.apache.log4j.Logger; > c:/code/apps/component/common-test/src/main/java/com/company/unittest/AbstractDatasourceEnabledTestCase.java:11: > package org.apache.commons.dbcp does not exist > import org.apache.commons.dbcp.BasicDataSource; > And lot more similar errors. > Additionally, there are a huge number of ClassCastExceptions from javadoc. > java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl > at > com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDescImpl.java:46) > at > com.sun.tools.doclets.internal.toolkit.util.Util.isDeprecated(Util.java:804) > at > com.sun.tools.doclets.formats.html.TagletWriterImpl.deprecatedTagOutput(TagletWriterImpl.java:85) > at > com.sun.tools.doclets.internal.toolkit.taglets.DeprecatedTaglet.getTagletOutput(DeprecatedTaglet.java:40) > at > com.sun.tools.doclets.formats.html.MethodWriterImpl.writeDeprecated(MethodWriterImpl.java:166) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildDeprecationInfo(MethodBuilder.java:183) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildMethodDoc(MethodBuilder.java:150) > at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildMethodDetails(ClassBuilder.java:322) > at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:124) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:108) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:155) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:177) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:161) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:106)
[jira] Commented: (WAGONHTTP-7) wagon-http dos not handle HTTP 204 No Content code as success
[ http://jira.codehaus.org/browse/WAGONHTTP-7?page=comments#action_67709 ] Andrea Aime commented on WAGONHTTP-7: - Sorry I was wrong, only one file has been uploaded > wagon-http dos not handle HTTP 204 No Content code as success > - > > Key: WAGONHTTP-7 > URL: http://jira.codehaus.org/browse/WAGONHTTP-7 > Project: wagon-http > Type: Bug > Versions: 1.0-alpha-6 > Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, against > Apache/2.0.54 (Fedora) DAV/2 > Reporter: Matthew Daniel > > > q.v. HTTP RFC 2616 section 9.6 "PUT": "If an existing resource is modified, >either the 200 (OK) or 204 (No Content) response codes SHOULD be sent >to indicate successful completion of the request." > Currently: > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifactat > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > 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:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying > artifact > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:160) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: > Error installing artifact's metadata: Error while deploying metadata: Failed > to transfer file: http://servername/path/to/my/artifactid/maven-metadata.xml. > Return code is: 204 > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:99) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:148) > ... 18 more > Caused by: > org.apache.maven.artifact.repository.metadata.RepositoryMetadataDeploymentException: > Error while deploying metadata: Failed to transfer file: > http://servername/path/to/my/artifactid/maven-metadata.xml. Return code is: > 204 > at > org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java:433) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:83) > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer > file: http://servername/path/to/my/artifactid/maven-metadata.xml. Return code > is: 204 > at > org.apache.maven.wagon.providers.http.HttpWagon.put(HttpWagon.java:209) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:180) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifactMetadata(DefaultWagonManager.java:116) > at > org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java:429) > ... 20 more -- 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: (WAGONHTTP-7) wagon-http dos not handle HTTP 204 No Content code as success
[ http://jira.codehaus.org/browse/WAGONHTTP-7?page=comments#action_67708 ] Andrea Aime commented on WAGONHTTP-7: - I'm hitting the same problem, the server is answering 204 and as a result the build fails. Yet, all the files have been uploaded, and the stack trace is a little different: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Unable to transfer file. HttpURLConnection returned the response code: 204 [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying artifact: Unable to transfer file. HttpURLConnec tion returned the response code: 204 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47 5) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying artifact: Unable to transfer file. HttpURLCon nection returned the response code: 204 at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:143) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error deploying artifact: Unable to transfer file. HttpURLConnection returned the response code: 204 at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:131) ... 18 more Caused by: org.apache.maven.wagon.TransferFailedException: Unable to transfer file. HttpURLConnection returned the respo nse code: 204 at org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(LightweightHttpWagon.java:143) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:180) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:77) In my pom I enabled the following extension: org.apache.maven.wagon wagon-webdav ... 19 more > wagon-http dos not handle HTTP 204 No Content code as success > - > > Key: WAGONHTTP-7 > URL: http://jira.codehaus.org/browse/WAGONHTTP-7 > Project: wagon-http > Type: Bug > Versions: 1.0-alpha-6 > Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, against > Apache/2.0.54 (Fedora) DAV/2 > Reporter: Matthew Daniel > > > q.v. HTTP RFC 2616 section 9.6 "PUT": "If an existing resource is modified, >either the 200 (OK) or 204 (No Content) response codes SHOULD be sent >to indicate successful completion of the request." > Currently: > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifactat > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleE
[jira] Commented: (MSUREFIRE-139) Argline splits on spaces, should not when quoted
[ http://jira.codehaus.org/browse/MSUREFIRE-139?page=comments#action_67459
]
Andrea Aime commented on MSUREFIRE-139:
---
Btw, I marked it as a blocker because I can't find any way out with antrun to
run my tests with runtime weaving
> Argline splits on spaces, should not when quoted
>
>
> Key: MSUREFIRE-139
> URL: http://jira.codehaus.org/browse/MSUREFIRE-139
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Versions: 2.2
> Reporter: Andrea Aime
> Priority: Blocker
>
>
> I need to run surefire with the following argline:
> -javaagent:\"${user.home}\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar\"
> -javaagent:\"C:\Documents
> Settings\wolf\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar\"
> The problem is, ForkConfiguration splits the arguments blindly with
> StringUtils.split and the above turns into three
> separate arguments:
> -javaagent:"C:\Documents
> and
> Settings\wolf\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar"
> And the the vm complains it cannot find the jar C:\Documents.
> When quoted, the split should not happen!
> The following method proved to support quoting properly when splitting on
> spaces (I'm using it in UmlGraph):
> public static String[] tokenize(String s) {
> ArrayList r = new ArrayList();
> String remain = s;
> int n = 0, pos;
> remain = remain.trim();
> while (remain.length() > 0) {
> if (remain.startsWith("\"")) {
> // Field in quotes
> pos = remain.indexOf('"', 1);
> if (pos == -1)
> break;
> r.add(remain.substring(1, pos));
> if (pos + 1 < remain.length())
> pos++;
> } else {
> // Space-separated field
> pos = remain.indexOf(' ', 0);
> if (pos == -1) {
> r.add(remain);
> remain = "";
> } else
> r.add(remain.substring(0, pos));
> }
> remain = remain.substring(pos + 1);
> remain = remain.trim();
> // - is used as a placeholder for empy fields
> if (r.get(n).equals("-"))
> r.set(n, "");
> n++;
> }
> return r.toArray(new String[0]);
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MSUREFIRE-139) Argline splits on spaces, should not when quoted
Argline splits on spaces, should not when quoted
Key: MSUREFIRE-139
URL: http://jira.codehaus.org/browse/MSUREFIRE-139
Project: Maven 2.x Surefire Plugin
Type: Bug
Versions: 2.2
Reporter: Andrea Aime
Priority: Blocker
I need to run surefire with the following argline:
-javaagent:\"${user.home}\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar\"
-javaagent:\"C:\Documents
Settings\wolf\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar\"
The problem is, ForkConfiguration splits the arguments blindly with
StringUtils.split and the above turns into three
separate arguments:
-javaagent:"C:\Documents
and
Settings\wolf\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar"
And the the vm complains it cannot find the jar C:\Documents.
When quoted, the split should not happen!
The following method proved to support quoting properly when splitting on
spaces (I'm using it in UmlGraph):
public static String[] tokenize(String s) {
ArrayList r = new ArrayList();
String remain = s;
int n = 0, pos;
remain = remain.trim();
while (remain.length() > 0) {
if (remain.startsWith("\"")) {
// Field in quotes
pos = remain.indexOf('"', 1);
if (pos == -1)
break;
r.add(remain.substring(1, pos));
if (pos + 1 < remain.length())
pos++;
} else {
// Space-separated field
pos = remain.indexOf(' ', 0);
if (pos == -1) {
r.add(remain);
remain = "";
} else
r.add(remain.substring(0, pos));
}
remain = remain.substring(pos + 1);
remain = remain.trim();
// - is used as a placeholder for empy fields
if (r.get(n).equals("-"))
r.set(n, "");
n++;
}
return r.toArray(new String[0]);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-72) Aggregating javadocs doesn't work
[ http://jira.codehaus.org/browse/MJAVADOC-72?page=comments#action_67434 ] Andrea Aime commented on MJAVADOC-72: - I do have the same problem, me too. A quick search on the net releaved that we're not the only ones seeing this: http://jira.codehaus.org/browse/ANNOGEN-14 > Aggregating javadocs doesn't work > - > > Key: MJAVADOC-72 > URL: http://jira.codehaus.org/browse/MJAVADOC-72 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Versions: 2.0 > Environment: WinXP SP2 > cygwin 1.5.19 > maven 2.0.4 > jdk 1.5.0_06 > javadoc-plugin 2.0 final > latest released plugins > Reporter: Bugittaa Pahasti > > > When I define true to javadoc plugin configuration in > parent pom, javadoc generation doesn't work from the parent (all other > configuration options are default). If run under individual components, > javadoc is generated without problems. It seems that the child dependencies > aren't resolved: > Embedded error: Exit code: 1 - > c:/code/apps/project/common/src/main/java/com/company/AbstractLogEnabled.java:3: > package org.apache.log4j does not exist > import org.apache.log4j.Logger; > c:/code/apps/component/common-test/src/main/java/com/company/unittest/AbstractDatasourceEnabledTestCase.java:11: > package org.apache.commons.dbcp does not exist > import org.apache.commons.dbcp.BasicDataSource; > And lot more similar errors. > Additionally, there are a huge number of ClassCastExceptions from javadoc. > java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl > at > com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDescImpl.java:46) > at > com.sun.tools.doclets.internal.toolkit.util.Util.isDeprecated(Util.java:804) > at > com.sun.tools.doclets.formats.html.TagletWriterImpl.deprecatedTagOutput(TagletWriterImpl.java:85) > at > com.sun.tools.doclets.internal.toolkit.taglets.DeprecatedTaglet.getTagletOutput(DeprecatedTaglet.java:40) > at > com.sun.tools.doclets.formats.html.MethodWriterImpl.writeDeprecated(MethodWriterImpl.java:166) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildDeprecationInfo(MethodBuilder.java:183) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildMethodDoc(MethodBuilder.java:150) > at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildMethodDetails(ClassBuilder.java:322) > at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:124) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:108) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:155) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:177) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:161) > at > com.
[jira] Created: (MJAVADOC-78) Add a flag to provide standard doclet parameters to custom ones too
Add a flag to provide standard doclet parameters to custom ones too --- Key: MJAVADOC-78 URL: http://jira.codehaus.org/browse/MJAVADOC-78 Project: Maven 2.x Javadoc Plugin Type: Improvement Versions: 2.0 Reporter: Andrea Aime I'm working on a custom doclet that wraps the standard doclet and add extra behaviour (automated class diagram generation in class javadocs and package javadocs). I want to run it under maven 2, but I've stumbled against the default behaviour: standard doclet parameters such as -link are provided only if the javadoc is the standard one (in AbstractJavadocMojo.java, the check is "if ( StringUtils.isEmpty( doclet ) ) ..."). A generally good behaviour would be not perform assumptions, but to call XXXDoclet.optionLength for each parameter, and see if the doclet accepts them or not (and thus provide only the one accepted). As an alternative, add at least a flag to allow the provision of the standard doclet parameters to the custom ones as well. -- 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
