[jira] Commented: (MJAVADOC-246) ExceptionInInitializerError
[ http://jira.codehaus.org/browse/MJAVADOC-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185831#action_185831 ] Parolini Antonio commented on MJAVADOC-246: --- Same here. My workaround is to force version 2.5 of the maven-javadoc-plugin > ExceptionInInitializerError > --- > > Key: MJAVADOC-246 > URL: http://jira.codehaus.org/browse/MJAVADOC-246 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: Hudson or command-line > Maven 2.1.0 or 2.2.0 > JDK 1.6 or JDK 1.7 > OpenSolaris >Reporter: Malachi de AElfweald >Priority: Blocker > Fix For: 2.6.1 > > > This bug only happens if I have maven-javadoc-plugin enabled. If I comment it > out site generation works. The POM is not specifying a particular version so > I am not sure which one it is using. > These bugs seem to report the same problem against other plugins: > http://jira.codehaus.org/browse/MOJO-1118 > http://jira.codehaus.org/browse/MOJO-1101 > Based on the error message, I checked the repository after successfully > building without JavaDoc and it shows these versions of commons-logging were > used: > 1.0 > 1.0.3 > 1.0.4 > 1.1 > The only SNAPSHOT dependency is 2.1-SNAPSHOT of the maven-site-plugin (to get > around site generation bugs). I am using the -U during building. > [INFO] Generating "JavaDocs" report. > [FATAL ERROR] org.apache.maven.plugins.site.SiteMojo#execute() caused a > linkage error (java.lang.ExceptionInInitializerError) and may be out-of-date. > Check the realms: > [FATAL ERROR] Plugin realm = > app0.child-container[org.apache.maven.plugins:maven-site-plugin:2.1-SNAPSHOT] > urls[0] = > file:/home/hudson/.m2/repository/org/apache/maven/plugins/maven-site-plugin/2.1-SNAPSHOT/maven-site-plugin-2.1-SNAPSHOT.jar > urls[1] = > file:/home/hudson/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar > urls[2] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.1.2-SNAPSHOT/doxia-module-xhtml-1.1.2-SNAPSHOT.jar > urls[3] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-core/1.1.2-SNAPSHOT/doxia-core-1.1.2-SNAPSHOT.jar > urls[4] = > file:/home/hudson/.m2/repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar > urls[5] = > file:/home/hudson/.m2/repository/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar > urls[6] = > file:/home/hudson/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar > urls[7] = > file:/home/hudson/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar > urls[8] = > file:/home/hudson/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > urls[9] = > file:/home/hudson/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar > urls[10] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-module-apt/1.1.2-SNAPSHOT/doxia-module-apt-1.1.2-SNAPSHOT.jar > urls[11] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-module-xdoc/1.1.2-SNAPSHOT/doxia-module-xdoc-1.1.2-SNAPSHOT.jar > urls[12] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-module-fml/1.1.2-SNAPSHOT/doxia-module-fml-1.1.2-SNAPSHOT.jar > urls[13] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.1.2-SNAPSHOT/doxia-decoration-model-1.1.2-SNAPSHOT.jar > urls[14] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.1.2-SNAPSHOT/doxia-site-renderer-1.1.2-SNAPSHOT.jar > urls[15] = > file:/home/hudson/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar > urls[16] = > file:/home/hudson/.m2/repository/org/codehaus/plexus/plexus-velocity/1.1.7/plexus-velocity-1.1.7.jar > urls[17] = > file:/home/hudson/.m2/repository/org/apache/velocity/velocity/1.5/velocity-1.5.jar > urls[18] = > file:/home/hudson/.m2/repository/commons-collections/commons-collections/3.2/commons-collections-3.2.jar > urls[19] = file:/home/hudson/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar > urls[20] = > file:/home/hudson/.m2/repository/org/apache/maven/shared/maven-doxia-tools/1.1-SNAPSHOT/maven-doxia-tools-1.1-SNAPSHOT.jar > urls[21] = > file:/home/hudson/.m2/repository/commons-io/commons-io/1.4/commons-io-1.4.jar > urls[22] = > file:/home/hudson/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar > urls[23] = > file:/home/hudson/.m2/repository/org/mortbay/jetty/jetty/6.1.5/jetty-6.1.5.jar > urls[24] = > file:/home/hudson/.m2/repository/org/mortbay/jetty/jetty-util/6.1.5/jetty-util-6.1.5.jar > urls[25] = > file:/home/hudson/.m2/repository/org/mortbay/jetty/servlet-api-2.5/6.1.5/servlet-api-2.5-6.1.5.jar > [FATAL ERROR] Container realm = plexus.core > urls[0] = file:/opt/apache-m
[jira] Commented: (MECLIPSE-449) Facet Generation generates duplicate entries - breaks RAD/RSA support
[ http://jira.codehaus.org/browse/MECLIPSE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185846#action_185846 ] Florian Probst commented on MECLIPSE-449: - I have the same issue when creating a new web module. Adding "jst.jsf" in version 1.2 automatically adds "jst.web" in version 2.4 what is not supported by Eclipse. When i include "jst.web" in correct version 2.5 it looks like: 1.2 2.5 2.0 The result is a duplicated entry of "jst.web" in both versions 2.4 AND 2.5. It works for me, deleting the 2.4 entry out of the file. Affects current version 2.7. > Facet Generation generates duplicate entries - breaks RAD/RSA support > - > > Key: MECLIPSE-449 > URL: http://jira.codehaus.org/browse/MECLIPSE-449 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.5.1 > Environment: WinXP, IBM RSA V7.0.0.6 (Eclipse 3.2.2) >Reporter: Chris Graham > > Using V2.5.1 of the maven-eclipse-plugin, I have some issues in getting the > generated artifacts being correct. > Take this section of the POM: > > 5.0 > 2.1 > 6.1 > > Generates this: > > > > > > > > > > You'll see that the jst.java facet is in there twice. > Removing the facet from the list: > > 2.1 > 6.1 > > Generates this: > > > > > > > > > Which is a little more correct. > I consider this a bug, as the facets (by their very definition) are unique > and should not be repeated. > Additionally, when compared to a RSA (V7) generated one, it is missing the > standard XML header: > > Also, where does the jst.utility facet come from? > It's inclusion is getting in the way of RSA recognising it as a true J2EE > component project (the EJB Deployment descriptor tree element does not > display in the Project Explorer view in the J2EE Perspective). > This is the complete RSA generated one, for reference: > > > > > > > > > > (Which raises another question, how do we specify the runtime items and if > something is fixed or not?) > However, to get it to be correctly recognised, all we need is this: > > > > > > -- 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-449) Facet Generation generates duplicate entries - breaks RAD/RSA support
[ http://jira.codehaus.org/browse/MECLIPSE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-449: - Fix Version/s: 2.8 > Facet Generation generates duplicate entries - breaks RAD/RSA support > - > > Key: MECLIPSE-449 > URL: http://jira.codehaus.org/browse/MECLIPSE-449 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.5.1 > Environment: WinXP, IBM RSA V7.0.0.6 (Eclipse 3.2.2) >Reporter: Chris Graham > Fix For: 2.8 > > > Using V2.5.1 of the maven-eclipse-plugin, I have some issues in getting the > generated artifacts being correct. > Take this section of the POM: > > 5.0 > 2.1 > 6.1 > > Generates this: > > > > > > > > > > You'll see that the jst.java facet is in there twice. > Removing the facet from the list: > > 2.1 > 6.1 > > Generates this: > > > > > > > > > Which is a little more correct. > I consider this a bug, as the facets (by their very definition) are unique > and should not be repeated. > Additionally, when compared to a RSA (V7) generated one, it is missing the > standard XML header: > > Also, where does the jst.utility facet come from? > It's inclusion is getting in the way of RSA recognising it as a true J2EE > component project (the EJB Deployment descriptor tree element does not > display in the Project Explorer view in the J2EE Perspective). > This is the complete RSA generated one, for reference: > > > > > > > > > > (Which raises another question, how do we specify the runtime items and if > something is fixed or not?) > However, to get it to be correctly recognised, all we need is this: > > > > > > -- 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-4280) [regression] Direct CLI invocation of goal causes "default-cli" config to be processed twice, duplicating list values
[regression] Direct CLI invocation of goal causes "default-cli" config to be
processed twice, duplicating list values
-
Key: MNG-4280
URL: http://jira.codehaus.org/browse/MNG-4280
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
As per MNG-3401, goals invoked from the CLI can also be configured by an
execution with the well-known "default-cli":
{noformat}
default-cli
CHILD-1
CHILD-3
CHILD-2
{noformat}
Trunk currently processes this config twice, thereby duplicating elements with
{{combine.children="append"}}, i.e. the {{stringParams}} list ends up with six
instead of three elements.
--
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: (MINSTALL-40) install with classifier with no target/classes fails
[ http://jira.codehaus.org/browse/MINSTALL-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185860#action_185860 ] Heiko commented on MINSTALL-40: --- For the records: It requires the deploy plugin v 2.4 > install with classifier with no target/classes fails > > > Key: MINSTALL-40 > URL: http://jira.codehaus.org/browse/MINSTALL-40 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 > Environment: Maven version: 2.0.5, Winx XP pro >Reporter: Michele Lorenzini >Assignee: Benjamin Bentmann >Priority: Minor > Attachments: clean-install-with-war-2.0.2.log, clean-install.log, > MINSTALL-40-fixed.zip, MINSTALL40-sample2.zip, sample-war.zip > > > The install plugin fails with the following error: > Error installing artifact: File C:\TEMP\sample-war\target\classes does not > exist > in a project where there is no class or classpath resource generation (so the > target/classes folder is not generated in the compile phase). > Suppose for example a war application with no java source code (maybe only > jar dependencies) and no classpath resource. > Installing the project as a primary artifact works fine. > Installing the project as a secondary artifact (so with "classifier" option) > with classes or resources works fine. > Installing the project as a secondary artifact without classes or resources > gives the error below. > Attached is a simple project with packaging WAR composed only by a web.xml > file. > Running "mvn install" on this project should give the error above. Commenting > the classifier tag will result in a successful install. > Also if I put a simple java file (or a resource) the compile goal will create > target/classes folder and the install works fine. > In fact I am using this kind of workaround for the moment (include a dummy > resource in the war build). > The same is with a similar jar project (although it may be less useful to > have an "empty" jar artifact). > Verified with both maven-install-plugin 2.1 and 2.2 -- 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: (MNG-4280) [regression] Direct CLI invocation of goal causes "default-cli" config to be processed twice, duplicating list values
[
http://jira.codehaus.org/browse/MNG-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4280.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 3.0-alpha-3
Fixed in [r800728|http://svn.apache.org/viewvc?view=rev&revision=800728].
> [regression] Direct CLI invocation of goal causes "default-cli" config to be
> processed twice, duplicating list values
> -
>
> Key: MNG-4280
> URL: http://jira.codehaus.org/browse/MNG-4280
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-3
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
>
> As per MNG-3401, goals invoked from the CLI can also be configured by an
> execution with the well-known "default-cli":
> {noformat}
>
> default-cli
>
>
> CHILD-1
> CHILD-3
> CHILD-2
>
>
>
> {noformat}
> Trunk currently processes this config twice, thereby duplicating elements
> with {{combine.children="append"}}, i.e. the {{stringParams}} list ends up
> with six instead of three elements.
--
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: (MRELEASE-469) Plugin hangs in preparation while checking deps and plugins for snapshots
Plugin hangs in preparation while checking deps and plugins for snapshots
-
Key: MRELEASE-469
URL: http://jira.codehaus.org/browse/MRELEASE-469
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-9, 2.0-beta-8
Environment: Gentoo Linux, Sun JDK 1.5, 32-bit
Reporter: Joerg Schaible
Priority: Blocker
Attachments: pom.xml
The release plugin completely hangs when checking in "release:prepare" the
dependencies and plugins for snapshot versions and I will have to kill it (^C
after some minutes):
{noformat}
$ mvn release:prepare -Dtag=v_0.0.1
[INFO] Scanning for projects...
[INFO]
[INFO] Building Scalaris QMB Plugin
[INFO]task-segment: [release:prepare] (aggregator-style)
[INFO]
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: /bin/sh -c cd /home/jos/work/research/qmb-plugin-webdev &&
svn --non-interactive status
[INFO] Working directory: /home/jos/work/research/qmb-plugin-webdev
[INFO] Checking dependencies and plugins for snapshots ...
^C
$ mvn release:rollback
[INFO] Scanning for projects...
[INFO]
[INFO] Building Scalaris QMB Plugin
[INFO]task-segment: [release:rollback] (aggregator-style)
[INFO]
[INFO] [release:rollback {execution: default-cli}]
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /home/jos/work/research/qmb-plugin-webdev &&
svn --non-interactive commit --file /tmp/maven-scm-322645963.commit --targets
/tmp/maven-scm-8571115898032334692-targets
[INFO] Working directory: /home/jos/work/research/qmb-plugin-webdev
[INFO] Cleaning up after release...
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 3 seconds
[INFO] Finished at: Tue Aug 04 12:57:00 CEST 2009
[INFO] Final Memory: 9M/56M
[INFO]
{noformat}
I tried this with M221-rc2, M221-rc1, M220, M210, M2010 and M209. To simplify
things I've replaced the original POM with a stripped-down effective-pom
(without parent), so everything is contained in the attached single POM file
that still behaves so weird. All you have to do is to adjust the SCM URLs to
some valid location.
Note, that this project has been released before without problems (it's a
plugin), just the dependencies have been updated from M209 to M210 artifacts.
--
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: (MRELEASE-469) Plugin hangs in preparation while checking deps and plugins for snapshots
[
http://jira.codehaus.org/browse/MRELEASE-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible closed MRELEASE-469.
---
Resolution: Not A Bug
Stupid me! I forgot that I colorized my Maven output last week (piping the
output of Maven through sed and add some ANSI color escape codes)! While this
is normally really helpful for large builds, it does not work at all for
interactive plugin communication. Sorry for the noise.
> Plugin hangs in preparation while checking deps and plugins for snapshots
> -
>
> Key: MRELEASE-469
> URL: http://jira.codehaus.org/browse/MRELEASE-469
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-8, 2.0-beta-9
> Environment: Gentoo Linux, Sun JDK 1.5, 32-bit
>Reporter: Joerg Schaible
>Priority: Blocker
> Attachments: pom.xml
>
>
> The release plugin completely hangs when checking in "release:prepare" the
> dependencies and plugins for snapshot versions and I will have to kill it (^C
> after some minutes):
> {noformat}
> $ mvn release:prepare -Dtag=v_0.0.1
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Scalaris QMB Plugin
> [INFO]task-segment: [release:prepare] (aggregator-style)
> [INFO]
>
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: /bin/sh -c cd /home/jos/work/research/qmb-plugin-webdev &&
> svn --non-interactive status
> [INFO] Working directory: /home/jos/work/research/qmb-plugin-webdev
> [INFO] Checking dependencies and plugins for snapshots ...
> ^C
> $ mvn release:rollback
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Scalaris QMB Plugin
> [INFO]task-segment: [release:rollback] (aggregator-style)
> [INFO]
>
> [INFO] [release:rollback {execution: default-cli}]
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /home/jos/work/research/qmb-plugin-webdev &&
> svn --non-interactive commit --file /tmp/maven-scm-322645963.commit --targets
> /tmp/maven-scm-8571115898032334692-targets
> [INFO] Working directory: /home/jos/work/research/qmb-plugin-webdev
> [INFO] Cleaning up after release...
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 3 seconds
> [INFO] Finished at: Tue Aug 04 12:57:00 CEST 2009
> [INFO] Final Memory: 9M/56M
> [INFO]
>
> {noformat}
> I tried this with M221-rc2, M221-rc1, M220, M210, M2010 and M209. To simplify
> things I've replaced the original POM with a stripped-down effective-pom
> (without parent), so everything is contained in the attached single POM file
> that still behaves so weird. All you have to do is to adjust the SCM URLs to
> some valid location.
> Note, that this project has been released before without problems (it's a
> plugin), just the dependencies have been updated from M209 to M210 artifacts.
--
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-2979) Cross module dependencies for multi-module site
[ http://jira.codehaus.org/browse/MNG-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185885#action_185885 ] Guillaume Barry commented on MNG-2979: -- Hi, I got the problem with maven 2.0.9 mvn site or mvn clean install site doesn't work. mvn clean install is working and of course after that mvn site works (using local repository) is there a workaround with a single command line build ? > Cross module dependencies for multi-module site > --- > > Key: MNG-2979 > URL: http://jira.codehaus.org/browse/MNG-2979 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.5 > Environment: Linux 2.6.18-gentoo-r6 #2 SMP PREEMPT Wed Feb 28 > 10:25:50 CET 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux >Reporter: Wally Wallou >Assignee: John Casey >Priority: Minor > Fix For: 2.2.2 > > Attachments: build.log, gwttk-m2.zip, maven-core-2.0.11-SNAPSHOT.jar, > maven.diff, maven.diff, mng-2979-testcase.tar.gz, package.txt, site.txt, > to-package.log > > > Considering a multi-module project A which declares two sub-projects > (modules) B and C. Having module C indicating in its POM a dependency against > module B. Compilation and packaging work great without having to install > module B in maven local repository, it locate module B for module C using > declared aggregation at top level project A. > But for site goals it does not work, that is to say when maven try to > generate site for module C it tells that module B artifact cannot be found. > So we have to install module B to be able to generate module C site, whereas > it is not necessary for compile or package goals. > I think it would be great if site goals behaves like compile and package with > aggregation. It would be more coherent, and avoid to have to run install just > for site goals. -- 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: (DOXIASITETOOLS-30) Update DocumentRenderer interface
Update DocumentRenderer interface - Key: DOXIASITETOOLS-30 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-30 Project: Maven Doxia Sitetools Issue Type: Sub-task Components: Doc renderer Affects Versions: 1.2 Reporter: Vincent Siveton Due to [r800800|http://svn.apache.org/viewvc?rev=800800&view=rev] -- 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: (DOXIASITETOOLS-21) Add Velocity support to DocRenderer
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed DOXIASITETOOLS-21. - Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.1.2 Fixed in [r800800|http://svn.apache.org/viewvc?rev=800800&view=rev] but we need to fix the interface (see subtask) > Add Velocity support to DocRenderer > --- > > Key: DOXIASITETOOLS-21 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-21 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Doc renderer >Affects Versions: 1.1 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.1.2 > > -- 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: (MPDF-24) Support Velocity files
Support Velocity files -- Key: MPDF-24 URL: http://jira.codehaus.org/browse/MPDF-24 Project: Maven 2.x PDF Plugin Issue Type: New Feature Affects Versions: 1.1 Reporter: Vincent Siveton See DOXIASITETOOLS-21 -- 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: (MPDF-24) Support Velocity files
[ http://jira.codehaus.org/browse/MPDF-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPDF-24. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.1 fixed in [r800813|http://svn.apache.org/viewvc?rev=800813&view=rev] TODO in the subtask > Support Velocity files > -- > > Key: MPDF-24 > URL: http://jira.codehaus.org/browse/MPDF-24 > Project: Maven 2.x PDF Plugin > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.1 > > > See DOXIASITETOOLS-21 -- 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: (MPDF-25) Use inteface instead of impl due to DOXIASITETOOLS-30
Use inteface instead of impl due to DOXIASITETOOLS-30 - Key: MPDF-25 URL: http://jira.codehaus.org/browse/MPDF-25 Project: Maven 2.x PDF Plugin Issue Type: Sub-task Affects Versions: 1.1 Reporter: Vincent Siveton -- 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-4281) remote snapshots are prefered over locally installed snapshots in maven3 svn rev 800808
remote snapshots are prefered over locally installed snapshots in maven3 svn rev 800808 --- Key: MNG-4281 URL: http://jira.codehaus.org/browse/MNG-4281 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0 Reporter: Igor Fedorenko Attachments: snapshots.zip Steps to reproduce the problem. 1. Install attached snapshots-a project with "mvn clean install" using maven 2.2.0. 2. Package attached snapshots-b project with "mvn clean package" using recent maven 3 (I've tried svn rev 800808) Note that "snapshot snapshots:snapshots-a:0.0.1-SNAPSHOT: checking for updates from nexus", which I believe indicates that maven3 checked remote repository "nexus" for snapshots updates. -- 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: (DOXIA-356) Relative URLs for images don't work with PDF
Relative URLs for images don't work with PDF Key: DOXIA-356 URL: http://jira.codehaus.org/browse/DOXIA-356 Project: Maven Doxia Issue Type: Bug Components: Book Affects Versions: 1.1.2 Environment: OSX 10.5.7, Java 5 Reporter: Nathan Sowatskey Hi With APT based sites only, one can use a relative URL for images: [../images/picture.jpg] With the PDF generation though, this won't work, so we need to have: [http://site/images/picture.jpg] Is there a good reason for this. Can it be changed? Thanks Nathan -- 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-2541) jt400-full-6.5.1-bundle
jt400-full-6.5.1-bundle --- Key: MAVENUPLOAD-2541 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2541 Project: Maven Upload Requests Issue Type: Wish Reporter: Jeff Lee Attachments: jt400-6.4-bundle.jar, jt400-6.5.1-bundle.jar https://sourceforge.net/projects/jt400 http://jt400.sourceforge.net/ http://jt400.sourceforge.net/team.html The IBM Toolbox for Java (also known as JTOpen) is a library of Java classes supporting the client/server and internet programming models to a system running OS/400, i5/OS, or IBM i. The classes can be used by Java applets, servlets, and applications to easily access OS/400, i5/OS, and IBM i data and resources. -- 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-2542) jt400-full-6.3-bundle
jt400-full-6.3-bundle - Key: MAVENUPLOAD-2542 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2542 Project: Maven Upload Requests Issue Type: Wish Reporter: Jeff Lee Attachments: jt400-6.2-bundle.jar, jt400-6.3-bundle.jar https://sourceforge.net/projects/jt400 http://jt400.sourceforge.net/ http://jt400.sourceforge.net/team.html The IBM Toolbox for Java (also known as JTOpen) is a library of Java classes supporting the client/server and internet programming models to a system running OS/400, i5/OS, or IBM i. The classes can be used by Java applets, servlets, and applications to easily access OS/400, i5/OS, and IBM i data and resources. -- 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-2543) jt400-full-6.1-bundle
jt400-full-6.1-bundle - Key: MAVENUPLOAD-2543 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2543 Project: Maven Upload Requests Issue Type: Wish Reporter: Jeff Lee Attachments: jt400-6.1-bundle.jar https://sourceforge.net/projects/jt400 http://jt400.sourceforge.net/ http://jt400.sourceforge.net/team.html The IBM Toolbox for Java (also known as JTOpen) is a library of Java classes supporting the client/server and internet programming models to a system running OS/400, i5/OS, or IBM i. The classes can be used by Java applets, servlets, and applications to easily access OS/400, i5/OS, and IBM i data and resources. -- 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-4211) [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+
[ http://jira.codehaus.org/browse/MNG-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185933#action_185933 ] John Casey commented on MNG-4211: - @Sylvain- Unfortunately, one of the bugfixes I had for RC1 addressed the single-download problem...but it got lost in version-control on my localhost, and didn't make it into RC1. This and the other issue with cross-pollution of wagon providers has been addressed in RC2. I'm not sure about the need to set https.proxyHost/Port, though. Can you try out 2.2.1-RC2: https://repository.apache.org/content/repositories/maven-staging-008/org/apache/maven/apache-maven/2.2.1-RC2 and report your results to the '[PLEASE TEST] Maven 2.2.1-RC2' thread out on the users or dev list? That would be a great help. > [regression] proxy access broken between maven version 2.0.10 and 2.1. > Probably due to addition of wagon 1.0-beta-4+ > - > > Key: MNG-4211 > URL: http://jira.codehaus.org/browse/MNG-4211 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1.0, 2.2.0 > Environment: WinXP SP2 >Reporter: Robert Glover Jr >Priority: Blocker > Fix For: 2.2.2 > > Attachments: jira_files_4_total.zip > > > At a large company, maven become impossible to use via proxy when maven > upgraded from 1.0.10 to 2.1. maven has always worked fine via proxy in 2.0.9 > and continues to work fine. however maven via proxy always fails in version > 2.1.0 and higher. > Attached is a zip file containing 1) log of GMAIL chat between the > creater of this JIRA and a maven developer. 2) two console outputs of > running maven 2.2. RC3 showing the proxy failure messages. 3) setting.xml > (with comments stripped out) -- 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-2543) jt400-full-6.1-bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185937#action_185937 ] Jeff Lee commented on MAVENUPLOAD-2543: --- Please change the summary description to "jt400-6.1-bundle". > jt400-full-6.1-bundle > - > > Key: MAVENUPLOAD-2543 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2543 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Jeff Lee > Attachments: jt400-6.1-bundle.jar > > > https://sourceforge.net/projects/jt400 > http://jt400.sourceforge.net/ > http://jt400.sourceforge.net/team.html > The IBM Toolbox for Java (also known as JTOpen) is a library of Java classes > supporting the client/server and internet programming models to a system > running OS/400, i5/OS, or IBM i. The classes can be used by Java applets, > servlets, and applications to easily access OS/400, i5/OS, and IBM i data and > resources. -- 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-2542) jt400-full-6.3-bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185938#action_185938 ] Jeff Lee commented on MAVENUPLOAD-2542: --- Please change the summary description to "jt400-6.3-bundle". > jt400-full-6.3-bundle > - > > Key: MAVENUPLOAD-2542 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2542 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Jeff Lee > Attachments: jt400-6.2-bundle.jar, jt400-6.3-bundle.jar > > > https://sourceforge.net/projects/jt400 > http://jt400.sourceforge.net/ > http://jt400.sourceforge.net/team.html > The IBM Toolbox for Java (also known as JTOpen) is a library of Java classes > supporting the client/server and internet programming models to a system > running OS/400, i5/OS, or IBM i. The classes can be used by Java applets, > servlets, and applications to easily access OS/400, i5/OS, and IBM i data and > resources. -- 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-2541) jt400-full-6.5.1-bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185939#action_185939 ] Jeff Lee commented on MAVENUPLOAD-2541: --- Please change the summary description to "jt400-6.5.1-bundle". > jt400-full-6.5.1-bundle > --- > > Key: MAVENUPLOAD-2541 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2541 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Jeff Lee > Attachments: jt400-6.4-bundle.jar, jt400-6.5.1-bundle.jar > > > https://sourceforge.net/projects/jt400 > http://jt400.sourceforge.net/ > http://jt400.sourceforge.net/team.html > The IBM Toolbox for Java (also known as JTOpen) is a library of Java classes > supporting the client/server and internet programming models to a system > running OS/400, i5/OS, or IBM i. The classes can be used by Java applets, > servlets, and applications to easily access OS/400, i5/OS, and IBM i data and > resources. -- 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-18) Repository bundles don't include .asc files or attached artifacts other than sources and javadocs
Repository bundles don't include .asc files or attached artifacts other than sources and javadocs - Key: MREPOSITORY-18 URL: http://jira.codehaus.org/browse/MREPOSITORY-18 Project: Maven 2.x Repository Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: John Casey -- 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-2544) 'Sync my repo' request
'Sync my repo' request -- Key: MAVENUPLOAD-2544 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2544 Project: Maven Upload Requests Issue Type: Wish Reporter: Damian Steer I believe you need the following: "net.rootdev","ma...@rootdev.net:/home/maven/site/repo","rsync_ssh","Damian Steer","pl...@mac.com",, Hope this is all correct. -- 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: (MNG-4281) remote snapshots are prefered over locally installed snapshots in maven3 svn rev 800808
[ http://jira.codehaus.org/browse/MNG-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4281. -- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 3.0-alpha-3 Fixed in [r800922|http://svn.apache.org/viewvc?view=rev&revision=800922]. > remote snapshots are prefered over locally installed snapshots in maven3 svn > rev 800808 > --- > > Key: MNG-4281 > URL: http://jira.codehaus.org/browse/MNG-4281 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0 >Reporter: Igor Fedorenko >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-3 > > Attachments: snapshots.zip > > > Steps to reproduce the problem. > 1. Install attached snapshots-a project with "mvn clean install" using maven > 2.2.0. > 2. Package attached snapshots-b project with "mvn clean package" using recent > maven 3 (I've tried svn rev 800808) > Note that "snapshot snapshots:snapshots-a:0.0.1-SNAPSHOT: checking for > updates from nexus", which I believe indicates that maven3 checked remote > repository "nexus" for snapshots updates. -- 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: (MENFORCER-81) Create a banned plugins rule
[ http://jira.codehaus.org/browse/MENFORCER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-81. -- Assignee: Brian Fox Resolution: Fixed Fix Version/s: 1.0-beta-2 Applied > Create a banned plugins rule > > > Key: MENFORCER-81 > URL: http://jira.codehaus.org/browse/MENFORCER-81 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 1.0-beta-1 >Reporter: Marvin Froeder >Assignee: Brian Fox > Fix For: 1.0-beta-2 > > Attachments: banned-plugin.patch, banned-plugin.patch > > > I created a new rule for banned plugins -- 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-4275) [regression] Direct relocations no longer log at WARNING level : MNG-3380 conflicts with MNG-1689
[ http://jira.codehaus.org/browse/MNG-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4275: Assignee: John Casey Fix Version/s: 2.2.1 Summary: [regression] Direct relocations no longer log at WARNING level : MNG-3380 conflicts with MNG-1689 (was: Direct relocations no longer log at WARNING level : MNG-3380 conflicts with MNG-1689) > [regression] Direct relocations no longer log at WARNING level : MNG-3380 > conflicts with MNG-1689 > - > > Key: MNG-4275 > URL: http://jira.codehaus.org/browse/MNG-4275 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.0 > Environment: Apache Maven 2.2.1-RC2-SNAPSHOT (r799976; 2009-08-02 > 19:18:34+1000) > Java version: 1.6.0_14 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.14/jre > Default locale: en_AU, platform encoding: UTF-8 > OS name: "linux" version: "2.6.28-14-generic" arch: "amd64" Family: "unix" >Reporter: Brett Randall >Assignee: John Casey >Priority: Minor > Fix For: 2.2.1 > > Attachments: MNG-4275.maven-trunks.patch > > > Changes for MNG-3380 [1] to Process relocations before child-nodes are > discovered during artifact collection, conflict with MNG-1689 [2] " Only > print relocation warnings in standard output for the current pom". This > results in a regression where (direct) relocations are no longer logged at > WARNING level and are only logged at DEBUG. Direct relocations should be > logged at WARNING level. > @675087 [3] MNG-3380 was applied to DefaultArtifactCollector - the result is > that the call to MavenMetadataSource#retrieveRelocatedArtifact() (then > retrieveRelocatedProject()) occur before the call to > artifact.setDependencyTrail( node.getDependencyTrail() ); in > DefaultArtifactCollector. This results in a null list in > MavenMetadataSource, which then fails the if-test to log at WARNING level > introduced in MNG-1689. > With a quick inspection I couldn't see the harm in bringing forward the call > to: > artifact.setDependencyTrail( node.getDependencyTrail() ) > , it is already called once when about to throw an exception, and this call > can be replaced. Proposed patch makes the setDependencyTrail call earlier, > prior to relocation detection. > See also Nabble post [4]. > [1] http://jira.codehaus.org/browse/MNG-3380 > [2] http://jira.codehaus.org/browse/MNG-1689 > [3] http://svn.apache.org/viewvc?view=rev&revision=675087 > [4] > http://www.nabble.com/2.0.9-%3E2.1.0-change-regression-in-relocation-WARNING--td24368186.html -- 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-4275) [regression] Direct relocations no longer log at WARNING level : MNG-3380 conflicts with MNG-1689
[ http://jira.codehaus.org/browse/MNG-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185974#action_185974 ] John Casey commented on MNG-4275: - This needs a test case before we can apply the patch. > [regression] Direct relocations no longer log at WARNING level : MNG-3380 > conflicts with MNG-1689 > - > > Key: MNG-4275 > URL: http://jira.codehaus.org/browse/MNG-4275 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.0 > Environment: Apache Maven 2.2.1-RC2-SNAPSHOT (r799976; 2009-08-02 > 19:18:34+1000) > Java version: 1.6.0_14 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.14/jre > Default locale: en_AU, platform encoding: UTF-8 > OS name: "linux" version: "2.6.28-14-generic" arch: "amd64" Family: "unix" >Reporter: Brett Randall >Assignee: John Casey >Priority: Minor > Fix For: 2.2.1 > > Attachments: MNG-4275.maven-trunks.patch > > > Changes for MNG-3380 [1] to Process relocations before child-nodes are > discovered during artifact collection, conflict with MNG-1689 [2] " Only > print relocation warnings in standard output for the current pom". This > results in a regression where (direct) relocations are no longer logged at > WARNING level and are only logged at DEBUG. Direct relocations should be > logged at WARNING level. > @675087 [3] MNG-3380 was applied to DefaultArtifactCollector - the result is > that the call to MavenMetadataSource#retrieveRelocatedArtifact() (then > retrieveRelocatedProject()) occur before the call to > artifact.setDependencyTrail( node.getDependencyTrail() ); in > DefaultArtifactCollector. This results in a null list in > MavenMetadataSource, which then fails the if-test to log at WARNING level > introduced in MNG-1689. > With a quick inspection I couldn't see the harm in bringing forward the call > to: > artifact.setDependencyTrail( node.getDependencyTrail() ) > , it is already called once when about to throw an exception, and this call > can be replaced. Proposed patch makes the setDependencyTrail call earlier, > prior to relocation detection. > See also Nabble post [4]. > [1] http://jira.codehaus.org/browse/MNG-3380 > [2] http://jira.codehaus.org/browse/MNG-1689 > [3] http://svn.apache.org/viewvc?view=rev&revision=675087 > [4] > http://www.nabble.com/2.0.9-%3E2.1.0-change-regression-in-relocation-WARNING--td24368186.html -- 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: (MREPOSITORY-18) Repository bundles don't include .asc files or attached artifacts other than sources and javadocs
[ http://jira.codehaus.org/browse/MREPOSITORY-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MREPOSITORY-18. - Resolution: Fixed added code that scans the outputDirectory / localRepository directory (depending on the mojo) and grabs all files that have the finalName prefix, other than the POM file which is already located. Once this scanning is done, the new code then prompts the user to verify the file list and either enter '0' to approve it, or enter the numbers in the list for the files that should be removed...the code will remove, and reprompt. This is more inclusive than simply looking for the javadoc and sources artifacts, and the warnings are preserved for missing javadoc/sources artifacts. > Repository bundles don't include .asc files or attached artifacts other than > sources and javadocs > - > > Key: MREPOSITORY-18 > URL: http://jira.codehaus.org/browse/MREPOSITORY-18 > Project: Maven 2.x Repository Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: John Casey >Assignee: John Casey > -- 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: (MREPOSITORY-18) Repository bundles don't include .asc files or attached artifacts other than sources and javadocs
[ http://jira.codehaus.org/browse/MREPOSITORY-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MREPOSITORY-18: -- Fix Version/s: 2.2 > Repository bundles don't include .asc files or attached artifacts other than > sources and javadocs > - > > Key: MREPOSITORY-18 > URL: http://jira.codehaus.org/browse/MREPOSITORY-18 > Project: Maven 2.x Repository Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.2 > > -- 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: (MREPOSITORY-13) NPE
[ http://jira.codehaus.org/browse/MREPOSITORY-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MREPOSITORY-13. - Assignee: John Casey Resolution: Won't Fix It looks like the section of your settings.xml is incorrect. If you're mirroring to a file location, please remember to use the file:/ protocol prefix. > NPE > --- > > Key: MREPOSITORY-13 > URL: http://jira.codehaus.org/browse/MREPOSITORY-13 > Project: Maven 2.x Repository Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: OS name: "linux" version: "2.6.28-11-generic" arch: > "i386" > Java version: 1.6.0_13 >Reporter: Aaron Stromas >Assignee: John Casey > > I have configured Artifactory and have tried to build Spring 2.0.7 sample > projects. > Running mvn clean compile generates NPE: > java.lang.NullPointerException > at org.apache.maven.wagon.PathUtils.protocol(PathUtils.java:206) > at > org.apache.maven.wagon.repository.Repository.setUrl(Repository.java:121) > at > org.apache.maven.wagon.repository.Repository.(Repository.java:74) > at > org.apache.maven.artifact.repository.DefaultArtifactRepository.(DefaultArtifactRepository.java:87) > at > org.apache.maven.artifact.repository.DefaultArtifactRepository.(DefaultArtifactRepository.java:57) > at > org.apache.maven.artifact.manager.DefaultWagonManager.addMirror(DefaultWagonManager.java:940) > at > org.apache.maven.DefaultMaven.resolveParameters(DefaultMaven.java:657) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:270) > 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: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) > I saw a couple of posts about missing and > elemants, so I have created the and > from settings.xml into the project's pom.xml. To no avail, I'm still getting > the NPE. > Here are my repositories, as they appear in settings.xml: > > > central > Artifactory Repository > http://localhost.com:8081/artifactory/repo > > fals > > > > snapshots > Artifactory Repository > http://localhost.com:8081/artifactory/repo > > false > > > > > > central > http://localhost.com:8081/artifactory/plugin-releases > > false > > > > snapshots > http://localhost.com:8081/artifactory/plugin-snapshots > > false > > > -- 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] Moved: (MNG-4282) improve the error message that tells the user how to install missing jars locally
[
http://jira.codehaus.org/browse/MNG-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey moved MREPOSITORY-8 to MNG-4282:
---
Complexity: Intermediate
Key: MNG-4282 (was: MREPOSITORY-8)
Project: Maven 2 (was: Maven 2.x Repository Plugin)
> improve the error message that tells the user how to install missing jars
> locally
> -
>
> Key: MNG-4282
> URL: http://jira.codehaus.org/browse/MNG-4282
> Project: Maven 2
> Issue Type: Improvement
> Environment: Maven 2.0.4, all platforms
>Reporter: S.
>Priority: Minor
>
> When a missing dependency is detected, maven reports to the user how to
> install that dependency locally ('mvn install:install-file...').
> However, the instructions are missing the '-DgeneratePom=true' directive.
> Without it, maven keeps looking for the dependencies in the repo, causing
> unnecessary delays in the build.
> I suggest to add '-DgeneratePom=true' to the error message.
--
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: (MREPOSITORY-7) When given blank repositories cannot attain goal
[ http://jira.codehaus.org/browse/MREPOSITORY-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MREPOSITORY-7. Assignee: John Casey Resolution: Won't Fix At a minimum, you need to point the for the repository to some location. This is required by Maven. In any case, the issue certainly doesn't belong in the Maven Repository Plugin JIRA project. > When given blank repositories cannot attain goal > > > Key: MREPOSITORY-7 > URL: http://jira.codehaus.org/browse/MREPOSITORY-7 > Project: Maven 2.x Repository Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Matthew Purland >Assignee: John Casey > > With the example in the pom.xml > > > > > > > > > > > Maven fails with the following: > [INFO] Scanning for projects... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at org.apache.maven.wagon.PathUtils.protocol(PathUtils.java:206) > at > org.apache.maven.wagon.repository.Repository.setUrl(Repository.java:119) > at > org.apache.maven.wagon.repository.Repository.(Repository.java:72) > at > org.apache.maven.artifact.repository.DefaultArtifactRepository.(DefaultArtifactRepository.java:84) > at > org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createArtifactRepository(DefaultArtifactRepositoryFactory.java:82) > at > org.apache.maven.project.ProjectUtils.buildArtifactRepository(ProjectUtils.java:102) > at > org.apache.maven.project.ProjectUtils.buildArtifactRepositories(ProjectUtils.java:53) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildArtifactRepositories(DefaultMavenProjectBuilder.java:811) > at > org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:958) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:674) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:416) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) > 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) -- 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-4282) improve the error message that tells the user how to install missing jars locally
[
http://jira.codehaus.org/browse/MNG-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-4282:
Affects Version/s: 2.0.6
Fix Version/s: 2.2.x
> improve the error message that tells the user how to install missing jars
> locally
> -
>
> Key: MNG-4282
> URL: http://jira.codehaus.org/browse/MNG-4282
> Project: Maven 2
> Issue Type: Improvement
>Affects Versions: 2.0.6
> Environment: Maven 2.0.4, all platforms
>Reporter: S.
>Priority: Minor
> Fix For: 2.2.x
>
>
> When a missing dependency is detected, maven reports to the user how to
> install that dependency locally ('mvn install:install-file...').
> However, the instructions are missing the '-DgeneratePom=true' directive.
> Without it, maven keeps looking for the dependencies in the repo, causing
> unnecessary delays in the build.
> I suggest to add '-DgeneratePom=true' to the error message.
--
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-4282) improve the error message that tells the user how to install missing jars locally
[
http://jira.codehaus.org/browse/MNG-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185986#action_185986
]
Benjamin Bentmann commented on MNG-4282:
As per MINSTALL-57, {{generatePom=true}} is the default behavior for the
Install Plugin unless a POM is already installed.
> improve the error message that tells the user how to install missing jars
> locally
> -
>
> Key: MNG-4282
> URL: http://jira.codehaus.org/browse/MNG-4282
> Project: Maven 2
> Issue Type: Improvement
>Affects Versions: 2.0.6
> Environment: Maven 2.0.4, all platforms
>Reporter: S.
>Priority: Minor
> Fix For: 2.2.x
>
>
> When a missing dependency is detected, maven reports to the user how to
> install that dependency locally ('mvn install:install-file...').
> However, the instructions are missing the '-DgeneratePom=true' directive.
> Without it, maven keeps looking for the dependencies in the repo, causing
> unnecessary delays in the build.
> I suggest to add '-DgeneratePom=true' to the error message.
--
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-4162) Removal of all reporting logic from the core of Maven
[ http://jira.codehaus.org/browse/MNG-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185990#action_185990 ] Olivier Lamy commented on MNG-4162: --- note [rev 800978|http://svn.apache.org/viewvc?view=rev&revision=800978] is needed for be able to use maven-project-info-reports-plugin. > Removal of all reporting logic from the core of Maven > - > > Key: MNG-4162 > URL: http://jira.codehaus.org/browse/MNG-4162 > Project: Maven 2 > Issue Type: Improvement >Reporter: Jason van Zyl > Fix For: 3.0 > > > Any reporting implementation will be implemented as a plugin. Maven will > provide any information, APIs, and extension points to make this possible. > But the conflation of building with reporting in the core makes it almost > impossible for anyone two understand the distinction, makes it impossible to > have alternate implementations and couple many tools like Doxia directly to > the core which is unacceptable for Maven 3.x. -- 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: (ARCHETYPE-110) Maven archetype overwrites parent information
[
http://jira.codehaus.org/browse/ARCHETYPE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185992#action_185992
]
Jeff Trimm commented on ARCHETYPE-110:
--
We tried the alpha-5 snapshot and this is not fixed yet. The parent POM
name/version/groupId is still getting stomped. Note: this is a multi-module
project and the POM containing the parent declaration we want to preserve is in
a sub-module. We used this version:
http://repository.apache.org/content/groups/snapshots-group/org/apache/maven/plugins/maven-archetype-plugin/2.0-alpha-5-SNAPSHOT/
> Maven archetype overwrites parent information
> -
>
> Key: ARCHETYPE-110
> URL: http://jira.codehaus.org/browse/ARCHETYPE-110
> Project: Maven Archetype
> Issue Type: Bug
>Reporter: Peter Liljenberg
>Priority: Critical
> Fix For: 2.0-alpha-5
>
> Attachments: ARCHETYPE-110.patch
>
>
> When creating a new archetype that I want to use for my projects I ran into
> some trouble with the created/copied pom.xml.
> The archetype pom.xml (\src\main\resources\archetype-resources\pom.xml) looks
> like this:
>
>
> group
> masterpom
> 1.0
>
> 4.0.0
> group
> ${artifactId}
> 1.0
>
> When I run my archetype it creates a pom.xml that looks like:
>
>
> integration
> group
> 1.0
>
> 4.0.0
> group
> test
> 1.0
>
> Where "integration" is the name of the pom in the folder that I'm running mvn
> archetype:create from.
> Digging into the source we find in DefaultArchetype.java that processTemplate
> is indeed reading the parent pom and overwriting whatever was found in the
> original pom.xml.
> Is this really what we want to achieve? It should be possible to keep the
> parent-pom from the pom.xml in the archetype since it reduces the need for
> all developers to change their newly created pom.xml.
>
> processTemplates
> if ( parentModel != null )
> {
> Parent parent = new Parent();
> parent.setGroupId( parentModel.getGroupId() );
> if ( parent.getGroupId() == null )
> {
> parent.setGroupId( parentModel.getParent().getGroupId() );
> }
> parent.setArtifactId( parentModel.getArtifactId() );
> parent.setVersion( parentModel.getVersion() );
> if ( parent.getVersion() == null )
> {
> parent.setVersion( parentModel.getParent().getVersion() );
> }
> generatedModel.setParent( parent );
>
> Two alternative solutions:
> * If the parent-pom is specified in the archetype-pom, don't replace it
> * A parameter that we can supply that will leave the archetype-pom parent
> setting untouched.
> I vote for solution number 1
--
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: (MREPOSITORY-3) Please add support for multi-module projects in repository:bundle-create mojo
[ http://jira.codehaus.org/browse/MREPOSITORY-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MREPOSITORY-3. Assignee: John Casey Resolution: Fixed Fix Version/s: 2.2 enabled bundle-create for packaging == pom, which allows multimodule processing. The result will be a bundle for each module project, in the module's target directory. Additionally, batch mode will disable the file-selection prompt and cause Maven to accept all files beginning with $finalName found in the outputDirectory / local-repo-directory for the project. > Please add support for multi-module projects in repository:bundle-create mojo > - > > Key: MREPOSITORY-3 > URL: http://jira.codehaus.org/browse/MREPOSITORY-3 > Project: Maven 2.x Repository Plugin > Issue Type: New Feature > Environment: Java 1.5, WinXP >Reporter: John R Fallows >Assignee: John Casey > Fix For: 2.2 > > > Currently the repository:bundle-create mojo only supports single module > upload bundles, so multi-module bundles must be created manually, once for > each sub-module, and each individual bundle file must be uploaded to a public > site individually. > In addition, the "pom" packaging (which is often used by the parent pom of a > multi-module project) is not supported repository:bundle-create, so upload > bundles for projects with "pom" packaging must be created manually, before > uploading to a public site. > Please support multi-module repository:bundle-create mojo such that: > $ mvn repository:bundle-create > in the top level of a multi-module project produces a single archive that can > be used to upload the multi-module project artifacts to ibiblio. -- 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: (MDEP-225) Dependency plugin seems to unpack archive even, if it is already unpacked
Dependency plugin seems to unpack archive even, if it is already unpacked - Key: MDEP-225 URL: http://jira.codehaus.org/browse/MDEP-225 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack Affects Versions: 2.1 Reporter: Jason Chaffee Assignee: Brian Fox The plugin used to be smart about not unpacking archives if it found the archive was already unpacked (maybe I was doing something different than..not sure). However, now it unpacks the archive every time, no matter what I try to keep it from doing it, including using overwriteIfNewer. I would like to be able to run the build once to extract the archive, then not have it extracted again, unless I clean the target directory because the archive takes several minutes to unpack. Here are the steps. 1) configure unpack in pom 2) run mvn clean install --> expect unpacking 3) run mvn install --> do not expect unpacking as it is still unpaced from step (2) -- 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-595) jst.web facet is inconsistently determined
jst.web facet is inconsistently determined
--
Key: MECLIPSE-595
URL: http://jira.codehaus.org/browse/MECLIPSE-595
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: WTP support
Affects Versions: 2.7
Reporter: Darien Hager
Priority: Minor
The first problem is the plugin chooses the wrong facet when it sees certain
dependencies.
The second is that even explicit facet choices won't override this, and merely
create a duplicate entry in the generated .settings file. At the very least
there should be some sort of warning text.
__
If you have the dependency:
{code}
javax.servlet
servlet-api
2.5
provided
{code}
The plugin will correctly create a jst.web facet of 2.5. However, this feature
breaks down when it encounters:
{code}
org.apache.tomcat
servlet-api
6.0.18
provided
{code}
And the plugin will chose a jst.web version of *6.0*, which thoroughly
confuses Eclipse. In fact, you can't fix the problem without *manually* editing
the _org.eclipse.wst.common.project.facet.core.xml_ file because Eclipse's GUI
is paralyzed by it.
This may be the wrong dependency to have, but the behavior is undocumented ( ?
) and caused me to waste a lot of time trying to figure out what was going on.
There should at least be some sort of warning.
Lastly, if you try to use _additionalProjectnatures_ to fix the problem...
{code}
2.5
{code}
You get an even more broken _org.eclipse.wst.common.project.facet.core.xml_
that repeats the facet twice.
{code}
faceted-project>
{code}
__
Requested fix:
1. When the jst.web version is "autodetected", have an INFO or DEBUG line about
it.
2. If the jst.web faced is explicit in the plugin configuration, it should
override and replace the autodetected version.
--
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] Moved: (WAGON-284) Artifacts are uploaded twice in the case of HTTP redirection
[ http://jira.codehaus.org/browse/WAGON-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey moved MNG-4268 to WAGON-284: --- Affects Version/s: (was: 2.1.0) 1.0-beta-6 Component/s: (was: Deployment) wagon-http Complexity: (was: Intermediate) Key: WAGON-284 (was: MNG-4268) Project: Maven Wagon (was: Maven 2) > Artifacts are uploaded twice in the case of HTTP redirection > > > Key: WAGON-284 > URL: http://jira.codehaus.org/browse/WAGON-284 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 1.0-beta-6 > Environment: Debian unstable, Sun JDK 6.0u14 >Reporter: Alex Hvostov >Priority: Minor > > When deploying to an HTTP (not DAV) repository, if the request is redirected, > the artifact is uploaded twice: once for the original request, and then again > at the redirect location. > Please consider using "Expect: 100-continue" when uploading, so as not to > waste bandwidth in the case of a redirect. See RFC 2616 section 8.2.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] Commented: (WAGON-284) Artifacts are uploaded twice in the case of HTTP redirection
[ http://jira.codehaus.org/browse/WAGON-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=186001#action_186001 ] John Casey commented on WAGON-284: -- This is a problem in the httpclient-driven wagon, which is what we defaulted to in maven 2.2.0 > Artifacts are uploaded twice in the case of HTTP redirection > > > Key: WAGON-284 > URL: http://jira.codehaus.org/browse/WAGON-284 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 1.0-beta-6 > Environment: Debian unstable, Sun JDK 6.0u14 >Reporter: Alex Hvostov >Priority: Minor > > When deploying to an HTTP (not DAV) repository, if the request is redirected, > the artifact is uploaded twice: once for the original request, and then again > at the redirect location. > Please consider using "Expect: 100-continue" when uploading, so as not to > waste bandwidth in the case of a redirect. See RFC 2616 section 8.2.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] Moved: (WAGON-283) Maven 2.2.0 fails to follow redirects when deploying artifacts via HTTP
[ http://jira.codehaus.org/browse/WAGON-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey moved MNG-4267 to WAGON-283: --- Affects Version/s: (was: 2.2.0) 1.0-beta-6 Component/s: (was: Deployment) wagon-http Complexity: (was: Intermediate) Key: WAGON-283 (was: MNG-4267) Project: Maven Wagon (was: Maven 2) > Maven 2.2.0 fails to follow redirects when deploying artifacts via HTTP > --- > > Key: WAGON-283 > URL: http://jira.codehaus.org/browse/WAGON-283 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 1.0-beta-6 > Environment: Debian unstable, Sun JDK 6.0u14 >Reporter: Alex Hvostov >Priority: Minor > > A project of mine is set to deploy to a repository by HTTP (not DAV), and > will receive a redirect (301) in so doing. This worked in Maven ≤2.1.0 > (aside from uploading each file twice), but in Maven 2.2.0, it fails with an > exception: > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Failed to transfer file: [FILE]. Return code is: 301 > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying > artifact: Failed to transfer file: [FILE]. Return code is: 301 > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:195) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 17 more > Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: > Error deploying artifact: Failed to transfer file: [FILE]. Return code is: 301 > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:121) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:173) > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer > file: [FILE]. Return code is: 301 > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107) > ... 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: (WAGON-283) Maven 2.2.0 fails to follow redirects when deploying artifacts via HTTP
[ http://jira.codehaus.org/browse/WAGON-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=186000#action_186000 ] John Casey commented on WAGON-283: -- The problem is in the httpclient-driven wagon. > Maven 2.2.0 fails to follow redirects when deploying artifacts via HTTP > --- > > Key: WAGON-283 > URL: http://jira.codehaus.org/browse/WAGON-283 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 1.0-beta-6 > Environment: Debian unstable, Sun JDK 6.0u14 >Reporter: Alex Hvostov >Priority: Minor > > A project of mine is set to deploy to a repository by HTTP (not DAV), and > will receive a redirect (301) in so doing. This worked in Maven ≤2.1.0 > (aside from uploading each file twice), but in Maven 2.2.0, it fails with an > exception: > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Failed to transfer file: [FILE]. Return code is: 301 > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying > artifact: Failed to transfer file: [FILE]. Return code is: 301 > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:195) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 17 more > Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: > Error deploying artifact: Failed to transfer file: [FILE]. Return code is: 301 > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:121) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:173) > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer > file: [FILE]. Return code is: 301 > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:368) > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107) > ... 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: (MNG-4162) Removal of all reporting logic from the core of Maven
[ http://jira.codehaus.org/browse/MNG-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=186003#action_186003 ] Olivier Lamy commented on MNG-4162: --- So it looks to works fine now. Please review core branches. Note no huge hack has been added only new methods. Please review before merging. Thanks > Removal of all reporting logic from the core of Maven > - > > Key: MNG-4162 > URL: http://jira.codehaus.org/browse/MNG-4162 > Project: Maven 2 > Issue Type: Improvement >Reporter: Jason van Zyl > Fix For: 3.0 > > > Any reporting implementation will be implemented as a plugin. Maven will > provide any information, APIs, and extension points to make this possible. > But the conflation of building with reporting in the core makes it almost > impossible for anyone two understand the distinction, makes it impossible to > have alternate implementations and couple many tools like Doxia directly to > the core which is unacceptable for Maven 3.x. -- 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-4275) [regression] Direct relocations no longer log at WARNING level : MNG-3380 conflicts with MNG-1689
[ http://jira.codehaus.org/browse/MNG-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=186008#action_186008 ] Brett Randall commented on MNG-4275: OK - in order to write the test case, since we are testing log-invocation on a relocated artifact, I'll need to: 1) Construct a relocated artifact in the test, and 2) Create a mock Log so that we can test if it is called with warn or debug. I'm not familiar with the existing test-util assets in this area - both might require a bit of work. > [regression] Direct relocations no longer log at WARNING level : MNG-3380 > conflicts with MNG-1689 > - > > Key: MNG-4275 > URL: http://jira.codehaus.org/browse/MNG-4275 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.0 > Environment: Apache Maven 2.2.1-RC2-SNAPSHOT (r799976; 2009-08-02 > 19:18:34+1000) > Java version: 1.6.0_14 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.14/jre > Default locale: en_AU, platform encoding: UTF-8 > OS name: "linux" version: "2.6.28-14-generic" arch: "amd64" Family: "unix" >Reporter: Brett Randall >Assignee: John Casey >Priority: Minor > Fix For: 2.2.1 > > Attachments: MNG-4275.maven-trunks.patch > > > Changes for MNG-3380 [1] to Process relocations before child-nodes are > discovered during artifact collection, conflict with MNG-1689 [2] " Only > print relocation warnings in standard output for the current pom". This > results in a regression where (direct) relocations are no longer logged at > WARNING level and are only logged at DEBUG. Direct relocations should be > logged at WARNING level. > @675087 [3] MNG-3380 was applied to DefaultArtifactCollector - the result is > that the call to MavenMetadataSource#retrieveRelocatedArtifact() (then > retrieveRelocatedProject()) occur before the call to > artifact.setDependencyTrail( node.getDependencyTrail() ); in > DefaultArtifactCollector. This results in a null list in > MavenMetadataSource, which then fails the if-test to log at WARNING level > introduced in MNG-1689. > With a quick inspection I couldn't see the harm in bringing forward the call > to: > artifact.setDependencyTrail( node.getDependencyTrail() ) > , it is already called once when about to throw an exception, and this call > can be replaced. Proposed patch makes the setDependencyTrail call earlier, > prior to relocation detection. > See also Nabble post [4]. > [1] http://jira.codehaus.org/browse/MNG-3380 > [2] http://jira.codehaus.org/browse/MNG-1689 > [3] http://svn.apache.org/viewvc?view=rev&revision=675087 > [4] > http://www.nabble.com/2.0.9-%3E2.1.0-change-regression-in-relocation-WARNING--td24368186.html -- 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
