[jira] Commented: (MPIR-147) Dependencies report hangs while accessing SSL site. Connection never closes
[ http://jira.codehaus.org/browse/MPIR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202228#action_202228 ] Amit m commented on MPIR-147: - The work around mentioned above false false does not work with maven 2.2.1 Maven reports (mvn site) still hang for a long time Is anyone listening? > Dependencies report hangs while accessing SSL site. Connection never closes > --- > > Key: MPIR-147 > URL: http://jira.codehaus.org/browse/MPIR-147 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 2.1 >Reporter: Jerome Lacoste > > mvn site hangs while generating the reports (dump below). This is 100% > reproducible. > This happens while contacting maven-repository.dev.java.net. The connection > is opened and never closed. The connection to this external repository was > done successfully several time in the same build. > Notes: > * a timeout would be useful: > at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312) > at > org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219) > * for some reason, the site report bypass our corporate repository (nexus). > Cf MPIR-137 > * workaround is to enable > false > false > as done in MPIR-137 > Full thread dump Java HotSpot(TM) Client VM (1.5.0_16-133 mixed mode): > "AWT-AppKit" daemon prio=5 tid=0x01038530 nid=0xa0110fa0 runnable > [0x..0xbfffe818] > "Low Memory Detector" daemon prio=5 tid=0x01009030 nid=0x805800 runnable > [0x..0x] > "CompilerThread0" daemon prio=9 tid=0x01008580 nid=0x812c00 waiting on > condition [0x..0xb0b077d8] > "Signal Dispatcher" daemon prio=9 tid=0x01008130 nid=0x811e00 waiting on > condition [0x..0x] > "Finalizer" daemon prio=8 tid=0x01007860 nid=0x819200 in Object.wait() > [0xb0a05000..0xb0a05d90] > at java.lang.Object.wait(Native Method) > - waiting on <0x0a440228> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120) > - locked <0x0a440228> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136) > at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) > "Reference Handler" daemon prio=10 tid=0x01007480 nid=0x817800 in > Object.wait() [0xb0984000..0xb0984d90] > at java.lang.Object.wait(Native Method) > - waiting on <0x0a4402b0> (a java.lang.ref.Reference$Lock) > at java.lang.Object.wait(Object.java:474) > at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) > - locked <0x0a4402b0> (a java.lang.ref.Reference$Lock) > "main" prio=5 tid=0x01001570 nid=0xb0801000 runnable [0xb07fe000..0xb0800148] > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.read(SocketInputStream.java:129) > at > com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293) > at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723) > - locked <0x05a4ba78> (a java.lang.Object) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:680) > at > com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75) > - locked <0x05a4bb28> (a com.sun.net.ssl.internal.ssl.AppInputStream) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) > at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) > at java.io.BufferedInputStream.read(BufferedInputStream.java:313) > - locked <0x06b58100> (a java.io.BufferedInputStream) > at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:681) > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626) > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:957) > - locked <0x06b56708> (a > sun.net.www.protocol.https.DelegateHttpsURLConnection) > at > java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367) > at > sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318) > at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312) > at > org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219) > at > org.apache.maven.report.projectinfo.dependencies.renderer.De
[jira] Created: (MDEP-245) goal to check classpath for duplicate resources/classes
goal to check classpath for duplicate resources/classes --- Key: MDEP-245 URL: http://jira.codehaus.org/browse/MDEP-245 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Reporter: Joerg Schaible Assignee: Brian Fox Priority: Minor The classpath sometimes contains unintended duplicate resources and classes e.g.: # an artifact is present in two different versions at the same time, because it changed its groupId or artifactId, but no relocation POM has been provided by the artifact's author # an artifact has been split into several artifacts (avalon-famework => avalon-framework-api and avalon-framework-impl) # an artifact has a collection of "foreign" classes (CGLIB 2.x contains stuff from ASM 1.5) A new goal of the dependency plugin might detect such cases. Obviously there are cases, when this is expected (stax-api implements stuff provided also by JDK 6) or cannot be avoided in general (even xpp3_min contains two classes from xmlpull-api) or is even part of the spec (SPI files in META-INF/services). -- 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-626) Upgrade Maven dependencies from 2.0.8 to at least 2.0.9 to match minimum version required to build
[ http://jira.codehaus.org/browse/MECLIPSE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Lynch updated MECLIPSE-626: - Attachment: MECLIPSE-626.patch Patch to pom.xml enforcing minimum Maven version of 2.0.9 for dependencies and running the build in all lifecycles. > Upgrade Maven dependencies from 2.0.8 to at least 2.0.9 to match minimum > version required to build > -- > > Key: MECLIPSE-626 > URL: http://jira.codehaus.org/browse/MECLIPSE-626 > Project: Maven 2.x Eclipse Plugin > Issue Type: Task >Affects Versions: 2.8 >Reporter: Peter Lynch > Attachments: MECLIPSE-626.patch > > > The pom.xml for this project uses the maven enforcer plugin to require it be > built with version 2.0.9 or greater of maven due to requirements of the > integration tests. > All the maven dependencies for this project require maven 2.0.8 however. > Things 'work' more or less however consider the following issue. > You want to run integration tests on this plugin and attach a debugger. So > when you execute maven, you are forced to use Maven 2.0.9. However the > debugger ( example one include with Netbeans or Eclipse) by default will load > sources from 2.0.8. This makes stepping through code accurately - impossible > - unless you manually run the inegration test and set sources by hand, by > passing IDE. As noted in the pom, 2.0.9 is required for some integration > tests. > Unless there is some major concern not evident the plugin dependencies marked > 2.0.8 should be updated to depend on Maven 2.0.9 or match whatever the > minimum required Maven version used to actually build the project. -- 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: (MSITE-440) Site document validation fails if unable to retrieve schema (in offline mode)
Site document validation fails if unable to retrieve schema (in offline mode) - Key: MSITE-440 URL: http://jira.codehaus.org/browse/MSITE-440 Project: Maven 2.x Site Plugin Issue Type: Bug Components: doxia integration Affects Versions: 2.1 Environment: Maven 2.2.1 Site Plugin 2.1-SNAPSHOT Doxia 1.1.2 Reporter: Dave Meibusch Priority: Critical The changes included DOXIA-263 to validate XML documents retrieves the DTD/Schema to validate the document. For example, for FML, xsi:schemaLocation="http://maven.apache.org/FML/1.0.1 http://maven.apache.org/xsd/fml-1.0.1.xsd"; the Doxia FML parser will retrieve http://maven.apache.org/xsd/fml-1.0.1.xsd before validating the document. If in offline mode, or in an environment without connectivity to apache.org, site generation will appear to hang until the HTTP client code times out (which is many minutes for each retry) then fail. Workaround: remove the schema definition from the document (and lose validation when online and IDE editing support). Perhaps each Doxia parser should have some embedded schemas (for FML, at least http://maven.apache.org/FML/1.0.1) so the entities can be resolved locally. Or at least a property for disabling document validation. I don't think v2.1 can be released with this issue unresolved. -- 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-4489) [regression] Mirror/proxy/auth does not apply to repositories discovered in POMs of build extensions
[ http://jira.codehaus.org/browse/MNG-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4489. -- Resolution: Fixed Fix Version/s: 3.0-alpha-6 Assignee: Benjamin Bentmann Fixed in [r889460|http://svn.apache.org/viewvc?view=revision&revision=889460]. > [regression] Mirror/proxy/auth does not apply to repositories discovered in > POMs of build extensions > > > Key: MNG-4489 > URL: http://jira.codehaus.org/browse/MNG-4489 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0-alpha-5 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-6 > > > When a project uses a build extension and the POM of this extension declares > repositories, those are not subject to the network configuration from the > settings. This results in bad resolution of the extension dependencies. -- 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-2670) maven-replacer-plugin upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202177#action_202177 ] Steven Baker commented on MAVENUPLOAD-2670: --- Can I please have some update on this? > maven-replacer-plugin upload > > > Key: MAVENUPLOAD-2670 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2670 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Steven Baker > > I am the project owner of maven-replacer-plugin and wish to have my project > uploaded to the maven repo. > The home page is: > http://code.google.com/p/maven-replacer-plugin/ > The bundle is available from: > http://maven-replacer-plugin.googlecode.com/files/maven-replacer-plugin-1.1-bundle.jar > The bundle should contain the sources jar and the actual packaged plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4489) [regression] Mirror/proxy/auth does not apply to repositories discovered in POMs of build extensions
[regression] Mirror/proxy/auth does not apply to repositories discovered in POMs of build extensions Key: MNG-4489 URL: http://jira.codehaus.org/browse/MNG-4489 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0-alpha-5 Reporter: Benjamin Bentmann When a project uses a build extension and the POM of this extension declares repositories, those are not subject to the network configuration from the settings. This results in bad resolution of the extension dependencies. -- 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: (SUREFIRE-569) There should be a way to run unit tests from a dependency jar.
[ http://jira.codehaus.org/browse/SUREFIRE-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202149#action_202149 ] Thomas Strecker commented on SUREFIRE-569: -- Yes, this is a work around. However, it means not just adding a test-dependency but also fiddling with the build, which is rather dangerous. In the one case I can tell my teammates: Hey, I got this cool set if tests you can run your implementation against, just add this dependency with scope "test". In the other I'd have to introduce them to the mysteries of plugin configurations and build process customization. The main beauty of maven is that it just works for most cases without having to tell anyone how to get it to work. :) > There should be a way to run unit tests from a dependency jar. > -- > > Key: SUREFIRE-569 > URL: http://jira.codehaus.org/browse/SUREFIRE-569 > Project: Maven Surefire > Issue Type: New Feature > Components: plugin >Reporter: Paul Gier > > In some cases it would be useful to have a set of tests that run with various > dependency configurations. One way to accomplish this would be to have a > single project that contains the unit tests and generates a test jar. > Several test configuration projects could then consume the unit tests and run > them with different dependency sets. The problem is that there is no easy > way to run tests in a dependency jar. The surefire plugin should have a > configuration to allow me to run all or a set of unit tests contained in a > dependency 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] Issue Comment Edited: (MNG-2315) Add option to exclude all transitive dependencies for a particular one
[
http://jira.codehaus.org/browse/MNG-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202133#action_202133
]
Brad Lee edited comment on MNG-2315 at 12/10/09 11:47 AM:
--
I like this idea as well. Useful in the assemblage cases:
http://www.sonatype.com/books/maven-book/reference/assemblies-sect-assembling-via-depend.html
was (Author: gte250p):
I agree. A necessity in some cases involving Assembling optional (or sets
of optional) dependencies. See this site:
http://www.sonatype.com/books/maven-book/reference/assemblies-sect-assembling-via-depend.html
Instead of the proposed solution, another neat way to do it could be regular
expression matching on the exclusion groupId and artifactId:
${project.groupId}
${someProjectId}
${project.version}
assemblage
zip
commons-.*
commons-.*
Maybe that is just overkill.
> Add option to exclude all transitive dependencies for a particular one
> --
>
> Key: MNG-2315
> URL: http://jira.codehaus.org/browse/MNG-2315
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 2.0.4
>Reporter: Carlos Sanchez
>Priority: Critical
> Fix For: 3.x
>
>
> Something like
>
> ...
> true
>
--
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-2315) Add option to exclude all transitive dependencies for a particular one
[
http://jira.codehaus.org/browse/MNG-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202133#action_202133
]
Brad Lee commented on MNG-2315:
---
I agree. A necessity in some cases involving Assembling optional (or sets of
optional) dependencies. See this site:
http://www.sonatype.com/books/maven-book/reference/assemblies-sect-assembling-via-depend.html
Instead of the proposed solution, another neat way to do it could be regular
expression matching on the exclusion groupId and artifactId:
${project.groupId}
${someProjectId}
${project.version}
assemblage
zip
commons-.*
commons-.*
Maybe that is just overkill.
> Add option to exclude all transitive dependencies for a particular one
> --
>
> Key: MNG-2315
> URL: http://jira.codehaus.org/browse/MNG-2315
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 2.0.4
>Reporter: Carlos Sanchez
>Priority: Critical
> Fix For: 3.x
>
>
> Something like
>
> ...
> true
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-128) SCM properties being replaced during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202125#action_202125
]
Havard Bjastad commented on MRELEASE-128:
-
Wow, this bug is THREE AND A HALF YEARS OLD and nobody has been able to fix it?
We're supposed to use Maven, but after all this time it's still not able to
create a release without messing up the POMs?
> SCM properties being replaced during release:perform
>
>
> Key: MRELEASE-128
> URL: http://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
>Reporter: Craig Dickson
>Assignee: Emmanuel Venisse
>Priority: Critical
> Fix For: 2.0
>
> Attachments: after-release-perform-pom.xml,
> after-release-prepre-pom.xml, MNG-128-maven-release-manager.patch,
> MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch,
> original-pom.xml
>
>
> The section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> Notice that the properties that were there for the base URLs for CVS and
> ViewCVS have been replaced with literal values.
> No other properties in the POM are being replaced
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-114) ${project.artifactId} was replaced with it's value during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202127#action_202127
]
Havard Bjastad commented on MRELEASE-114:
-
Emmanuel, you're saying "Already fixed", but we're still seeing this problem
with Maven 2.0.9. There are also open issues on this, e.g. MRELEASE-128 and
MRELEASE-325, what exactly is fixed here, as opposed to the other ones?
> ${project.artifactId} was replaced with it's value during release:perform
> -
>
> Key: MRELEASE-114
> URL: http://jira.codehaus.org/browse/MRELEASE-114
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Environment: Windows XP, Java 1.4.2
>Reporter: Paul Spencer
>Assignee: Emmanuel Venisse
> Fix For: 2.0-beta-5
>
> Attachments: MRELEASE-128-maven-release-plugin.patch
>
>
> In release:perform, the variable ${project.artifactId} was replaced with it's
> value in the connection and developerConnection tags in the pom. This did NOT
> happen in other place in the pom!
> Before release:
> scm:cvs:pserver:cvsa...@cvs.foo.com:/bar:${project.artifactId}
> After release:
> scm:cvs:pserver:cvsa...@cvs.foo.com:/bar:master-pom
> BTW: The issue http://jira.codehaus.org/browse/MRELEASE-16 may be
> related to the above 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
Re: [jira] Created: (MPLUGIN-149) ParseException with annotation @XmlType in JavaDocBuilder
Hi
I m facing the same issue.
I have added the below dependencies in my pom.xml
com.thoughtworks.qdox
qdox
1.10
org.apache.maven.plugins
maven-plugin-plugin
2.5.1
Does any one know the solution
Thanks a lot in advance
Regards
Binu
JIRA j...@codehaus.org wrote:
>
> ParseException with annotation @XmlType in JavaDocBuilder
> -
>
> Key: MPLUGIN-149
> URL: http://jira.codehaus.org/browse/MPLUGIN-149
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Javadoc
> Affects Versions: 2.5
> Environment: Apache Maven 2.1.0 (r755702; 2009-03-19
> 04:10:27+0900)
> Java version: 1.6.0_12
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> Reporter: Jean-Paul GUIGUI
> Priority: Critical
>
>
> I'm generating code from the template changes-1.0.0.xsd with Jaxb and the
> code generated is used by an in-house maven plugin.
> There is a regression in the maven-plugin-plugin: with version 2.4.2 is
> used to work properly, now with version 2.4.3 and 2.5 the
> plugin:descriptor task is failing with a ParseException.
>
> The JavaDocBuilder is not able to parse the following lines:
> @XmlAccessorType(XmlAccessType.FIELD)
> @XmlType(name = "ChangesDocument", namespace =
> "http://maven.apache.org/changes/1.0.0";, propOrder = {
>
> })
>
> It is failing with both mvn 2.09 and 2.1.0
>
> [INFO] [plugin:descriptor]
> [INFO] Using 2 extractors.
> [INFO] Applying extractor for language: java
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] syntax error @[44,1] in
> file:/C:/MyProject/target/generated-sources/jaxb/myproject/jaxb/ChangesDocument.java
> [INFO]
>
> [INFO] Trace
> com.thoughtworks.qdox.parser.ParseException: syntax error @[44,1] in
> file:/C:/MyProjects/target/generated-sources/jaxb/myproject/ChangesDocument.java
> at
> com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:716)
> at
> com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:826)
> at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:697)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:300)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:316)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:312)
> at
> com.thoughtworks.qdox.JavaDocBuilder$1.visitFile(JavaDocBuilder.java:369)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:43)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.scan(DirectoryScanner.java:52)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:366)
> at
> org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.discoverClasses(JavaMojoDescriptorEx
> tractor.java:605)
> at
> org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.execute(JavaMojoDescriptorExtractor.
> java:572)
> at
> org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:96)
>
> at
> org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:146)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor
[jira] Created: (MAVENUPLOAD-2688) JasperReports Repository Sync
JasperReports Repository Sync - Key: MAVENUPLOAD-2688 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2688 Project: Maven Upload Requests Issue Type: Wish Reporter: Teodor Danciu "jasperreports","mavens...@web.sourceforge.net:/home/groups/j/ja/jasperreports/htdocs/maven2","rsync_ssh","Teodor Danciu","teod...@users.sourceforge.net",, -- 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: (MSITE-424) Unable to perform release
[ http://jira.codehaus.org/browse/MSITE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-424. --- Resolution: Not A Bug This is a bug tracking system. It is not a bug that a certain version is not released yet. If you want to speed things up, you can bug (!) devs on the mailing list or IRC, or check yourself what issues are left that prevent a release. The more time we spend checking out pointless tickets the less we have to work towards your desired release... > Unable to perform release > - > > Key: MSITE-424 > URL: http://jira.codehaus.org/browse/MSITE-424 > Project: Maven 2.x Site Plugin > Issue Type: Task > Components: doxia integration >Affects Versions: 2.1 >Reporter: Malachi de AElfweald >Priority: Blocker > > I am unable to perform a release because I depend on doxia 1.1.1 for > DOXIA-309, DOXIA-310 and DOXIA-311 > The last tagged version of the site plugin is 2.0.1 which relies on doxia 1.0 > The current trunk version depends on doxia 1.1.2-SNAPSHOT > I need a tagged version of the site plugin built against doxia 1.1.1 or later > so that I can perform a release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-67) Embedded error: error in opening zip on directory
[ http://jira.codehaus.org/browse/MSHADE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202085#action_202085 ] Max Berger commented on MSHADE-67: -- The issue is invalid - I tried to bind the shade-plugin to the prepare-package phase instead of the package phase. So please change the topic to: [Wish] support attaching to prepare-package phase. > Embedded error: error in opening zip on directory > - > > Key: MSHADE-67 > URL: http://jira.codehaus.org/browse/MSHADE-67 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.2.2 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.6.0_13 > Java home: /software/java/jdk1.6.0_13-x86_64_sun/jre > Default locale: de_AT, platform encoding: UTF-8 > OS name: "linux" version: "2.6.9-67.ellargesmp" arch: "amd64" Family: "unix" >Reporter: Max Berger > > for whatever reason, the shade plugin tries to add my target/classes > directory to the list of zip files: > Embedded error: error in opening zip > file/home/.../workspace/project/target/classes > which fails because it is a directory. Instead, it should use the normal file > inclusion. > This issue may or may not be related to #MSHADE-60 and #MSHADE-65 -- 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: (DOXIA-68) Adding twiki plugin as build extension makes goal site:site fail.
[ http://jira.codehaus.org/browse/DOXIA-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202082#action_202082 ] Lukas Theussl commented on DOXIA-68: Doxia 1.1.x is not compatible with any (yet) published site/project-info plugin. Try the newest twiki module from the 1.0.x branch, it should work as per comments above. > Adding twiki plugin as build extension makes goal site:site fail. > - > > Key: DOXIA-68 > URL: http://jira.codehaus.org/browse/DOXIA-68 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Twiki >Affects Versions: 1.0-alpha-8 > Environment: WinXp, Java5 >Reporter: Martin Zeltner >Assignee: Lukas Theussl > > When I add the twiki module as an extension in my pom.xml the goal site:site > will fail. > Extension config snippet: > -- > > > > > doxia-module-twiki > org.apache.maven.doxia > 1.0-alpha-9-SNAPSHOT > > > > -- > Console output: > -- > mvn site:site -X > + Error stacktraces are turned on. > Maven version: 2.1-SNAPSHOT > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building EL4J module core > [INFO]task-segment: [site:site] > [INFO] > > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. > [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] Setting property: resource.manager.logwhenfound => 'false'. > [INFO] ** > [INFO] Starting Jakarta Velocity v1.4 > [INFO] RuntimeInstance initializing. > [INFO] Default Properties File: > org\apache\velocity\runtime\defaults\velocity.properties > [INFO] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceManagerImpl) > [INFO] Resource Loader Instantiated: > org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader > [INFO] ClasspathResourceLoader : initialization starting. > [INFO] ClasspathResourceLoader : initialization complete. > [INFO] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [INFO] Default ResourceManager initialization complete. > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [INFO] Created: 20 parsers. > [INFO] Velocimacro : initialization starting. > [INFO] Velocimacro : adding VMs from VM library template : > VM_global_library.vm > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > [INFO] Velocimacro : VM library template macro registration complete. > [INFO] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOT replace previous VM definitions > [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allowed. > [INFO] Velocimacro : initialization complete. > [INFO] Velocity successfully started. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error getting reports from the plugin > 'org.apache.maven.plugins:maven-jxr-plugin': Unable to find the mojo > 'org.apache.maven.plugins:maven-jxr-plugin:2.1-SNAPSHOT:jxr' in the plugin > 'org.apache > .maven.plugins:maven-jxr-plugin' > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error getting reports > from the plugin 'org.apache.maven.plugins:maven-jxr-plugin': Unable to find > the mojo 'org.apache.maven.plugins:maven-jxr-p > lugin:2.1-SNAPSHOT:jxr' in the plugin > 'org.apache.maven.plugins:maven-jxr-plugin' > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getR
[jira] Created: (MSHADE-67) Embedded error: error in opening zip on directory
Embedded error: error in opening zip on directory - Key: MSHADE-67 URL: http://jira.codehaus.org/browse/MSHADE-67 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.2.2 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_13 Java home: /software/java/jdk1.6.0_13-x86_64_sun/jre Default locale: de_AT, platform encoding: UTF-8 OS name: "linux" version: "2.6.9-67.ellargesmp" arch: "amd64" Family: "unix" Reporter: Max Berger for whatever reason, the shade plugin tries to add my target/classes directory to the list of zip files: Embedded error: error in opening zip file/home/.../workspace/project/target/classes which fails because it is a directory. Instead, it should use the normal file inclusion. This issue may or may not be related to #MSHADE-60 and #MSHADE-65 -- 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-2687) Upload struts2-jQuery plugin version 1.8.0
Upload struts2-jQuery plugin version 1.8.0 -- Key: MAVENUPLOAD-2687 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2687 Project: Maven Upload Requests Issue Type: Sub-task Reporter: Johannes Geppert I'm a developer and project owner in struts2 jquery plugin project, please upload! Developer johgep -- 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: (DOXIA-68) Adding twiki plugin as build extension makes goal site:site fail.
[
http://jira.codehaus.org/browse/DOXIA-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202077#action_202077
]
Petr Kozelka commented on DOXIA-68:
---
I wonder if there is a way to make twiki working against released versions. I
tried this:
{code}
...
org.apache.maven.plugins
maven-project-info-reports-plugin
2.1.2
org.apache.maven.doxia
doxia-module-twiki
1.1.2
...
{code}
but got following error:
{code}
...
this realm = plexus.core
urls[0] = file:/home/pk/opt/maven/lib/maven-2.2.1-uber.jar
Number of imports: 10
import: org.codehaus.classworlds.en...@a6c57a42
import: org.codehaus.classworlds.en...@12f43f3b
import: org.codehaus.classworlds.en...@20025374
import: org.codehaus.classworlds.en...@f8e44ca4
import: org.codehaus.classworlds.en...@92758522
import: org.codehaus.classworlds.en...@ebf2705b
import: org.codehaus.classworlds.en...@bb25e54
import: org.codehaus.classworlds.en...@bece5185
import: org.codehaus.classworlds.en...@3fee8e37
import: org.codehaus.classworlds.en...@3fee19d8
-
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error getting reports from the plugin
'org.apache.maven.plugins:maven-project-info-reports-plugin:2.1.2': Unable to
find the mojo 'project-team' (or one of its required components) in the plugin
'org.apache.maven.plugins:maven-project-info-reports-plugin'
org.apache.maven.doxia.module.site.AbstractSiteModule.(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V
...
{code}
It seems that adding the dependency impacts dependency graph for the plugin
classpath somehow. Is there any better version to use ?
> Adding twiki plugin as build extension makes goal site:site fail.
> -
>
> Key: DOXIA-68
> URL: http://jira.codehaus.org/browse/DOXIA-68
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Twiki
>Affects Versions: 1.0-alpha-8
> Environment: WinXp, Java5
>Reporter: Martin Zeltner
>Assignee: Lukas Theussl
>
> When I add the twiki module as an extension in my pom.xml the goal site:site
> will fail.
> Extension config snippet:
> --
>
>
>
>
> doxia-module-twiki
> org.apache.maven.doxia
> 1.0-alpha-9-SNAPSHOT
>
>
>
> --
> Console output:
> --
> mvn site:site -X
> + Error stacktraces are turned on.
> Maven version: 2.1-SNAPSHOT
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'site'.
> [INFO]
>
> [INFO] Building EL4J module core
> [INFO]task-segment: [site:site]
> [INFO]
>
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] **
> [INFO] Starting Jakarta Velocity v1.4
> [INFO] RuntimeInstance initializing.
> [INFO] Default Properties File:
> org\apache\velocity\runtime\defaults\velocity.properties
> [INFO] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> [INFO] Resource Loader Instantiated:
> org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
> [INFO] ClasspathResourceLoader : initialization starting.
> [INFO] ClasspathResourceLoader : initialization complete.
> [INFO] ResourceCache : initialized. (class
> org.apache.velocity.runtime.resource.ResourceCacheImpl)
> [INFO] Default ResourceManager initialization complete.
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [INFO] Created: 20 parsers.
> [INFO] Velocimacro : initialization starting.
> [INFO] Velocimacro : adding VMs from VM library template :
> VM_global_library.vm
> [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in
> any resource loader.
> [INFO] Velocimacro :
[jira] Issue Comment Edited: (MPIR-150) the dependency report ignores mirrors
[ http://jira.codehaus.org/browse/MPIR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202076#action_202076 ] Lukas Laag edited comment on MPIR-150 at 12/10/09 6:39 AM: --- The workaround consisting in locking down the plugin to version 2.0.1 only works partially for me (works for the "Dependencies" report but no for the "Project License" report) was (Author: laaglu): The workaround consisting in locking down the plugin to version 2.0.1 only works only partially for me (works for the "Dependencies" report but no for the "Project License" report) > the dependency report ignores mirrors > - > > Key: MPIR-150 > URL: http://jira.codehaus.org/browse/MPIR-150 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 2.1.1 >Reporter: Brian Fox > > The dependencies report takes forever and running debug i can see it's > hitting the same repos over and over and bypassing my repository manager. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MPIR-150) the dependency report ignores mirrors
[ http://jira.codehaus.org/browse/MPIR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202076#action_202076 ] Lukas Laag edited comment on MPIR-150 at 12/10/09 6:39 AM: --- The workaround consisting in locking down the plugin to version 2.0.1 only works partially for me (works for the "Dependencies" report but not for the "Project License" report) was (Author: laaglu): The workaround consisting in locking down the plugin to version 2.0.1 only works partially for me (works for the "Dependencies" report but no for the "Project License" report) > the dependency report ignores mirrors > - > > Key: MPIR-150 > URL: http://jira.codehaus.org/browse/MPIR-150 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 2.1.1 >Reporter: Brian Fox > > The dependencies report takes forever and running debug i can see it's > hitting the same repos over and over and bypassing my repository manager. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-150) the dependency report ignores mirrors
[ http://jira.codehaus.org/browse/MPIR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202076#action_202076 ] Lukas Laag commented on MPIR-150: - The workaround consisting in locking down the plugin to version 2.0.1 only works only partially for me (works for the "Dependencies" report but no for the "Project License" report) > the dependency report ignores mirrors > - > > Key: MPIR-150 > URL: http://jira.codehaus.org/browse/MPIR-150 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 2.1.1 >Reporter: Brian Fox > > The dependencies report takes forever and running debug i can see it's > hitting the same repos over and over and bypassing my repository manager. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSTAGE-9) Stage plugin fails with ClassCastException
[ http://jira.codehaus.org/browse/MSTAGE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202075#action_202075 ] Benjamin Bentmann commented on MSTAGE-9: Due to MNG-3581, be sure to use Maven 2.0.10 or newer. > Stage plugin fails with ClassCastException > -- > > Key: MSTAGE-9 > URL: http://jira.codehaus.org/browse/MSTAGE-9 > Project: Maven 2.x Stage Plugin > Issue Type: Bug >Affects Versions: 1.0-alpha-1 >Reporter: Benson Margulies > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org.apache.maven.wagon.providers.ssh.jsch.ScpWagon > [INFO] > > [INFO] Trace > java.lang.ClassCastException: > org.apache.maven.wagon.providers.ssh.jsch.ScpWagon > at > org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252) > at > org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227) > 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: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) > [INFO] > > [INFO] Total time: 49 seconds > [INFO] Finished at: Wed Dec 10 22:13:24 EST 2008 > [INFO] Final Memory: 3M/6M > [INFO] > > /Users/benson/xmlschema > mvn stage:copy \ >-Dsource="http://people.apache.org/~bimargulies/maven_staging"; \ > > -Dtarget="scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository" > \ >-Dversion=1.4.3 \ >-DtargetRepositoryId=apache.releases > > > apache-repo > bimargulies > > > apache.releases > bimargulies > > > apache-snapshots > bimargulies > > -- 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: (MSTAGE-9) Stage plugin fails with ClassCastException
[ http://jira.codehaus.org/browse/MSTAGE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202073#action_202073 ] Emmanuel Lécharny commented on MSTAGE-9: Same problem with 1.0-alpha2 : > MacBookPro:trunk pajbam$ mvn stage:copy > -Dsource="http://localhost/~pajbam/ApacheDirectoryStudio-1.5.2.v20091209"; > -Dtarget="scpexe://people.apache.org/home/pamarcelot/repository" > -Dversion=1.5.2.v20091209 -DtargetRepositoryId=aplease -Prelease > > [INFO] Scanning for projects... > > [-SNIP-] > > [INFO] Creating zip file. > > [INFO] Creating rename script. > > [INFO] Uploading zip file to the target repository. > > [INFO] Unpacking zip file on the target machine. > > [INFO] > > > > [ERROR] FATAL ERROR > > [INFO] > > > > [INFO] org.apache.maven.wagon.providers.ssh.external.ScpExternalWagon > > cannot be cast to org.apache.maven.wagon.providers.ssh.jsch.ScpWagon > > [INFO] > > > > [INFO] Trace > > java.lang.ClassCastException: > > org.apache.maven.wagon.providers.ssh.external.ScpExternalWagon cannot be > > cast to org.apache.maven.wagon.providers.ssh.jsch.ScpWagon > > at > > org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252) > > at > > org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93) > > at > > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227) > > 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: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) > > [INFO] > > > > [INFO] Total time: 55 minutes 36 seconds > > [INFO] Finished at: Thu Dec 10 11:38:46 CET 2009 > > [INFO] Final Memory: 22M/80M > > [INFO] > > > Stage plugin fails with ClassCastException > -- > > Key: MSTAGE-9 > URL: http://jira.codehaus.org/browse/MSTAGE-9 > Project: Maven 2.x Stage Plugin > Issue Type: Bug >Affects Versions: 1.0-alpha-1 >Reporter: Benson Margulies > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org.apache.maven.wagon.providers.ssh.jsch.ScpWagon > [INFO] > > [INFO] Trace > java.lang.ClassCastException: > org.apache.maven.wagon.providers.ssh.jsch.ScpWagon > at > org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252) > at > org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.
[jira] Commented: (MDEPLOY-114) Add an option to not fail when remote file already exists and redeploy is forbidden
[ http://jira.codehaus.org/browse/MDEPLOY-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202072#action_202072 ] Julien HENRY commented on MDEPLOY-114: -- We are not using the staging process currently. But you are right, it may certainly be a good thing to investigate. > Add an option to not fail when remote file already exists and redeploy is > forbidden > --- > > Key: MDEPLOY-114 > URL: http://jira.codehaus.org/browse/MDEPLOY-114 > Project: Maven 2.x Deploy Plugin > Issue Type: Wish > Components: deploy:deploy >Affects Versions: 2.4 >Reporter: Julien HENRY > > In my organisation we are using a MRM (Nexus) with redeployment of release > that is forbidden. > Sometimes the release:perform may fail in the middle of a multi-module > release. It means some modules were deployed but other are not. > Currently it is not possible to restart the release as it will fail on first > deployment (usually the parent pom of the multimodule) because the pom was > already deployed during the first attempt. > I would like to add an option to the deploy plugin that may deal with this > case. Perhaps an option like -Dredeploy=false that may either : > 1) check if the remote file already exists before trying to upload > 2) try to upload everytime but not fail the build > The problem with the second proposal is the error returned by Nexus is > authorization error so we may not be able to distinguish real authorization > error on a new file and redeploy attempt. > Caused by: org.apache.maven.wagon.authorization.AuthorizationException: > Access denied to: http://nexus.mycompany.com/ > content/repositories/myrepo/com/mycustomer/project/parent/3.2.0/parent-3.2.0.pom > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:360) > Other options may be more complicated like implementing an atomic deploy > process on multimodule (may need a big change of the deploy protocol). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-450) release:perform shoult not call test:test as release:prepare already did
[ http://jira.codehaus.org/browse/MRELEASE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202071#action_202071 ] Sei Syvalta commented on MRELEASE-450: -- I have also seen many test failures from clean checkout, so it would be good to leave the default functionality as is. > release:perform shoult not call test:test as release:prepare already did > > > Key: MRELEASE-450 > URL: http://jira.codehaus.org/browse/MRELEASE-450 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: perform >Affects Versions: 2.0-beta-9 > Environment: linux >Reporter: Christian Hammers >Assignee: Olivier Lamy >Priority: Minor > Fix For: 2.0-beta-10 > > > Hello > When doing a "mvn release:prepare" and then "mvn release:perform" the > complete test suite is run twice. As it takes a couple of minutes it feels > annoying. Also I don't really see the necessarity of running the test:test > goal in release:perform as release:prepare already does so and afterwards tag > the source code so that the perform cannot be made on a non-tested code, or? > bye, > -christian- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-114) Add an option to not fail when remote file already exists and redeploy is forbidden
[ http://jira.codehaus.org/browse/MDEPLOY-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202070#action_202070 ] Benjamin Bentmann commented on MDEPLOY-114: --- Why not simply drop the staging repository in Nexus before redoing the release? > Add an option to not fail when remote file already exists and redeploy is > forbidden > --- > > Key: MDEPLOY-114 > URL: http://jira.codehaus.org/browse/MDEPLOY-114 > Project: Maven 2.x Deploy Plugin > Issue Type: Wish > Components: deploy:deploy >Affects Versions: 2.4 >Reporter: Julien HENRY > > In my organisation we are using a MRM (Nexus) with redeployment of release > that is forbidden. > Sometimes the release:perform may fail in the middle of a multi-module > release. It means some modules were deployed but other are not. > Currently it is not possible to restart the release as it will fail on first > deployment (usually the parent pom of the multimodule) because the pom was > already deployed during the first attempt. > I would like to add an option to the deploy plugin that may deal with this > case. Perhaps an option like -Dredeploy=false that may either : > 1) check if the remote file already exists before trying to upload > 2) try to upload everytime but not fail the build > The problem with the second proposal is the error returned by Nexus is > authorization error so we may not be able to distinguish real authorization > error on a new file and redeploy attempt. > Caused by: org.apache.maven.wagon.authorization.AuthorizationException: > Access denied to: http://nexus.mycompany.com/ > content/repositories/myrepo/com/mycustomer/project/parent/3.2.0/parent-3.2.0.pom > at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:360) > Other options may be more complicated like implementing an atomic deploy > process on multimodule (may need a big change of the deploy protocol). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEPLOY-114) Add an option to not fail when remote file already exists and redeploy is forbidden
Add an option to not fail when remote file already exists and redeploy is forbidden --- Key: MDEPLOY-114 URL: http://jira.codehaus.org/browse/MDEPLOY-114 Project: Maven 2.x Deploy Plugin Issue Type: Wish Components: deploy:deploy Affects Versions: 2.4 Reporter: Julien HENRY In my organisation we are using a MRM (Nexus) with redeployment of release that is forbidden. Sometimes the release:perform may fail in the middle of a multi-module release. It means some modules were deployed but other are not. Currently it is not possible to restart the release as it will fail on first deployment (usually the parent pom of the multimodule) because the pom was already deployed during the first attempt. I would like to add an option to the deploy plugin that may deal with this case. Perhaps an option like -Dredeploy=false that may either : 1) check if the remote file already exists before trying to upload 2) try to upload everytime but not fail the build The problem with the second proposal is the error returned by Nexus is authorization error so we may not be able to distinguish real authorization error on a new file and redeploy attempt. Caused by: org.apache.maven.wagon.authorization.AuthorizationException: Access denied to: http://nexus.mycompany.com/ content/repositories/myrepo/com/mycustomer/project/parent/3.2.0/parent-3.2.0.pom at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:360) Other options may be more complicated like implementing an atomic deploy process on multimodule (may need a big change of the deploy protocol). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-88) enforcer ignores super pom definitions.
enforcer ignores super pom definitions. --- Key: MENFORCER-88 URL: http://jira.codehaus.org/browse/MENFORCER-88 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 1.0-beta-1 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100) Java version: 1.6.0_16 Java home: C:\Java\jdk1.6.0_16\jre Default locale: en_GB, platform encoding: Cp1252 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" Reporter: James Nord Priority: Minor Attachments: pom.xml The RequirePluginVersions rule incorrectly ignores any versions defiend in the Super POM. This is inconistent with the documentation, "This rule enforces that all plugins have a version defined, either in the plugin or pluginManagement section of the pom or a parent pom." The POM's implicit parent is the Super POM. Expected outcome: The attached project (to be used as an Integration Test) should pass the validate stage with Maven 2.2.1 Actual outcome: The project build fails with: Some plugins are missing valid versions:(LATEST RELEASE SNAPSHOT are not allowed ) org.apache.maven.plugins:maven-clean-plugin.The version currently in use is 2.3 org.apache.maven.plugins:maven-deploy-plugin. The version currently in use is 2.4 org.apache.maven.plugins:maven-install-plugin. The version currently in use is 2.3 org.apache.maven.plugins:maven-site-plugin. The version currently in use is 2.0.1 All these plugins have their versions defined in the Super POM. -- 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-493) Prepare step doesn't stop if there are modified local files
[ http://jira.codehaus.org/browse/MRELEASE-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRELEASE-493. - Resolution: Fixed Fix Version/s: 2.0-beta-10 Assignee: Olivier Lamy fixed by SCM-480 > Prepare step doesn't stop if there are modified local files > --- > > Key: MRELEASE-493 > URL: http://jira.codehaus.org/browse/MRELEASE-493 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-9 > Environment: client : svn, version 1.6.2 (r37639) > server : svn, version 1.6.3 (r38063) >Reporter: Dominique Jean-Prost >Assignee: Olivier Lamy >Priority: Critical > Fix For: 2.0-beta-10 > > > I'm quite sure this used ot work "before" (before what ?), but actually, the > prepare step does not stop anymore if there are locally modified files. > Please look hereunder at the trace that shows plugin version and that there > are modified files > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-release-plugin:2.0-beta-9:prepare' --> > [DEBUG] (f) addSchema = true > [DEBUG] (f) allowReleasePluginSnapshot = false > [DEBUG] (f) allowTimestampedSnapshots = false > [DEBUG] (f) autoVersionSubmodules = true > [DEBUG] (s) basedir = C:\root\common_util > [DEBUG] (f) commitByProject = false > [DEBUG] (f) dryRun = true > [DEBUG] (f) generateReleasePoms = false > [DEBUG] (f) javaHome = C:\Bin\jdk1.5.0_13\jre > [DEBUG] (f) mavenExecutorId = invoker > [DEBUG] (f) mavenHome = C:\Bin\apache-maven-2.1.0\bin\.. > [DEBUG] (f) preparationGoals = clean install > [DEBUG] (f) project = MavenProject: > com.dexia.sofaxis.siactuel:common_util:1.0.4-SNAPSHOT @ > C:\root\common_util\pom.xml > [DEBUG] (f) reactorProjects = [MavenProject: > com.dexia.sofaxis.siactuel:common_util:1.0.4-SNAPSHOT @ > C:\root\common_util\pom.xml] > [DEBUG] (f) remoteTagging = true > [DEBUG] (f) resume = false > [DEBUG] (f) scmCommentPrefix = [maven-release-plugin] > [DEBUG] (f) settings = org.apache.maven.settings.setti...@dc0435 > [DEBUG] (f) updateDependencies = true > [DEBUG] (f) useEditMode = false > [DEBUG] -- end configuration -- > [INFO] [release:prepare] > [INFO] Verifying that there are no local modifications... > [INFO] Executing: cmd.exe /X /C "svn --non-interactive status" > [INFO] Working directory: C:\root\common_util > [DEBUG] ? pom.xml.releaseBackup > [DEBUG] ? release.properties > [DEBUG] M src\test\java\com\dexia\common\util\UtilsTest.java > [INFO] Checking dependencies and plugins for snapshots ... > What is the release version for "common_util"? > (com.dexia.sofaxis.siactuel:common_util) 1.0.4: : -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
