[jira] Reopened: (MIDEA-102) Module filepath is generated incorrectly for sibling parent
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg reopened MIDEA-102: --- gotama, There is no patch from Roman - it's just a piece of code embedded in a comment. That won't show up on my radar when I'm looking for patches to apply. Contributors should alway supply a patch-file and attach it to the issue. The patch I applied wasn't mine , but came from Joern who was the person who filed this issue. That being said, I'll probably throw the whole toRelative() method out and use a method from doxia tools instead. That code includes lots unit tests and has been extracted from already tried and tested components. We still need to get a release of it out the door. In the meantime I'll push out another SNAPSHOT using that code. Stay tuned. > Module filepath is generated incorrectly for sibling parent > --- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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: (MCHANGES-106) the generated jira-result.xml contains no jira-items
[ http://jira.codehaus.org/browse/MCHANGES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128136 ] Dennis Lundberg commented on MCHANGES-106: -- There is an xml error in your pom. You should remove the text "". Are the usernam/password for a proxy or for the webapp server that runs JIRA? Do you have anonymous access to JIRA? > the generated jira-result.xml contains no jira-items > > > Key: MCHANGES-106 > URL: http://jira.codehaus.org/browse/MCHANGES-106 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira-report >Affects Versions: 2.0-beta-3 > Environment: windows maven-2.0.8 jira Professional Edition, Version: > 3.11-#288 >Reporter: Rene Boers >Priority: Critical > Attachments: jira-report.html, jira-report.log, jira-results.xml, > jira-results.xml, pom.xml, screenshot-1.jpg > > > when i run the maven site or mvn changes:jira-report the resulting > jira-reports doesnot contain jira-issues it only contains the link to the > searchrequest. > This results in an empty jira-report. > I have included the jira-reports.xml and the logging from the mvn > changes:jira report. > When open the jira-reports.xml in firefox i do have a page with the request > jira-issues available. In explorer i just get the representation of the xml > file. > Any suggestions why no jira-report is generated. -- 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: (MPLUGIN-102) The 2.4 Release Breaks Previously-Working Builds
[
http://jira.codehaus.org/browse/MPLUGIN-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128137
]
Dennis Lundberg commented on MPLUGIN-102:
-
James, why do you have this in the pom of your archetype?
{code}
maven-plugin
{code}
That's what is pulling in the plugin-plugin. But your code doesn't have any
plugin in it so plugin-plugin (correctly IMO) reports the error.
> The 2.4 Release Breaks Previously-Working Builds
>
>
> Key: MPLUGIN-102
> URL: http://jira.codehaus.org/browse/MPLUGIN-102
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 2.4
> Environment: Maven version: 2.0.8
> Java version: 1.5.0_14
> OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows"
>Reporter: James Carman
> Attachments: archetype-test.zip, debug.log
>
>
> We have an archetype contained within our project. Today, when I tried to
> run our build, I got the following error:
> [INFO] [plugin:descriptor]
> [INFO] Using 2 extractors.
> [INFO] Applying extractor for language: java
> [INFO] Extractor for language: java found 0 mojo descriptors.
> [INFO] Applying extractor for language: bsh
> [INFO] Extractor for language: bsh found 0 mojo descriptors.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in
> plugin.'
> However, if I add this to my pom.xml file for that module:
>
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
> 2.3
>
>
>
> the build works just fine, as usual (understandable since the 2.4 release
> came out yesterday).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-103) Adding License and/or Notice into META-INF folder
[ http://jira.codehaus.org/browse/MJAR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128138 ] Dennis Lundberg commented on MJAR-103: -- What is it that is not working for you when you put your license file in src/main/resources? Please provide a configuration example. > Adding License and/or Notice into META-INF folder > - > > Key: MJAR-103 > URL: http://jira.codehaus.org/browse/MJAR-103 > Project: Maven 2.x Jar Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Michael Osipov > > I'd like to be able to add my license.txt into the jar package. > an xml tag like true/false > would be extremely convenient. This can be achived right now with > build/resouces but the default resources have to be redeclared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-103) Adding License and/or Notice into META-INF folder
[
http://jira.codehaus.org/browse/MJAR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128139
]
Michael Osipov commented on MJAR-103:
-
I did not say that it does not work the way you described. I want to have a
single LICENSE.txt in the default place (${basedir}). I don't want to multiple
copies of it. That's the reason for the extra tag.
> Adding License and/or Notice into META-INF folder
> -
>
> Key: MJAR-103
> URL: http://jira.codehaus.org/browse/MJAR-103
> Project: Maven 2.x Jar Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Michael Osipov
>
> I'd like to be able to add my license.txt into the jar package.
> an xml tag like true/false
> would be extremely convenient. This can be achived right now with
> build/resouces but the default resources have to be redeclared.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-103) Adding License and/or Notice into META-INF folder
[
http://jira.codehaus.org/browse/MJAR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128142
]
Dennis Lundberg commented on MJAR-103:
--
You can configure the resource plugin to do it for you, like this:
{code:xml}
${basedir}
META-INF
LICENSE.txt
{code}
> Adding License and/or Notice into META-INF folder
> -
>
> Key: MJAR-103
> URL: http://jira.codehaus.org/browse/MJAR-103
> Project: Maven 2.x Jar Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Michael Osipov
>
> I'd like to be able to add my license.txt into the jar package.
> an xml tag like true/false
> would be extremely convenient. This can be achived right now with
> build/resouces but the default resources have to be redeclared.
--
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: (MPLUGIN-102) The 2.4 Release Breaks Previously-Working Builds
[ http://jira.codehaus.org/browse/MPLUGIN-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128141 ] James Carman commented on MPLUGIN-102: -- Because I followed the directions here when I created it: http://maven.apache.org/guides/mini/guide-creating-archetypes.html > The 2.4 Release Breaks Previously-Working Builds > > > Key: MPLUGIN-102 > URL: http://jira.codehaus.org/browse/MPLUGIN-102 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-test.zip, debug.log > > > We have an archetype contained within our project. Today, when I tried to > run our build, I got the following error: > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin.' > However, if I add this to my pom.xml file for that module: > > > > org.apache.maven.plugins > maven-plugin-plugin > 2.3 > > > > the build works just fine, as usual (understandable since the 2.4 release > came out yesterday). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-103) Adding License and/or Notice into META-INF folder
[
http://jira.codehaus.org/browse/MJAR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128143
]
Michael Osipov commented on MJAR-103:
-
Dennis,
I did look
[here|http://dev.fckeditor.net/browser/FCKeditor.Java/branches/2.4/pom.xml#L234].
The down side, it overrides the default resources and you have to redeclare it.
{code:xml}
maven-jar-plugin
2.2
true
{code}
would be much besser and easier to understand
> Adding License and/or Notice into META-INF folder
> -
>
> Key: MJAR-103
> URL: http://jira.codehaus.org/browse/MJAR-103
> Project: Maven 2.x Jar Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Michael Osipov
>
> I'd like to be able to add my license.txt into the jar package.
> an xml tag like true/false
> would be extremely convenient. This can be achived right now with
> build/resouces but the default resources have to be redeclared.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-103) Adding License and/or Notice into META-INF folder
[
http://jira.codehaus.org/browse/MJAR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128144
]
Benjamin Bentmann commented on MJAR-103:
If ever, a simply boolean option like "addLicence" is not flexibile enough.
Some people may call the file "LICENSE.txt" and others just "LICENSE". You need
at least the possibility to specify the path to the license file:
{code:xml}
LICENSE.txt
{code}
Then, this is just one file. Tomorrow people want to include a NOTICE file as
well or something else. If the JAR plugin should really be extended for this
purpose instead of simply reusing existing resources capabilities, it would be
more flexible to add a parameter that accepts a full-blown fileset, i.e.
directory with some includes/excludes, just like the "filesets" parameter for
the maven-clean-plugin.
> Adding License and/or Notice into META-INF folder
> -
>
> Key: MJAR-103
> URL: http://jira.codehaus.org/browse/MJAR-103
> Project: Maven 2.x Jar Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Michael Osipov
>
> I'd like to be able to add my license.txt into the jar package.
> an xml tag like true/false
> would be extremely convenient. This can be achived right now with
> build/resouces but the default resources have to be redeclared.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-103) Adding License and/or Notice into META-INF folder
[ http://jira.codehaus.org/browse/MJAR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128146 ] Michael Osipov commented on MJAR-103: - well, since maven is convention over configuration, I stuck to the default namings LICENSE.txt, README.txt and NOTICE.txt. Maybe this will suffice. Anything else could be done with anyway. What do you think about it? > Adding License and/or Notice into META-INF folder > - > > Key: MJAR-103 > URL: http://jira.codehaus.org/browse/MJAR-103 > Project: Maven 2.x Jar Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Michael Osipov > > I'd like to be able to add my license.txt into the jar package. > an xml tag like true/false > would be extremely convenient. This can be achived right now with > build/resouces but the default resources have to be redeclared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-103) Adding License and/or Notice into META-INF folder
[ http://jira.codehaus.org/browse/MJAR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128147 ] Dennis Lundberg commented on MJAR-103: -- I think it's a nice idea, if it can be "conventionalized", but the issue really belongs in the resources plugin. Jar is just one way to package something. > Adding License and/or Notice into META-INF folder > - > > Key: MJAR-103 > URL: http://jira.codehaus.org/browse/MJAR-103 > Project: Maven 2.x Jar Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Michael Osipov > > I'd like to be able to add my license.txt into the jar package. > an xml tag like true/false > would be extremely convenient. This can be achived right now with > build/resouces but the default resources have to be redeclared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-103) Adding License and/or Notice into META-INF folder
[ http://jira.codehaus.org/browse/MJAR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128148 ] Michael Osipov commented on MJAR-103: - Dennis, I took [this|http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html] for the text files. If Maven defines those, it would make sense to include the license into the jar, just in case. > Adding License and/or Notice into META-INF folder > - > > Key: MJAR-103 > URL: http://jira.codehaus.org/browse/MJAR-103 > Project: Maven 2.x Jar Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Michael Osipov > > I'd like to be able to add my license.txt into the jar package. > an xml tag like true/false > would be extremely convenient. This can be achived right now with > build/resouces but the default resources have to be redeclared. -- 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: (MANT-36) Use correct file encoding when writing build files
Use correct file encoding when writing build files
--
Key: MANT-36
URL: http://jira.codehaus.org/browse/MANT-36
Project: Maven 2.x Ant Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Benjamin Bentmann
The {{AntBuildWriter}} employs a {{FileWriter}} to output UTF-8 encoded XML
files, this is buggy, see also [Common
Bugs|http://www.nabble.com/Common-Bugs-to14783703s177.html#a15919795].
--
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: (MPLUGIN-102) The 2.4 Release Breaks Previously-Working Builds
[ http://jira.codehaus.org/browse/MPLUGIN-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128156 ] Dennis Lundberg commented on MPLUGIN-102: - It turns out that that page is not correct. You should change the packaging to "jar" to solve your problem. I've committed a change to said document in svn. > The 2.4 Release Breaks Previously-Working Builds > > > Key: MPLUGIN-102 > URL: http://jira.codehaus.org/browse/MPLUGIN-102 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-test.zip, debug.log > > > We have an archetype contained within our project. Today, when I tried to > run our build, I got the following error: > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin.' > However, if I add this to my pom.xml file for that module: > > > > org.apache.maven.plugins > maven-plugin-plugin > 2.3 > > > > the build works just fine, as usual (understandable since the 2.4 release > came out yesterday). -- 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: (MPLUGIN-102) The 2.4 Release Breaks Previously-Working Builds
[ http://jira.codehaus.org/browse/MPLUGIN-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128157 ] James Carman commented on MPLUGIN-102: -- But, it's not a jar module. It's an archetype. It seems like there might be support for a "maven-archetype" packaging: http://jira.codehaus.org/browse/ARCHETYPE-88 However, this worked in the past just fine and apparently was the way we were supposed to do it. So, I guess this is a backward compatibility issue? If the packaging must change because of this code change, maybe the error message could give us a little hint? Error extracting plugin descriptor: 'No mojo descriptors found in plugin (for archetypes, please use packaging jar/maven-archetype).' > The 2.4 Release Breaks Previously-Working Builds > > > Key: MPLUGIN-102 > URL: http://jira.codehaus.org/browse/MPLUGIN-102 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-test.zip, debug.log > > > We have an archetype contained within our project. Today, when I tried to > run our build, I got the following error: > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin.' > However, if I add this to my pom.xml file for that module: > > > > org.apache.maven.plugins > maven-plugin-plugin > 2.3 > > > > the build works just fine, as usual (understandable since the 2.4 release > came out yesterday). -- 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: (MPLUGIN-102) The 2.4 Release Breaks Previously-Working Builds
[ http://jira.codehaus.org/browse/MPLUGIN-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128160 ] Dennis Lundberg commented on MPLUGIN-102: - I did go and ask the developers about this before I replied. You can read the thread here: http://www.nabble.com/Is-an-archetype-really-a-plugin--to16198757s177.html > The 2.4 Release Breaks Previously-Working Builds > > > Key: MPLUGIN-102 > URL: http://jira.codehaus.org/browse/MPLUGIN-102 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-test.zip, debug.log > > > We have an archetype contained within our project. Today, when I tried to > run our build, I got the following error: > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin.' > However, if I add this to my pom.xml file for that module: > > > > org.apache.maven.plugins > maven-plugin-plugin > 2.3 > > > > the build works just fine, as usual (understandable since the 2.4 release > came out yesterday). -- 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: (MINVOKER-27) Allow to set MAVEN_OPTS when invoking Maven
Allow to set MAVEN_OPTS when invoking Maven --- Key: MINVOKER-27 URL: http://jira.codehaus.org/browse/MINVOKER-27 Project: Maven 2.x Invoker Plugin Issue Type: New Feature Affects Versions: 1.1 Reporter: Benjamin Bentmann It would be cool it there was a possibility to pass some args to the JVM itself. Example use case: Passing "-Dfile.encoding=..." to the JVM in order to enforce a particual default encoding when checking that Maven properly reads/writes text files. -- 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: (MCOMPILER-64) "mvn clean install" crashes with java.lang.OutOfMemoryError: PermGen space after update to java 1.6.0_04
[ http://jira.codehaus.org/browse/MCOMPILER-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128164 ] Sebastian Dehne commented on MCOMPILER-64: -- Same problem here. I tried to upgrade to j6u5 but that didn't help. However, no such problem when using j6u2. Consult the following stack trace for details. java.lang.OutOfMemoryError: PermGen space at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.codehaus.plexus.compiler.javac.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:56) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at com.sun.tools.javac.main.Main.compile(Main.java:340) at com.sun.tools.javac.main.Main.compile(Main.java:279) at com.sun.tools.javac.main.Main.compile(Main.java:270) at com.sun.tools.javac.Main.compile(Main.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:400) at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:136) at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:483) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) Thanks. > "mvn clean install" crashes with java.lang.OutOfMemoryError: PermGen space > after update to java 1.6.0_04 > > > Key: MCOMPILER-64 > URL: http://jira.codehaus.org/browse/MCOMPILER-64 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Maven version: 2.0.8 > Java version: 1.6.0_04 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Joern Huxhorn >Priority: Critical > > After upgrading to java 1.6.0_04 i can't build a big multi-module project > anymore. > java.exe keeps allocating more and more memory (ca. 260MB) until it crashes > with an error like the following: > Failure executing javac, but could not parse the error: > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: PermGen space > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at > org.codehaus.plexus.compiler.javac.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:56) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at com.sun.tools.javac.comp.Annotate.(Annotate.java:52) > at com.sun.tools.javac.comp.Annota
[jira] Created: (MANT-37) Wrong path to test resources in maven-build.xml
Wrong path to test resources in maven-build.xml
---
Key: MANT-37
URL: http://jira.codehaus.org/browse/MANT-37
Project: Maven 2.x Ant Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Benjamin Bentmann
Priority: Minor
Current content of maven-build.xml:
{code:xml}
{code}
Expected content of maven-build.xml:
{code:xml}
{code}
--
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: (MANT-37) Wrong path to test resources in maven-build.xml
[
http://jira.codehaus.org/browse/MANT-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MANT-37.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.1
Fixed in r639680.
> Wrong path to test resources in maven-build.xml
> ---
>
> Key: MANT-37
> URL: http://jira.codehaus.org/browse/MANT-37
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 2.1
>
>
> Current content of maven-build.xml:
> {code:xml}
>
> {code}
> Expected content of maven-build.xml:
> {code:xml}
>
> {code}
--
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: (MPLUGIN-102) The 2.4 Release Breaks Previously-Working Builds
[ http://jira.codehaus.org/browse/MPLUGIN-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128168 ] James Carman commented on MPLUGIN-102: -- Ok, so the old documentation was wrong? That means that there are probably lots (as many people who were willing to write their own archetypes for maven :-) of folks out there using maven-plugin as their packaging in their archetypes. The unfortunate thing is that this actually worked in the past and now it doesn't. > The 2.4 Release Breaks Previously-Working Builds > > > Key: MPLUGIN-102 > URL: http://jira.codehaus.org/browse/MPLUGIN-102 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-test.zip, debug.log > > > We have an archetype contained within our project. Today, when I tried to > run our build, I got the following error: > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin.' > However, if I add this to my pom.xml file for that module: > > > > org.apache.maven.plugins > maven-plugin-plugin > 2.3 > > > > the build works just fine, as usual (understandable since the 2.4 release > came out yesterday). -- 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: (MPLUGIN-102) The 2.4 Release Breaks Previously-Working Builds
[ http://jira.codehaus.org/browse/MPLUGIN-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128168 ] jwcarman edited comment on MPLUGIN-102 at 3/21/08 11:00 AM: Ok, so the old documentation was wrong? That means that there are probably lots (as many people who were willing to write their own archetypes for maven) of folks out there using maven-plugin as their packaging in their archetypes. The unfortunate thing is that this actually worked in the past and now it doesn't. was (Author: jwcarman): Ok, so the old documentation was wrong? That means that there are probably lots (as many people who were willing to write their own archetypes for maven :-) of folks out there using maven-plugin as their packaging in their archetypes. The unfortunate thing is that this actually worked in the past and now it doesn't. > The 2.4 Release Breaks Previously-Working Builds > > > Key: MPLUGIN-102 > URL: http://jira.codehaus.org/browse/MPLUGIN-102 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Attachments: archetype-test.zip, debug.log > > > We have an archetype contained within our project. Today, when I tried to > run our build, I got the following error: > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin.' > However, if I add this to my pom.xml file for that module: > > > > org.apache.maven.plugins > maven-plugin-plugin > 2.3 > > > > the build works just fine, as usual (understandable since the 2.4 release > came out yesterday). -- 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-3426) regression : in plugin configuration doesn't override plugin classpath
[ http://jira.codehaus.org/browse/MNG-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3426. --- Assignee: John Casey (was: nicolas de loof) Resolution: Fixed The move to use LinkedHashSet was definitely correct IMO, but it led to some weird side effects for dependency ordering. I've gone back and added a pre-processing step using a LinkedHashMap to merge in the plugin-level dependencies and those from the plugin-POM itself. I kept the plugin-level deps as first to be added, which gives them precedence (so they can replace dependencies from the plugin POM), but added code to make sure any duplicates according to dependencyConflictId are avoided. This is consistent with dependencies in the POM, where duplicates there should lead to a model validation exception during project building. I think this issue can safely be put to bed now. > regression : in plugin configuration doesn't override plugin > classpath > --- > > Key: MNG-3426 > URL: http://jira.codehaus.org/browse/MNG-3426 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API >Affects Versions: 2.0.8 >Reporter: nicolas de loof >Assignee: John Casey >Priority: Critical > Fix For: 2.0.9 > > > Many maven plugins are wrapper around other tools. The plugin is designed for > a version of the tool, and in many case user will want to use a specific > version without having to patch the plugin. The element on > plugin configuration is a common way to do this, by overriding the plugin POM > dependency with another version. > >castor-maven-plugin > > > org.codehaus.castor > castor > VERSION OF CASTOR I WANT TO USE FOR CODE > GENERATION > > > > This used to work with maven < 2.0.8 > In maven 2.0.8, this doesn't work anymore as the set in plugin > configuration is added to plugin classpath, as a duplicate for the one > declared by the plugin but LATER in the classpath (but I may be wrong on this > analysis). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-3473) site generation with 2.0.9 and plugin:report is broken
[ http://jira.codehaus.org/browse/MNG-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey reopened MNG-3473: - The issue with the plugin plugin isn't the LinkedHashSet...it's incorrect ordering of dependencies in the plugin's POM, and a change in the artifact-resolution code that uses an ordered set now where it didn't used to. I've verified that the ordering of artifacts resolved for the same plugin POM is different between 2.0.8 and the 2.0.9 code, where the 2.0.9 resolution order is actually correct...the plugin POM specifies dependencies on maven-reporting-impl 2.0.4 and doxia-site-renderer 1.0-alpha-10 IN THAT ORDER. This means that it resolves: # maven-reporting-impl 2.0.4 -> doxia-core 1.0-alpha-7 # doxia-site-renderer 1.0-alpha-10 -> doxia-core 1.0-alpha-10 and, since it sees -alpha-7 of doxia-core FIRST (it's at the same transitivity level as the other doxia-core dependency), -alpha-7 wins. This is correct according to the rules implemented in the ArtifactCollector. Previously, I think it was just dumb luck that it worked using a bad ordering algorithm (or, more precisely, no ordering algorithm). > site generation with 2.0.9 and plugin:report is broken > -- > > Key: MNG-3473 > URL: http://jira.codehaus.org/browse/MNG-3473 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.9 >Reporter: Brian Fox >Assignee: John Casey > Fix For: 2.0.9 > > > Generating a site that works in 2.0.8 breaks in 2.0.9 with an exception: > Caused by: java.lang.NoClassDefFoundError: > org/apache/maven/doxia/module/site/manager/SiteModuleNotFoundException > There is already a committed IT for this. It may be related to issues with > MPLUGIN-104, however in this case the 2.4 version of the plugin does work in > 2.0.8 so we need to investigate it in the core as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3473) site generation with 2.0.9 and plugin:report (2.4 ONLY) is broken
[ http://jira.codehaus.org/browse/MNG-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3473: Summary: site generation with 2.0.9 and plugin:report (2.4 ONLY) is broken (was: site generation with 2.0.9 and plugin:report is broken) > site generation with 2.0.9 and plugin:report (2.4 ONLY) is broken > - > > Key: MNG-3473 > URL: http://jira.codehaus.org/browse/MNG-3473 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.9 >Reporter: Brian Fox >Assignee: John Casey > Fix For: 2.0.9 > > > Generating a site that works in 2.0.8 breaks in 2.0.9 with an exception: > Caused by: java.lang.NoClassDefFoundError: > org/apache/maven/doxia/module/site/manager/SiteModuleNotFoundException > There is already a committed IT for this. It may be related to issues with > MPLUGIN-104, however in this case the 2.4 version of the plugin does work in > 2.0.8 so we need to investigate it in the core as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPLUGIN-104) plugin report broken in 2.4
[
http://jira.codehaus.org/browse/MPLUGIN-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128171
]
John Casey commented on MPLUGIN-104:
I think this is related to a piece of code that was originally duplicated in
the site mojo, which takes care of constructing a sink from the site renderer
component...these two (multiple?) copies diverged as time went on, and now the
site run including the plugin-plugin succeeds because it constructs and passes
in a sink, where the plugin:report execution fails.
That's just a theory.
> plugin report broken in 2.4
> ---
>
> Key: MPLUGIN-104
> URL: http://jira.codehaus.org/browse/MPLUGIN-104
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 2.4
>Reporter: Brian Fox
>
> In 2.4 with 2.0.8 I get:
> {noformat}
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO]
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> [INFO]
>
> [DEBUG] Trace
> java.lang.NoSuchMethodError:
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> 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:324)
> 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)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANT-36) Use correct file encoding when writing build files
[
http://jira.codehaus.org/browse/MANT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MANT-36.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.1
Fixed in r639695.
> Use correct file encoding when writing build files
> --
>
> Key: MANT-36
> URL: http://jira.codehaus.org/browse/MANT-36
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 2.1
>
>
> The {{AntBuildWriter}} employs a {{FileWriter}} to output UTF-8 encoded XML
> files, this is buggy, see also [Common
> Bugs|http://www.nabble.com/Common-Bugs-to14783703s177.html#a15919795].
--
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: (MPLUGIN-105) incorrect order of dependencies on maven-reporting-impl and doxia-site-renderer leads to wrong doxia-core
incorrect order of dependencies on maven-reporting-impl and doxia-site-renderer leads to wrong doxia-core - Key: MPLUGIN-105 URL: http://jira.codehaus.org/browse/MPLUGIN-105 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: Plugin Plugin Affects Versions: 2.4 Reporter: John Casey Priority: Blocker Since the 2.0.9 code for Maven preserves the ordering of dependencies in a POM for artifact resolution, the order of these dependencies now matters. In the plugin plugin, it specifies two dependencies that drag in different versions of doxia-core...the ordering of these two direct dependencies results in an incompatible doxia-core version (from the maven-reporting-impl version 2.0.4) being chosen over that from doxia-site-renderer. We need to either (a) exclude doxia-core from the transitive dependencies brought in by maven-reporting-impl, or (b) state a direct dependency on doxia-core. Which is done depends on whether the plugin plugin in fact makes direct use of classes from doxia-core... maven-plugin-plugin 2.4 is unusable from the current maven-2.0.9 code as a result of this problem, unless the user specifies a plugin-level dependency in their own POM on doxia-core 1.0-alpha-10. -- 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: (MPLUGIN-102) The 2.4 Release Breaks Previously-Working Builds
[ http://jira.codehaus.org/browse/MPLUGIN-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MPLUGIN-102: -- Fix Version/s: 2.5 > The 2.4 Release Breaks Previously-Working Builds > > > Key: MPLUGIN-102 > URL: http://jira.codehaus.org/browse/MPLUGIN-102 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman > Fix For: 2.5 > > Attachments: archetype-test.zip, debug.log > > > We have an archetype contained within our project. Today, when I tried to > run our build, I got the following error: > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin.' > However, if I add this to my pom.xml file for that module: > > > > org.apache.maven.plugins > maven-plugin-plugin > 2.3 > > > > the build works just fine, as usual (understandable since the 2.4 release > came out yesterday). -- 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: (MPLUGIN-105) incorrect order of dependencies on maven-reporting-impl and doxia-site-renderer leads to wrong doxia-core
[ http://jira.codehaus.org/browse/MPLUGIN-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MPLUGIN-105: -- Fix Version/s: 2.5 > incorrect order of dependencies on maven-reporting-impl and > doxia-site-renderer leads to wrong doxia-core > - > > Key: MPLUGIN-105 > URL: http://jira.codehaus.org/browse/MPLUGIN-105 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4 >Reporter: John Casey >Priority: Blocker > Fix For: 2.5 > > > Since the 2.0.9 code for Maven preserves the ordering of dependencies in a > POM for artifact resolution, the order of these dependencies now matters. In > the plugin plugin, it specifies two dependencies that drag in different > versions of doxia-core...the ordering of these two direct dependencies > results in an incompatible doxia-core version (from the maven-reporting-impl > version 2.0.4) being chosen over that from doxia-site-renderer. > We need to either (a) exclude doxia-core from the transitive dependencies > brought in by maven-reporting-impl, or (b) state a direct dependency on > doxia-core. Which is done depends on whether the plugin plugin in fact makes > direct use of classes from doxia-core... > maven-plugin-plugin 2.4 is unusable from the current maven-2.0.9 code as a > result of this problem, unless the user specifies a plugin-level dependency > in their own POM on doxia-core 1.0-alpha-10. -- 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: (MPLUGIN-104) plugin report broken in 2.4
[
http://jira.codehaus.org/browse/MPLUGIN-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MPLUGIN-104:
--
Fix Version/s: 2.5
> plugin report broken in 2.4
> ---
>
> Key: MPLUGIN-104
> URL: http://jira.codehaus.org/browse/MPLUGIN-104
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 2.4
>Reporter: Brian Fox
> Fix For: 2.5
>
>
> In 2.4 with 2.0.8 I get:
> {noformat}
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO]
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> [INFO]
>
> [DEBUG] Trace
> java.lang.NoSuchMethodError:
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> 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:324)
> 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)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-154) mvn release:perform does not inherit command line variable
[ http://jira.codehaus.org/browse/MRELEASE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128179 ] Mike Beaubien commented on MRELEASE-154: Have you tried using the -Darguments flag that is in the documentation for the plugin? > mvn release:perform does not inherit command line variable > -- > > Key: MRELEASE-154 > URL: http://jira.codehaus.org/browse/MRELEASE-154 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Michael Semb Wever >Priority: Critical > > When I deploy i must add -Duser.name=mickw to ensure scpexe logins in with > the correct username. > eg mvn deploy -Duser.name=mick > But when I run "mvn release:perform" scpexe fails when it forks the sub > process: > mvn deploy site-deploy --no-plugin-updates -P null,null -DperformRelease=true > and it's missing the -Duser.name=mickw variable. > I need some way of setting the user.name property to make it possible to run > release:perform -- 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-44) Add uniqueVersion parameter to deploy goal as deploy-file goal
[ http://jira.codehaus.org/browse/MDEPLOY-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128181 ] Farrukh Najmi commented on MDEPLOY-44: -- The workaround listed in previous comment would be quite adequate for me but its not working for me. Perhaps there is a mistake in the example given? > Add uniqueVersion parameter to deploy goal as deploy-file goal > -- > > Key: MDEPLOY-44 > URL: http://jira.codehaus.org/browse/MDEPLOY-44 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.2.1 > Environment: Maven 2.0.4 >Reporter: David Vicente > > We developp a big application which we deploy in our local repository with > deploy goal. > But deploy goal use a timestamp to name the archive file and we have many > problems of disk space that obliges us to clean manually our local repository. > it's possible to add the uniqueVersion parameter to deploy goal as done with > deploy-file goal which would remove us the obligation to purge ? > thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-334) Can't release project due to non released dependencies
[ http://jira.codehaus.org/browse/MRELEASE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128183 ] Dennis Lundberg commented on MRELEASE-334: -- If you *really* don't care about the reproducibility of your reporting plugins, you can (as a work-around) remove the version element for the ones that are SNAPSHOTs. > Can't release project due to non released dependencies > -- > > Key: MRELEASE-334 > URL: http://jira.codehaus.org/browse/MRELEASE-334 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-7 >Reporter: Kamen Petroff > Attachments: maven-release-manager.patch, maven-release-manager.patch > > > I guess the problem is already known. But once again > in maven-release-manager 1.0-alpha-4 > org/apache/maven/shared/release/phase/CheckDependencySnapshotsPhase.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3474) Add parameter --internet to test Internet access with and without using proxy defined in settings.xml
Add parameter --internet to test Internet access with and without using proxy defined in settings.xml - Key: MNG-3474 URL: http://jira.codehaus.org/browse/MNG-3474 Project: Maven 2 Issue Type: New Feature Components: Command Line Affects Versions: 2.0.8 Reporter: Wayne Fay Based on the number of problems we see reported on the User list relating to web proxies, I think this is an area we should attempt to address. I think we might seriously want to throw a little code in core-uber that is delivered with the installation that can attempt to access the Internet without any proxy, and then some more code that uses the settings.xml proxy info, to be used for debugging these kinds of situations. Then we can tell people, what does "mvn --internet" say? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-25) mvn site:site ignores server configuration in settings.xml
[ http://jira.codehaus.org/browse/MSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128184 ] Adam C. Migus commented on MSITE-25: I also think it should be reopened since 2.0-beta-6 has been released without the fix included. Or at least 2.0-beta-6 still contains the bug anyway. A fix for 2.0-beta-7 seems reasonable since a patch is already available and presumably it only needs to be applied and tested right? > mvn site:site ignores server configuration in settings.xml > -- > > Key: MSITE-25 > URL: http://jira.codehaus.org/browse/MSITE-25 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Alan Cabrera >Assignee: Carlos Sanchez >Priority: Critical > Fix For: 2.0-beta-6 > > Attachments: MSITE-25-01.patch, MSITE-25.txt, > patch-MSITE-25-artifact-manager.diff, patch-MSITE-25-site-plugin.diff > > > mvn site:site ignores parts of my settings.xml: > > livetribe-website > 664 > 775 > > plink > pscp > > livetribe > > It uses the username when ssh but does not invoke plink. > [INFO] [site:deploy] > Using private key: C:\Documents and Settings\adc\.ssh\id_dsa > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Opened > Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o > "BatchMode yes" [EMAIL PROTECTED] "mkdir -p > /home/projects/livetribe/public_html/maven/." > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnecting > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnected -- 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: (MPLUGIN-105) incorrect order of dependencies on maven-reporting-impl and doxia-site-renderer leads to wrong doxia-core
[ http://jira.codehaus.org/browse/MPLUGIN-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MPLUGIN-105. - Resolution: Fixed Reordered the dependencies and confirmed it now fixes MNG-3473 > incorrect order of dependencies on maven-reporting-impl and > doxia-site-renderer leads to wrong doxia-core > - > > Key: MPLUGIN-105 > URL: http://jira.codehaus.org/browse/MPLUGIN-105 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4 >Reporter: John Casey >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.5 > > > Since the 2.0.9 code for Maven preserves the ordering of dependencies in a > POM for artifact resolution, the order of these dependencies now matters. In > the plugin plugin, it specifies two dependencies that drag in different > versions of doxia-core...the ordering of these two direct dependencies > results in an incompatible doxia-core version (from the maven-reporting-impl > version 2.0.4) being chosen over that from doxia-site-renderer. > We need to either (a) exclude doxia-core from the transitive dependencies > brought in by maven-reporting-impl, or (b) state a direct dependency on > doxia-core. Which is done depends on whether the plugin plugin in fact makes > direct use of classes from doxia-core... > maven-plugin-plugin 2.4 is unusable from the current maven-2.0.9 code as a > result of this problem, unless the user specifies a plugin-level dependency > in their own POM on doxia-core 1.0-alpha-10. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-25) mvn site:site ignores server configuration in settings.xml
[ http://jira.codehaus.org/browse/MSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128187 ] Dennis Lundberg commented on MSITE-25: -- Can someone please provide a sample project that shows that this issue has not been fixed? I suspect a settings.xml snippet should also be included. > mvn site:site ignores server configuration in settings.xml > -- > > Key: MSITE-25 > URL: http://jira.codehaus.org/browse/MSITE-25 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Alan Cabrera >Assignee: Carlos Sanchez >Priority: Critical > Fix For: 2.0-beta-6 > > Attachments: MSITE-25-01.patch, MSITE-25.txt, > patch-MSITE-25-artifact-manager.diff, patch-MSITE-25-site-plugin.diff > > > mvn site:site ignores parts of my settings.xml: > > livetribe-website > 664 > 775 > > plink > pscp > > livetribe > > It uses the username when ssh but does not invoke plink. > [INFO] [site:deploy] > Using private key: C:\Documents and Settings\adc\.ssh\id_dsa > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Opened > Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o > "BatchMode yes" [EMAIL PROTECTED] "mkdir -p > /home/projects/livetribe/public_html/maven/." > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnecting > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnected -- 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: (MASSEMBLY-301) assembly:attach wrongly renames/overwrites assemblies to the primary artifact
assembly:attach wrongly renames/overwrites assemblies to the primary artifact
-
Key: MASSEMBLY-301
URL: http://jira.codehaus.org/browse/MASSEMBLY-301
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Reporter: Dan Diephouse
I've configure the assembly plugin in my project like so:
maven-assembly-plugin
${artifactId}-${version}
assembly.xml
false
make-assembly
package
attached
Note, that my project is producing a JAR artifact in addition to the zip/tar.gz
artifacts produced by the assembly plugin. However, the assembly plugin in
beta-2 feels the need to make the zip assembly the primary assembly and make it
a jar!
[INFO] [install:install]
[INFO] Installing
c:\workspaces\cxf\workspace\mule-transport-restlet\target\mule-transport-restlet-1.0-SNAPSHOT.zip
to
c:\repo\org\mule\transports\mule-transport-restlet\1.0-SNAPSHOT\mule-transport-restlet-1.0-SNAPSHOT.jar
[INFO] [deploy:deploy]
altDeploymentRepository = null
[INFO] Retrieving previous build number from muleforge.webdav.snapshots
Uploading:
https://dav.muleforge.org/snapshots.repository/restlet//org/mule/transports/mule-transport-restlet/1.0-SNAPSHOT/mule-transport-restlet-1.0-20080321.175727-2.jar
During that last line Maven is uploading the zip as the jar!
Reverting back to 2.2-beta-1 fixies 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-3475) Some directories are not basedir aligned
Some directories are not basedir aligned
Key: MNG-3475
URL: http://jira.codehaus.org/browse/MNG-3475
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.8
Reporter: Benjamin Bentmann
Attachments: base-directory-alignment.patch
The output from
{code:xml}
${project.build.sourceDirectory}
${project.build.testSourceDirectory}
${project.build.scriptSourceDirectory}
${project.build.directory}
${project.build.outputDirectory}
${project.build.testOutputDirectory}
${project.reporting.outputDirectory}
{code}
delivers something like
{noformat}
[echo] M:\maven\z\antrun\src\main\java
[echo] M:\maven\z\antrun\src\test\java
[echo] src/main/scripts
[echo] M:\maven\z\antrun\target
[echo] M:\maven\z\antrun\target\classes
[echo] M:\maven\z\antrun\target\test-classes
[echo] target/site
{noformat}
revealing that neither the script source directory nor the reporting output
directory are basedir aligned.
--
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: (MASSEMBLY-291) attach the resulting assembly not working as expected
[ http://jira.codehaus.org/browse/MASSEMBLY-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128190 ] Benjamin Bentmann commented on MASSEMBLY-291: - bq. false This setting causes the Assembly plugin to set the generated assembly as the file of the project's main artifact instead of attaching it as a separate artifact. This fails for a project with packaging "pom" because the Install plugin does not expect that. The same logic caused MASSEMBLY-301. > attach the resulting assembly not working as expected > - > > Key: MASSEMBLY-291 > URL: http://jira.codehaus.org/browse/MASSEMBLY-291 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Vlad Skarzhevskyy > Attachments: test.zip > > > After changing to 2.2-beta-2 attach is not working in our project. > This is configuration used: > project: pom > maven-assembly-plugin: > package > single > >true >false > > The idea is to replace main artifact jar with created jar. packaging pom > has been selected base on example form the site. May be this is wrong but > used to work in version 2.1. > Full Project here: > https://microemulator.svn.sourceforge.net/svnroot/microemulator/branches/microemulator_2_0_2/microemulator > PS > We also have second sources assembly in the same pom.xml This assembly is > installed to local repository! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-154) mvn release:perform does not inherit command line variable
[ http://jira.codehaus.org/browse/MRELEASE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever closed MRELEASE-154. --- Resolution: Won't Fix The documentation > Additional arguments to pass to the Maven executions, separated by spaces. while accurate, is a little unclear. It really needs an example, eg -Darguments="-Duser.name=mickw -DskipTests=true" Otherwise sorry for the erroneous bug report. > mvn release:perform does not inherit command line variable > -- > > Key: MRELEASE-154 > URL: http://jira.codehaus.org/browse/MRELEASE-154 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Michael Semb Wever >Priority: Critical > > When I deploy i must add -Duser.name=mickw to ensure scpexe logins in with > the correct username. > eg mvn deploy -Duser.name=mick > But when I run "mvn release:perform" scpexe fails when it forks the sub > process: > mvn deploy site-deploy --no-plugin-updates -P null,null -DperformRelease=true > and it's missing the -Duser.name=mickw variable. > I need some way of setting the user.name property to make it possible to run > release:perform -- 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-1973) Upload of maven-deployment-package-plugin
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128192 ] Siamak Haschemi commented on MAVENUPLOAD-1973: -- Thanks for the clarification, yes, I will change the name and upload a new version soon. > Upload of maven-deployment-package-plugin > - > > Key: MAVENUPLOAD-1973 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1973 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Siamak Haschemi > > http://kent.dl.sourceforge.net/sourceforge/mvn-dp-plugin/maven-deployment-package-plugin-0.1.0-bundle.jar > https://sourceforge.net/projects/mvn-dp-plugin/ > https://sourceforge.net/project/memberlist.php?group_id=221773 > I'm a developer in maven-deployment-package-plugin, please upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-232) Nested list parsing is not generating correct events
Nested list parsing is not generating correct events
Key: DOXIA-232
URL: http://jira.codehaus.org/browse/DOXIA-232
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.0-alpha-10
Reporter: Vincent Massol
Here's some input I've used (verified it works in Confluence):
{noformat}
# Item 1
## Item 2
##* Item 3
## Item 4
# Item 5
* Item 1
** Item 2
*** Item 3
** Item 4
* Item 5
* Item 6
{noformat}
This generates the following events: NL, LI, NL, LI, LI_, LI, LI_, LI, LI_,
NL_, LI_, etc
It should have generated: NL, LI, NL, LI, LIST, LI, LI_, LIST_, LI_, etc
--
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: (MPLUGIN-32) Make it an error for a plugin to have no mojo
[ http://jira.codehaus.org/browse/MPLUGIN-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MPLUGIN-32. Assignee: Brian Fox Resolution: Duplicate Fix Version/s: 2.4 > Make it an error for a plugin to have no mojo > - > > Key: MPLUGIN-32 > URL: http://jira.codehaus.org/browse/MPLUGIN-32 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement >Reporter: Kohsuke Kawaguchi >Assignee: Brian Fox > Fix For: 2.4 > > > Maven plugins must have mojos to be useful, and not having a mojo causes a > problem down the line like MNG-2925. > Therefore it would be desirable for the plugin plugin to check for this and > issue an error, so that errors will be caught early, not later. A silly pom > mistake (such as not setting build/sourceDirectory right) causes this kind of > problems. -- 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-145) Adding logger feature
[ http://jira.codehaus.org/browse/DOXIA-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128193 ] Vincent Massol commented on DOXIA-145: -- Remark: I don't think adding a enableLoggin() interface to the Sink API is a good solution but I understand it may be an interim one. From an external users of the Doxia API having to implement an enableLogging() method when all I do is provide an implementation for my Sink is strange. I don't want to log anything in my Sink (or if I do it's with my own logging subsystem). > Adding logger feature > - > > Key: DOXIA-145 > URL: http://jira.codehaus.org/browse/DOXIA-145 > Project: Maven Doxia > Issue Type: New Feature > Components: Core, Modules, Sink API >Reporter: Vincent Siveton >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: DOXIA-145.patch > > > Doxia needs to have logger capability insides -- 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: (MRESOURCES-61) PluginDescriptor not found
PluginDescriptor not found -- Key: MRESOURCES-61 URL: http://jira.codehaus.org/browse/MRESOURCES-61 Project: Maven 2.x Resources Plugin Issue Type: Bug Reporter: Brill Pappin The following error, every time I run a build has been ongoing for quite some time now. 3/21/08 3:34:06 PM EDT: Build error for /aleixo-console/pom.xml; java.lang.IllegalStateException: The PluginDescriptor for the plugin org.apache.maven.plugins:maven-resources-plugin was not found It seems to go away if I run with a -U to update the plugins but comes back regularly. Can somebody please fix whatever issue is causing this to occur? -- 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: (MPLUGIN-106) remove no mojo deprecation warning and throw an exception
[ http://jira.codehaus.org/browse/MPLUGIN-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MPLUGIN-106: -- Fix Version/s: 2.5 > remove no mojo deprecation warning and throw an exception > - > > Key: MPLUGIN-106 > URL: http://jira.codehaus.org/browse/MPLUGIN-106 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4.1 >Reporter: Brian Fox > Fix For: 2.5 > > > MNG-1889 suddenly changed functionality that broke existing builds resulting > in MPLUGIN-102. We restored the old functionality with a deprecation warning > and commented out the test. Remove this in the next release and make it fail > the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPLUGIN-106) remove no mojo deprecation warning and throw an exception
[ http://jira.codehaus.org/browse/MPLUGIN-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MPLUGIN-106: -- Description: MPLUGIN-103 (was MNG-1889) suddenly changed functionality that broke existing builds resulting in MPLUGIN-102. We restored the old functionality with a deprecation warning and commented out the test. Remove this in the next release and make it fail the build. (was: MNG-1889 suddenly changed functionality that broke existing builds resulting in MPLUGIN-102. We restored the old functionality with a deprecation warning and commented out the test. Remove this in the next release and make it fail the build. ) > remove no mojo deprecation warning and throw an exception > - > > Key: MPLUGIN-106 > URL: http://jira.codehaus.org/browse/MPLUGIN-106 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4.1 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.5 > > > MPLUGIN-103 (was MNG-1889) suddenly changed functionality that broke existing > builds resulting in MPLUGIN-102. We restored the old functionality with a > deprecation warning and commented out the test. Remove this in the next > release and make it fail the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-106) remove no mojo deprecation warning and throw an exception
remove no mojo deprecation warning and throw an exception - Key: MPLUGIN-106 URL: http://jira.codehaus.org/browse/MPLUGIN-106 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: Plugin Plugin Affects Versions: 2.4.1 Reporter: Brian Fox Fix For: 2.5 MNG-1889 suddenly changed functionality that broke existing builds resulting in MPLUGIN-102. We restored the old functionality with a deprecation warning and commented out the test. Remove this in the next release and make it fail the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPLUGIN-104) plugin report broken in 2.4
[
http://jira.codehaus.org/browse/MPLUGIN-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MPLUGIN-104.
--
Assignee: John Casey
Resolution: Fixed
Made a copy of the 2.0.4 tag for maven-reporting-impl to
https://svn.apache.org/repos/asf/maven/shared/branches/maven-reporting-impl-2.0.4.1-dev,
then adjusted the AbstractMavenReport and SinkFactory to avoid using the
Renderer interface for creating Sink instances. Also bumped the doxia
dependencies there to 1.0-alpha-10 to keep up with things. The new version is
current 2.0.4.1-SNAPSHOT.
Finally, I bumped the maven-reporting-impl version from 2.0.4 to
2.0.4.1-SNAPSHOT to take advantage of the fixes to AbstractMavenReport.
> plugin report broken in 2.4
> ---
>
> Key: MPLUGIN-104
> URL: http://jira.codehaus.org/browse/MPLUGIN-104
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 2.4
>Reporter: Brian Fox
>Assignee: John Casey
> Fix For: 2.4.1
>
>
> In 2.4 with 2.0.8 I get:
> {noformat}
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO]
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> [INFO]
>
> [DEBUG] Trace
> java.lang.NoSuchMethodError:
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> 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:324)
> 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)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPLUGIN-102) The 2.4 Release Breaks Previously-Working Builds
[
http://jira.codehaus.org/browse/MPLUGIN-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MPLUGIN-102.
-
Resolution: Fixed
We're restoring the old functionality for one release with a huge warning:
{noformat}
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING] ***
[WARNING] Deprecation Alert:
[WARNING] No mojo descriptors were found in this project, which has a packaging
type of maven-plugin.
[WARNING] In future versions of the plugin tools, this will fail the build.
[WARNING] If this project is an archetype, change the packaging type from
maven-plugin to maven-archetype.
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
[WARNING]
{noformat}
> The 2.4 Release Breaks Previously-Working Builds
>
>
> Key: MPLUGIN-102
> URL: http://jira.codehaus.org/browse/MPLUGIN-102
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 2.4
> Environment: Maven version: 2.0.8
> Java version: 1.5.0_14
> OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows"
>Reporter: James Carman
>Assignee: Brian Fox
> Fix For: 2.4.1
>
> Attachments: archetype-test.zip, debug.log
>
>
> We have an archetype contained within our project. Today, when I tried to
> run our build, I got the following error:
> [INFO] [plugin:descriptor]
> [INFO] Using 2 extractors.
> [INFO] Applying extractor for language: java
> [INFO] Extractor for language: java found 0 mojo descriptors.
> [INFO] Applying extractor for language: bsh
> [INFO] Extractor for language: bsh found 0 mojo descriptors.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in
> plugin.'
> However, if I add this to my pom.xml file for that module:
>
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
> 2.3
>
>
>
> the build works just fine, as usual (understandable since the 2.4 release
> came out yesterday).
--
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-3476) [maven-reporting-impl] 2.0.4 uses old doxia-site-renderer with obsolete Renderer.createSink(..) call
[maven-reporting-impl] 2.0.4 uses old doxia-site-renderer with obsolete Renderer.createSink(..) call Key: MNG-3476 URL: http://jira.codehaus.org/browse/MNG-3476 Project: Maven 2 Issue Type: Bug Components: Shared, Sites & Reporting Reporter: John Casey Priority: Critical AbstractMavenReport calls Renderer.createSink(..) which is obsolete. The doxia-site-renderer 1.0-alpha-10 release is newest, and Renderer interface in that release doesn't contain this method...The site plugin avoids this problem by creating its own Sink and side-stepping the call in AbstractMavenReport, but this leaves plugin:report (for instance) to fail when called on its own. Since the 2.0.4 release of reporting-impl, many changes have been incorporated, such that I cannot guarantee we won't see significant other problems if we try to use it. (there are several abstract methods that seem to have literally disappeared out of AbstractMavenReport, for example). I've created a copy of the 2.0.4 tag for this project into: https://svn.apache.org/repos/asf/maven/shared/branches/maven-reporting-impl-2.0.4.1-dev to allow us to make a much smaller updated release without all the other changes, just to help stabilize plugins like the maven-plugin-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3476) [maven-reporting-impl] 2.0.4 uses old doxia-site-renderer with obsolete Renderer.createSink(..) call
[ http://jira.codehaus.org/browse/MNG-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3476. --- Assignee: John Casey Resolution: Fixed fixed and ready to stage for a quick release. > [maven-reporting-impl] 2.0.4 uses old doxia-site-renderer with obsolete > Renderer.createSink(..) call > > > Key: MNG-3476 > URL: http://jira.codehaus.org/browse/MNG-3476 > Project: Maven 2 > Issue Type: Bug > Components: Shared, Sites & Reporting >Reporter: John Casey >Assignee: John Casey >Priority: Critical > > AbstractMavenReport calls Renderer.createSink(..) which is obsolete. The > doxia-site-renderer 1.0-alpha-10 release is newest, and Renderer interface in > that release doesn't contain this method...The site plugin avoids this > problem by creating its own Sink and side-stepping the call in > AbstractMavenReport, but this leaves plugin:report (for instance) to fail > when called on its own. > Since the 2.0.4 release of reporting-impl, many changes have been > incorporated, such that I cannot guarantee we won't see significant other > problems if we try to use it. (there are several abstract methods that seem > to have literally disappeared out of AbstractMavenReport, for example). I've > created a copy of the 2.0.4 tag for this project into: > https://svn.apache.org/repos/asf/maven/shared/branches/maven-reporting-impl-2.0.4.1-dev > to allow us to make a much smaller updated release without all the other > changes, just to help stabilize plugins like the maven-plugin-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-3477) Authentication failures on dependency download aren't reported
Authentication failures on dependency download aren't reported -- Key: MNG-3477 URL: http://jira.codehaus.org/browse/MNG-3477 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Reporter: Justin Edelson We have a Maven proxy server (using Proximity) that requires authentication. Users store their username and passwords in settings.xml. If the login information is incorrect, they are not informed the the problem is due to bad credentials, just that the dependencies are missing. -e and -X don't add anything useful. This is true for both dependencies and 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] Commented: (MSITE-25) mvn site:site ignores server configuration in settings.xml
[
http://jira.codehaus.org/browse/MSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128199
]
Adam C. Migus commented on MSITE-25:
Here's my server declaration from settings.xml:
jws.website
amigus
${user.home}/id_dsa.ppk
0775
0664
C:\Program
Files\PuTTY\plink.exe
-batch -C
C:\Program
Files\PuTTY\pscp.exe
-q -batch -C
Here's the end of the output (with hostname changed):
...
[INFO] [site:deploy]
scpexe://myhost.mydomain.com/web/code/docs/jws/code - Session: Opened
Executing command: cmd.exe /X /C '"ssh -i
C:\Work\workspaces\jws\${user.home}\id_dsa.ppk -o "BatchMode yes" [EMAIL
PROTECTED] "mkdir -p /web/code/docs/jws/code/.""'
'ssh' is not recognized as an internal or external command,
operable program or batch file.
scpexe://myhost.mydomain.com/web/code/docs/jws/code - Session: Disconnecting
scpexe://myhost.mydomain.com/web/code/docs/jws/code - Session: Disconnected
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error uploading site
Embedded error: Error performing commands for file transfer
Exit code 1 - 'ssh' is not recognized as an internal or external command,
operable program or batch file.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 4 seconds
[INFO] Finished at: Fri Mar 21 16:12:57 EDT 2008
[INFO] Final Memory: 6M/12M
[INFO]
Also notice that ${user.home} is not getting dereferenced. Is that another bug?
> mvn site:site ignores server configuration in settings.xml
> --
>
> Key: MSITE-25
> URL: http://jira.codehaus.org/browse/MSITE-25
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Reporter: Alan Cabrera
>Assignee: Carlos Sanchez
>Priority: Critical
> Fix For: 2.0-beta-6
>
> Attachments: MSITE-25-01.patch, MSITE-25.txt,
> patch-MSITE-25-artifact-manager.diff, patch-MSITE-25-site-plugin.diff
>
>
> mvn site:site ignores parts of my settings.xml:
>
> livetribe-website
> 664
> 775
>
> plink
> pscp
>
> livetribe
>
> It uses the username when ssh but does not invoke plink.
> [INFO] [site:deploy]
> Using private key: C:\Documents and Settings\adc\.ssh\id_dsa
> scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ -
> Session: Opened
> Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o
> "BatchMode yes" [EMAIL PROTECTED] "mkdir -p
> /home/projects/livetribe/public_html/maven/."
> scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ -
> Session: Disconnecting
> scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ -
> Session: Disconnected
--
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: (MRESOURCES-61) PluginDescriptor not found
[ http://jira.codehaus.org/browse/MRESOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128205 ] Dennis Lundberg commented on MRESOURCES-61: --- Please provide a complete build log with stacktrace turned on. mvn package -e > PluginDescriptor not found > -- > > Key: MRESOURCES-61 > URL: http://jira.codehaus.org/browse/MRESOURCES-61 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Reporter: Brill Pappin > > The following error, every time I run a build has been ongoing for quite some > time now. > 3/21/08 3:34:06 PM EDT: Build error for /aleixo-console/pom.xml; > java.lang.IllegalStateException: The PluginDescriptor for the plugin > org.apache.maven.plugins:maven-resources-plugin was not found > It seems to go away if I run with a -U to update the plugins but comes back > regularly. > Can somebody please fix whatever issue is causing this to occur? -- 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-3474) Add parameter --internet to test Internet access with and without using proxy defined in settings.xml
[ http://jira.codehaus.org/browse/MNG-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3474: --- Fix Version/s: 2.0.10 > Add parameter --internet to test Internet access with and without using proxy > defined in settings.xml > - > > Key: MNG-3474 > URL: http://jira.codehaus.org/browse/MNG-3474 > Project: Maven 2 > Issue Type: New Feature > Components: Command Line >Affects Versions: 2.0.8 >Reporter: Wayne Fay > Fix For: 2.0.10 > > > Based on the number of problems we see reported on the User list relating to > web proxies, I think this is an area we should attempt to address. > I think we might seriously want to throw a little code in core-uber that is > delivered with the installation that can attempt to access the Internet > without any proxy, and then some more code that uses the settings.xml proxy > info, to be used for debugging these kinds of situations. > Then we can tell people, what does "mvn --internet" say? -- 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: (MPLUGIN-102) The 2.4 Release Breaks Previously-Working Builds
[ http://jira.codehaus.org/browse/MPLUGIN-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128215 ] James Carman commented on MPLUGIN-102: -- I like it! Thanks. > The 2.4 Release Breaks Previously-Working Builds > > > Key: MPLUGIN-102 > URL: http://jira.codehaus.org/browse/MPLUGIN-102 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_14 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" >Reporter: James Carman >Assignee: Brian Fox > Fix For: 2.4.1 > > Attachments: archetype-test.zip, debug.log > > > We have an archetype contained within our project. Today, when I tried to > run our build, I got the following error: > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in > plugin.' > However, if I add this to my pom.xml file for that module: > > > > org.apache.maven.plugins > maven-plugin-plugin > 2.3 > > > > the build works just fine, as usual (understandable since the 2.4 release > came out yesterday). -- 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: (MANT-32) java.lang.ClassCastException when packaging jeuclid-3.0.1
[
http://jira.codehaus.org/browse/MANT-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MANT-32.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.1
Fixed in r639856, with Dennis' unit test in place.
The problem was that collection-valued parameters with only a single element
were not recognized as collections. A possible though ugly workaround is to
double up the single collection item:
{code:xml}
**/Bad.java
**/Bad.java
{code}
However, I don't know for sure whether all plugins would handle such a
duplication gracefully. To fix the error that Peter originally faced, he would
need to double up the {{}} element from his javadoc configuration.
> java.lang.ClassCastException when packaging jeuclid-3.0.1
> -
>
> Key: MANT-32
> URL: http://jira.codehaus.org/browse/MANT-32
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Fedora 7 Linux with Sun JDK 1.6.0_02
>Reporter: Peter Wainwright
>Assignee: Benjamin Bentmann
> Fix For: 2.1
>
> Attachments: MANT-32-testcase.patch
>
>
> "mvn package" causes java.lang.ClassCastException when packaging jeuclid-3.0.1
> Stack dump is here:
> [INFO] Building jar:
> /home/prw/src/jeuclid-parent-3.0.1/jeuclid-core/target/jeuclid-core-3.0.1.jar
> [INFO] [ant:ant {execution: default}]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] java.util.HashMap cannot be cast to [Ljava.util.Map;
> [INFO]
>
> [INFO] Trace
> java.lang.ClassCastException: java.util.HashMap cannot be cast to
> [Ljava.util.Map;
> at
> org.apache.maven.plugin.ant.AntBuildWriterUtil.getMavenPluginOptions(AntBuildWriterUtil.java:980)
> at
> org.apache.maven.plugin.ant.AntBuildWriterUtil.getMavenJavadocPluginOptions(AntBuildWriterUtil.java:823)
> at
> org.apache.maven.plugin.ant.AntBuildWriterUtil.writeJavadocTask(AntBuildWriterUtil.java:533)
> at
> org.apache.maven.plugin.ant.AntBuildWriter.writeJavadocTarget(AntBuildWriter.java:865)
> at
> org.apache.maven.plugin.ant.AntBuildWriter.writeGeneratedBuildXml(AntBuildWriter.java:299)
> at
> org.apache.maven.plugin.ant.AntBuildWriter.writeBuildXmls(AntBuildWriter.java:112)
> at org.apache.maven.plugin.ant.AntMojo.execute(AntMojo.java:112)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java: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)
> Unfortunately I don't know enough Java to fix this. Nor do I have a clue
> what the code is
> supposed to be doing. However, it seems that
> getMavenPluginConfigurationsImpl().get()
> returns a single HashMap, and getMavenPluginOptions is trying to cast this to
> an array of Maps.
> Is this possible?
> The previous version, 2.0-beta-1, works OK.
--
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:
[jira] Commented: (MANT-34) The generated maven-build.xml and maven-build.properties contains absolute path to local repository
[
http://jira.codehaus.org/browse/MANT-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128221
]
Benjamin Bentmann commented on MANT-34:
---
I just tweaked your original fix such that the {{maven-build.xml}} always uses
the generic value "${user.home}/.m2/repository". This build file is meant to be
under version control and hence shared among different users, absolute paths
are not of any use here.
The path to the local repo is a user-specific setting, it should therefore be
configured in the {{${user.home\}/.m2/maven.properties}} that is imported by
the {{maven-build.xml}}.
> The generated maven-build.xml and maven-build.properties contains absolute
> path to local repository
> ---
>
> Key: MANT-34
> URL: http://jira.codehaus.org/browse/MANT-34
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
> Fix For: 2.1
>
>
> Even though the local repository is in the default location
> ${user.home}/.m2/repository, the generated files contains absolute paths for
> maven.repo.local. Ant knows about ${user.home} so that can be used in both
> files.
--
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: (MSITE-25) mvn site:site ignores server configuration in settings.xml
[ http://jira.codehaus.org/browse/MSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated MSITE-25: --- Attachment: MSITE-25.settings.xml.fragment.txt MSITE-25.sample.pom.xml I will try to provide the simplest sample project (well, its just a pom, but ... :-) Recipe: (0) Add from attached MSITE-25.settings.xml.fragment.txt to your settings.xml (1) Add attached MSITE-25.sample.pom.xml to a newly created local directory (as pom.xml) (2) mvn site-deploy (in above directory) This is designed to fail. Depending on whether you have commandline ssh or not, you will either see things along the lines of "Host does not exist" or "'ssh' is not recognized as an internal or external command, operable program or batch file." Note that in any case, the sshExecutable used is 'ssh' whereas we're requesting 'plink' in the server configuration. See other comments in this JIRA for complete console readout. (3) Apply my patch MSITE-25-01.patch to the maven-site-plugin, install 2.0-beta-7-SNAPSHOT locally. See previous comments for rationale about the patch. (4) mvn site:deploy This will still fail :-) but the sshExecutable will be 'plink' as desired. I'm happy to answer questions if any of this is unclear. Thanks for your time. > mvn site:site ignores server configuration in settings.xml > -- > > Key: MSITE-25 > URL: http://jira.codehaus.org/browse/MSITE-25 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Alan Cabrera >Assignee: Carlos Sanchez >Priority: Critical > Fix For: 2.0-beta-6 > > Attachments: MSITE-25-01.patch, MSITE-25.sample.pom.xml, > MSITE-25.settings.xml.fragment.txt, MSITE-25.txt, > patch-MSITE-25-artifact-manager.diff, patch-MSITE-25-site-plugin.diff > > > mvn site:site ignores parts of my settings.xml: > > livetribe-website > 664 > 775 > > plink > pscp > > livetribe > > It uses the username when ssh but does not invoke plink. > [INFO] [site:deploy] > Using private key: C:\Documents and Settings\adc\.ssh\id_dsa > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Opened > Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o > "BatchMode yes" [EMAIL PROTECTED] "mkdir -p > /home/projects/livetribe/public_html/maven/." > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnecting > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnected -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MSITE-25) mvn site:site ignores server configuration in settings.xml
[ http://jira.codehaus.org/browse/MSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg reopened MSITE-25: -- Assignee: Dennis Lundberg (was: Carlos Sanchez) Seems that this wasn't completely fixed. > mvn site:site ignores server configuration in settings.xml > -- > > Key: MSITE-25 > URL: http://jira.codehaus.org/browse/MSITE-25 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Alan Cabrera >Assignee: Dennis Lundberg >Priority: Critical > Fix For: 2.0-beta-6 > > Attachments: MSITE-25-01.patch, MSITE-25.sample.pom.xml, > MSITE-25.settings.xml.fragment.txt, MSITE-25.txt, > patch-MSITE-25-artifact-manager.diff, patch-MSITE-25-site-plugin.diff > > > mvn site:site ignores parts of my settings.xml: > > livetribe-website > 664 > 775 > > plink > pscp > > livetribe > > It uses the username when ssh but does not invoke plink. > [INFO] [site:deploy] > Using private key: C:\Documents and Settings\adc\.ssh\id_dsa > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Opened > Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o > "BatchMode yes" [EMAIL PROTECTED] "mkdir -p > /home/projects/livetribe/public_html/maven/." > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnecting > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnected -- 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-25) mvn site:site ignores server configuration in settings.xml
[ http://jira.codehaus.org/browse/MSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-25. Resolution: Fixed Fix Version/s: (was: 2.0-beta-6) 2.0-beta-7 I applied Rahul's patch with modifications. Thanks! I moved the code added by the patch to the configureWagon() method. That way, when we upgrade the Maven dependency to 2.0.5 in the site-plugin, your code will be removed along side other code that is available in Maven 2.0.5. A new 2.0-beta-7-SNAPSHOT has been deployed. Please try it and confirm that it fixes this issue. > mvn site:site ignores server configuration in settings.xml > -- > > Key: MSITE-25 > URL: http://jira.codehaus.org/browse/MSITE-25 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Alan Cabrera >Assignee: Dennis Lundberg >Priority: Critical > Fix For: 2.0-beta-7 > > Attachments: MSITE-25-01.patch, MSITE-25.sample.pom.xml, > MSITE-25.settings.xml.fragment.txt, MSITE-25.txt, > patch-MSITE-25-artifact-manager.diff, patch-MSITE-25-site-plugin.diff > > > mvn site:site ignores parts of my settings.xml: > > livetribe-website > 664 > 775 > > plink > pscp > > livetribe > > It uses the username when ssh but does not invoke plink. > [INFO] [site:deploy] > Using private key: C:\Documents and Settings\adc\.ssh\id_dsa > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Opened > Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o > "BatchMode yes" [EMAIL PROTECTED] "mkdir -p > /home/projects/livetribe/public_html/maven/." > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnecting > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnected -- 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: (MSITE-101) schedule and release doxia 1.0
[ http://jira.codehaus.org/browse/MSITE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-101: -- Fix Version/s: (was: 2.0-beta-7) 2.0 > schedule and release doxia 1.0 > -- > > Key: MSITE-101 > URL: http://jira.codehaus.org/browse/MSITE-101 > Project: Maven 2.x Site Plugin > Issue Type: Task > Components: doxia integration >Reporter: Brett Porter > Fix For: 2.0 > > > resolve any outstanding issues -- 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: (MANT-4) Generated ANT contains hardcoded "get" tasks that look at the "C:\" drive etc... when using a local repository
[
http://jira.codehaus.org/browse/MANT-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MANT-4.
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.1
Fixed in r639932.
The Ant script now contains snippets like below for "file:" repos that are
relative to ${basedir}:
{code:xml}
{code}
> Generated ANT contains hardcoded "get" tasks that look at the "C:\" drive
> etc... when using a local repository
> --
>
> Key: MANT-4
> URL: http://jira.codehaus.org/browse/MANT-4
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Reporter: Michael Neale
>Assignee: Benjamin Bentmann
>Priority: Critical
> Fix For: 2.1
>
> Attachments: build.xml, pom.xml
>
>
> For projects which have a repository with a "file://" style URL (ie a local
> repo just for the project) - mvn ant:ant generates a build.xml which contains
> hard coded paths, even though all the paths in the pom are relative.
> (see attached for some specific examples).
> Otherwise works a treat !
--
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: (MRESOURCES-61) PluginDescriptor not found
[ http://jira.codehaus.org/browse/MRESOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128235 ] Brill Pappin commented on MRESOURCES-61: Of course I can't get it to happen now... I'll post a stack trace when I next encounter it, but its been happening for about 4-6 months now. > PluginDescriptor not found > -- > > Key: MRESOURCES-61 > URL: http://jira.codehaus.org/browse/MRESOURCES-61 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Reporter: Brill Pappin > > The following error, every time I run a build has been ongoing for quite some > time now. > 3/21/08 3:34:06 PM EDT: Build error for /aleixo-console/pom.xml; > java.lang.IllegalStateException: The PluginDescriptor for the plugin > org.apache.maven.plugins:maven-resources-plugin was not found > It seems to go away if I run with a -U to update the plugins but comes back > regularly. > Can somebody please fix whatever issue is causing this to occur? -- 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
