[jira] Created: (MAVENUPLOAD-1978) Please add org.jsecurity to the automatically synch'd repos
Please add org.jsecurity to the automatically synch'd repos --- Key: MAVENUPLOAD-1978 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1978 Project: maven-upload-requests Issue Type: Task Reporter: Les Hazlewood "org.jsecurity","[EMAIL PROTECTED]:/home/groups/j/js/jsecurity/htdocs/m2repo","rsync_ssh","Les Hazlewood","[EMAIL PROTECTED]",, Thanks! Les -- 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-3426) regression : in plugin configuration doesn't override plugin classpath
[ http://jira.codehaus.org/browse/MNG-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128108 ] Paul Benedict commented on MNG-3426: I know MNG-3473 was reverted, but why since 2.0.9 is all about increasing stability? It seems, in my opinion, that these two should be solved together. If this is about timing, I don't see a critical need to push out 2.0.9 soon. Just my 2 cents. > regression : in plugin configuration doesn't override plugin > classpath > --- > > Key: MNG-3426 > URL: http://jira.codehaus.org/browse/MNG-3426 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API >Affects Versions: 2.0.8 >Reporter: nicolas de loof >Assignee: nicolas de loof >Priority: Critical > Fix For: 2.0.9 > > > Many maven plugins are wrapper around other tools. The plugin is designed for > a version of the tool, and in many case user will want to use a specific > version without having to patch the plugin. The element on > plugin configuration is a common way to do this, by overriding the plugin POM > dependency with another version. > >castor-maven-plugin > > > org.codehaus.castor > castor > VERSION OF CASTOR I WANT TO USE FOR CODE > GENERATION > > > > This used to work with maven < 2.0.8 > In maven 2.0.8, this doesn't work anymore as the set in plugin > configuration is added to plugin classpath, as a duplicate for the one > declared by the plugin but LATER in the classpath (but I may be wrong on this > analysis). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1973) Upload of maven-deployment-package-plugin
[
http://jira.codehaus.org/browse/MAVENUPLOAD-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128105
]
Wayne Fay commented on MAVENUPLOAD-1973:
Irregardless of the ${name}-maven-plugin issue, I do think you should alter the
name so it is clear that this plugin is designed for use with OSGi.
> Upload of maven-deployment-package-plugin
> -
>
> Key: MAVENUPLOAD-1973
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1973
> Project: maven-upload-requests
> Issue Type: Wish
>Reporter: Siamak Haschemi
>
> http://kent.dl.sourceforge.net/sourceforge/mvn-dp-plugin/maven-deployment-package-plugin-0.1.0-bundle.jar
> https://sourceforge.net/projects/mvn-dp-plugin/
> https://sourceforge.net/project/memberlist.php?group_id=221773
> I'm a developer in maven-deployment-package-plugin, please upload!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1973) Upload of maven-deployment-package-plugin
[
http://jira.codehaus.org/browse/MAVENUPLOAD-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128104
]
Wayne Fay commented on MAVENUPLOAD-1973:
Some "rules" are discussed here, in the section "Shortening the Command Line":
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
The pattern maven-${name}-plugin is used by the official Maven2 plugins, and
${name}-maven-plugin is used by Mojo project plugins. But I can't find any
specific requirement that you abide by a given naming convention, so I guess
its just convention rather than an absolute rule. So the "must" above should
have been "are usually". As I said, I could be wrong. ;-)
Having said that, most m2 plugin developers will use ${name}-maven-plugin for
their own plugins. Felix is not really a fair comparison as both Maven2 and
Felix are Apache projects. But if you check this list here:
http://www.mvnrepository.com/search.html?query=maven-plugin you'll see that
most are using ${name}-maven-plugin.
So, until someone like Carlos weighs in here, you'll just have to wait.
> Upload of maven-deployment-package-plugin
> -
>
> Key: MAVENUPLOAD-1973
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1973
> Project: maven-upload-requests
> Issue Type: Wish
>Reporter: Siamak Haschemi
>
> http://kent.dl.sourceforge.net/sourceforge/mvn-dp-plugin/maven-deployment-package-plugin-0.1.0-bundle.jar
> https://sourceforge.net/projects/mvn-dp-plugin/
> https://sourceforge.net/project/memberlist.php?group_id=221773
> I'm a developer in maven-deployment-package-plugin, please upload!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-1977) maven-license-plugin-1.2.1 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Carbou updated MAVENUPLOAD-1977: Attachment: maven-license-plugin-1.2.2-bundle.jar Here is an update that fix the issue 9 reported at http://code.google.com/p/maven-license-plugin/issues/list. => Please upload maven-license-plugin-1.2.2 in central repo :-) Thanks ! > maven-license-plugin-1.2.1 upload request > - > > Key: MAVENUPLOAD-1977 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1977 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Mathieu Carbou > Attachments: maven-license-plugin-1.2.1-bundle.jar, > maven-license-plugin-1.2.2-bundle.jar > > > -- Project URL: > http://code.google.com/p/maven-license-plugin/ > -- Project developer and owner: > Mathieu Carbou > [EMAIL PROTECTED] -- 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-1977) maven-license-plugin-1.2.1 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128089 ] Mathieu Carbou commented on MAVENUPLOAD-1977: - Hi, Please can you upload this maven plugin in the central repo ? This is a plugin to manage license headers of projects. Thanks ! > maven-license-plugin-1.2.1 upload request > - > > Key: MAVENUPLOAD-1977 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1977 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Mathieu Carbou > Attachments: maven-license-plugin-1.2.1-bundle.jar > > > -- Project URL: > http://code.google.com/p/maven-license-plugin/ > -- Project developer and owner: > Mathieu Carbou > [EMAIL PROTECTED] -- 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-1977) maven-license-plugin-1.2.1 upload request
maven-license-plugin-1.2.1 upload request - Key: MAVENUPLOAD-1977 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1977 Project: maven-upload-requests Issue Type: Wish Reporter: Mathieu Carbou Attachments: maven-license-plugin-1.2.1-bundle.jar -- Project URL: http://code.google.com/p/maven-license-plugin/ -- Project developer and owner: Mathieu Carbou [EMAIL PROTECTED] -- 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: (MJAR-103) Adding License and/or Notice into META-INF folder
Adding License and/or Notice into META-INF folder - Key: MJAR-103 URL: http://jira.codehaus.org/browse/MJAR-103 Project: Maven 2.x Jar Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Michael Osipov I'd like to be able to add my license.txt into the jar package. an xml tag like true/false would be extremely convenient. This can be achived right now with build/resouces but the default resources have to be redeclared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAR-102) Using ${artifcactId}-Extention-Name in MANIFEST file can create invalid MANIFEST files
Using ${artifcactId}-Extention-Name in MANIFEST file can create invalid
MANIFEST files
--
Key: MJAR-102
URL: http://jira.codehaus.org/browse/MJAR-102
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.1, 2.0
Environment: Java HotSpot(TM) Client VM (build 1.5.0_13-121)
Reporter: Todd Caine
If you have a maven dependency on an something with an artifactId that contains
a '.' in it, it creates an illegal manifest file when trying to create an
executable jar file (java -jar foo.jar).
Exception in thread "main" java.io.IOException: invalid header field name:
geronimo-jms_1.1_spec-Extension-Name
at java.util.jar.Attributes.read(Attributes.java:409)
at java.util.jar.Manifest.read(Manifest.java:167)
at java.util.jar.Manifest.(Manifest.java:52)
at java.util.jar.JarFile.getManifestFromReference(JarFile.java:158)
at java.util.jar.JarFile.getManifest(JarFile.java:145)
Here's my configuration:
org.apache.maven.plugins
maven-jar-plugin
my.class.Test
true
true
./lib/
I added the following dependency:
org.apache.geronimo.specs
geronimo-jms_1.1_spec
When the maven-archiver tries to create a manifest file with the JARs
dependencies it adds the following to the META-INF/MANIFEST.MF file:
geronimo-jms_1.1_spec-Extension-Name: geronimo-jms_1.1_spec
geronimo-jms_1.1_spec-Implementation-Version: 1.0
After digging around a bit it turns out that '.' is an illegal character in the
"Extension-Name" and "Implementaion-Version" header fields, which leads to the
following exception when I try to run "java -jar Test.jar"
java.io.IOException: invalid header field name:
geronimo-jms_1.1_spec-Extension-Name
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-475) Classloader getResource() returns resource from wrong directory
Classloader getResource() returns resource from wrong directory --- Key: SUREFIRE-475 URL: http://jira.codehaus.org/browse/SUREFIRE-475 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.4.2 Reporter: Alex Eagle In upgrading from version 2.3 to 2.4.2, we encountered a different behaviour in classloading. We have a classes/ and a test-classes/ folder under target, and both contain the same package, "foo": |-- target/test-classes | `-- foo `-- some file |-- target/classes `-- foo In 2.3, a Classloader.getResource() call in our app returns the target/test-classes/foo folder, in which we find some file. In 2.4.2, the same code returns the target/classes/foo folder, and so some file cannot be found. Note that there are two actual directories that resolve to from same classpath location. To get the classes folder in the classpath when running tests, we are using this testResources in the pom: src/test/resources src/main/resources Perhaps SUREFIRE-443 can provide a way to correctly copy resources between the classes and test-classes folders, so that there is only one location on the disk for each classpath URI. -- 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-3473) site generation with 2.0.9 and plugin:report is broken
[ http://jira.codehaus.org/browse/MNG-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128080 ] John Casey commented on MNG-3473: - Rolled back the switch from HashSet to LinkedHashSet for plugin dependencies, which was originally changed in the commit for MNG-3426. We do need that change, but for now it breaks at least the plugin:report execution when run from within the site lifecycle phase...the result is the exception reported in the description of this issue. I'll open a new issue to get this fixed in the next Maven release. > site generation with 2.0.9 and plugin:report is broken > -- > > Key: MNG-3473 > URL: http://jira.codehaus.org/browse/MNG-3473 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.9 >Reporter: Brian Fox >Assignee: John Casey > Fix For: 2.0.9 > > > Generating a site that works in 2.0.8 breaks in 2.0.9 with an exception: > Caused by: java.lang.NoClassDefFoundError: > org/apache/maven/doxia/module/site/manager/SiteModuleNotFoundException > There is already a committed IT for this. It may be related to issues with > MPLUGIN-104, however in this case the 2.4 version of the plugin does work in > 2.0.8 so we need to investigate it in the core as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3473) site generation with 2.0.9 and plugin:report is broken
[ http://jira.codehaus.org/browse/MNG-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3473. --- Resolution: Fixed > site generation with 2.0.9 and plugin:report is broken > -- > > Key: MNG-3473 > URL: http://jira.codehaus.org/browse/MNG-3473 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.9 >Reporter: Brian Fox >Assignee: John Casey > Fix For: 2.0.9 > > > Generating a site that works in 2.0.8 breaks in 2.0.9 with an exception: > Caused by: java.lang.NoClassDefFoundError: > org/apache/maven/doxia/module/site/manager/SiteModuleNotFoundException > There is already a committed IT for this. It may be related to issues with > MPLUGIN-104, however in this case the 2.4 version of the plugin does work in > 2.0.8 so we need to investigate it in the core as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-102) Module filepath is generated incorrectly for sibling parent
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128079 ] gotama commented on MIDEA-102: -- Also, this issue should not be closed until its agreed its fixed. Please reopen. > Module filepath is generated incorrectly for sibling parent > --- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-102) Module filepath is generated incorrectly for sibling parent
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128078 ] gotama commented on MIDEA-102: -- Dennis, the patch you applied is highly unnecessarily complex. Take a look at the patch that Roman lists above. This is the one that should be applied. Its 3 times smaller and easy to follow. If Roman's patch does not work, please explain why your patch works better. However, Daniel, I have tested both Roman's patch and Dennis' patch, and they both work. I did not pull the snapshot though, I complied the patches myself. You may want to delete the .m2\repository\org\apache\maven\plugins\maven-idea-plugin directory to ensure you are in fact using the 2.2-SNAPSHOT. If it still does not work, please elaborate using the test pom's below. Example: Is the result of running mvn idea:idea on: c:\foo\parent\pom.xml http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 com.test parent stubhub.com pom 3.0.6 Parent POM 2008 ../child c:\foo\child\pom.xml http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 com.test parent 3.0.6 child test pom 3.0.6 child of test 2008 So, again, lets throw Roman's patch in 2.2 and release this puppy. Nothing else is open for 2.2. Thanks. > Module filepath is generated incorrectly for sibling parent > --- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1976) Please Upload SAC 1.3
Please Upload SAC 1.3 - Key: MAVENUPLOAD-1976 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1976 Project: maven-upload-requests Issue Type: Wish Reporter: Daniel Gredler SAC is a standard interface for CSS parsers from the W3C. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-381) TestNG Reporter.log() calls don't show up in any reports
[
http://jira.codehaus.org/browse/SUREFIRE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128073
]
Ray Case commented on SUREFIRE-381:
---
>From the testng code, TestNG only writes Reporter.log("") to the .html files.
>If SUREFIRE-474 gets fixed, this will at least partially work.
> TestNG Reporter.log() calls don't show up in any reports
>
>
> Key: SUREFIRE-381
> URL: http://jira.codehaus.org/browse/SUREFIRE-381
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.4
>Reporter: Dan Fabulich
> Fix For: 2.x
>
> Attachments: testng-reporter.zip
>
>
> You can call Reporter.log() in TestNG tests, but it has no effect: the logged
> messages don't appear in the surefire-reports directory, and thus they don't
> appear in the generated site/surefire-report.html file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-151) Add Myfaces Archetypes to archetype-catalog.xml
[ http://jira.codehaus.org/browse/ARCHETYPE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128056 ] Leonardo Uribe commented on ARCHETYPE-151: -- the version for all archetypes is 1.0.0 like here org.apache.myfaces.buildtools myfaces-archetype-helloworld 1.0.0 http://repo1.maven.org/maven2 Simple Web application using Apache Myfaces org.apache.myfaces.buildtools myfaces-archetype-helloworld-facelets 1.0.0 http://repo1.maven.org/maven2 A simple archetype using MyFaces and facelets org.apache.myfaces.buildtools myfaces-archetype-trinidad 1.0.0 http://repo1.maven.org/maven2 A simple archetype using Myfaces and Trinidad org.apache.myfaces.buildtools myfaces-archetype-jsfcomponents 1.0.0 http://repo1.maven.org/maven2 A simple archetype for create custom JSF components using MyFaces > Add Myfaces Archetypes to archetype-catalog.xml > --- > > Key: ARCHETYPE-151 > URL: http://jira.codehaus.org/browse/ARCHETYPE-151 > Project: Maven Archetype > Issue Type: Improvement > Components: Archetypes >Affects Versions: 2.0-alpha-2 >Reporter: Leonardo Uribe > > It could be good if by default you can choose the following archetypes to the > default or internal archetype-catalog.xml: > It's as simple as add the nodes to the file on archetype-common > project. > > > > > org.apache.myfaces.buildtools > myfaces-archetype-helloworld > 1.0.0 > http://repo1.maven.org/maven2 > Simple Web application using Apache Myfaces > > > org.apache.myfaces.buildtools > myfaces-archetype-helloworld-facelets > 1.0.0 > http://repo1.maven.org/maven2 > A simple archetype using MyFaces and facelets > > > org.apache.myfaces.buildtools > myfaces-archetype-trinidad > 1.0 > http://repo1.maven.org/maven2 > A simple archetype using Myfaces and Trinidad > > > org.apache.myfaces.buildtools > myfaces-archetype-jsfcomponents > 1.0 > http://repo1.maven.org/maven2 > A simple archetype for create custom JSF components using > MyFaces > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-3426) regression : in plugin configuration doesn't override plugin classpath
[ http://jira.codehaus.org/browse/MNG-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reopened MNG-3426: This issue causes MNG-3473. Reverting the change in v633014 causes the tests to pass. > regression : in plugin configuration doesn't override plugin > classpath > --- > > Key: MNG-3426 > URL: http://jira.codehaus.org/browse/MNG-3426 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API >Affects Versions: 2.0.8 >Reporter: nicolas de loof >Assignee: nicolas de loof >Priority: Critical > Fix For: 2.0.9 > > > Many maven plugins are wrapper around other tools. The plugin is designed for > a version of the tool, and in many case user will want to use a specific > version without having to patch the plugin. The element on > plugin configuration is a common way to do this, by overriding the plugin POM > dependency with another version. > >castor-maven-plugin > > > org.codehaus.castor > castor > VERSION OF CASTOR I WANT TO USE FOR CODE > GENERATION > > > > This used to work with maven < 2.0.8 > In maven 2.0.8, this doesn't work anymore as the set in plugin > configuration is added to plugin classpath, as a duplicate for the one > declared by the plugin but LATER in the classpath (but I may be wrong on this > analysis). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MPLUGIN-104) plugin report broken in 2.4
[
http://jira.codehaus.org/browse/MPLUGIN-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128057
]
bentmann edited comment on MPLUGIN-104 at 3/20/08 2:47 PM:
Somehow this stack trace looks familar: MCHANGES-88.
Dennis had the same problem with the l10n-plugin over at Mojo and could "cure"
it by downgrading to doxia 1.0-alpha-7, see [plugin's promotion
vote|http://www.nabble.com/-VOTE--Promote-Localization-Tools-Maven-Plugin-from-the-sandbox-to15916797.html#a15926961].
Maybe a newer release of the maven-reporting-impl is due to catch up with doxia.
was (Author: bentmann):
Somehow this stack trace looks familar: MCHANGES-88
Maybe a newer release of the maven-reporting-impl is due catch up with doxia.
> plugin report broken in 2.4
> ---
>
> Key: MPLUGIN-104
> URL: http://jira.codehaus.org/browse/MPLUGIN-104
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 2.4
>Reporter: Brian Fox
>
> In 2.4 with 2.0.8 I get:
> {noformat}
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO]
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> [INFO]
>
> [DEBUG] Trace
> java.lang.NoSuchMethodError:
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-25) mvn site:site ignores server configuration in settings.xml
[ http://jira.codehaus.org/browse/MSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128067 ] Rahul Akolkar commented on MSITE-25: IMO, this should be reopened, and fix version set to 2.0-beta-7. > mvn site:site ignores server configuration in settings.xml > -- > > Key: MSITE-25 > URL: http://jira.codehaus.org/browse/MSITE-25 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Alan Cabrera >Assignee: Carlos Sanchez >Priority: Critical > Fix For: 2.0-beta-6 > > Attachments: MSITE-25-01.patch, MSITE-25.txt, > patch-MSITE-25-artifact-manager.diff, patch-MSITE-25-site-plugin.diff > > > mvn site:site ignores parts of my settings.xml: > > livetribe-website > 664 > 775 > > plink > pscp > > livetribe > > It uses the username when ssh but does not invoke plink. > [INFO] [site:deploy] > Using private key: C:\Documents and Settings\adc\.ssh\id_dsa > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Opened > Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o > "BatchMode yes" [EMAIL PROTECTED] "mkdir -p > /home/projects/livetribe/public_html/maven/." > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnecting > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnected -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1973) Upload of maven-deployment-package-plugin
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128060 ] Siamak Haschemi commented on MAVENUPLOAD-1973: -- Hello, I didn't know this rule. I followed the naming of the Felix OSGi project. They have maven-plugins like: maven-bundle-plugin (http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/felix/maven-bundle-plugin/) maven-orb-plugin (http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/felix/maven-obr-plugin/) maven-src-plugin (http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/felix/maven-scr-plugin/) ... So I thought the naming would be o.k. Btw, can you give me an URL where I can find the naming rules? > Upload of maven-deployment-package-plugin > - > > Key: MAVENUPLOAD-1973 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1973 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Siamak Haschemi > > http://kent.dl.sourceforge.net/sourceforge/mvn-dp-plugin/maven-deployment-package-plugin-0.1.0-bundle.jar > https://sourceforge.net/projects/mvn-dp-plugin/ > https://sourceforge.net/project/memberlist.php?group_id=221773 > I'm a developer in maven-deployment-package-plugin, please upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-25) mvn site:site ignores server configuration in settings.xml
[ http://jira.codehaus.org/browse/MSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated MSITE-25: --- Attachment: MSITE-25-01.patch Patch to populate SiteDeployMojo#serverConfigurationMap, rooted at maven-site-plugin trunk. > mvn site:site ignores server configuration in settings.xml > -- > > Key: MSITE-25 > URL: http://jira.codehaus.org/browse/MSITE-25 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Alan Cabrera >Assignee: Carlos Sanchez >Priority: Critical > Fix For: 2.0-beta-6 > > Attachments: MSITE-25-01.patch, MSITE-25.txt, > patch-MSITE-25-artifact-manager.diff, patch-MSITE-25-site-plugin.diff > > > mvn site:site ignores parts of my settings.xml: > > livetribe-website > 664 > 775 > > plink > pscp > > livetribe > > It uses the username when ssh but does not invoke plink. > [INFO] [site:deploy] > Using private key: C:\Documents and Settings\adc\.ssh\id_dsa > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Opened > Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o > "BatchMode yes" [EMAIL PROTECTED] "mkdir -p > /home/projects/livetribe/public_html/maven/." > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnecting > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnected -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-25) mvn site:site ignores server configuration in settings.xml
[ http://jira.codehaus.org/browse/MSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128065 ] Rahul Akolkar commented on MSITE-25: I manually populated the serverConfigurationMap (is there a better way?). That picks up the configuration as expected, and makes site deploys work. I'll attach a patch here in a minute. > mvn site:site ignores server configuration in settings.xml > -- > > Key: MSITE-25 > URL: http://jira.codehaus.org/browse/MSITE-25 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Alan Cabrera >Assignee: Carlos Sanchez >Priority: Critical > Fix For: 2.0-beta-6 > > Attachments: MSITE-25.txt, patch-MSITE-25-artifact-manager.diff, > patch-MSITE-25-site-plugin.diff > > > mvn site:site ignores parts of my settings.xml: > > livetribe-website > 664 > 775 > > plink > pscp > > livetribe > > It uses the username when ssh but does not invoke plink. > [INFO] [site:deploy] > Using private key: C:\Documents and Settings\adc\.ssh\id_dsa > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Opened > Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o > "BatchMode yes" [EMAIL PROTECTED] "mkdir -p > /home/projects/livetribe/public_html/maven/." > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnecting > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnected -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3473) site generation with 2.0.9 and plugin:report is broken
[ http://jira.codehaus.org/browse/MNG-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3473: --- Description: Generating a site that works in 2.0.8 breaks in 2.0.9 with an exception: Caused by: java.lang.NoClassDefFoundError: org/apache/maven/doxia/module/site/manager/SiteModuleNotFoundException There is already a committed IT for this. It may be related to issues with MPLUGIN-104, however in this case the 2.4 version of the plugin does work in 2.0.8 so we need to investigate it in the core as well. was:This is a holder for now as we don't actually know what the cause is. I want a Jira number to relate tests and eventual fixes against for now. Summary: site generation with 2.0.9 and plugin:report is broken (was: something is wrong with 2.0.9 and the plugin tools release 2.4) Component/s: Plugins and Lifecycle > site generation with 2.0.9 and plugin:report is broken > -- > > Key: MNG-3473 > URL: http://jira.codehaus.org/browse/MNG-3473 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.9 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0.9 > > > Generating a site that works in 2.0.8 breaks in 2.0.9 with an exception: > Caused by: java.lang.NoClassDefFoundError: > org/apache/maven/doxia/module/site/manager/SiteModuleNotFoundException > There is already a committed IT for this. It may be related to issues with > MPLUGIN-104, however in this case the 2.4 version of the plugin does work in > 2.0.8 so we need to investigate it in the core as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-25) mvn site:site ignores server configuration in settings.xml
[ http://jira.codehaus.org/browse/MSITE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128062 ] Rahul Akolkar commented on MSITE-25: Is this working for anyone? I see an empty serverConfigurationMap in SiteDeployMojo#configureWagon(Wagon,String) >From SiteDeployMojo.java, here is the snippet for the field in question: /** Map( String, XmlPlexusConfiguration ) with the repository id and the wagon configuration */ private Map serverConfigurationMap = new HashMap(); The comment above seems to indicate what it should contain. How does it come to contain that? > mvn site:site ignores server configuration in settings.xml > -- > > Key: MSITE-25 > URL: http://jira.codehaus.org/browse/MSITE-25 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Alan Cabrera >Assignee: Carlos Sanchez >Priority: Critical > Fix For: 2.0-beta-6 > > Attachments: MSITE-25.txt, patch-MSITE-25-artifact-manager.diff, > patch-MSITE-25-site-plugin.diff > > > mvn site:site ignores parts of my settings.xml: > > livetribe-website > 664 > 775 > > plink > pscp > > livetribe > > It uses the username when ssh but does not invoke plink. > [INFO] [site:deploy] > Using private key: C:\Documents and Settings\adc\.ssh\id_dsa > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Opened > Executing command: ssh -i "C:\Documents and Settings\adc\.ssh\id_dsa" -o > "BatchMode yes" [EMAIL PROTECTED] "mkdir -p > /home/projects/livetribe/public_html/maven/." > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnecting > scpexe://repo.livetribe.org/home/projects/livetribe/public_html/maven/ - > Session: Disconnected -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPLUGIN-104) plugin report broken in 2.4
[
http://jira.codehaus.org/browse/MPLUGIN-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128057
]
Benjamin Bentmann commented on MPLUGIN-104:
---
Somehow this stack trace looks familar: MCHANGES-88
Maybe a newer release of the maven-reporting-impl is due catch up with doxia.
> plugin report broken in 2.4
> ---
>
> Key: MPLUGIN-104
> URL: http://jira.codehaus.org/browse/MPLUGIN-104
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 2.4
>Reporter: Brian Fox
>
> In 2.4 with 2.0.8 I get:
> {noformat}
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO]
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> [INFO]
>
> [DEBUG] Trace
> java.lang.NoSuchMethodError:
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-151) Add Myfaces Archetypes to archetype-catalog.xml
Add Myfaces Archetypes to archetype-catalog.xml --- Key: ARCHETYPE-151 URL: http://jira.codehaus.org/browse/ARCHETYPE-151 Project: Maven Archetype Issue Type: Improvement Components: Archetypes Affects Versions: 2.0-alpha-2 Reporter: Leonardo Uribe It could be good if by default you can choose the following archetypes to the default or internal archetype-catalog.xml: It's as simple as add the nodes to the file on archetype-common project. org.apache.myfaces.buildtools myfaces-archetype-helloworld 1.0.0 http://repo1.maven.org/maven2 Simple Web application using Apache Myfaces org.apache.myfaces.buildtools myfaces-archetype-helloworld-facelets 1.0.0 http://repo1.maven.org/maven2 A simple archetype using MyFaces and facelets org.apache.myfaces.buildtools myfaces-archetype-trinidad 1.0 http://repo1.maven.org/maven2 A simple archetype using Myfaces and Trinidad org.apache.myfaces.buildtools myfaces-archetype-jsfcomponents 1.0 http://repo1.maven.org/maven2 A simple archetype for create custom JSF components using MyFaces -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPLUGIN-104) plugin report broken in 2.4
[
http://jira.codehaus.org/browse/MPLUGIN-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128052
]
Brian Fox commented on MPLUGIN-104:
---
I added an IT to reproduce this here:
https://svn.apache.org/repos/asf/maven/plugin-tools/trunk/maven-plugin-plugin/src/it
Notice that the IT first calls the report version 2.3 and it works. Report
version 2.4 then fails on the same project.
> plugin report broken in 2.4
> ---
>
> Key: MPLUGIN-104
> URL: http://jira.codehaus.org/browse/MPLUGIN-104
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 2.4
>Reporter: Brian Fox
>
> In 2.4 with 2.0.8 I get:
> {noformat}
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO]
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> [INFO]
>
> [DEBUG] Trace
> java.lang.NoSuchMethodError:
> org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-104) plugin report broken in 2.4
plugin report broken in 2.4
---
Key: MPLUGIN-104
URL: http://jira.codehaus.org/browse/MPLUGIN-104
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 2.4
Reporter: Brian Fox
In 2.4 with 2.0.8 I get:
{noformat}
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO]
org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
[INFO]
[DEBUG] Trace
java.lang.NoSuchMethodError:
org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink;
at
org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-124) Dependency incorrectly reported as "Unused declared"
[
http://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128044
]
Brian Fox commented on MDEP-124:
There's no way to fix the analysis in this instance since it's looking at
bytecode. We should be able to safely skip the analysis though when we find no
classes to analyze.
> Dependency incorrectly reported as "Unused declared"
>
>
> Key: MDEP-124
> URL: http://jira.codehaus.org/browse/MDEP-124
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Olivier Dehon
>Assignee: Brian Fox
>
> When a dependency is only required for a constant in a JAR,
> dependency:analyze incorrectly reports the dependency as "Unused declared".
> Example:
> Constants.jar has 1 class called Constants.java:
> {code}
> package com.myco.util;
> public class Constants
> {
> private Constants() {};
> public static final double PI = 3.14159;
> }
> {code}
> Then App jar has App.java as:
> {code}
> package com.myco.app;
> public class App
> {
> public static void main( String[] args )
> {
> System.out.println( com.myco.util.Constants.PI );
> }
> }
> {code}
> Since the constant gets optimized away in the generated {{App.class}}, the
> dependency is not detected, even though the project won't compile without it.
--
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: (SUREFIRE-457) TestNG should log on the console before/after every test class
[ http://jira.codehaus.org/browse/SUREFIRE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-457: -- Attachment: testNGListenerTest.zip Jason Chaffee claims that you can get the right thing with onStart/onFinish notifications. I've attached a sample project that seems to show that this is false. http://markmail.org/message/in2iosogjpjev5yk http://markmail.org/message/yhbzjbhxmcydvqna I've attached a sample project that simply attaches an ITestListener that logs to system.out whenever it gets called, specifically during onStart and onFinish. It's got two test classes: Foo and Bar, each of which have one method "foo()" and "bar()" respectively. So you'd expect: onStart [Foo] onTestStart [foo()] onTestFinish [foo()] onFinish [Foo] onStart [Bar] onTestStart [bar()] onTestFinish [bar()] onFinish [Bar] But here's what you get instead: onStart onTestStart [foo()] onTestFinish [foo()] onTestStart [bar()] onTestFinish [bar()] onFinish ... not too useful, is it? In fact, onStart is called at the start/end of the "test" which is TestNG's very silly term for a collection of tests that isn't a "group" or a "suite". > TestNG should log on the console before/after every test class > -- > > Key: SUREFIRE-457 > URL: http://jira.codehaus.org/browse/SUREFIRE-457 > Project: Maven Surefire > Issue Type: Wish > Components: TestNG support >Affects Versions: 2.4, 2.4.1, 2.4.2 >Reporter: Dan Fabulich >Priority: Minor > Fix For: Future > > Attachments: testNGListenerTest.zip > > > In Surefire 2.3.x, when running the tests in "directory mode" (i.e. without a > suite.xml file) we used to run each TestNG class as a separate suite. As a > result, we logged to the console before/after every test class. > This behavior totally broke tests that had rich interdependencies (which is a > big part of the point of TestNG), so in Surefire 2.4 we handed more control > over to TestNG. As a result, we let TestNG run the entire directory at once, > and we aren't notified when classes start/end. Since we aren't notified, we > can't log to the console before/after every test class. But this looks like > a regression to those who were used to the 2.3.x behavior. > (This is trickier than it looks, because TestNG can/will run test methods > entirely out of order, running part of class X, and then part of class Y, > then back to class X, then a bit of class Z, etc. And that's not even > considering parallelized testing.) > I argue that to fix this "right" we'd need TestNG to notify us when classes > start/end; we should pressure the TestNG team to provide this functionality. > Benjamin has argued that there should be an option to run each test in its > own suite; I think that option is confusing and error-prone. > http://www.nabble.com/Re%3A-Test-Suites%2C-Ant%2C-Surefire%2C-and-JunitReport-p15094586.html > If you think you want a one-class-per-suite option, I offer this remark: Many > TestNG tests aren't safe to run in one-class-per-suite mode. If your tests > are safe to run in that mode, then they're also safe to run in JUnit 4. (In > fact, if your tests are that simple, you probably aren't using any of > TestNG's unique features, and you should prefer to use JUnit 4.) So, as a > workaround, don't use TestNG; use JUnit 4 instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1973) Upload of maven-deployment-package-plugin
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128039 ] Wayne Fay commented on MAVENUPLOAD-1973: Per the policy, only Maven core plugins (created or adopted by the Maven team themselves) can be named maven-xyz-plugin. Non-core plugins must be named xyz-maven-plugin. So, I don't think this will be accepted unless you change the name to something else (though I could be wrong). Since your plugin is specific to OSGi, I think you should include that in the name, too. So I'd suggest a new name of osgi-deployment-package-maven-plugin. > Upload of maven-deployment-package-plugin > - > > Key: MAVENUPLOAD-1973 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1973 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Siamak Haschemi > > http://kent.dl.sourceforge.net/sourceforge/mvn-dp-plugin/maven-deployment-package-plugin-0.1.0-bundle.jar > https://sourceforge.net/projects/mvn-dp-plugin/ > https://sourceforge.net/project/memberlist.php?group_id=221773 > I'm a developer in maven-deployment-package-plugin, please upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3473) something is wrong with 2.0.9 and the plugin tools release 2.4
[ http://jira.codehaus.org/browse/MNG-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3473: --- Assignee: Brian Fox Fix Version/s: 2.0.9 > something is wrong with 2.0.9 and the plugin tools release 2.4 > -- > > Key: MNG-3473 > URL: http://jira.codehaus.org/browse/MNG-3473 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0.9 > > > This is a holder for now as we don't actually know what the cause is. I want > a Jira number to relate tests and eventual fixes against for now. -- 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-3473) something is wrong with 2.0.9 and the plugin tools release 2.4
something is wrong with 2.0.9 and the plugin tools release 2.4 -- Key: MNG-3473 URL: http://jira.codehaus.org/browse/MNG-3473 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Reporter: Brian Fox Fix For: 2.0.9 This is a holder for now as we don't actually know what the cause is. I want a Jira number to relate tests and eventual fixes against for now. -- 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: (MANTRUN-84) Taskdef classpath not reolved
Taskdef classpath not reolved - Key: MANTRUN-84 URL: http://jira.codehaus.org/browse/MANTRUN-84 Project: Maven 2.x Antrun Plugin Issue Type: Bug Affects Versions: 1.1 Environment: Maven version: 2.0.7 Java version: 1.6.0_05 OS name: "windows xp" version: "5.1" arch: "x86" Apache Ant version 1.7.0 compiled on December 13 2006 Reporter: Daniel Frey Attachments: test.zip Trying to run an antrun tast ReplaceRegExp that relies on ant-optional and a regular expression parser using Java 1.6. I have included a ZIP with the relevant files for a testcase as follows: 0. Running with JDK 1.6 and Maven 2.0.7 1. The pom.xml contains an antrun task that tries to replace some values in a given file. 2. Running the test with "mvn package" fails with the error "No supported regular expression matcher found". 3. Decommenting the property line in pom.xml does lead to another error "ClassNotFoundException: org.apache.tools.ant.util.regexp.JakartaOroRegexp" On the other hand running the same task in ant 1.7 runs perfectly (as long as the property line is not decommented). Please try to reproduce the error. 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] Created: (MAVENUPLOAD-1975) Please add org.dbunit to syched repos
Please add org.dbunit to syched repos - Key: MAVENUPLOAD-1975 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1975 Project: maven-upload-requests Issue Type: Task Reporter: Roberto Lo Giacco "org.dbunit","[EMAIL PROTECTED]:/home/groups/d/db/dbunit/htdocs/m2repo","rsync_ssh","Roberto Lo Giacco","[EMAIL PROTECTED]",, -- 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: (SUREFIRE-423) Output a title for the report
[
http://jira.codehaus.org/browse/SUREFIRE-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed SUREFIRE-423.
--
Assignee: Herve Boutemy
Resolution: Fixed
Fix Version/s: (was: 2.x)
2.5
patch applied in r639314, thanks
I added the title not only in the header but as a sectionTitle1 too, like it is
done in most other report plugins
> Output a title for the report
> -
>
> Key: SUREFIRE-423
> URL: http://jira.codehaus.org/browse/SUREFIRE-423
> Project: Maven Surefire
> Issue Type: Bug
> Components: report plugin
>Affects Versions: 2.3
>Reporter: Benjamin Bentmann
>Assignee: Herve Boutemy
>Priority: Trivial
> Fix For: 2.5
>
> Attachments: report-header.patch
>
>
> Currently, the final HTML output of the report plugin has a title like
> "${project.name} - ". See the [Surefire report of the Taglist
> Plugin|http://mojo.codehaus.org/taglist-maven-plugin/surefire-report.html|]
> for an example. But it should be something like "${project.name} - Surefire
> Report".
--
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: (MWAR-151) Overlay filtering does not work when build takes place through reactor.
Overlay filtering does not work when build takes place through reactor. --- Key: MWAR-151 URL: http://jira.codehaus.org/browse/MWAR-151 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Environment: Running on Windows Vista. Reporter: Nathaniel Stoddard When building a war project directly, overlays are processed correctly (including excludes, includes and skip). When building through a parent reactor the overlay is processed but any includes, excludes or skip configuration is ignored. -- 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-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128021 ] Douglas Kaminsky commented on MNG-553: -- Any traction on this issue? Been over 2 years since it's been reported. > Secure Storage of Server Passwords > -- > > Key: MNG-553 > URL: http://jira.codehaus.org/browse/MNG-553 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0-alpha-3 > Environment: Although it may not be relevant since this is a general > improvement issue, Windows XP, JDK 1.4.1. >Reporter: J. Michael McGarr >Assignee: Brett Porter >Priority: Critical > Fix For: 2.1 > > > This was a question pose to the Maven User's Group and it was suggested I add > it here. > It would be benefitial to provide a more secure means of storing password's > to the servers listed in the .m2/settings.xml. They are currently being > stored as plain text and could definately be considered a security breach. > Numerous organizations would undoubtedly considered this an unacceptable > security risk, and this could prevent widespread adoption of Maven2. > I would suggest leaving an option to encrypt the password into the settings > file (more secure, but not foolproof) or even requiring the password to be > manually provided per build (would prevent automation of builds). I am sure > that there is a secure solution to this problem and it should be part of the > 2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-470) Surefire website should expose configuration documentation better
[ http://jira.codehaus.org/browse/SUREFIRE-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed SUREFIRE-470. -- Assignee: Herve Boutemy Resolution: Won't Fix like any plugin, this document is accessible: - via "Overview > Goals" in the menu on the left, then choose "surefire:test" goal - and in the main Introduction page, there is a direct link in the "Goal Overview" section these are parts of the [Plugin Documentation Standard|http://maven.apache.org/guides/development/guide-plugin-documentation.html], which are checked through [DOCCK plugin|http://maven.apache.org/plugins/maven-docck-plugin/] If you have ideas on how to improve the documentation standard or the documentation checker tool, feel free to open an issue in DOCCK Jira > Surefire website should expose configuration documentation better > - > > Key: SUREFIRE-470 > URL: http://jira.codehaus.org/browse/SUREFIRE-470 > Project: Maven Surefire > Issue Type: Improvement > Components: documentation >Affects Versions: 2.4.2 >Reporter: Tarjei Huse >Assignee: Herve Boutemy >Priority: Minor > > The only way I've managed to find this document: > http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html > is by googing for "surefire testng attributes". This document should be > linked to from the "Using Testng" document. > regards, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-174) Various information is written to stdout instead of log which is not embedder-friendly
[ http://jira.codehaus.org/browse/SUREFIRE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127999 ] Herve Boutemy commented on SUREFIRE-174: can you check if the problems are still here with 2.4? then please explain how to reproduce problems (what is expected precisely, and what is obtained) > Various information is written to stdout instead of log which is not > embedder-friendly > -- > > Key: SUREFIRE-174 > URL: http://jira.codehaus.org/browse/SUREFIRE-174 > Project: Maven Surefire > Issue Type: Bug >Reporter: Stepan Roh > Fix For: 2.x > > > The information (known to me) written to stdout in maven-surefire-plugin-2.2 > and surefire-booter-2.0 is: > - SurefireBooter writes "Forking command line..." if debug is enabled > - SurefireBooter redirects stdout and stderr of forked process to stdout > (this one is most serious, I think) > - SurefirePlugin outputs summary and/or text report to console (I know it can > be switched off and/or written to file, but I would like to have it written > to log) > It is important to have all this information written to log instead of > stdout, because information is "lost" if written to console and embedder is > used (two or more embedders may run and confuse their output) and it is also > important to be able to align such information with information already > logged. -- 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: (MDEP-124) Dependency incorrectly reported as "Unused declared"
[
http://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127997
]
B. Garvelink commented on MDEP-124:
---
Likewise, if you run {{dependency-analyze[Only]}} on a project without any
source code in it (the plugin is defined in my root pom, and I'm building an
EAR module), all project dependencies are reported as unused declared.
> Dependency incorrectly reported as "Unused declared"
>
>
> Key: MDEP-124
> URL: http://jira.codehaus.org/browse/MDEP-124
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Olivier Dehon
>Assignee: Brian Fox
>
> When a dependency is only required for a constant in a JAR,
> dependency:analyze incorrectly reports the dependency as "Unused declared".
> Example:
> Constants.jar has 1 class called Constants.java:
> {code}
> package com.myco.util;
> public class Constants
> {
> private Constants() {};
> public static final double PI = 3.14159;
> }
> {code}
> Then App jar has App.java as:
> {code}
> package com.myco.app;
> public class App
> {
> public static void main( String[] args )
> {
> System.out.println( com.myco.util.Constants.PI );
> }
> }
> {code}
> Since the constant gets optimized away in the generated {{App.class}}, the
> dependency is not detected, even though the project won't compile without it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3147) No component for RAR packaging projects in components.xml
[
http://jira.codehaus.org/browse/MNG-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-3147:
---
Summary: No component for RAR packaging projects in components.xml (was:
CLONE -No component for RAR packaging projects in components.xml)
> No component for RAR packaging projects in components.xml
> -
>
> Key: MNG-3147
> URL: http://jira.codehaus.org/browse/MNG-3147
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: Peter Liljenberg
>Assignee: Jason van Zyl
> Fix For: 2.0.8
>
>
> For a project with packaging "rar" the codehaus maven plugin for Cobertura
> does not work.
> During instrumentation the following message is displayed:
> "Not executing cobertura:instrument as the project is not a Java
> classpath-capable package"
> The reason for this is that in the CoberturaInstrumentMojo.execute() the
> code checks which language that the artifact is implemented in, like this:
> ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
> if ( !"java".equals( artifactHandler.getLanguage() ) )
> {
> getLog().info( "Not executing cobertura:instrument as the project
> is not a Java classpath-capable package" );
> }
> Looking at the components.xml in the Maven sources, we find that the "rar"
> packaging is not specified at all, meaning that it will be handled with the
> DefaultArtifactHandler and all properties set to null, including the language
> property.
> This can be fixed with the following addition to components.xml:
>
>
>
> org.apache.maven.artifact.handler.ArtifactHandler
> rar
>
> org.apache.maven.artifact.handler.DefaultArtifactHandler
>
> rar
> rar
> true
> java
> false
>
>
> ...
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3147) CLONE -No component for RAR packaging projects in components.xml
[
http://jira.codehaus.org/browse/MNG-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-3147:
---
Assignee: Jason van Zyl
Fix Version/s: 2.0.8
done in r593857 see http://svn.apache.org/viewvc?view=rev&revision=593857
not precisely the same configuration as proposed here
> CLONE -No component for RAR packaging projects in components.xml
>
>
> Key: MNG-3147
> URL: http://jira.codehaus.org/browse/MNG-3147
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: Peter Liljenberg
>Assignee: Jason van Zyl
> Fix For: 2.0.8
>
>
> For a project with packaging "rar" the codehaus maven plugin for Cobertura
> does not work.
> During instrumentation the following message is displayed:
> "Not executing cobertura:instrument as the project is not a Java
> classpath-capable package"
> The reason for this is that in the CoberturaInstrumentMojo.execute() the
> code checks which language that the artifact is implemented in, like this:
> ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
> if ( !"java".equals( artifactHandler.getLanguage() ) )
> {
> getLog().info( "Not executing cobertura:instrument as the project
> is not a Java classpath-capable package" );
> }
> Looking at the components.xml in the Maven sources, we find that the "rar"
> packaging is not specified at all, meaning that it will be handled with the
> DefaultArtifactHandler and all properties set to null, including the language
> property.
> This can be fixed with the following addition to components.xml:
>
>
>
> org.apache.maven.artifact.handler.ArtifactHandler
> rar
>
> org.apache.maven.artifact.handler.DefaultArtifactHandler
>
> rar
> rar
> true
> java
> false
>
>
> ...
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127989 ] Will Hoover commented on MECLIPSE-404: -- Despite whether the path is relative or not, doesn't it seem counter intuitive to have "M2_REPO/nemours/java/maven/repository" as the result? Seems like an unexpected behavior seeing that the path is getting repeated. IMHO, judging by the amount of users that have the same issue, the logical solution would be to maintain the functionality prior to version 2.5 (which is currently how maven behaves). The "look" of double appending the path does not seem natural :o) > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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: (MRAR-17) No RAR packaging (Causes Maven-cobertura-plugin to fail)
[
http://jira.codehaus.org/browse/MRAR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127990
]
Herve Boutemy commented on MRAR-17:
---
rar lifecycle mapping has been done for MNG-150 in r232602 in august 2005, see
http://svn.apache.org/viewvc?view=rev&revision=232602
rar ArtifactHandler definition in components.xml has been done in r593857 on
11/11/2007, released in Maven 2.0.8, see
http://svn.apache.org/viewvc?view=rev&revision=593857
but the definition is somewhat different from your proposal:
{code:xml}
org.apache.maven.artifact.handler.ArtifactHandler
rar
org.apache.maven.artifact.handler.DefaultArtifactHandler
rar
java
true
{code}
instead of
{code:xml}
org.apache.maven.artifact.handler.ArtifactHandler
rar
org.apache.maven.artifact.handler.DefaultArtifactHandler
rar
rar
true
java
false
{code}
Then my question is: should the actual configuration be modified?
1. add rar
2. add true
3. change true to
false
I'm not a rar expert, so my opinion on the topic is weak :)
BTW, I'll change MNG-3147 to mark it as fixed in Maven 2.0.8
And when we're ok with the changes to do, I'll create another MNG issue
For the dispatch of the diverse ArtifactHandler configurations from Maven Core
to corresponding plugins, I think it is another topic. Don't know if it is
already covered in an existing Jira issue...
> No RAR packaging (Causes Maven-cobertura-plugin to fail)
>
>
> Key: MRAR-17
> URL: http://jira.codehaus.org/browse/MRAR-17
> Project: Maven 2.x Rar Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Peter Liljenberg
>
> For a project with packaging "rar" the codehaus maven plugin for Cobertura
> does not work.
> During instrumentation the following message is displayed:
> "Not executing cobertura:instrument as the project is not a Java
> classpath-capable package"
> The reason for this is that in the CoberturaInstrumentMojo.execute() the
> code checks which language that the artifact is implemented in, like this:
> ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
> if ( !"java".equals( artifactHandler.getLanguage() ) )
> {
> getLog().info( "Not executing cobertura:instrument as the project
> is not a Java classpath-capable package" );
> }
> Looking at the components.xml in the Maven sources, we find that the "rar"
> packaging is not specified at all, meaning that it will be handled with the
> DefaultArtifactHandler and all properties set to null, including the language
> property.
> This can be fixed with the following addition to components.xml:
>
>
>
> org.apache.maven.artifact.handler.ArtifactHandler
> rar
>
> org.apache.maven.artifact.handler.DefaultArtifactHandler
>
> rar
> rar
> true
> java
> false
>
>
> ...
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-106) the generated jira-result.xml contains no jira-items
[ http://jira.codehaus.org/browse/MCHANGES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Boers updated MCHANGES-106: Attachment: jira-report.log here the requested output logfile. > the generated jira-result.xml contains no jira-items > > > Key: MCHANGES-106 > URL: http://jira.codehaus.org/browse/MCHANGES-106 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira-report >Affects Versions: 2.0-beta-3 > Environment: windows maven-2.0.8 jira Professional Edition, Version: > 3.11-#288 >Reporter: Rene Boers >Priority: Critical > Attachments: jira-report.html, jira-report.log, jira-results.xml, > jira-results.xml, pom.xml, screenshot-1.jpg > > > when i run the maven site or mvn changes:jira-report the resulting > jira-reports doesnot contain jira-issues it only contains the link to the > searchrequest. > This results in an empty jira-report. > I have included the jira-reports.xml and the logging from the mvn > changes:jira report. > When open the jira-reports.xml in firefox i do have a page with the request > jira-issues available. In explorer i just get the representation of the xml > file. > Any suggestions why no jira-report is generated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-334) Can't release project due to non released dependencies
[ http://jira.codehaus.org/browse/MRELEASE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127975 ] Mike R. Haller commented on MRELEASE-334: - We've got this issue too, with SNAPSHOT versions of a reporting plugin. The maven release plugin permits the release of our projects due to the dependency on a SNAPSHOT reporting plugin, which doesn't make sense in most cases. I don't care about reports for a release, so there should be a configuration or command line parameter to exclude reporting plugins from the "no snapshot dependencies" verification. > Can't release project due to non released dependencies > -- > > Key: MRELEASE-334 > URL: http://jira.codehaus.org/browse/MRELEASE-334 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-7 >Reporter: Kamen Petroff > Attachments: maven-release-manager.patch, maven-release-manager.patch > > > I guess the problem is already known. But once again > in maven-release-manager 1.0-alpha-4 > org/apache/maven/shared/release/phase/CheckDependencySnapshotsPhase.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3472) configuration possibilities to limit size of local repository
configuration possibilities to limit size of local repository - Key: MNG-3472 URL: http://jira.codehaus.org/browse/MNG-3472 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.0.8 Reporter: manuel aldana it would be great to make repository-size configurable, for instance by setting the maximum number of downloads of a snapshot-version to be kept. thus the explosion of local repository size can be reduced. especially when you are working with many in-house multi-module projects which are marked as snapshots before released , can increase repository size significantly. see mailing-list discussion: http://www.nabble.com/limit-size-of-local-repository%2C-limit-number-of-snapshots-td16147475s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
