[jira] Updated: (DOXIA-303) Confluence: Image attributes are not recognized
[
http://jira.codehaus.org/browse/DOXIA-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated DOXIA-303:
Description:
For example the following line:
{noformat}
!waterfall.jpg|thumbnail!
{noformat}
should generate thumbnail of given image, now it is not recognized.
was:
For example the following line:
!waterfall.jpg|thumbnail!
should generate thumbnail of given image, now it is not recognized.
> Confluence: Image attributes are not recognized
> ---
>
> Key: DOXIA-303
> URL: http://jira.codehaus.org/browse/DOXIA-303
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.1
>Reporter: Kornel
> Attachments: MNG-303-module-confluence.patch
>
>
> For example the following line:
> {noformat}
> !waterfall.jpg|thumbnail!
> {noformat}
> should generate thumbnail of given image, now it is not recognized.
--
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-361) Confluence: figure captions not rendered
Confluence: figure captions not rendered Key: DOXIA-361 URL: http://jira.codehaus.org/browse/DOXIA-361 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.1 Reporter: Lukas Theussl Figure captions seem to go into the attribute, ie they are not rendered in the xhtml output. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-83) Banned dependencies should support regular expressions
Banned dependencies should support regular expressions -- Key: MENFORCER-83 URL: http://jira.codehaus.org/browse/MENFORCER-83 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Components: Standard Rules Affects Versions: 1.0-beta-1 Reporter: Eric Lewis The includes and excludes of the bannedDependencies rule support wildcards, but only for an entire section. They should be enhanced to support regular expressions. For instance instead of having my.company:abc-api my.company:def-api my.company:ghi-api my.company:jkl-api one would specify my.company:.*\-api To be compatible, the wildcard '*' would be treated as regular expression '.*' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3139) The skin does not exist: Unable to determine the release version
[ http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187571#action_187571 ] Benjamin Bentmann commented on MNG-3139: Neil, without some more information like a full debug log or an example project, we have no basis for investigation. > The skin does not exist: Unable to determine the release version > > > Key: MNG-3139 > URL: http://jira.codehaus.org/browse/MNG-3139 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.7 >Reporter: eyal david >Assignee: John Casey > Fix For: 2.0.11, 2.1.0, 3.0-alpha-3 > > Attachments: cached-metadata.patch > > > hi I have problem generating site when im using the command mvn site > it performs all stagegs and when it came to site generation the message is > shown : > The skin does not exist: Unable to determine the release version > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.skins > -DartifactId=maven > -default-skin \ > -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file > org.apache.maven.skins:maven-default-skin:jar:RELEASE > do u have an idea what is the problem ? > p.s the jar is registered in my local repository and in the remote repository > thank u -- 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: (MENFORCER-83) Banned dependencies should support regular expressions
[ http://jira.codehaus.org/browse/MENFORCER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187572#action_187572 ] Eric Lewis commented on MENFORCER-83: - Sorry, I wasn't aware of the syntax in JIRA. The last sentence should read To be compatible, the wildcard * would be treated as regular expression .* > Banned dependencies should support regular expressions > -- > > Key: MENFORCER-83 > URL: http://jira.codehaus.org/browse/MENFORCER-83 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0-beta-1 >Reporter: Eric Lewis > > The includes and excludes of the bannedDependencies rule support wildcards, > but only for an entire section. > They should be enhanced to support regular expressions. > For instance instead of having > > my.company:abc-api > my.company:def-api > my.company:ghi-api > my.company:jkl-api > > one would specify > > my.company:.*\-api > > To be compatible, the wildcard '*' would be treated as regular expression '.*' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3139) The skin does not exist: Unable to determine the release version
[
http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187578#action_187578
]
Neil Almodiel commented on MNG-3139:
Sorry, the issue log and all details are the same (see below) as initially
reported by eyal david.
It's just that I encountered the same issue in 2.2.0 even though it was
supposed to have been fixed since 2.1.0
Just forgot to merge maybe? Thanks!
[INFO] [site:site {execution: default-site}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] SiteToolException: ArtifactNotFoundException: The skin does not exist:
Unable to determine the release version
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.skins
-DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.skins
-DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
org.apache.maven.skins:maven-default-skin:jar:RELEASE
> The skin does not exist: Unable to determine the release version
>
>
> Key: MNG-3139
> URL: http://jira.codehaus.org/browse/MNG-3139
> Project: Maven 2
> Issue Type: Bug
> Components: Sites & Reporting
>Affects Versions: 2.0.7
>Reporter: eyal david
>Assignee: John Casey
> Fix For: 2.0.11, 2.1.0, 3.0-alpha-3
>
> Attachments: cached-metadata.patch
>
>
> hi I have problem generating site when im using the command mvn site
> it performs all stagegs and when it came to site generation the message is
> shown :
> The skin does not exist: Unable to determine the release version
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.maven.skins
> -DartifactId=maven
> -default-skin \
> -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file
> org.apache.maven.skins:maven-default-skin:jar:RELEASE
> do u have an idea what is the problem ?
> p.s the jar is registered in my local repository and in the remote repository
> thank u
--
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: (MJAVADOC-247) location of doc-files is wrong on page http://maven.apache.org/plugins/maven-javadoc-plugin/examples/test-javadocs.html
[
http://jira.codehaus.org/browse/MJAVADOC-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MJAVADOC-247:
-
Description:
On the web-page
http://maven.apache.org/plugins/maven-javadoc-plugin/examples/test-javadocs.html
there is a tree-view of a directory layout (see below)
It shows the hypothetical path:
src/main/javadoc/org/apache/myapp/doc-files/app.png
This is a bad example as it will not work w/o fiddling around with pom
configuration.
It should say:
src/main/javadoc/doc-files/app.png
If you were to use the layout given, you would discover that app.png is never
copied into the
target directory.
{noformat}
yourproject
|-- src
|-- main
| |-- java
| | |-- org
| | |-- apache
| ||-- myapp
| | `-- App.java
| |-- javadoc
| `-- overview.html
| |-- org
||-- apache
| |-- myapp
|`-- package.html
| |-- doc-files
| `-- app.png
|-- test
|-- java
| |-- org
| |-- apache
||-- myapp
| `-- AppTest.java
|-- javadoc
`-- overview.html
|-- org
|-- apache
|-- myapp
`-- package.html
|-- doc-files
`-- app.png
{noformat}
was:
On the web-page
http://maven.apache.org/plugins/maven-javadoc-plugin/examples/test-javadocs.html
there is a tree-view of a directory layout (see below)
It shows the hypothetical path:
src/main/javadoc/org/apache/myapp/doc-files/app.png
This is a bad example as it will not work w/o fiddling around with pom
configuration.
It should say:
src/main/javadoc/doc-files/app.png
If you were to use the layout given, you would discover that app.png is never
copied into the
target directory.
yourproject
|-- src
|-- main
| |-- java
| | |-- org
| | |-- apache
| ||-- myapp
| | `-- App.java
| |-- javadoc
| `-- overview.html
| |-- org
||-- apache
| |-- myapp
|`-- package.html
| |-- doc-files
| `-- app.png
|-- test
|-- java
| |-- org
| |-- apache
||-- myapp
| `-- AppTest.java
|-- javadoc
`-- overview.html
|-- org
|-- apache
|-- myapp
`-- package.html
|-- doc-files
`-- app.png
> location of doc-files is wrong on page
> http://maven.apache.org/plugins/maven-javadoc-plugin/examples/test-javadocs.html
> ---
>
> Key: MJAVADOC-247
> URL: http://jira.codehaus.org/browse/MJAVADOC-247
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
> Environment: Published web page
>Reporter: bruce weertman
>Priority: Minor
>
> On the web-page
>
> http://maven.apache.org/plugins/maven-javadoc-plugin/examples/test-javadocs.html
>
> there is a tree-view of a directory layout (see below)
> It shows the hypothetical path:
>src/main/javadoc/org/apache/myapp/doc-files/app.png
> This is a bad example as it will not work w/o fiddling around with pom
> configuration.
> It should say:
> src/main/javadoc/doc-files/app.png
> If you were to use the layout given, you would discover that app.png is never
> copied into the
> target directory.
> {noformat}
> yourproject
> |-- src
> |-- main
> | |-- java
> | | |-- org
> | | |-- apache
> | ||-- myapp
> | | `-- App.java
> | |-- javadoc
> | `-- overview.html
> | |-- org
> ||-- apache
> | |-- myapp
> |`-- package.html
> | |-- doc-files
> | `-- app.png
> |-- test
> |-- java
> | |-- org
> | |-- apache
> ||-- myapp
> | `-- AppTest.java
> |-- javadoc
> `-- overview.html
>|-- org
> |-- apache
> |-- myapp
> `-- package.html
> |-- doc-files
> `-- app.png
> {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] Issue Comment Edited: (MNG-3139) The skin does not exist: Unable to determine the release version
[ http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187581#action_187581 ] Benjamin Bentmann edited comment on MNG-3139 at 8/19/09 4:47 AM: - Well, we have an IT that says this issue is fixed in 2.2.0, too. There's always a chance that the IT doesn't cover all erroneous code paths that would exhibit the problem but that's hard to find out without more information like debug logs. With debug log I mean the output from running "mvn ... -X > debug.log", this usually produces several KB of output and is far more informative than the few lines around "[ERROR] BUILD ERROR". was (Author: bentmann): Well, we have an IT that says this issue is fixed in 2.2.0, too. There's always a chance that the IT doesn't cover all erroneous code paths that would exhibit the problem but that's hard to find out without more information like debug logs. With debug log I mean the output from running "mvn ... -X", this usually produces several KB of output and is far more informative than the few lines around "[ERROR] BUILD ERROR". > The skin does not exist: Unable to determine the release version > > > Key: MNG-3139 > URL: http://jira.codehaus.org/browse/MNG-3139 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.7 >Reporter: eyal david >Assignee: John Casey > Fix For: 2.0.11, 2.1.0, 3.0-alpha-3 > > Attachments: cached-metadata.patch > > > hi I have problem generating site when im using the command mvn site > it performs all stagegs and when it came to site generation the message is > shown : > The skin does not exist: Unable to determine the release version > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.skins > -DartifactId=maven > -default-skin \ > -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file > org.apache.maven.skins:maven-default-skin:jar:RELEASE > do u have an idea what is the problem ? > p.s the jar is registered in my local repository and in the remote repository > thank u -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3139) The skin does not exist: Unable to determine the release version
[ http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187581#action_187581 ] Benjamin Bentmann commented on MNG-3139: Well, we have an IT that says this issue is fixed in 2.2.0, too. There's always a chance that the IT doesn't cover all erroneous code paths that would exhibit the problem but that's hard to find out without more information like debug logs. With debug log I mean the output from running "mvn ... -X", this usually produces several KB of output and is far more informative than the few lines around "[ERROR] BUILD ERROR". > The skin does not exist: Unable to determine the release version > > > Key: MNG-3139 > URL: http://jira.codehaus.org/browse/MNG-3139 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.7 >Reporter: eyal david >Assignee: John Casey > Fix For: 2.0.11, 2.1.0, 3.0-alpha-3 > > Attachments: cached-metadata.patch > > > hi I have problem generating site when im using the command mvn site > it performs all stagegs and when it came to site generation the message is > shown : > The skin does not exist: Unable to determine the release version > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.skins > -DartifactId=maven > -default-skin \ > -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file > org.apache.maven.skins:maven-default-skin:jar:RELEASE > do u have an idea what is the problem ? > p.s the jar is registered in my local repository and in the remote repository > thank u -- 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: (MJAVADOC-247) location of doc-files is wrong on page http://maven.apache.org/plugins/maven-javadoc-plugin/examples/test-javadocs.html
[
http://jira.codehaus.org/browse/MJAVADOC-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MJAVADOC-247.
Resolution: Not A Bug
You need to set docfilessubdirs parameter to true. See
http://maven.apache.org/plugins/maven-javadoc-plugin/examples/javadoc-resources.html
> location of doc-files is wrong on page
> http://maven.apache.org/plugins/maven-javadoc-plugin/examples/test-javadocs.html
> ---
>
> Key: MJAVADOC-247
> URL: http://jira.codehaus.org/browse/MJAVADOC-247
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
> Environment: Published web page
>Reporter: bruce weertman
>Priority: Minor
>
> On the web-page
>
> http://maven.apache.org/plugins/maven-javadoc-plugin/examples/test-javadocs.html
>
> there is a tree-view of a directory layout (see below)
> It shows the hypothetical path:
>src/main/javadoc/org/apache/myapp/doc-files/app.png
> This is a bad example as it will not work w/o fiddling around with pom
> configuration.
> It should say:
> src/main/javadoc/doc-files/app.png
> If you were to use the layout given, you would discover that app.png is never
> copied into the
> target directory.
> {noformat}
> yourproject
> |-- src
> |-- main
> | |-- java
> | | |-- org
> | | |-- apache
> | ||-- myapp
> | | `-- App.java
> | |-- javadoc
> | `-- overview.html
> | |-- org
> ||-- apache
> | |-- myapp
> |`-- package.html
> | |-- doc-files
> | `-- app.png
> |-- test
> |-- java
> | |-- org
> | |-- apache
> ||-- myapp
> | `-- AppTest.java
> |-- javadoc
> `-- overview.html
>|-- org
> |-- apache
> |-- myapp
> `-- package.html
> |-- doc-files
> `-- app.png
> {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] Created: (MRELEASE-474) When is the release of maven-release-plugin version 2.0-beta-10 planned?
When is the release of maven-release-plugin version 2.0-beta-10 planned? Key: MRELEASE-474 URL: http://jira.codehaus.org/browse/MRELEASE-474 Project: Maven 2.x Release Plugin Issue Type: Wish Components: prepare Affects Versions: 2.0-beta-10 Reporter: Ginu Varghese Priority: Critical My issue is same as explained in MRELEASE-261 is closed. That is why i am raising this as a new issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2567) Java Native Access (JNA) 3.2.1 upload
Java Native Access (JNA) 3.2.1 upload - Key: MAVENUPLOAD-2567 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2567 Project: Maven Upload Requests Issue Type: Wish Reporter: Ahmed Ashour JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code no JNI or native code is required. This functionality is comparable to Windows' Platform/Invoke and Python's ctypes. Access is dynamic at runtime without code generation. -- 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-2567) Java Native Access (JNA) 3.2.1 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187593#action_187593 ] Ahmed Ashour commented on MAVENUPLOAD-2567: --- PS: I am not sure if LGPL is an issue > Java Native Access (JNA) 3.2.1 upload > - > > Key: MAVENUPLOAD-2567 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2567 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Ahmed Ashour > > JNA provides Java programs easy access to native shared libraries (DLLs on > Windows) without writing anything but Java code no JNI or native code is > required. > This functionality is comparable to Windows' Platform/Invoke and Python's > ctypes. Access is dynamic at runtime without code generation. -- 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: (MJAVADOC-244) Javadoc plugin: java files under src/main/javadoc and doc-files directory are being compiled
[ http://jira.codehaus.org/browse/MJAVADOC-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-244. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.6.1 fixed in [r805778|http://svn.apache.org/viewvc?rev=805778&view=rev], snap deployed > Javadoc plugin: java files under src/main/javadoc and doc-files directory are > being compiled > > > Key: MJAVADOC-244 > URL: http://jira.codehaus.org/browse/MJAVADOC-244 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Chris Wilkes >Assignee: Vincent Siveton >Priority: Minor > Fix For: 2.6.1 > > Attachments: javadoc-problem.zip > > > Maven was trying to compile src/main/javadoc/my/company/doc-files/Foo.java > even though I set the docfilessubdirs configuration option to true. Renaming > it to .txt works, however maven should probably not compile anything under > src/main/javadoc/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-245) Aggregate does not work
[ http://jira.codehaus.org/browse/MJAVADOC-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187598#action_187598 ] Vincent Siveton commented on MJAVADOC-245: -- Jorg, could you send us a test case? Did you tried my test case? > Aggregate does not work > --- > > Key: MJAVADOC-245 > URL: http://jira.codehaus.org/browse/MJAVADOC-245 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.5, 2.6 >Reporter: Jörg Hohwiller > Attachments: MJAVADOC-245.zip > > > I want to have an aggregated javadoc for the entire project as well as per > module. > Therefore I followed instructions at: > http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html > When I do mvn site:stage I get no aggregated javadoc but just per module. > This does not even change if I only do > > > > aggregate > > > > So to me this looks as if is magically ignored here. > I have tested 2.5 as well as 2.6 from > https://repository.apache.org/content/repositories/maven-staging-027/org/apache/maven/plugins/maven-javadoc-plugin/2.6/ -- 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: (MJAVADOC-253) Http proxy does not work any more
[ http://jira.codehaus.org/browse/MJAVADOC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MJAVADOC-253: - Summary: Http proxy does not work any more (was: HTTP PROXY DOES NOT WORK ANY MORE) > Http proxy does not work any more > - > > Key: MJAVADOC-253 > URL: http://jira.codehaus.org/browse/MJAVADOC-253 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: Maven 2.0.9 > JDK5 (Sun) >Reporter: Mohan K >Priority: Critical > > It appears the update of Wagon Provider in 2.6 is not compatible with Maven > 2.0.x. Here is the > email snippet as posted to maven users group (no responses) > I am using Maven 2.0.9 and maven-javadoc-plugin 2.6. I have the "links" > configured in my > plugin config. Now all resolution of external links fail (we are behind a > proxy *not* NTLM) > with this: > Aug 12, 2009 12:02:31 AM > org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme > INFO: ntlm authentication scheme selected > Aug 12, 2009 12:02:31 AM org.apache.commons.httpclient.HttpMethodDirector > authenticate > The wagon provider appears to have been upgraded to 1.0-beta-6 in the > maven-javadoc-plugin 2.6 > (as opposed to 1.0-beta-2 in 2.5). I seem to remember that (maybe it is > wrong) that wagon 1.0-beta-6 > requires Maven 2.1.x and above? If that is the case, I don't understand how > the plugin was released with > prerequisite of 2.0.9? > Is there a workaround to disable the default ntlm auth scheme via a magical > system property? TIA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-253) Http proxy does not work any more
[ http://jira.codehaus.org/browse/MJAVADOC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187600#action_187600 ] Vincent Siveton commented on MJAVADOC-253: -- Does the MJAVADOC-252 patch help you? > Http proxy does not work any more > - > > Key: MJAVADOC-253 > URL: http://jira.codehaus.org/browse/MJAVADOC-253 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: Maven 2.0.9 > JDK5 (Sun) >Reporter: Mohan K >Priority: Critical > > It appears the update of Wagon Provider in 2.6 is not compatible with Maven > 2.0.x. Here is the > email snippet as posted to maven users group (no responses) > I am using Maven 2.0.9 and maven-javadoc-plugin 2.6. I have the "links" > configured in my > plugin config. Now all resolution of external links fail (we are behind a > proxy *not* NTLM) > with this: > Aug 12, 2009 12:02:31 AM > org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme > INFO: ntlm authentication scheme selected > Aug 12, 2009 12:02:31 AM org.apache.commons.httpclient.HttpMethodDirector > authenticate > The wagon provider appears to have been upgraded to 1.0-beta-6 in the > maven-javadoc-plugin 2.6 > (as opposed to 1.0-beta-2 in 2.5). I seem to remember that (maybe it is > wrong) that wagon 1.0-beta-6 > requires Maven 2.1.x and above? If that is the case, I don't understand how > the plugin was released with > prerequisite of 2.0.9? > Is there a workaround to disable the default ntlm auth scheme via a magical > system property? TIA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-255) Cannot suppress reports
[ http://jira.codehaus.org/browse/MJAVADOC-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187602#action_187602 ] Vincent Siveton commented on MJAVADOC-255: -- Do you provide us a test case? > Cannot suppress reports > --- > > Key: MJAVADOC-255 > URL: http://jira.codehaus.org/browse/MJAVADOC-255 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Benson Margulies > > I wanted to suppress javadoc aggregation for mvn site:site. > So, I tried > > No effect. it goes ahead and runs the aggregate report. help:effectivePom > does not show the empty reportSets element. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-254) aggregation fails to get classpath, blows up
[ http://jira.codehaus.org/browse/MJAVADOC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187601#action_187601 ] Vincent Siveton commented on MJAVADOC-254: -- Could you provide us a test case? > aggregation fails to get classpath, blows up > > > Key: MJAVADOC-254 > URL: http://jira.codehaus.org/browse/MJAVADOC-254 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven 2.1.0, macos, java 1.5. >Reporter: Benson Margulies > Attachments: foo > > > javadoc:aggregate blows up with an error inside of the javadoc tool. The > immediate problem is that junit isn't in the classpath, so junit annotations > explode. If I add junit to the dependencies of the aggregating project, I > just run into trouble with other missing annotations, like some for Spring. > [DEBUG] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - > javadoc: error - In doclet class com.sun.tools.doclets.standard.Standard, > method start has thrown an exception > java.lang.reflect.InvocationTargetException > java.lang.AssertionError: cannot find method org.junit.runner.RunWith.value() > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.findAccessMethod(ClassReader.java:1074) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompound(ClassReader.java:1057) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompoundList(ClassReader.java:1046) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationCompleter.enterAnnotation(ClassReader.java:1195) > at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:94) > at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1541) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) > at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) > at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) > at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:105) > at > com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:116) > at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:574) > at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:546) > at > com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:152) > at > com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:168) > at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) > Command line > was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-254) aggregation fails to get classpath, blows up
[ http://jira.codehaus.org/browse/MJAVADOC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187604#action_187604 ] Benson Margulies commented on MJAVADOC-254: --- Sadly, not easily. I have two pretty big multi-module projects. One works, one does not. Did the log I posted give you any clues? I could try to boil down if not. > aggregation fails to get classpath, blows up > > > Key: MJAVADOC-254 > URL: http://jira.codehaus.org/browse/MJAVADOC-254 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven 2.1.0, macos, java 1.5. >Reporter: Benson Margulies > Attachments: foo > > > javadoc:aggregate blows up with an error inside of the javadoc tool. The > immediate problem is that junit isn't in the classpath, so junit annotations > explode. If I add junit to the dependencies of the aggregating project, I > just run into trouble with other missing annotations, like some for Spring. > [DEBUG] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - > javadoc: error - In doclet class com.sun.tools.doclets.standard.Standard, > method start has thrown an exception > java.lang.reflect.InvocationTargetException > java.lang.AssertionError: cannot find method org.junit.runner.RunWith.value() > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.findAccessMethod(ClassReader.java:1074) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompound(ClassReader.java:1057) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompoundList(ClassReader.java:1046) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationCompleter.enterAnnotation(ClassReader.java:1195) > at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:94) > at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1541) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) > at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) > at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) > at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:105) > at > com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:116) > at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:574) > at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:546) > at > com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:152) > at > com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:168) > at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) > Command line > was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages -- 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-4289) Bump to latest Modello
[ http://jira.codehaus.org/browse/MNG-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MNG-4289. Assignee: Vincent Siveton Resolution: Fixed applied in [r805789|http://svn.apache.org/viewvc?rev=805789&view=rev] > Bump to latest Modello > -- > > Key: MNG-4289 > URL: http://jira.codehaus.org/browse/MNG-4289 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.10, 2.1.0, 2.2.0 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 2.2.2 > > > Due to MODELLO-189, we will need to bump to latest release of Modello -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-254) aggregation fails to get classpath, blows up
[ http://jira.codehaus.org/browse/MJAVADOC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187606#action_187606 ] Vincent Siveton commented on MJAVADOC-254: -- Not really, but you send us the javadoc files using -Ddebug [1] [1] http://maven.apache.org/plugins/maven-javadoc-plugin/faq.html#How_to_know_exactly_the_Javadoc_command_line > aggregation fails to get classpath, blows up > > > Key: MJAVADOC-254 > URL: http://jira.codehaus.org/browse/MJAVADOC-254 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven 2.1.0, macos, java 1.5. >Reporter: Benson Margulies > Attachments: foo > > > javadoc:aggregate blows up with an error inside of the javadoc tool. The > immediate problem is that junit isn't in the classpath, so junit annotations > explode. If I add junit to the dependencies of the aggregating project, I > just run into trouble with other missing annotations, like some for Spring. > [DEBUG] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - > javadoc: error - In doclet class com.sun.tools.doclets.standard.Standard, > method start has thrown an exception > java.lang.reflect.InvocationTargetException > java.lang.AssertionError: cannot find method org.junit.runner.RunWith.value() > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.findAccessMethod(ClassReader.java:1074) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompound(ClassReader.java:1057) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompoundList(ClassReader.java:1046) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationCompleter.enterAnnotation(ClassReader.java:1195) > at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:94) > at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1541) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) > at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) > at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) > at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:105) > at > com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:116) > at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:574) > at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:546) > at > com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:152) > at > com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:168) > at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) > Command line > was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages -- 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: (MJAVADOC-254) aggregation fails to get classpath, blows up
[ http://jira.codehaus.org/browse/MJAVADOC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MJAVADOC-254: -- Attachment: javadoc.sh javadoc.sh > aggregation fails to get classpath, blows up > > > Key: MJAVADOC-254 > URL: http://jira.codehaus.org/browse/MJAVADOC-254 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven 2.1.0, macos, java 1.5. >Reporter: Benson Margulies > Attachments: foo, javadoc.sh > > > javadoc:aggregate blows up with an error inside of the javadoc tool. The > immediate problem is that junit isn't in the classpath, so junit annotations > explode. If I add junit to the dependencies of the aggregating project, I > just run into trouble with other missing annotations, like some for Spring. > [DEBUG] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - > javadoc: error - In doclet class com.sun.tools.doclets.standard.Standard, > method start has thrown an exception > java.lang.reflect.InvocationTargetException > java.lang.AssertionError: cannot find method org.junit.runner.RunWith.value() > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.findAccessMethod(ClassReader.java:1074) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompound(ClassReader.java:1057) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompoundList(ClassReader.java:1046) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationCompleter.enterAnnotation(ClassReader.java:1195) > at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:94) > at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1541) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) > at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) > at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) > at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:105) > at > com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:116) > at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:574) > at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:546) > at > com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:152) > at > com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:168) > at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) > Command line > was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages -- 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: (MJAVADOC-254) aggregation fails to get classpath, blows up
[ http://jira.codehaus.org/browse/MJAVADOC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MJAVADOC-254: -- Attachment: packages options And the details. > aggregation fails to get classpath, blows up > > > Key: MJAVADOC-254 > URL: http://jira.codehaus.org/browse/MJAVADOC-254 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven 2.1.0, macos, java 1.5. >Reporter: Benson Margulies > Attachments: foo, javadoc.sh, options, packages > > > javadoc:aggregate blows up with an error inside of the javadoc tool. The > immediate problem is that junit isn't in the classpath, so junit annotations > explode. If I add junit to the dependencies of the aggregating project, I > just run into trouble with other missing annotations, like some for Spring. > [DEBUG] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - > javadoc: error - In doclet class com.sun.tools.doclets.standard.Standard, > method start has thrown an exception > java.lang.reflect.InvocationTargetException > java.lang.AssertionError: cannot find method org.junit.runner.RunWith.value() > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.findAccessMethod(ClassReader.java:1074) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompound(ClassReader.java:1057) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompoundList(ClassReader.java:1046) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationCompleter.enterAnnotation(ClassReader.java:1195) > at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:94) > at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1541) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) > at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) > at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) > at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:105) > at > com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:116) > at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:574) > at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:546) > at > com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:152) > at > com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:168) > at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) > Command line > was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-254) aggregation fails to get classpath, blows up
[ http://jira.codehaus.org/browse/MJAVADOC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187610#action_187610 ] Benson Margulies commented on MJAVADOC-254: --- No real hints in these files as to what source directories (main versus test) have ended up in the mixture. > aggregation fails to get classpath, blows up > > > Key: MJAVADOC-254 > URL: http://jira.codehaus.org/browse/MJAVADOC-254 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven 2.1.0, macos, java 1.5. >Reporter: Benson Margulies > Attachments: foo, javadoc.sh, options, packages > > > javadoc:aggregate blows up with an error inside of the javadoc tool. The > immediate problem is that junit isn't in the classpath, so junit annotations > explode. If I add junit to the dependencies of the aggregating project, I > just run into trouble with other missing annotations, like some for Spring. > [DEBUG] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - > javadoc: error - In doclet class com.sun.tools.doclets.standard.Standard, > method start has thrown an exception > java.lang.reflect.InvocationTargetException > java.lang.AssertionError: cannot find method org.junit.runner.RunWith.value() > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.findAccessMethod(ClassReader.java:1074) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompound(ClassReader.java:1057) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompoundList(ClassReader.java:1046) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationCompleter.enterAnnotation(ClassReader.java:1195) > at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:94) > at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1541) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) > at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) > at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) > at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:105) > at > com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:116) > at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:574) > at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:546) > at > com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:152) > at > com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:168) > at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) > Command line > was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages -- 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-4311) JAVA_HOME pointing to JDK but /usr/lib/java/../lib/tools.jar being used
JAVA_HOME pointing to JDK but /usr/lib/java/../lib/tools.jar being used
-
Key: MNG-4311
URL: http://jira.codehaus.org/browse/MNG-4311
Project: Maven 2
Issue Type: Bug
Components: Errors
Affects Versions: 2.2.0
Environment: Linux sombriks 2.6.24.5-smp #2 SMP Wed Apr 30 13:41:38
CDT 2008 i686 Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz GenuineIntel
GNU/Linux
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
echo $JAVA_HOME
/usr/lib/java
which javac
/usr/lib/java/bin/javac
Reporter: sombriks
using command line or netbeans plugin it's happening:
leona...@sombriks:~/NetBeansProjects/arena/arena-client$ mvn compile
[INFO] Scanning for projects...
[INFO]
[INFO] Building Arena PUJ Client (jar)
[INFO]task-segment: [compile]
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (ISO-8859-1 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 1 source file to
/home/leonardo/NetBeansProjects/arena/arena-client/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
Unable to locate the Javac Compiler in:
/usr/lib/java/../lib/tools.jar
Please ensure you are using JDK 1.4 or above and
not a JRE (the com.sun.tools.javac.Main class is required).
In most cases you can change the location of your Java
installation by setting the JAVA_HOME environment variable.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 3 seconds
[INFO] Finished at: Wed Aug 19 11:10:59 BRT 2009
[INFO] Final Memory: 9M/65M
[INFO]
leona...@sombriks:~/NetBeansProjects/arena/arena-client$
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-254) aggregation fails to get classpath, blows up
[ http://jira.codehaus.org/browse/MJAVADOC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187611#action_187611 ] Benson Margulies commented on MJAVADOC-254: --- There was no 'files' file left behind. > aggregation fails to get classpath, blows up > > > Key: MJAVADOC-254 > URL: http://jira.codehaus.org/browse/MJAVADOC-254 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven 2.1.0, macos, java 1.5. >Reporter: Benson Margulies > Attachments: foo, javadoc.sh, options, packages > > > javadoc:aggregate blows up with an error inside of the javadoc tool. The > immediate problem is that junit isn't in the classpath, so junit annotations > explode. If I add junit to the dependencies of the aggregating project, I > just run into trouble with other missing annotations, like some for Spring. > [DEBUG] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - > javadoc: error - In doclet class com.sun.tools.doclets.standard.Standard, > method start has thrown an exception > java.lang.reflect.InvocationTargetException > java.lang.AssertionError: cannot find method org.junit.runner.RunWith.value() > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.findAccessMethod(ClassReader.java:1074) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompound(ClassReader.java:1057) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompoundList(ClassReader.java:1046) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationCompleter.enterAnnotation(ClassReader.java:1195) > at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:94) > at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1541) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) > at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) > at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) > at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:105) > at > com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:116) > at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:574) > at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:546) > at > com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:152) > at > com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:168) > at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) > Command line > was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages -- 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
[MAVEN-2.1.0] Using site:deploy for Wagon-scp-exe is not successful.
Hi,
This is my first email to Maven Users List. Hope I find a solution or
help or pointer to solve my issue.
I am trying to deploy my site data using scpexe://
I have already configured password less authenitication using rsa2. i.e.
id_rsa and authorized_keys are configured.
Since it does not complain about ssh errors, so my settings.xml is
configured and distribution management for site is also correct I guess.
m.website
M Website
scpexe://mobiletv.w.c/var/www/html/docs/${project.version}/modules<
/url>
I used Cygwin to run "mvn site:site site:deploy" command and upload
failed with a permission denied message like below.
My remote host is a RHEL 5 desktop and I deploy from Windows XP (using
Cygwin)
[INFO] [site:deploy]
scpexe://mobiletv.w.c/var/www/html/docs/3.3.14.1-SNAPSHOT/modules/mbs_ut
ilities - Session: Opened
Executing command: mkdir -p
/var/www/html/docs/3.3.14.1-SNAPSHOT/modules/mbs_utilities/.
Executing command: cmd.exe /X /C "ssh -i "C:\Documents and
Settings\subirs\.ssh\id_rsa" -o "BatchMode yes" sub...@mobiletv.w.c
"mkdir -p /var/www/html/docs/3.3.14.1-SNAPSHOT/modules/mbs_utilities/.""
Permission denied (publickey,gssapi-with-mic,password).
scpexe://mobiletv.w.c/var/www/html/docs/3.3.14.1-SNAPSHOT/modules/mbs_ut
ilities - Session: Disconnecting
scpexe://mobiletv.w.c/var/www/html/docs/3.3.14.1-SNAPSHOT/modules/mbs_ut
ilities - Session: Disconnected
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error uploading site
Embedded error: Error performing commands for file transfer
Exit code 255 - Permission denied (publickey,gssapi-with-mic,password).
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 4 minutes 6 seconds
[INFO] Finished at: Wed Aug 19 19:41:32 IST 2009
[INFO] Final Memory: 61M/254M
[INFO]
However if I use the same command from Cygwin command line it does not
complain of anything.
$> ssh sub...@mobiletv.w.c "mkdir -p
/var/www/html/docs/3.3.14.1-SNAPSHOT/modules/mbs_utilities/."
Enter passphrase for key 'C:\Documents and Settings\subirs\.ssh\id_rsa':
If I give passphrase directory is also created successfully with the
above command.
So I guess there is some issue with Maven scp-exe wagon, but not able to
figure out what it is...
Any help appreciated.
Subir S
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
[jira] Commented: (MJAVADOC-254) aggregation fails to get classpath, blows up
[ http://jira.codehaus.org/browse/MJAVADOC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187614#action_187614 ] Benson Margulies commented on MJAVADOC-254: --- So, where is the list of source directories hiding? > aggregation fails to get classpath, blows up > > > Key: MJAVADOC-254 > URL: http://jira.codehaus.org/browse/MJAVADOC-254 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven 2.1.0, macos, java 1.5. >Reporter: Benson Margulies > Attachments: foo, javadoc.sh, options, packages > > > javadoc:aggregate blows up with an error inside of the javadoc tool. The > immediate problem is that junit isn't in the classpath, so junit annotations > explode. If I add junit to the dependencies of the aggregating project, I > just run into trouble with other missing annotations, like some for Spring. > [DEBUG] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - > javadoc: error - In doclet class com.sun.tools.doclets.standard.Standard, > method start has thrown an exception > java.lang.reflect.InvocationTargetException > java.lang.AssertionError: cannot find method org.junit.runner.RunWith.value() > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.findAccessMethod(ClassReader.java:1074) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompound(ClassReader.java:1057) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompoundList(ClassReader.java:1046) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationCompleter.enterAnnotation(ClassReader.java:1195) > at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:94) > at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1541) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) > at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) > at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) > at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:105) > at > com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:116) > at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:574) > at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:546) > at > com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:152) > at > com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:168) > at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) > Command line > was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages -- 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: (MANTRUN-95) Plugin classpath problem in multi module maven project
[ http://jira.codehaus.org/browse/MANTRUN-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MANTRUN-95. Resolution: Duplicate This is a duplicate of MANTRUN-51 > Plugin classpath problem in multi module maven project > -- > > Key: MANTRUN-95 > URL: http://jira.codehaus.org/browse/MANTRUN-95 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug > Environment: WindowsXP Pro > jdk1.5.0_11 > MAVEN 2.0.9 >Reporter: Alexandre GIGLEUX > Attachments: ProblemMavenPluginClasspath.zip > > > We have a pom.xml with : > > ./Module1 > ./Module2 > > In Module1 we use the define . > In Module2 we also define for maven-antrun-plugin with other > . > Problem when we display />, in Module2 we have the classpath of the Module1. > The only workaround is to add specific of Module2, in Module1 > (for the maven-antrun-plugin plugin). > It looks like the plugin classpath is not updated for each Module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-255) Cannot suppress reports
[ http://jira.codehaus.org/browse/MJAVADOC-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187620#action_187620 ] Benson Margulies commented on MJAVADOC-255: --- I'm working on one for 254, and a trivial edit to that will demonstrate this. > Cannot suppress reports > --- > > Key: MJAVADOC-255 > URL: http://jira.codehaus.org/browse/MJAVADOC-255 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Benson Margulies > > I wanted to suppress javadoc aggregation for mvn site:site. > So, I tried > > No effect. it goes ahead and runs the aggregate report. help:effectivePom > does not show the empty reportSets element. -- 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-422) Output the resulting tag name or branch name during dryRun
[ http://jira.codehaus.org/browse/MRELEASE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MRELEASE-422. -- Resolution: Won't Fix This turned out to be more complicated than I originally thought. The scm url is not readily available unless the brachBase parameter has been set. So I changed the code to print the url only if the branchBase is not null. > Output the resulting tag name or branch name during dryRun > -- > > Key: MRELEASE-422 > URL: http://jira.codehaus.org/browse/MRELEASE-422 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: branch, prepare >Affects Versions: 2.0-beta-7 >Reporter: Philippe Laflamme >Assignee: Paul Gier >Priority: Trivial > Fix For: 2.0-beta-10 > > > During execution of a dryRun, it would be very helpful to see where the > resulting tag or branch name would be created in the log output. Currently, > we get: > "[INFO] Full run would be branching /home/user/projects/myProject with label: > 'project-1.1.x'" > But we don't know WHERE project-1.1.x will be created (in SVN). > I understand that not all SCM have a notion of location of tags and branches, > but having this information when it is supported would make the dryRun much > more useful. -- 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: (MRELEASE-377) Missing releaseVersion parameter in release:branch goal
[ http://jira.codehaus.org/browse/MRELEASE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MRELEASE-377: --- Assignee: Paul Gier Fix Version/s: 2.0-beta-10 > Missing releaseVersion parameter in release:branch goal > --- > > Key: MRELEASE-377 > URL: http://jira.codehaus.org/browse/MRELEASE-377 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: branch >Affects Versions: 2.0-beta-8 >Reporter: Nicolas Coquelet >Assignee: Paul Gier > Fix For: 2.0-beta-10 > > Attachments: MRELEASE-377-maven-release.patch > > > Can you add the releaseVersion paramater in the BranchReleaseMojo of > the2.0-beta8 release ? > The MapVersionPhase can already use it after fixing MRELEASE-173. > 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] Closed: (MRELEASE-377) Missing releaseVersion parameter in release:branch goal
[ http://jira.codehaus.org/browse/MRELEASE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MRELEASE-377. -- Resolution: Fixed Looks like this has been fixed by MRELEASE-387. > Missing releaseVersion parameter in release:branch goal > --- > > Key: MRELEASE-377 > URL: http://jira.codehaus.org/browse/MRELEASE-377 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: branch >Affects Versions: 2.0-beta-8 >Reporter: Nicolas Coquelet >Assignee: Paul Gier > Fix For: 2.0-beta-10 > > Attachments: MRELEASE-377-maven-release.patch > > > Can you add the releaseVersion paramater in the BranchReleaseMojo of > the2.0-beta8 release ? > The MapVersionPhase can already use it after fixing MRELEASE-173. > Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-254) aggregation fails to get classpath, blows up
[ http://jira.codehaus.org/browse/MJAVADOC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187627#action_187627 ] Benson Margulies commented on MJAVADOC-254: --- OK, here's the situation. If module a exports its test with a classifier of 'tests', and module b depends on it without a scope, then this happens. Not too surprisingly, the classified jar doesn't carry along its dependencies. I think you want to close this out as pilot error. > aggregation fails to get classpath, blows up > > > Key: MJAVADOC-254 > URL: http://jira.codehaus.org/browse/MJAVADOC-254 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven 2.1.0, macos, java 1.5. >Reporter: Benson Margulies > Attachments: foo, javadoc.sh, options, packages > > > javadoc:aggregate blows up with an error inside of the javadoc tool. The > immediate problem is that junit isn't in the classpath, so junit annotations > explode. If I add junit to the dependencies of the aggregating project, I > just run into trouble with other missing annotations, like some for Spring. > [DEBUG] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - > javadoc: error - In doclet class com.sun.tools.doclets.standard.Standard, > method start has thrown an exception > java.lang.reflect.InvocationTargetException > java.lang.AssertionError: cannot find method org.junit.runner.RunWith.value() > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.findAccessMethod(ClassReader.java:1074) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompound(ClassReader.java:1057) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompoundList(ClassReader.java:1046) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationCompleter.enterAnnotation(ClassReader.java:1195) > at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:94) > at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1541) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) > at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) > at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) > at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:105) > at > com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:116) > at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:574) > at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:546) > at > com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:152) > at > com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:168) > at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) > Command line > was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages -- 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-474) When is the release of maven-release-plugin version 2.0-beta-10 planned?
[ http://jira.codehaus.org/browse/MRELEASE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MRELEASE-474. -- Resolution: Not A Bug You can view the project roadmap to see what needs to be done before a release, or you can ask on the maven user or dev list (http://maven.apache.org/mail-lists.html). > When is the release of maven-release-plugin version 2.0-beta-10 planned? > > > Key: MRELEASE-474 > URL: http://jira.codehaus.org/browse/MRELEASE-474 > Project: Maven 2.x Release Plugin > Issue Type: Wish > Components: prepare >Affects Versions: 2.0-beta-10 >Reporter: Ginu Varghese >Priority: Critical > > My issue is same as explained in MRELEASE-261 is closed. That is why i am > raising this as a new issue. -- 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: (MRELEASE-475) Don't print stack trace when release:branch finds uncommitted files.
[ http://jira.codehaus.org/browse/MRELEASE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MRELEASE-475: --- Assignee: Paul Gier Fix Version/s: 2.0-beta-10 > Don't print stack trace when release:branch finds uncommitted files. > > > Key: MRELEASE-475 > URL: http://jira.codehaus.org/browse/MRELEASE-475 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: branch >Affects Versions: 2.0-beta-9 >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 2.0-beta-10 > > > If release:branch finds local uncommitted files, a stack trace is printed in > addition to the short error message. The stack trace should be printed only > in debug mode or not at all similar to release:prepare. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-475) Don't print stack trace when release:branch finds uncommitted files.
Don't print stack trace when release:branch finds uncommitted files. Key: MRELEASE-475 URL: http://jira.codehaus.org/browse/MRELEASE-475 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: branch Affects Versions: 2.0-beta-9 Reporter: Paul Gier If release:branch finds local uncommitted files, a stack trace is printed in addition to the short error message. The stack trace should be printed only in debug mode or not at all similar to release:prepare. -- 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-475) Don't print stack trace when release:branch finds uncommitted files.
[ http://jira.codehaus.org/browse/MRELEASE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MRELEASE-475. -- Resolution: Fixed Fixed in r805849. > Don't print stack trace when release:branch finds uncommitted files. > > > Key: MRELEASE-475 > URL: http://jira.codehaus.org/browse/MRELEASE-475 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: branch >Affects Versions: 2.0-beta-9 >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 2.0-beta-10 > > > If release:branch finds local uncommitted files, a stack trace is printed in > addition to the short error message. The stack trace should be printed only > in debug mode or not at all similar to release:prepare. -- 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: (MREACTOR-11) Can't pass a parameter with a comma to -Dmake.goals
[
http://jira.codehaus.org/browse/MREACTOR-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187634#action_187634
]
Damian Carrillo commented on MREACTOR-11:
-
I think that the patch might be overkill if the gist of the problem is to
include those two build profiles in the builds spawned by the reactor. Instead
of issuing the command as you have done, try using the following:
$ mvn reactor:make -Dmake.goals="install -Pprofile1 -Pprofile2"
You can even pass any combination of command line parameters this way, ie:
$ mvn reactor:make -Dmake.goals="install -Pprofile1 -Pprofile2
-Dmaven.test.skip=true"
> Can't pass a parameter with a comma to -Dmake.goals
> ---
>
> Key: MREACTOR-11
> URL: http://jira.codehaus.org/browse/MREACTOR-11
> Project: Maven 2.x Reactor Plugin
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Henri Tremblay
> Attachments: comma.patch
>
>
> If tried to do
> {{mvn reactor:make -Dmake.goals=install,-Pprofile1,profile2}}
> If fails because {{-Pprofile1,profile2}} is split in two parameters.
> My solution was to be able to escape a comma by doubling it.
> Its implementation and the test case are in attachment.
--
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: (MREACTOR-11) Can't pass a parameter with a comma to -Dmake.goals
[
http://jira.codehaus.org/browse/MREACTOR-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187636#action_187636
]
Henri Tremblay commented on MREACTOR-11:
Historically, it wasn't possible to have two -P in the command line.
I just tried with maven 2.1.0 and it now seems to work.
If that's the case, indeed there's a nice workaround to my issue.
> Can't pass a parameter with a comma to -Dmake.goals
> ---
>
> Key: MREACTOR-11
> URL: http://jira.codehaus.org/browse/MREACTOR-11
> Project: Maven 2.x Reactor Plugin
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Henri Tremblay
> Attachments: comma.patch
>
>
> If tried to do
> {{mvn reactor:make -Dmake.goals=install,-Pprofile1,profile2}}
> If fails because {{-Pprofile1,profile2}} is split in two parameters.
> My solution was to be able to escape a comma by doubling it.
> Its implementation and the test case are in attachment.
--
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: (MRRESOURCES-41) add support for multi-module dependencies listing and other top-of-tree calculations on sub-modules
add support for multi-module dependencies listing and other top-of-tree calculations on sub-modules --- Key: MRRESOURCES-41 URL: http://jira.codehaus.org/browse/MRRESOURCES-41 Project: Maven 2.x Remote Resources Plugin Issue Type: New Feature Affects Versions: 1.0 Reporter: John Casey Currently, the dependencies file only contains the dependencies in the current project. However, in cases where we're releasing a multi-module project all at one go, it would be nice to support collecting all dependencies from sub-modules, winnowing out the inter-module dependencies, and using that collection for generating the dependencies file instead of only those dependencies of the current project. It also may make more sense in these cases to mimic the assembly plugin's runOnlyAtExecutionRoot flag, and only process the remote resources once for a project tree. -- 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: (MRRESOURCES-41) add support for multi-module dependencies listing and other top-of-tree calculations on sub-modules
[ http://jira.codehaus.org/browse/MRRESOURCES-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MRRESOURCES-41: -- Fix Version/s: (was: 1.0.1) 1.1 > add support for multi-module dependencies listing and other top-of-tree > calculations on sub-modules > --- > > Key: MRRESOURCES-41 > URL: http://jira.codehaus.org/browse/MRRESOURCES-41 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.0 >Reporter: John Casey > Fix For: 1.1 > > > Currently, the dependencies file only contains the dependencies in the > current project. However, in cases where we're releasing a multi-module > project all at one go, it would be nice to support collecting all > dependencies from sub-modules, winnowing out the inter-module dependencies, > and using that collection for generating the dependencies file instead of > only those dependencies of the current project. > It also may make more sense in these cases to mimic the assembly plugin's > runOnlyAtExecutionRoot flag, and only process the remote resources once for a > project tree. -- 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: (MRRESOURCES-41) add support for multi-module dependencies listing and other top-of-tree calculations on sub-modules
[ http://jira.codehaus.org/browse/MRRESOURCES-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MRRESOURCES-41: -- Fix Version/s: 1.0.1 > add support for multi-module dependencies listing and other top-of-tree > calculations on sub-modules > --- > > Key: MRRESOURCES-41 > URL: http://jira.codehaus.org/browse/MRRESOURCES-41 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.0 >Reporter: John Casey > Fix For: 1.0.1 > > > Currently, the dependencies file only contains the dependencies in the > current project. However, in cases where we're releasing a multi-module > project all at one go, it would be nice to support collecting all > dependencies from sub-modules, winnowing out the inter-module dependencies, > and using that collection for generating the dependencies file instead of > only those dependencies of the current project. > It also may make more sense in these cases to mimic the assembly plugin's > runOnlyAtExecutionRoot flag, and only process the remote resources once for a > project tree. -- 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: (MRRESOURCES-36) ${project.build.sourceEncoding} not honoured.
[
http://jira.codehaus.org/browse/MRRESOURCES-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MRRESOURCES-36:
--
Fix Version/s: (was: 1.0.1)
1.1
Moving fix-for to 1.1 since 1.0.1 release didn't make it (owing to incorrect
source-release format), and now we need a new feature added to this plugin to
support a standardized maven source-release assembly descriptor for
multi-module projects. The next release attempt will be for 1.1 and include
this feature.
FWIW, the feature is described in MRRESOURCES-41
> ${project.build.sourceEncoding} not honoured.
> -
>
> Key: MRRESOURCES-36
> URL: http://jira.codehaus.org/browse/MRRESOURCES-36
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.0
> Environment: Maven version: 2.0.9
> Java version: 1.6.0_07
> OS name: "linux" version: "2.6.27.6-workstation" arch: "i386" Family: "unix"
>Reporter: Christian Schulte
>Assignee: Jason van Zyl
>Priority: Blocker
> Fix For: 1.1
>
> Attachments: MRRESOURCES-36, MRRESOURCES-36-2,
> MRRESOURCES-36-3.patch, MRRESOURCES-36-4.patch, MRRESOURCES-36-4.zip
>
>
> Velocity has its own default encoding (ISO-8859-1) when reading templates and
> does not honour the current environment setting. Also the plugin ignores any
> source encoding which leads to encoding issues for any non-ASCII resources.
> The attached patch adds a new mojo parameter sourceEncoding which defaults to
> ${project.build.sourceEncoding} and makes copying and appending to resources
> encoding aware.
--
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: (MRRESOURCES-38) Remove inadvertent dependency on MavenReportException in maven-reporting-api
[ http://jira.codehaus.org/browse/MRRESOURCES-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MRRESOURCES-38: -- Fix Version/s: (was: 1.0.1) 1.1 Moving fix-for to 1.1 since 1.0.1 release didn't make it (owing to incorrect source-release format), and now we need a new feature added to this plugin to support a standardized maven source-release assembly descriptor for multi-module projects. The next release attempt will be for 1.1 and include this feature. FWIW, the feature is described in MRRESOURCES-41 > Remove inadvertent dependency on MavenReportException in maven-reporting-api > > > Key: MRRESOURCES-38 > URL: http://jira.codehaus.org/browse/MRRESOURCES-38 > Project: Maven 2.x Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 1.1 > > > This creates a coupling to the reporting API which is not necessary. -- 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: (MRRESOURCES-41) add support for multi-module dependencies listing and other top-of-tree calculations on sub-modules
[ http://jira.codehaus.org/browse/MRRESOURCES-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MRRESOURCES-41: -- Priority: Blocker (was: Major) > add support for multi-module dependencies listing and other top-of-tree > calculations on sub-modules > --- > > Key: MRRESOURCES-41 > URL: http://jira.codehaus.org/browse/MRRESOURCES-41 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.0 >Reporter: John Casey >Priority: Blocker > Fix For: 1.1 > > > Currently, the dependencies file only contains the dependencies in the > current project. However, in cases where we're releasing a multi-module > project all at one go, it would be nice to support collecting all > dependencies from sub-modules, winnowing out the inter-module dependencies, > and using that collection for generating the dependencies file instead of > only those dependencies of the current project. > It also may make more sense in these cases to mimic the assembly plugin's > runOnlyAtExecutionRoot flag, and only process the remote resources once for a > project tree. -- 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: (MRRESOURCES-35) ClassCastException
[ http://jira.codehaus.org/browse/MRRESOURCES-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MRRESOURCES-35: -- Fix Version/s: (was: 1.0.1) 1.1 Moving fix-for to 1.1 since 1.0.1 release didn't make it (owing to incorrect source-release format), and now we need a new feature added to this plugin to support a standardized maven source-release assembly descriptor for multi-module projects. The next release attempt will be for 1.1 and include this feature. FWIW, the feature is described in MRRESOURCES-41 > ClassCastException > -- > > Key: MRRESOURCES-35 > URL: http://jira.codehaus.org/browse/MRRESOURCES-35 > Project: Maven 2.x Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Christian Schulte >Assignee: Jason van Zyl >Priority: Blocker > Fix For: 1.1 > > Attachments: MRRESOURCES-35.patch > > > Having a dependency with RELEASE gives ClassCastException. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org.apache.maven.model.Repository > [INFO] > > [INFO] Trace > java.lang.ClassCastException: org.apache.maven.model.Repository > at > org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.mergeMetadata(DefaultRepositoryMetadataManager.java:193) > at > org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:166) > at > org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:65) > at > org.apache.maven.artifact.transform.ReleaseArtifactTransformation.transformForResolve(ReleaseArtifactTransformation.java:49) > at > org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForResolve(DefaultArtifactTransformationManager.java:57) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:129) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74) > at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:557) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:250) > at > org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.getProjects(ProcessRemoteResourcesMojo.java:505) > at > org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.configureVelocityContext(ProcessRemoteResourcesMojo.java:665) > at > org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:413) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:466) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:127) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:302) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.
[jira] Work started: (MASSEMBLY-385) Filtering replaces tokens it should not be replacing
[
http://jira.codehaus.org/browse/MASSEMBLY-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MASSEMBLY-385 started by Edwin Punzalan.
> Filtering replaces tokens it should not be replacing
>
>
> Key: MASSEMBLY-385
> URL: http://jira.codehaus.org/browse/MASSEMBLY-385
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: Maven 2.0.9
>Reporter: Robert Bracewell
>Assignee: Edwin Punzalan
>Priority: Critical
> Attachments: component.zip
>
>
> What is described below is attached as an example that duplicates this
> When filtering is turned on and a token ends with .url then very strange
> things happen
> The assembly descriptor uses
>
>
> ${basedir}/src/config/xml/applicationContext.xml
> xml
> true
>
>
> The file being filtered contains:
>
>
>
>
> value="${vanity.url.message}"/>
>
>
>
> After the assembly is run the file contains:
>
>
>
>
> value="${vanity.url.message}"/>
>
>
>
> The string This is a not a URL but demonstrates the BUG comes from the url
> tag defined in parent pom
> The string test1 is the artifactId
--
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-385) Filtering replaces tokens it should not be replacing
[
http://jira.codehaus.org/browse/MASSEMBLY-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187645#action_187645
]
Edwin Punzalan commented on MASSEMBLY-385:
--
Revision involves using maven-filtering instead of an internal filter processor.
> Filtering replaces tokens it should not be replacing
>
>
> Key: MASSEMBLY-385
> URL: http://jira.codehaus.org/browse/MASSEMBLY-385
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: Maven 2.0.9
>Reporter: Robert Bracewell
>Assignee: Edwin Punzalan
>Priority: Critical
> Attachments: component.zip
>
>
> What is described below is attached as an example that duplicates this
> When filtering is turned on and a token ends with .url then very strange
> things happen
> The assembly descriptor uses
>
>
> ${basedir}/src/config/xml/applicationContext.xml
> xml
> true
>
>
> The file being filtered contains:
>
>
>
>
> value="${vanity.url.message}"/>
>
>
>
> After the assembly is run the file contains:
>
>
>
>
> value="${vanity.url.message}"/>
>
>
>
> The string This is a not a URL but demonstrates the BUG comes from the url
> tag defined in parent pom
> The string test1 is the artifactId
--
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: (MASSEMBLY-385) Filtering replaces tokens it should not be replacing
[
http://jira.codehaus.org/browse/MASSEMBLY-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edwin Punzalan updated MASSEMBLY-385:
-
Priority: Major (was: Critical)
> Filtering replaces tokens it should not be replacing
>
>
> Key: MASSEMBLY-385
> URL: http://jira.codehaus.org/browse/MASSEMBLY-385
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: Maven 2.0.9
>Reporter: Robert Bracewell
>Assignee: Edwin Punzalan
> Attachments: component.zip
>
>
> What is described below is attached as an example that duplicates this
> When filtering is turned on and a token ends with .url then very strange
> things happen
> The assembly descriptor uses
>
>
> ${basedir}/src/config/xml/applicationContext.xml
> xml
> true
>
>
> The file being filtered contains:
>
>
>
>
> value="${vanity.url.message}"/>
>
>
>
> After the assembly is run the file contains:
>
>
>
>
> value="${vanity.url.message}"/>
>
>
>
> The string This is a not a URL but demonstrates the BUG comes from the url
> tag defined in parent pom
> The string test1 is the artifactId
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-256) No list of the possible reports in the doc
[ http://jira.codehaus.org/browse/MJAVADOC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187647#action_187647 ] Vincent Siveton commented on MJAVADOC-256: -- Did you read this page? Is it enough for you? http://maven.apache.org/plugins/maven-javadoc-plugin/plugin-info.html > No list of the possible reports in the doc > -- > > Key: MJAVADOC-256 > URL: http://jira.codehaus.org/browse/MJAVADOC-256 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Benson Margulies > > Reading up one side of the doc and down the other, I get the feeling that > there is a 1-1 relationship between the goals and the reports. But nothing on > the site says this in so many words. The pom doc on reporting and reportSets > seems to think that the javadoc plugin will carry the load, and vica versa. -- 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-363) Filter replaces all variables ending in ., .url, .file, etc. with corresponding value from POM
[
http://jira.codehaus.org/browse/MASSEMBLY-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187646#action_187646
]
Edwin Punzalan commented on MASSEMBLY-363:
--
Is this the same as MASSEMBLY-385 ?
> Filter replaces all variables ending in ., .url, .file, etc. with
> corresponding value from POM
> --
>
> Key: MASSEMBLY-363
> URL: http://jira.codehaus.org/browse/MASSEMBLY-363
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Win32, Maven 2.0.9
>Reporter: Stephen Robinson
>Priority: Minor
>
> A resource file (a Unix shell file) with this definition
> : ${BASE_DIR:=..}
> results in this after being filtered by the assembly plugin
> : MavenProject: catmktg:FlexRxProject:T1.4.0 @ F:\FlexRx\checkouts\pom.xml
> The expectation is that '..' would be left alone as there is no definition
> for this in our context. Turns out there is in ${project}, however.
> Specifying ${.url} and ${.file}, etc. result in replacements same as
> ${project.url} and ${project.file} as well. This seems like a bug but perhaps
> it is a feature that needs some refinement.
> The workaround in our case is to quote the dots ('..') which works when using
> it in a Unix path. However, this may not suffice in other cases.
> I've seen similar reports in MWAR-133 and MRESOURCES-20 but I cannot find a
> report in MASSEMBLY.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MCOMPILER-104) JAVA_HOME pointing to JDK but /usr/lib/java/../lib/tools.jar being used
[
http://jira.codehaus.org/browse/MCOMPILER-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann moved MNG-4311 to MCOMPILER-104:
--
Affects Version/s: (was: 2.2.0)
2.0.2
Component/s: (was: Errors)
Complexity: (was: Intermediate)
Key: MCOMPILER-104 (was: MNG-4311)
Project: Maven 2.x Compiler Plugin (was: Maven 2)
> JAVA_HOME pointing to JDK but /usr/lib/java/../lib/tools.jar being used
> -
>
> Key: MCOMPILER-104
> URL: http://jira.codehaus.org/browse/MCOMPILER-104
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: Linux sombriks 2.6.24.5-smp #2 SMP Wed Apr 30 13:41:38
> CDT 2008 i686 Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz GenuineIntel
> GNU/Linux
> java version "1.6.0_10"
> Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
> Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
> echo $JAVA_HOME
> /usr/lib/java
> which javac
> /usr/lib/java/bin/javac
>Reporter: sombriks
>
> using command line or netbeans plugin it's happening:
> leona...@sombriks:~/NetBeansProjects/arena/arena-client$ mvn compile
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Arena PUJ Client (jar)
> [INFO]task-segment: [compile]
> [INFO]
>
> [INFO] [resources:resources {execution: default-resources}]
> [WARNING] Using platform encoding (ISO-8859-1 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Compiling 1 source file to
> /home/leonardo/NetBeansProjects/arena/arena-client/target/classes
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
> Unable to locate the Javac Compiler in:
> /usr/lib/java/../lib/tools.jar
> Please ensure you are using JDK 1.4 or above and
> not a JRE (the com.sun.tools.javac.Main class is required).
> In most cases you can change the location of your Java
> installation by setting the JAVA_HOME environment variable.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 3 seconds
> [INFO] Finished at: Wed Aug 19 11:10:59 BRT 2009
> [INFO] Final Memory: 9M/65M
> [INFO]
>
> leona...@sombriks:~/NetBeansProjects/arena/arena-client$
--
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: (MSHARED-121) FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the drive letter.
[ http://jira.codehaus.org/browse/MSHARED-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MSHARED-121: --- Description: FilteringUtils.escapeWindowsPath requires a drive letter to be present in the path, or at least the string ":\\" to be present in order to trigger escaping the value as a windows path. In cases where the path is an absolute reference to a file on the current drive (no drive letter is included), or when the path starts with an unresolved expression (in cases where n+1 level interpolation will eventually resolve the expression), escaping doesn't happen at all. was: FilteringUtils.escapeWindowsPath requires a drive letter to be present in the path, or at least the string ":\\" to be present in order to trigger escaping the value as a windows path. In cases where the path is an absolute reference to a file on the current drive (no drive letter is included), or when the path starts with an unresolved expression (in cases where n+1 level interpolation will eventually resolve the expression), escaping doesn't happen at all. > FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the > drive letter. > -- > > Key: MSHARED-121 > URL: http://jira.codehaus.org/browse/MSHARED-121 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-filtering >Affects Versions: maven-filtering-1.0-beta-3 >Reporter: John Casey > Attachments: FilteringUtilsTest.java > > > FilteringUtils.escapeWindowsPath requires a drive letter to be present in the > path, or at least the string ":\\" to be present in order to > trigger escaping the value as a windows path. > In cases where the path is an absolute reference to a file on the current > drive (no drive letter is included), or when the path starts with an > unresolved expression (in cases where n+1 level interpolation will eventually > resolve the expression), escaping doesn't happen at all. -- 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: (MSHARED-121) FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the drive letter.
FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the drive letter. -- Key: MSHARED-121 URL: http://jira.codehaus.org/browse/MSHARED-121 Project: Maven Shared Components Issue Type: Bug Components: maven-filtering Affects Versions: maven-filtering-1.0-beta-3 Reporter: John Casey Attachments: FilteringUtilsTest.java FilteringUtils.escapeWindowsPath requires a drive letter to be present in the path, or at least the string ":\\" to be present in order to trigger escaping the value as a windows path. In cases where the path is an absolute reference to a file on the current drive (no drive letter is included), or when the path starts with an unresolved expression (in cases where n+1 level interpolation will eventually resolve the expression), escaping doesn't happen at all. -- 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: (MSHARED-121) FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the drive letter.
[
http://jira.codehaus.org/browse/MSHARED-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MSHARED-121:
---
Description:
FilteringUtils.escapeWindowsPath requires a drive letter to be present in the
path, or at least the string {noformat}":\\"{noformat} to be present in order
to trigger escaping the value as a windows path.
In cases where the path is an absolute reference to a file on the current drive
(no drive letter is included), or when the path starts with an unresolved
expression (in cases where n+1 level interpolation will eventually resolve the
expression), escaping doesn't happen at all.
was:
FilteringUtils.escapeWindowsPath requires a drive letter to be present in the
path, or at least the string ":\\" to be present in order to trigger
escaping the value as a windows path.
In cases where the path is an absolute reference to a file on the current drive
(no drive letter is included), or when the path starts with an unresolved
expression (in cases where n+1 level interpolation will eventually resolve the
expression), escaping doesn't happen at all.
> FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the
> drive letter.
> --
>
> Key: MSHARED-121
> URL: http://jira.codehaus.org/browse/MSHARED-121
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.0-beta-3
>Reporter: John Casey
> Attachments: FilteringUtilsTest.java
>
>
> FilteringUtils.escapeWindowsPath requires a drive letter to be present in the
> path, or at least the string {noformat}":\\"{noformat} to be present in order
> to trigger escaping the value as a windows path.
> In cases where the path is an absolute reference to a file on the current
> drive (no drive letter is included), or when the path starts with an
> unresolved expression (in cases where n+1 level interpolation will eventually
> resolve the expression), escaping doesn't happen at all.
--
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: (MSHARED-121) FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the drive letter.
[
http://jira.codehaus.org/browse/MSHARED-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MSHARED-121:
---
Fix Version/s: maven-filtering-1.0-beta-3
> FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the
> drive letter.
> --
>
> Key: MSHARED-121
> URL: http://jira.codehaus.org/browse/MSHARED-121
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.0-beta-3
>Reporter: John Casey
> Fix For: maven-filtering-1.0-beta-3
>
> Attachments:
> 0001-MSHARED-121-Don-t-require-a-drive-letter-to-escape-a.patch,
> FilteringUtilsTest.java
>
>
> FilteringUtils.escapeWindowsPath requires a drive letter to be present in the
> path, or at least the string {noformat}":\\"{noformat} to be present in order
> to trigger escaping the value as a windows path.
> In cases where the path is an absolute reference to a file on the current
> drive (no drive letter is included), or when the path starts with an
> unresolved expression (in cases where n+1 level interpolation will eventually
> resolve the expression), escaping doesn't happen at all.
--
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: (MSHARED-121) FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the drive letter.
[
http://jira.codehaus.org/browse/MSHARED-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MSHARED-121:
---
Attachment: 0001-MSHARED-121-Don-t-require-a-drive-letter-to-escape-a.patch
a patch containing the unit tests for three use cases: complete absolute
windows path, windows path absolute from current drive, and windows path
starting with an unresolved expression. Also contains a simplistic solution to
assume anything with a backslash is a windows path. I'm fairly certain we'll
want something more fine-grained than this, but not sure how to address it yet.
> FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the
> drive letter.
> --
>
> Key: MSHARED-121
> URL: http://jira.codehaus.org/browse/MSHARED-121
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.0-beta-3
>Reporter: John Casey
> Fix For: maven-filtering-1.0-beta-3
>
> Attachments:
> 0001-MSHARED-121-Don-t-require-a-drive-letter-to-escape-a.patch,
> FilteringUtilsTest.java
>
>
> FilteringUtils.escapeWindowsPath requires a drive letter to be present in the
> path, or at least the string {noformat}":\\"{noformat} to be present in order
> to trigger escaping the value as a windows path.
> In cases where the path is an absolute reference to a file on the current
> drive (no drive letter is included), or when the path starts with an
> unresolved expression (in cases where n+1 level interpolation will eventually
> resolve the expression), escaping doesn't happen at all.
--
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-2552) JUnit 4.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187651#action_187651 ] Tim Moore commented on MAVENUPLOAD-2552: This doesn't seem to have included the "junit-dep" alternate artifact that is there for 4.4 and 4.5 (though not 4.6): http://sourceforge.net/projects/junit/files/junit/4.7/junit-dep-4.7.jar/download Honestly, IMO, the "dep" version should replace the standard junit:junit artifact entirely, since the standard junit artifact contains a bundled Hamcrest dependency that wreaks havoc if you depend on a newer version of Hamcrest elsewhere. But if others disagree, then at least keeping the junit-dep artifact id up-to-date with the junit artifact would be great. > JUnit 4.7 > - > > Key: MAVENUPLOAD-2552 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2552 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Simon Brandhof >Assignee: Carlos Sanchez > Attachments: junit-4.7-bundle.jar > > > Please upload this new version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-254) aggregation fails to get classpath, blows up
[ http://jira.codehaus.org/browse/MJAVADOC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-254. Assignee: Vincent Siveton Resolution: Not A Bug as requested by Benson > aggregation fails to get classpath, blows up > > > Key: MJAVADOC-254 > URL: http://jira.codehaus.org/browse/MJAVADOC-254 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven 2.1.0, macos, java 1.5. >Reporter: Benson Margulies >Assignee: Vincent Siveton > Attachments: foo, javadoc.sh, options, packages > > > javadoc:aggregate blows up with an error inside of the javadoc tool. The > immediate problem is that junit isn't in the classpath, so junit annotations > explode. If I add junit to the dependencies of the aggregating project, I > just run into trouble with other missing annotations, like some for Spring. > [DEBUG] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - > javadoc: error - In doclet class com.sun.tools.doclets.standard.Standard, > method start has thrown an exception > java.lang.reflect.InvocationTargetException > java.lang.AssertionError: cannot find method org.junit.runner.RunWith.value() > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.findAccessMethod(ClassReader.java:1074) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompound(ClassReader.java:1057) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationDeproxy.deproxyCompoundList(ClassReader.java:1046) > at > com.sun.tools.javac.jvm.ClassReader$AnnotationCompleter.enterAnnotation(ClassReader.java:1195) > at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:94) > at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1541) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) > at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) > at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) > at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:105) > at > com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:116) > at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:574) > at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:546) > at > com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:152) > at > com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:168) > at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) > Command line > was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc > @options @packages -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-255) Cannot suppress reports
[ http://jira.codehaus.org/browse/MJAVADOC-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187653#action_187653 ] Vincent Siveton commented on MJAVADOC-255: -- Is it similar to MJAVADOC-254 ie to be close? > Cannot suppress reports > --- > > Key: MJAVADOC-255 > URL: http://jira.codehaus.org/browse/MJAVADOC-255 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Benson Margulies > > I wanted to suppress javadoc aggregation for mvn site:site. > So, I tried > > No effect. it goes ahead and runs the aggregate report. help:effectivePom > does not show the empty reportSets element. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2568) I am DynamicJasper's project leader, please upload.
I am DynamicJasper's project leader, please upload. --- Key: MAVENUPLOAD-2568 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2568 Project: Maven Upload Requests Issue Type: Task Reporter: Juan Manuel Alvarez I am DynamicJasper's project leader, please upload. DynamicJasper (DJ) is an API that hides the complexity of Jasper Reports, it helps developers to save time when designing simple/medium complexity reports generating the layout of the report elements automatically. It creates reports dynamically, defining at runtime the columns, column width (auto width), groups, variables, fonts, charts, crosstabs, sub reports (that can also be dynamic), page size and everything else that you can define at design time. -- 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-397) release:prepare goal does not check early enough whether the specified tag already exists in SVN
[ http://jira.codehaus.org/browse/MRELEASE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MRELEASE-397. -- Assignee: Paul Gier Resolution: Duplicate Closing because this is a duplicate of MRELEASE-165 > release:prepare goal does not check early enough whether the specified tag > already exists in SVN > > > Key: MRELEASE-397 > URL: http://jira.codehaus.org/browse/MRELEASE-397 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-8 > Environment: multi-module build >Reporter: Ian Springer >Assignee: Paul Gier > > I ran: > mvn release:prepare -Dresume=false -X -e "-DpreparationGoals=clean install > -Dmaven.test.skip=true" -Dtag=MyTag > not realizing a tag named MyTag already existed in SVN. > The release plugin eventually failed with a MyTag already exists error, but > not until after it had already updated all poms in the reactor to the release > version and committed them to SVN. But it did not roll back the SVN commit it > had done before aborting, so I had to roll it back manually. > The release plugin should check whether the tag already exists right in the > beginning (before anything has been committed to SVN) and abort if it does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-256) No list of the possible reports in the doc
[ http://jira.codehaus.org/browse/MJAVADOC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187673#action_187673 ] Benson Margulies commented on MJAVADOC-256: --- I did. And it never mentions reportSets. > No list of the possible reports in the doc > -- > > Key: MJAVADOC-256 > URL: http://jira.codehaus.org/browse/MJAVADOC-256 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Benson Margulies > > Reading up one side of the doc and down the other, I get the feeling that > there is a 1-1 relationship between the goals and the reports. But nothing on > the site says this in so many words. The pom doc on reporting and reportSets > seems to think that the javadoc plugin will carry the load, and vica versa. -- 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: (DOXIA-353) IText sink: Definition Lists are not formatted correctly
[ http://jira.codehaus.org/browse/DOXIA-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed DOXIA-353. - Assignee: Vincent Siveton Resolution: Fixed fixed in [r805990|http://svn.apache.org/viewvc?rev=805990&view=rev] > IText sink: Definition Lists are not formatted correctly > > > Key: DOXIA-353 > URL: http://jira.codehaus.org/browse/DOXIA-353 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Itext >Affects Versions: 1.1.1 >Reporter: Lukas Theussl >Assignee: Vincent Siveton > Fix For: 1.1.2 > > > This can be checked by running 'test' in the itext-module, see the result in > test-output/sink/test_model.pdf (or the attached test project at MPDF-23). > Compare the corresponding output of the fo module (test-output/sink/test.pdf). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPDF-23) Definition Lists are not formatted correctly
[
http://jira.codehaus.org/browse/MPDF-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MPDF-23.
---
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 1.1
Should be fixed with DOXIA-253, snapshot deployed
> Definition Lists are not formatted correctly
>
>
> Key: MPDF-23
> URL: http://jira.codehaus.org/browse/MPDF-23
> Project: Maven 2.x PDF Plugin
> Issue Type: Improvement
>Affects Versions: 1.0
> Environment: OS: Mac OS X (10.5.7)
> Java Version: (1.6.0_13)
> PDF Plugin Implementation: itext
> Documentation Source Format: APT
>Reporter: Steven Swor
>Assignee: Vincent Siveton
>Priority: Trivial
> Fix For: 1.1
>
> Attachments: pdfPluginDefinitionTest.zip
>
>
> When creating a definition list using APT, the resulting PDF is formatted
> incorrectly. For example:
> {noformat}
> [Term 1] Definition 1.
> [Term 2] Definition 2.
> [Term 3] Definition 3.
> []
> {noformat}
> produces the following output
> {noformat}
> Term 1
> Definition 1. Term 2.
> Definition 2. Term 3.
> Definition 3.
> {noformat}
> The two problems I have with this are that 1) new terms are on the same line
> as the definition of the previous term, and 2) there is not enough formatting
> difference between terms and their definitions. It'd be nice to make the
> terms bold-face, or indent the definitions, or something like that, to make
> the PDF more human-readable.
--
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: (MRESOURCES-79) are filtered by test filters
[ http://jira.codehaus.org/browse/MRESOURCES-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MRESOURCES-79. Assignee: John Casey Resolution: Fixed Starting in 2.4, you'll be able to configure the resources and testResources mojos separately (using Maven 2.2.0+). When you use the default-resources and default-testResources executionIds to separate configuration specific to the two mojos, you can setup a new parameter introduced for this issue, called 'extraFilters'. This parameter works the same way as the build/filters section in the main POM, by listing a series of properties file locations to be used during the mojo execution. These extraFilters will be PREPENDED to the filters list for that execution. This allows the user to configure extraFilters separately for the two resources/testResources mojo executions, thereby filtering the two sets of resources individually. > are filtered by test filters > > > Key: MRESOURCES-79 > URL: http://jira.codehaus.org/browse/MRESOURCES-79 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.9, Java 1.6.0_07 OS_X >Reporter: nodje >Assignee: John Casey > Fix For: 2.4 > > Attachments: resources-testcase.zip > > > With the following configuration I assume should get filtered by > src/main/filters/* and by src/test/filters/* : > > src/main/filters/dev.filter.properties > src/test/filters/dev.filter.properties > > > > src/main/resources > true > > > > > src/test/resources > true > > > But all resources files end up being filtered by the src/test/filters/*. > Attached is the simpliest Maven2 proect reproducing this behavior. -- 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: (MRESOURCES-81) 2.3 escapes characters when filtering properties
[
http://jira.codehaus.org/browse/MRESOURCES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MRESOURCES-81.
Resolution: Fixed
new parameter has been introduced: escapeWindowsPaths. This is true by default
to preserve backward compat, but can be turned off to disable path escaping.
> 2.3 escapes characters when filtering properties
>
>
> Key: MRESOURCES-81
> URL: http://jira.codehaus.org/browse/MRESOURCES-81
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows
>Reporter: Paul Jackson
>Assignee: John Casey
> Fix For: 2.4
>
>
> When filtering a property additional escaping characters are inserted into
> the replacement text. Here's an example pom snippett:
>
>
> Automated-Testing-Windows
>
> nt
>
> D:\\AutomatedTesting
>
> ${server.remote.base.dir}\\temp
>
>
>
>
>
> src/main/resources/${server.resource.type}
> true
>
>
>
>
>
> maven-resources-plugin
> 2.3
>
>
> resources
> process-resources
>
> resources
>
>
>
> ${project.build.directory}/resources
> true
>
>
>
>
>
>
> and the following line of text in a file in src\main\resources\nt
> cd /d ${server.remote.temp.dir}
> Resources plug in version 2.2 filters this property as follows:
> cd /d D:\\AutomatedTesting\\temp
> Resources plug in version 2.3 filters this property differently:
> cd /d D\:AutomatedTestingtemp
> Notice the extra backslashes inserted before each backslash (minor issue) and
> colon (major issue). Is there a way to prevent maven from inserting these
> escape characters?
>
> I also checked out 2.4-SNAPSHOT revision 732027 and observed the same
> behavior.
> Thanks,
> -Paul
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-255) Cannot suppress reports
[ http://jira.codehaus.org/browse/MJAVADOC-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187672#action_187672 ] Benson Margulies commented on MJAVADOC-255: --- no > Cannot suppress reports > --- > > Key: MJAVADOC-255 > URL: http://jira.codehaus.org/browse/MJAVADOC-255 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Benson Margulies > > I wanted to suppress javadoc aggregation for mvn site:site. > So, I tried > > No effect. it goes ahead and runs the aggregate report. help:effectivePom > does not show the empty reportSets element. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-492) [Patch] Support for tagging
[Patch] Support for tagging --- Key: SCM-492 URL: http://jira.codehaus.org/browse/SCM-492 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-bazaar Affects Versions: 1.2 Reporter: Johan Walles Attachments: maven-scm-bazaar-tag.patch The bazaar repository provider doesn't support the "tag" command. Here's a patch that fixes that in this branch: https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.2/ The patch passes the tagging TCK tests, so I checked the "Testcase included" box. Note that there are other TCK tests that the Bazaar code doesn't pass, but they don't pass without this patch either :-(. I intend to start working on that next. Regards //Johan -- 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: (SCM-492) [Patch] Support for tagging
[ http://jira.codehaus.org/browse/SCM-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187721#action_187721 ] Johan Walles commented on SCM-492: -- The failing TCK tests have supposedly been fixed in SCM-490, AFAIU the fix just hasn't been committed yet. My tagging patch is attached to this bug, it wasn't obvious from the bug mail I got so I thought I should mention it. > [Patch] Support for tagging > --- > > Key: SCM-492 > URL: http://jira.codehaus.org/browse/SCM-492 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-bazaar >Affects Versions: 1.2 >Reporter: Johan Walles > Attachments: maven-scm-bazaar-tag.patch > > > The bazaar repository provider doesn't support the "tag" command. Here's a > patch that fixes that in this branch: > https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.2/ > The patch passes the tagging TCK tests, so I checked the "Testcase included" > box. > Note that there are other TCK tests that the Bazaar code doesn't pass, but > they don't pass without this patch either :-(. I intend to start working on > that next. > Regards //Johan -- 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-465) -Dusername= switch ignored
[
http://jira.codehaus.org/browse/MRELEASE-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187722#action_187722
]
Johan Walles commented on MRELEASE-465:
---
I implemented tagging and sent in a patch at SCM-492.
> -Dusername= switch ignored
> --
>
> Key: MRELEASE-465
> URL: http://jira.codehaus.org/browse/MRELEASE-465
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0-beta-7
> Environment: Bazaar (bzr) 1.16.1
> Maven version: 2.0.9
> Java version: 1.5.0_17
> OS name: "linux" version: "2.6.26-2-686" arch: "i386" Family: "unix"
>Reporter: Johan Walles
> Attachments: pom.xml
>
>
> I'm calling mvn release:prepare with the -Dusername=johanwalles switch as
> instructed on
> http://maven.apache.org/plugins/maven-release-plugin/usage.html. In spite of
> that, when contacting Sourceforge's bzr daemon, Maven tries to use my local
> user name ("johan").
> The URL used by Maven is:
> bzr+ssh://expectj.bzr.sourceforge.net/bzrroot/expectj/trunk/
> The URL Maven *should* be using to work like the docs say is:
> bzr+ssh://johanwal...@expectj.bzr.sourceforge.net/bzrroot/expectj/trunk/
> To try this yourselves, do "bzr branch
> bzr://expectj.bzr.sourceforge.net/bzrroot/expectj/trunk/", then "mvn
> -Dusername=johanwalles release:prepare".
> I'm attaching my pom.xml for reference as well.
> Here's my full session, note that I'm not entering any password because I
> don't have one for that account:
> "
> jo...@johansdator:~/src/expectj-bzr$ mvn -Dusername=johanwalles
> release:prepare
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'release'.
> [INFO]
>
> [INFO] Building ExpectJ
> [INFO]task-segment: [release:prepare] (aggregator-style)
> [INFO]
>
> [INFO] [release:prepare]
> [INFO] Verifying that there are no local modifications...
> [INFO] EXECUTING: bzr status
> [INFO] [release.properties:unknown]
> [INFO] Checking dependencies and plugins for snapshots ...
> What is the release version for "ExpectJ"? (net.sourceforge.expectj:expectj)
> 2.0.1: :
> What is SCM release tag or label for "ExpectJ"?
> (net.sourceforge.expectj:expectj) expectj-2.0.1: :
> What is the new development version for "ExpectJ"?
> (net.sourceforge.expectj:expectj) 2.0.2-SNAPSHOT: :
> [INFO] Transforming 'ExpectJ'...
> [INFO] Not generating release POMs
> [INFO] Executing goals 'clean verify'...
> [INFO] Executing: mvn clean verify --no-plugin-updates
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building ExpectJ
> [INFO]task-segment: [clean, verify]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory /home/johan/src/expectj-bzr/target
> Downloading:
> http://repo1.maven.org/maven2/net/java/dev/jna/jna/3.0.5/jna-3.0.5.pom
> Downloading:
> http://repo1.maven.org/maven2/net/java/dev/jna/jna/3.0.5/jna-3.0.5.pom
> [INFO] [buildnumber:create {execution: default}]
> [INFO] Checking for local modifications: skipped.
> [INFO] Updating project files from SCM: skipped.
> [WARNING] Cannot get the revision information from the scm
> repository, proceeding with revision of MOJO1300 :
> Exception while executing SCM command.
> [INFO] Storing buildNumber: MOJO1300 at timestamp: 1248891626907
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 12 source files to
> /home/johan/src/expectj-bzr/target/classes
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] Compiling 3 source files to
> /home/johan/src/expectj-bzr/target/test-classes
> [INFO] [surefire:test]
> [INFO] Surefire report directory:
> /home/johan/src/expectj-bzr/target/surefire-reports
>
> ---
> T E S T S
> ---
> Running expectj.TestExpect
>
> flaskagrisflaskanyckelgrisflaskagrisflaskanyckelgrisflaskahinkbilnyckelg...@sltests
> run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.314 sec
>
> Results :
>
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0
>
> stork
> [INFO] [jar:jar]
> [INFO] Building j
