[jira] Updated: (MRELEASE-101) tests contains jdk1.5 method (impossible to build it without skipping test or using need jdk upgrade)
[ http://jira.codehaus.org/browse/MRELEASE-101?page=all ] Carlos Sanchez updated MRELEASE-101: Assign To: (was: Brett Porter) Version: 2.0-beta-4 > tests contains jdk1.5 method (impossible to build it without skipping test or > using need jdk upgrade) > - > > Key: MRELEASE-101 > URL: http://jira.codehaus.org/browse/MRELEASE-101 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: all (jdk1.4.*) > Reporter: Olivier Lamy > > > The test ForkedMavenExecutorTest.java contains the use of Integer.valueOf(int > i) which is since 1.5. > AFAIK jdk1.5 is not mandatory to maven2.0 ? > Is it possible to remove it ? > The best solution to prevent this should to set target in compiler plugin to > the value 1.4. > Thanks, > Olivier -- This message is automatically generated by JIRA. - If 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-101) tests contains jdk1.5 method (impossible to build it without skipping test or using need jdk upgrade)
[ http://jira.codehaus.org/browse/MRELEASE-101?page=all ] Brett Porter closed MRELEASE-101: - Assign To: Brett Porter Resolution: Fixed > tests contains jdk1.5 method (impossible to build it without skipping test or > using need jdk upgrade) > - > > Key: MRELEASE-101 > URL: http://jira.codehaus.org/browse/MRELEASE-101 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: all (jdk1.4.*) > Reporter: Olivier Lamy > Assignee: Brett Porter > > > The test ForkedMavenExecutorTest.java contains the use of Integer.valueOf(int > i) which is since 1.5. > AFAIK jdk1.5 is not mandatory to maven2.0 ? > Is it possible to remove it ? > The best solution to prevent this should to set target in compiler plugin to > the value 1.4. > Thanks, > Olivier -- This message is automatically generated by JIRA. - If 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: (MSUREFIRE-102) Latest surefire code causes XML parser problems
[ http://jira.codehaus.org/browse/MSUREFIRE-102?page=all ] Carlos Sanchez updated MSUREFIRE-102: - Version: 2.2 > Latest surefire code causes XML parser problems > --- > > Key: MSUREFIRE-102 > URL: http://jira.codehaus.org/browse/MSUREFIRE-102 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Environment: Latest surefire as of May 1 > Reporter: Patrick Lightbody > Priority: Blocker > Fix For: 2.2 > > > With the latest releases surefire, the webwork tests ran just fine. > With the latest code in trunk, I get weird XML parser errors that only get > fixed once I set forkMode=once or childDelegation=false > See for yourself: > svn co https://svn.apache.org/repos/asf/incubator/webwork2 > cd webwork2 > mvn install > The error I get in various tests is: > javax.xml.parsers.FactoryConfigurationError: Provider for > javax.xml.parsers.SAXParserFactory cannot be found > at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) > at com.opensymphony.xwork.util.DomHelper.parse(DomHelper.java:86) -- This message is automatically generated by JIRA. - If 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-101) tests contains jdk1.5 method (impossible to build it without skipping test or using need jdk upgrade)
[ http://jira.codehaus.org/browse/MRELEASE-101?page=all ] Brett Porter updated MRELEASE-101: -- Assign To: Brett Porter Fix Version: 2.0-beta-4 > tests contains jdk1.5 method (impossible to build it without skipping test or > using need jdk upgrade) > - > > Key: MRELEASE-101 > URL: http://jira.codehaus.org/browse/MRELEASE-101 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: all (jdk1.4.*) > Reporter: Olivier Lamy > Assignee: Brett Porter > Fix For: 2.0-beta-4 > > > The test ForkedMavenExecutorTest.java contains the use of Integer.valueOf(int > i) which is since 1.5. > AFAIK jdk1.5 is not mandatory to maven2.0 ? > Is it possible to remove it ? > The best solution to prevent this should to set target in compiler plugin to > the value 1.4. > Thanks, > Olivier -- This message is automatically generated by JIRA. - If 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-874) CoWarp 0.5 Release
[ http://jira.codehaus.org/browse/MAVENUPLOAD-874?page=comments#action_64721 ] Carsten Ziegeler commented on MAVENUPLOAD-874: -- Do you mean I should create a dated version of the two Cocoon jars and put it into the repository using *my* (osoco.org) group id? Now, the problem I see here is that Cocoon in turn depends on about 70 other projects of which ten or more are not released into the m2 repository yet. So, in the end, this will create imho a mess. Now CoWarp is only usable *if* you're using Cocoon, so perhaps removing the dependencies from the pom is a better alternative for now? > CoWarp 0.5 Release > -- > > Key: MAVENUPLOAD-874 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-874 > Project: maven-upload-requests > Type: Task > Reporter: Carsten Ziegeler > > > This is the latest release of CoWarp - an extension to the Apache Cocoon > project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-19) Make file upload more robust
[ http://jira.codehaus.org/browse/WAGON-19?page=all ] Henry S. Isidro updated WAGON-19: - Attachment: (was: FtpWagon.patch) > Make file upload more robust > > > Key: WAGON-19 > URL: http://jira.codehaus.org/browse/WAGON-19 > Project: wagon > Type: Improvement > Components: wagon-webdav, wagon-ssh-external, wagon-ssh, wagon-ftp, > wagon-file > Environment: All scp, sftp and ftp upload of files to Repositories > Reporter: Mark Diggory > Priority: Critical > Fix For: 1.0-beta-1 > > > We would recommend that for upload of files to a repository that the > following cases be handled to provide greater robustness. > 1.) All uploads be to a "staging" area, this staging area could be the same > directory or a temp directory and would upload the file with the file name > extension of > Henk Penning comments: > > That would be great. > > > > I think, the best way for adding/replace stuff is > > > > -- write a 'temp' > > -- rename 'temp' to 'file' > > > > because a rename is truly atomic if 'temp' and 'file' are > > in the same file system. > > > > If you can implement the 'temp' for 'file' to be, > > for instance, '.tmp.file', I can easily teach the checkers > > to ignore '.tmp.*' files. I think rsync does something > > like that (even better .tmp.$$.file). > > > So the goals here are to verify that rsync handles ".tmp.$$.file" which will > stop it from attempting to sync partial uploads. Henk can alter the md5 > checking utilities at Apache to postpone checking .tmp files md5 signatures. > 2.) All file permissions on uploaded files would best handled to be only > writable by the individual user, not writable by group and readable by all. > All directory permissions should be writable for user and group and readable > by all. This forces the following implementation to be required. > Any file upload that attempts to overwrite a file should instead, move that > file out of the way to a temporary location, upload to the new file using > strategy (1) and then name it to the old file, once this is completed the old > file can be removed. This provides a means be which file "ownership" can be > determined and maintained. The problem this solves is the following, if files > are "group writable" then any individual in the group can overwite the file > altering its contents, historically we cannot tell who actually made the > alteration. If there are concerns about the integrity of the artifact or its > signature, it is unclear who was responsible for the alteration. > -Mark Diggory -- This message is automatically generated by JIRA. - If 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: (WAGON-19) Make file upload more robust
[ http://jira.codehaus.org/browse/WAGON-19?page=all ] Henry S. Isidro updated WAGON-19: - Attachment: WebDavWagon.patch > Make file upload more robust > > > Key: WAGON-19 > URL: http://jira.codehaus.org/browse/WAGON-19 > Project: wagon > Type: Improvement > Components: wagon-webdav, wagon-ssh-external, wagon-ssh, wagon-ftp, > wagon-file > Environment: All scp, sftp and ftp upload of files to Repositories > Reporter: Mark Diggory > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: WebDavWagon.patch, wagon.patch > > > We would recommend that for upload of files to a repository that the > following cases be handled to provide greater robustness. > 1.) All uploads be to a "staging" area, this staging area could be the same > directory or a temp directory and would upload the file with the file name > extension of > Henk Penning comments: > > That would be great. > > > > I think, the best way for adding/replace stuff is > > > > -- write a 'temp' > > -- rename 'temp' to 'file' > > > > because a rename is truly atomic if 'temp' and 'file' are > > in the same file system. > > > > If you can implement the 'temp' for 'file' to be, > > for instance, '.tmp.file', I can easily teach the checkers > > to ignore '.tmp.*' files. I think rsync does something > > like that (even better .tmp.$$.file). > > > So the goals here are to verify that rsync handles ".tmp.$$.file" which will > stop it from attempting to sync partial uploads. Henk can alter the md5 > checking utilities at Apache to postpone checking .tmp files md5 signatures. > 2.) All file permissions on uploaded files would best handled to be only > writable by the individual user, not writable by group and readable by all. > All directory permissions should be writable for user and group and readable > by all. This forces the following implementation to be required. > Any file upload that attempts to overwrite a file should instead, move that > file out of the way to a temporary location, upload to the new file using > strategy (1) and then name it to the old file, once this is completed the old > file can be removed. This provides a means be which file "ownership" can be > determined and maintained. The problem this solves is the following, if files > are "group writable" then any individual in the group can overwite the file > altering its contents, historically we cannot tell who actually made the > alteration. If there are concerns about the integrity of the artifact or its > signature, it is unclear who was responsible for the alteration. > -Mark Diggory -- This message is automatically generated by JIRA. - If 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: (WAGON-19) Make file upload more robust
[ http://jira.codehaus.org/browse/WAGON-19?page=all ] Henry S. Isidro updated WAGON-19: - Attachment: wagon.patch > Make file upload more robust > > > Key: WAGON-19 > URL: http://jira.codehaus.org/browse/WAGON-19 > Project: wagon > Type: Improvement > Components: wagon-webdav, wagon-ssh-external, wagon-ssh, wagon-ftp, > wagon-file > Environment: All scp, sftp and ftp upload of files to Repositories > Reporter: Mark Diggory > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: WebDavWagon.patch, wagon.patch > > > We would recommend that for upload of files to a repository that the > following cases be handled to provide greater robustness. > 1.) All uploads be to a "staging" area, this staging area could be the same > directory or a temp directory and would upload the file with the file name > extension of > Henk Penning comments: > > That would be great. > > > > I think, the best way for adding/replace stuff is > > > > -- write a 'temp' > > -- rename 'temp' to 'file' > > > > because a rename is truly atomic if 'temp' and 'file' are > > in the same file system. > > > > If you can implement the 'temp' for 'file' to be, > > for instance, '.tmp.file', I can easily teach the checkers > > to ignore '.tmp.*' files. I think rsync does something > > like that (even better .tmp.$$.file). > > > So the goals here are to verify that rsync handles ".tmp.$$.file" which will > stop it from attempting to sync partial uploads. Henk can alter the md5 > checking utilities at Apache to postpone checking .tmp files md5 signatures. > 2.) All file permissions on uploaded files would best handled to be only > writable by the individual user, not writable by group and readable by all. > All directory permissions should be writable for user and group and readable > by all. This forces the following implementation to be required. > Any file upload that attempts to overwrite a file should instead, move that > file out of the way to a temporary location, upload to the new file using > strategy (1) and then name it to the old file, once this is completed the old > file can be removed. This provides a means be which file "ownership" can be > determined and maintained. The problem this solves is the following, if files > are "group writable" then any individual in the group can overwite the file > altering its contents, historically we cannot tell who actually made the > alteration. If there are concerns about the integrity of the artifact or its > signature, it is unclear who was responsible for the alteration. > -Mark Diggory -- This message is automatically generated by JIRA. - If 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: (MPGENAPP-26) Problem with maven.genapp.repackage.dir and maven.genapp.repackage
Problem with maven.genapp.repackage.dir and maven.genapp.repackage -- Key: MPGENAPP-26 URL: http://jira.codehaus.org/browse/MPGENAPP-26 Project: maven-genapp-plugin Type: Bug Versions: 2.3 Environment: Test on windows Reporter: Charles Rathouis Attachments: saint-gobain.zip When you use the maven.genapp.repackage.dir properties and set it to . , the files contained in the maven.genapp.repackage directory are not < moved > to the new package directory, but copied in it, and steel in the base directory. Here is the template.properties file : maven.genapp.repackage.dir= maven.genapp.repackage=main/src/java,test/src/unit maven.genapp.filter=project.xml maven.genapp.default.package=com.saint-gobain.sgsi.my_application maven.genapp.filter=project.xml,main/src/webapp/WEB-INF/web.xml The content of "main/src/java" are not moved in "main/src/java/com/saint-gobain/sgsi/my_application" but copyed in it and steel in the "main/src/java" directory. If I put the main and test directory in a "src" directory, and remove the "maven.genapp.repackage.dir" propertie, everything works fine. You can find in attachment the template -- This message is automatically generated by JIRA. - If 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: (SCM-162) Add tests for remote repositories
[ http://jira.codehaus.org/browse/SCM-162?page=all ] Torbjørn EIkli Smørgrav closed SCM-162: --- Resolution: Fixed Fixed by revision r399266: >From the revision letter: * BazaarScmProvider - fix bug in validateScmUrl - formatting * BazaarScmProviderRepository and Test: - extend ScmProviderRepositoryWithHost - parse file, [a|s]ftp and http[s] protocols - enable external authentication information (from super class) - add validation and diagnostic method - add unit tests for the parser > Add tests for remote repositories > - > > Key: SCM-162 > URL: http://jira.codehaus.org/browse/SCM-162 > Project: Maven SCM > Type: Test > Components: maven-scm-provider-bazaar > Versions: 1.0-beta-3 > Reporter: Torbjørn EIkli Smørgrav > Assignee: Torbjørn EIkli Smørgrav > > > Only local and readonly http repositories are currently tested. We need to > test that the provider can handlerepositories over eg. sftp aswell -- This message is automatically generated by JIRA. - If 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: (MEV-386) FOP 0.20.5 dependencies
FOP 0.20.5 dependencies --- Key: MEV-386 URL: http://jira.codehaus.org/browse/MEV-386 Project: Maven Evangelism Type: Improvement Components: Missing POM Reporter: Joerg Schaible Attachments: fop-0.20.5.patch The POM of fop:fop:0.20.5 was generated from M1 repo and misses all dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEV-386) FOP 0.20.5 dependencies
[ http://jira.codehaus.org/browse/MEV-386?page=all ] Joerg Schaible updated MEV-386: --- Attachment: fop-0.20.5.patch > FOP 0.20.5 dependencies > --- > > Key: MEV-386 > URL: http://jira.codehaus.org/browse/MEV-386 > Project: Maven Evangelism > Type: Improvement > Components: Missing POM > Reporter: Joerg Schaible > Attachments: fop-0.20.5.patch > > > The POM of fop:fop:0.20.5 was generated from M1 repo and misses all > dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEV-386) FOP 0.20.5 dependencies
[ http://jira.codehaus.org/browse/MEV-386?page=all ] Joerg Schaible updated MEV-386: --- Attachment: fop-0.20.5.patch > FOP 0.20.5 dependencies > --- > > Key: MEV-386 > URL: http://jira.codehaus.org/browse/MEV-386 > Project: Maven Evangelism > Type: Improvement > Components: Missing POM > Reporter: Joerg Schaible > Attachments: fop-0.20.5.patch, fop-0.20.5.patch > > > The POM of fop:fop:0.20.5 was generated from M1 repo and misses all > dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-386) FOP 0.20.5 dependencies
[ http://jira.codehaus.org/browse/MEV-386?page=comments#action_64729 ] Joerg Schaible commented on MEV-386: Sorry, you have to go the the "Manage Attachments" to select the newest patch. > FOP 0.20.5 dependencies > --- > > Key: MEV-386 > URL: http://jira.codehaus.org/browse/MEV-386 > Project: Maven Evangelism > Type: Improvement > Components: Missing POM > Reporter: Joerg Schaible > Attachments: fop-0.20.5.patch, fop-0.20.5.patch > > > The POM of fop:fop:0.20.5 was generated from M1 repo and misses all > dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-871) Upload request for SLF4J version 1.0.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-871?page=comments#action_64730 ] Ceki Gulcu commented on MAVENUPLOAD-871: Thanks Fabrizio I'll do the necessary changes shortly and make a new submission. > Upload request for SLF4J version 1.0.1 > -- > > Key: MAVENUPLOAD-871 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-871 > Project: maven-upload-requests > Type: Task > Reporter: Ceki Gulcu > Attachments: jcl104-over-slf4j-1.0.1-bundle.jar, slf4j-jcl-1.0.1-bundle.jar, > slf4j-jdk14-1.0.1-bundle.jar, slf4j-log4j12-1.0.1-bundle.jar, > slf4j-log4j13-1.0.1-bundle.jar, slf4j-nop-1.0.1-bundle.jar, > slf4j-simple-1.0.1-bundle.jar > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-31) [webstart] NPE when signing dependencies
[ http://jira.codehaus.org/browse/MJAR-31?page=comments#action_64731 ] Jerome Lacoste commented on MJAR-31: Adrian. According to my knowledge, this issue has been fixed (at least the main one). I couldn't reproduce the second one. I will push again for a fresh snapshot to be deployed. In the mean time, please compile and install the jar by hand. > [webstart] NPE when signing dependencies > > > Key: MJAR-31 > URL: http://jira.codehaus.org/browse/MJAR-31 > Project: Maven 2.x Jar Plugin > Type: Bug > Environment: WinXP > Maven 2.0.2 > Latest maven-jar-plugin from SVN > Latest webstart checkout > Reporter: Michael Böckling > Priority: Critical > Attachments: MOJO-295.diff > > > In JarSignMojo, the call to this.signedjar.getPath() produces a NPE, because > in JnlpMojo:863, signJar.setSignedJar() has been commented out. > Stacktrace: > [debug] jarsigner > executable=[C:\Programme\Java\jdk1.5.0_06\jre\..\bin\jarsigner > .exe] > [INFO] > - > --- > [ERROR] BUILD ERROR > [INFO] > - > --- > [INFO] Failure to run the plugin: > [INFO] > - > --- > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failure to run the > plugi > n: > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi > fecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.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) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failure to run the > pl > ugin: > at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:479) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi > nManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:531) > ... 16 more > Caused by: java.lang.NullPointerException > at > org.apache.maven.plugin.jar.JarSignMojo.signJar(JarSignMojo.java:227) > at > org.apache.maven.plugin.jar.JarSignMojo.execute(JarSignMojo.java:185) > at org.codehaus.mojo.webstart.JnlpMojo.signJars(JnlpMojo.java:865) > at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:441) > ... 18 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPXDOC-179) Can't use relative links for external entities
[ http://jira.codehaus.org/browse/MPXDOC-179?page=comments#action_64732 ] Arnaud Heritier commented on MPXDOC-179: (for the users) ... because the core overrides the dependencies in the plugins with the ones it uses itself. It's the case for dom4J, thus we need to upgrade the dom4j used in the core to fix this problem (or we modify the classloader mechanism - which was done in m2). > Can't use relative links for external entities > -- > > Key: MPXDOC-179 > URL: http://jira.codehaus.org/browse/MPXDOC-179 > Project: maven-xdoc-plugin > Type: Bug > Versions: 1.10, 1.9.1, 1.9.2, 1.9 > Environment: maven-1.1 beta 3 from SVN > Reporter: Arnaud Heritier > > > Actually we can't use a relative path in xdocs to declare external entities > For exemple in plugins\trunk\xdoc\xdocs\reference\xdocs.xml we reference > escapeXml.xml like this with an absolute path from where maven is generally > called (in the xdoc plugin root directory) > > ]> > Thus if we use a multiproject the site fails. For example : > plugins\trunk>maven -Dgoal=site > -Dmaven.multiproject.includes=xdoc/project.xml multiproject:goal > gives : > LA CONSTRUCTION A ╚CHOU╚ > Fichier... > D:\Data\maven-1\cache\maven-multiproject-plugin-1.5-SNAPSHOT\plugin.jelly > ╚lement... maven:reactor > Ligne. 226 > Colonne... -1 > Unable to obtain goal [site] -- > D:\Data\maven-1\cache\maven-xdoc-plugin-1.10-SNAPSHOT\plugin.jelly:490:-1: > xdocs\reference\escapeX > ml.xml (The system cannot find the path specified) Nested exception: > xdocs\reference\escapeXml.xml (The system cannot find the path specifie > d) > If I use a relative path : > > ]> > With the same command as previously I receive a similar error : > Fichier... > D:\Data\maven-1\cache\maven-multiproject-plugin-1.5-SNAPSHOT\plugin.jelly > ╚lement... maven:reactor > Ligne. 226 > Colonne... -1 > Unable to obtain goal [site] -- > D:\Data\maven-1\cache\maven-xdoc-plugin-1.10-SNAPSHOT\plugin.jelly:490:-1: > Error on line 3 of docu > ment : URI relative "file:escapeXml.xml"; ne peut Ûtre rÚsolue sans URI de > base. Nested exception: URI relative "file:escapeXml.xml"; ne pe > ut Ûtre rÚsolue sans URI de base. > It seems to be a problem with dom4j 1.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-94) reactorProjector projects have null Artifact files when using assembly:assembly
reactorProjector projects have null Artifact files when using assembly:assembly --- Key: MASSEMBLY-94 URL: http://jira.codehaus.org/browse/MASSEMBLY-94 Project: Maven 2.x Assembly Plugin Type: Bug Versions: 2.1 Reporter: Edwin Punzalan So the work-around is to use "mvn package assembly:assembly"... also, assembly:attached doesn't have this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-14) assembly plugin does not include dependencies for all artifacts in reactor.
[ http://jira.codehaus.org/browse/MASSEMBLY-14?page=all ] Edwin Punzalan closed MASSEMBLY-14: --- Resolution: Fixed already in SVN. However, to those who want to use it, please see: http://jira.codehaus.org/browse/MASSEMBLY-94 > assembly plugin does not include dependencies for all artifacts in reactor. > --- > > Key: MASSEMBLY-14 > URL: http://jira.codehaus.org/browse/MASSEMBLY-14 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Erick Dovale > Assignee: Edwin Punzalan > Attachments: MNG-1206-maven-assembly-plugin.patch, test-assembly-m2.zip > > > When trying to create an archive using maven-assembly-plugin the dependencies > for the artifacts in the reactor are not added to the archive. > attached is a whole project structure that can be used to reproduce this > 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: (SCM-162) Add tests for remote repositories
[ http://jira.codehaus.org/browse/SCM-162?page=all ] Emmanuel Venisse updated SCM-162: - Fix Version: 1.0 > Add tests for remote repositories > - > > Key: SCM-162 > URL: http://jira.codehaus.org/browse/SCM-162 > Project: Maven SCM > Type: Test > Components: maven-scm-provider-bazaar > Versions: 1.0-beta-3 > Reporter: Torbjørn EIkli Smørgrav > Assignee: Torbjørn EIkli Smørgrav > Fix For: 1.0 > > > Only local and readonly http repositories are currently tested. We need to > test that the provider can handlerepositories over eg. sftp aswell -- This message is automatically generated by JIRA. - If 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: (MEV-386) FOP 0.20.5 dependencies
[ http://jira.codehaus.org/browse/MEV-386?page=all ] Joerg Schaible updated MEV-386: --- Attachment: fop-0.20.5.patch > FOP 0.20.5 dependencies > --- > > Key: MEV-386 > URL: http://jira.codehaus.org/browse/MEV-386 > Project: Maven Evangelism > Type: Improvement > Components: Missing POM > Reporter: Joerg Schaible > Attachments: fop-0.20.5.patch, fop-0.20.5.patch, fop-0.20.5.patch > > > The POM of fop:fop:0.20.5 was generated from M1 repo and misses all > dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-117) Add parameters to scm configuration element
[ http://jira.codehaus.org/browse/SCM-117?page=comments#action_64739 ] Antonio D'Errico commented on SCM-117: -- Hi, also for me a better flexibility in scm plugin configuration can be achieved using parameters to add to command line. For example I've a project configured under StarTeam that always ask the active item when I do a checkin, so the only way to perform such action is add the -active argument to command line. > Add parameters to scm configuration element > --- > > Key: SCM-117 > URL: http://jira.codehaus.org/browse/SCM-117 > Project: Maven SCM > Type: Wish > Components: maven-scm-provider-starteam > Versions: 1.0-beta-2 > Reporter: Aviran Mordo > Assignee: Dan Tran > > > It would be very nice to have the ability to add parameters to the scm > element. For instance to add parameter to always force checkout. for instance > in Starteam I would like to add -o so every time stcmd is called the > parameters will be concatenated to the command line -- This message is automatically generated by JIRA. - If 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-67) JavaDoc plugin will not locate overview file.
[ http://jira.codehaus.org/browse/MJAVADOC-67?page=comments#action_64743 ]
David Jackman commented on MJAVADOC-67:
---
This issue was reported in MJAVADOC-19, which is fixed in the code but not in
2.0-beta-3 and not available in any 2.0 snapshot (since no 2.0 snapshots have
been deployed).
> JavaDoc plugin will not locate overview file.
> -
>
> Key: MJAVADOC-67
> URL: http://jira.codehaus.org/browse/MJAVADOC-67
> Project: Maven 2.x Javadoc Plugin
> Type: Bug
> Versions: 2.0
> Environment: Maven version: 2.0.4
> Microsoft Windows XP [Version 5.1.2600]
> Reporter: Steven Coco
> Fix For: 2.0
> Attachments: JavaDoc Overview Tester.zip
>
>
> No matter what I specify for the overview in the javadoc plugin, Maven will
> not locate it. The file separators are stripped from the returned file path.
> The POM declares:
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
> ${project.build.sourceDirectory}/overview.html
>
>
> javadoc fails with the error message:
> Embedded error: Exit code: 1 - javadoc: error - Error while reading file
> C:Documents and SettingsCocoMy DocumentsJavaNet.StevenCocoXML Propertie
> s Convertersrcmainjava/overview.html
> Using: ${basedir}/src/main/java/overview.html yields:
> Embedded error: Exit code: 1 - javadoc: error - Error while reading file
> C:Documents and SettingsCocoMy DocumentsJavaNet.StevenCocoXML Propertie
> s Converter/src/main/java/overview.html
> Using: src/main/java/overview.html yields:
> Embedded error: Exit code: 1 - javadoc: error - Error while reading file
> src/main/java/overview.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-871) Upload request for SLF4J version 1.0.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-871?page=all ] Ceki Gulcu updated MAVENUPLOAD-871: --- Attachment: slf4j-simple-1.0.1-bundle.jar slf4j-nop-1.0.1-bundle.jar slf4j-log4j13-1.0.1-bundle.jar > Upload request for SLF4J version 1.0.1 > -- > > Key: MAVENUPLOAD-871 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-871 > Project: maven-upload-requests > Type: Task > Reporter: Ceki Gulcu > Attachments: jcl104-over-slf4j-1.0.1-bundle.jar, slf4j-jcl-1.0.1-bundle.jar, > slf4j-jcl-1.0.1-bundle.jar, slf4j-jdk14-1.0.1-bundle.jar, > slf4j-jdk14-1.0.1-bundle.jar, slf4j-log4j12-1.0.1-bundle.jar, > slf4j-log4j12-1.0.1-bundle.jar, slf4j-log4j13-1.0.1-bundle.jar, > slf4j-log4j13-1.0.1-bundle.jar, slf4j-nop-1.0.1-bundle.jar, > slf4j-nop-1.0.1-bundle.jar, slf4j-simple-1.0.1-bundle.jar, > slf4j-simple-1.0.1-bundle.jar > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-871) Upload request for SLF4J version 1.0.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-871?page=all ] Ceki Gulcu updated MAVENUPLOAD-871: --- Attachment: slf4j-log4j12-1.0.1-bundle.jar slf4j-jdk14-1.0.1-bundle.jar slf4j-jcl-1.0.1-bundle.jar > Upload request for SLF4J version 1.0.1 > -- > > Key: MAVENUPLOAD-871 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-871 > Project: maven-upload-requests > Type: Task > Reporter: Ceki Gulcu > Attachments: jcl104-over-slf4j-1.0.1-bundle.jar, slf4j-jcl-1.0.1-bundle.jar, > slf4j-jcl-1.0.1-bundle.jar, slf4j-jdk14-1.0.1-bundle.jar, > slf4j-jdk14-1.0.1-bundle.jar, slf4j-log4j12-1.0.1-bundle.jar, > slf4j-log4j12-1.0.1-bundle.jar, slf4j-log4j13-1.0.1-bundle.jar, > slf4j-log4j13-1.0.1-bundle.jar, slf4j-nop-1.0.1-bundle.jar, > slf4j-nop-1.0.1-bundle.jar, slf4j-simple-1.0.1-bundle.jar, > slf4j-simple-1.0.1-bundle.jar > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGONSSH-20) make KnownHosts configurable
[ http://jira.codehaus.org/browse/WAGONSSH-20?page=comments#action_64747 ] Dan Fabulich commented on WAGONSSH-20: -- Assuming I understand this issue, I think I really need either WAGONSSH-20 or WAGONSSH-19 to be fixed. On my official build system, I don't have the authority to leave files in the home directory. (The official build machine needs to remain pristine; if everybody just dropped one little custom file for their build, there'd be no way to reproduce the build machine.) That means that I need to be able to convince Maven to accept a host with an arbitrary public key. It looks like there's already a patch available... can somebody just merge this in? > make KnownHosts configurable > > > Key: WAGONSSH-20 > URL: http://jira.codehaus.org/browse/WAGONSSH-20 > Project: wagon-ssh > Type: Task > Reporter: Juan F. Codagnone > Attachments: WAGONSSH-20.diff > > > AbstractKnownHostsProvider sometimes tries to set a null property: > [DEBUG] Trace > java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:396) > at java.util.Properties.setProperty(Properties.java:128) > at > org.apache.maven.wagon.providers.ssh.knownhost.AbstractKnownHostsProvider.addConfiguration(AbstractKnownHostsProvider.java:37) > at > org.apache.maven.wagon.providers.ssh.AbstractSshWagon.openConnection(AbstractSshWagon.java:207) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:354) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:282) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:244) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:124) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) > at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:380) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:346) > at > org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:101) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:255) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1152) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:353) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > 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.
[jira] Commented: (WAGONSSH-19) make SingleKnownHostProvider configurable
[ http://jira.codehaus.org/browse/WAGONSSH-19?page=comments#action_64748 ] Dan Fabulich commented on WAGONSSH-19: -- Assuming I understand this issue, I think I really need either WAGONSSH-20 or WAGONSSH-19 to be fixed. On my official build system, I don't have the authority to leave files in the home directory. (The official build machine needs to remain pristine; if everybody just dropped one little custom file for their build, there'd be no way to reproduce the build machine.) That means that I need to be able to convince Maven to accept a host with an arbitrary public key. It looks like there's already a patch available... can somebody just merge this in? > make SingleKnownHostProvider configurable > -- > > Key: WAGONSSH-19 > URL: http://jira.codehaus.org/browse/WAGONSSH-19 > Project: wagon-ssh > Type: Task > Reporter: Juan F. Codagnone > Priority: Minor > Attachments: WAGONSSH-19.diff > > > Make org.apache.maven.wagon.providers.ssh.knownhost.SingleKnownHostProvider > configurable like > > test-private-repo > > > > implementation="org.apache.maven.wagon.providers.ssh.knownhos > t.SingleKnownHostProvider"> >localhost > > B3NzaC1yc2EBIwAAAIEAwps9EL+UKFG6Fb9spvV6YSOi > yLFwVGAgtyQ5r6xdADZRw0AdcCE87uwlVgUgMjGm0D/kifVEYFZu1DQUaKfg+6B3LEz7Dgq5Ir8eJJXq > 62mIVqHnXKPOqGIp1TPrtc2BMhSHk5z+4puun6Nbi0hw+g7b0/ywHVbs+7wb01SMREU= > > > > -- This message is automatically generated by JIRA. - If 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-2271) It should be possible to specify the public key for a repository as well as the private key
It should be possible to specify the public key for a repository as well as the private key --- Key: MNG-2271 URL: http://jira.codehaus.org/browse/MNG-2271 Project: Maven 2 Type: Improvement Components: General, Ant tasks Reporter: Dan Fabulich This bug is related to WAGONSSH-19. Right now settings.xml and the repository ant tasks allow you to specify a path to a private key, but not a path to a public key. WAGONSSH-19 suggests a way in which this could be configured using arbitrary properties, but that's not as clean as allowing the user to explicitly specify a element on the element in settings.xml or as a "publickey" attribute on the element in an Ant task. -- This message is automatically generated by JIRA. - If 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: (MEJB-12) EJB - Client jar doesn't have Session.class files
[ http://jira.codehaus.org/browse/MEJB-12?page=all ] raghurajan gurunathan closed MEJB-12: - Resolution: Fixed Fix Version: 2.1 Just tested with 2.1 snapshot version of ejb plugin this is working > EJB - Client jar doesn't have Session.class files > -- > > Key: MEJB-12 > URL: http://jira.codehaus.org/browse/MEJB-12 > Project: Maven 2.x Ejb Plugin > Type: Bug > Environment: win xp, unix, linux > Reporter: raghurajan gurunathan > Fix For: 2.1 > > > The ejb-client jar created from ejb-plugin does not contains remote interface > class like *Session.class Pls, see below > > > org.apache.maven.plugins > > maven-ejb-plugin > > > true > > > with reference to above section of pom.xml the created > artifactId-version-client.jar doesn't have Session.class, and even if tried > to include them using as shown below it doesn't help > > > org.apache.maven.plugins > > maven-ejb-plugin > > > true > > > **/session/** > > > -- This message is automatically generated by JIRA. - If 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-2272) It should be possible to trust all public keys implicitly
It should be possible to trust all public keys implicitly - Key: MNG-2272 URL: http://jira.codehaus.org/browse/MNG-2272 Project: Maven 2 Type: Improvement Components: General, Ant tasks Reporter: Dan Fabulich There should be a setting in server.xml and in the element for the ant task that allows you to turn off host key checking, and to explicitly trust all hosts, without prompting you to accept the certificate. (Ant's task allows you to do this.) On my official build system, I don't have the authority to leave files in the home directory. (The official build machine needs to remain pristine; if everybody just dropped one little custom file for their build, there'd be no way to reproduce the build machine.) That means that I need to be able to convince Maven to accept a host with an arbitrary public key. -- This message is automatically generated by JIRA. - If 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: (MEJB-6) Make the ejb-jar.xml deployment descriptor optional
[ http://jira.codehaus.org/browse/MEJB-6?page=comments#action_64753 ] Wayne Fay commented on MEJB-6: -- The EJB3 "final draft" was voted on and accepted by the JCP Executive Committee recently. Among the details is a confirmation that ejb-jar.xml is now optional, and ejb3 containers will now rely on metadata and automatic configurations of beans rather than requiring the deployment descriptor. So I believe Dan's patch should be accepted and applied to the maven-ejb-plugin, and a new release (or at least an official snapshot) produced asap. Relevant links: http://www.theserverside.com/news/thread.tss?thread_id=40199 http://jcp.org/en/jsr/detail?id=220 Copied from the EJB 3.0 final draft PDF document: 1.2 What is New in EJB 3.0 The Enterprise JavaBeans 3.0 architecture presented in this document extends Enterprise JavaBeans to include the following new functionality and simplifications to the earlier EJB APIs: Definition of the Java language metadata annotations that can be used to annotate EJB applications. These metadata annotations are targeted at simplifying the developer's task, at reducing the number of program classes and interfaces the developer is required to implement, and at eliminating the need for the developer to provide an EJB deployment descriptor. Specification of programmatic defaults, including for metadata, to reduce the need for the developer to specify common, expected behaviors and requirements on the EJB container. A "configuration by exception" approach is taken whenever possible. > Make the ejb-jar.xml deployment descriptor optional > --- > > Key: MEJB-6 > URL: http://jira.codehaus.org/browse/MEJB-6 > Project: Maven 2.x Ejb Plugin > Type: Improvement > Reporter: Tim Kettler > Priority: Trivial > Attachments: MEJB-4-maven-ejb-plugin.patch, MEJB-6-maven-ejb-plugin.patch > > > In the now near final EJB3 specification the use of deployment descripors is > optional. It would be nice if the maven-ejb-plugin wouldn't bump out with an > error if no descriptor is present. > The attached patch introduces a new boolean configuration option > 'enforceDeploymentDescriptor' which defaults to true so that the default > behavior is not changed. Feel free to change the name of the property if > appropriate. -- This message is automatically generated by JIRA. - If 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: (MEV-387) Acegi 1.0.0-RC2 POM missing
Acegi 1.0.0-RC2 POM missing --- Key: MEV-387 URL: http://jira.codehaus.org/browse/MEV-387 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Ralph Poellath There's no POM in http://www.ibiblio.org/maven2/org/acegisecurity/acegi-security/1.0.0-RC2/ It might be sufficient to copy http://www.ibiblio.org/maven2/org/acegisecurity/acegi-security/1.0.0-RC1/acegi-security-1.0.0-RC1.pom and update the version number. -- This message is automatically generated by JIRA. - If 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: (MASSEMBLY-29) Possibility to aggrates sources from other modules
[ http://jira.codehaus.org/browse/MASSEMBLY-29?page=all ] John Casey reopened MASSEMBLY-29: - looks like no longer exists in the .mdo...that will kill this feature, no? > Possibility to aggrates sources from other modules > -- > > Key: MASSEMBLY-29 > URL: http://jira.codehaus.org/browse/MASSEMBLY-29 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Alexandre Poitras > Assignee: Edwin Punzalan > Fix For: 2.1 > > Original Estimate: 5 hours >Time Spent: 10 hours > Remaining: 0 minutes > > It would be nice if it was possible to aggregate the sources of the other > sibling modules instead of having to archive different jar files containing > the sources. I would like also to be able to do that with Javadoc but I think > it's already in the scope of the javadoc plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-32) Provide installer support like NSIS or InnoSetup
[ http://jira.codehaus.org/browse/MASSEMBLY-32?page=all ] John Casey updated MASSEMBLY-32: Fix Version: (was: 2.1) I'm tabling this issue until we have a little more time to look at the impact on the descriptor and how the installers and archivers really line up, beyond being superficially similar. I don't want this to hold up the release of other important fixes/features for now. > Provide installer support like NSIS or InnoSetup > > > Key: MASSEMBLY-32 > URL: http://jira.codehaus.org/browse/MASSEMBLY-32 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Vincent Siveton > Assignee: John Casey > Attachments: MASSEMBLY-32.patch, MNG-1643.diff, MNG-1643.diff, > maven-assembly-plugin.zip, plexus-installer.diff > > > Add the support of installer compiler like NSIS or InnoSetup. > See the thread: > http://www.nabble.com/m2-developers-rfc%3A-The-assembly-plugin-ans-thirdparty-installation-builders-%28REPOST%29-t57.html#a1546470 -- This message is automatically generated by JIRA. - If 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: (MEJB-12) EJB - Client jar doesn't have Session.class files
[ http://jira.codehaus.org/browse/MEJB-12?page=all ] raghurajan gurunathan reopened MEJB-12: --- ok 2.1 plugin just works for clientIncludes but still when i tried to include *Session.class its not including > EJB - Client jar doesn't have Session.class files > -- > > Key: MEJB-12 > URL: http://jira.codehaus.org/browse/MEJB-12 > Project: Maven 2.x Ejb Plugin > Type: Bug > Environment: win xp, unix, linux > Reporter: raghurajan gurunathan > Fix For: 2.1 > > > The ejb-client jar created from ejb-plugin does not contains remote interface > class like *Session.class Pls, see below > > > org.apache.maven.plugins > > maven-ejb-plugin > > > true > > > with reference to above section of pom.xml the created > artifactId-version-client.jar doesn't have Session.class, and even if tried > to include them using as shown below it doesn't help > > > org.apache.maven.plugins > > maven-ejb-plugin > > > true > > > **/session/** > > > -- This message is automatically generated by JIRA. - If 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-21) Option to not copy 'provided' scoped jars
[ http://jira.codehaus.org/browse/MDEP-21?page=comments#action_64767 ] Gwyn Evans commented on MDEP-21: It looks as if the line DefaultArtifact artifact = (DefaultArtifact) i.next(); should be Artifact artifact = (Artifact) i.next(); by the way... > Option to not copy 'provided' scoped jars > - > > Key: MDEP-21 > URL: http://jira.codehaus.org/browse/MDEP-21 > Project: Maven 2.x Dependency Plugin > Type: Wish > Environment: Maven2 > Reporter: Gwyn Evans > > > It would be useful if there were an option that could be set such that a > 'scope=provided' jar would not be copied via copy-dependencies, but I can't > see any way of setting such or otherwise excluding such a jar from the copy. -- This message is automatically generated by JIRA. - If 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-183) Added listFiles to ScmProvider
[ http://jira.codehaus.org/browse/SCM-183?page=comments#action_64770 ] Carlos Sanchez commented on SCM-183: I'm working on a SVN implementation of this > Added listFiles to ScmProvider > -- > > Key: SCM-183 > URL: http://jira.codehaus.org/browse/SCM-183 > Project: Maven SCM > Type: New Feature > Components: maven-scm-api > Reporter: Zsolt Koppany > Assignee: Carlos Sanchez > Attachments: scm-maven.patch, scm-maven.patch > > > This patch adds "listFiles" method to "ScmProvider" and contains the > implementation for subversion. -- This message is automatically generated by JIRA. - If 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: (SCM-193) NullPointer in local provider update when a new file is added
[ http://jira.codehaus.org/browse/SCM-193?page=all ] Emmanuel Venisse closed SCM-193: Assign To: Emmanuel Venisse Resolution: Fixed Fixed in AbstractUpdateCommand > NullPointer in local provider update when a new file is added > - > > Key: SCM-193 > URL: http://jira.codehaus.org/browse/SCM-193 > Project: Maven SCM > Type: Bug > Components: maven-scm-provider-local > Versions: 1.0-beta-3 > Reporter: Carlos Sanchez > Assignee: Emmanuel Venisse > Priority: Critical > Fix For: 1.0 > > > org.apache.maven.continuum.scm.ContinuumScmException: Error while update > sources. > at > org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:272) > at > org.apache.maven.continuum.core.action.UpdateWorkingDirectoryFromScmContinuumAction.execute(UpdateWorkingDirectoryFromScmContinuumAction.java:58) > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:166) > at > org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) > at java.lang.Thread.run(Thread.java:595) > Caused by: org.apache.maven.scm.ScmException: Exception while executing SCM > command. > at > org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59) > at > org.apache.maven.scm.provider.local.LocalScmProvider.update(LocalScmProvider.java:191) > at > org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:386) > at > org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:363) > at > org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:242) > ... 5 more > Caused by: java.lang.NullPointerException > at java.util.Date.getMillisOf(Date.java:938) > at java.util.Date.after(Date.java:911) > at > org.apache.maven.scm.command.update.AbstractUpdateCommand.executeCommand(AbstractUpdateCommand.java:89) > at > org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:55) > ... 9 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-194) local provider doesn't trigger build when a file is edited
[ http://jira.codehaus.org/browse/SCM-194?page=all ] Emmanuel Venisse closed SCM-194: Assign To: Emmanuel Venisse Resolution: Cannot Reproduce > local provider doesn't trigger build when a file is edited > -- > > Key: SCM-194 > URL: http://jira.codehaus.org/browse/SCM-194 > Project: Maven SCM > Type: Bug > Components: maven-scm-provider-local > Versions: 1.0-beta-3 > Reporter: Carlos Sanchez > Assignee: Emmanuel Venisse > > -- This message is automatically generated by JIRA. - If 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: (CONTINUUM-679) Insecure html in build output leads to bad html rendering - could be used for malicious cross-site scripting.
Insecure html in build output leads to bad html rendering - could be used for malicious cross-site scripting. - Key: CONTINUUM-679 URL: http://jira.codehaus.org/browse/CONTINUUM-679 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.3 Reporter: Christian Gruber Priority: Critical In a custom maven2 build that calls an ant script to invoke weblogic's compiler for workshop, some warning output includes a warning about the "" tag. Continuum does not convert < and > into lt and gt entities. Since the build output is in another textarea it is sometimes not a problem. However, some browsers render nested textareas, and the remaining build log output is contained within the inner textarea. While this is annoying, it is dangerous. One need only alter the build script to something more malicious - say something with javascript - to cause damage. The fix is to pre-process the output to strip it of any html tag content. This bug should be reproducable by creating a small build.xml that echo's a and calling it from a maven pom 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] Created: (CONTINUUM-680) Strange behaviour when guest enabled but has no privs.
Strange behaviour when guest enabled but has no privs. -- Key: CONTINUUM-680 URL: http://jira.codehaus.org/browse/CONTINUUM-680 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.3 Environment: Firefox on Windows XP SP2 Reporter: Christian Gruber Priority: Trivial Guest with no privs (not even show projects) still gets a list of projects on the front page, which can be navigated. The resulting pages, however, have only the basic info, don't show the build history, etc. The above might be as-designed, however there is no show projects button, and the user has to use the back button. I suggest that a way back to the front page is still necessary. This may be breadcrumbs (in which case this would be a duplicate bug) or a home page link or something clearer in the UI. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-19) Make file upload more robust
[ http://jira.codehaus.org/browse/WAGON-19?page=comments#action_64772 ] Carlos Sanchez commented on WAGON-19: - The part about permissions is covered by MDEPLOY-28 > Make file upload more robust > > > Key: WAGON-19 > URL: http://jira.codehaus.org/browse/WAGON-19 > Project: wagon > Type: Improvement > Components: wagon-webdav, wagon-ssh-external, wagon-ssh, wagon-ftp, > wagon-file > Environment: All scp, sftp and ftp upload of files to Repositories > Reporter: Mark Diggory > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: WebDavWagon.patch, wagon.patch > > > We would recommend that for upload of files to a repository that the > following cases be handled to provide greater robustness. > 1.) All uploads be to a "staging" area, this staging area could be the same > directory or a temp directory and would upload the file with the file name > extension of > Henk Penning comments: > > That would be great. > > > > I think, the best way for adding/replace stuff is > > > > -- write a 'temp' > > -- rename 'temp' to 'file' > > > > because a rename is truly atomic if 'temp' and 'file' are > > in the same file system. > > > > If you can implement the 'temp' for 'file' to be, > > for instance, '.tmp.file', I can easily teach the checkers > > to ignore '.tmp.*' files. I think rsync does something > > like that (even better .tmp.$$.file). > > > So the goals here are to verify that rsync handles ".tmp.$$.file" which will > stop it from attempting to sync partial uploads. Henk can alter the md5 > checking utilities at Apache to postpone checking .tmp files md5 signatures. > 2.) All file permissions on uploaded files would best handled to be only > writable by the individual user, not writable by group and readable by all. > All directory permissions should be writable for user and group and readable > by all. This forces the following implementation to be required. > Any file upload that attempts to overwrite a file should instead, move that > file out of the way to a temporary location, upload to the new file using > strategy (1) and then name it to the old file, once this is completed the old > file can be removed. This provides a means be which file "ownership" can be > determined and maintained. The problem this solves is the following, if files > are "group writable" then any individual in the group can overwite the file > altering its contents, historically we cannot tell who actually made the > alteration. If there are concerns about the integrity of the artifact or its > signature, it is unclear who was responsible for the alteration. > -Mark Diggory -- This message is automatically generated by JIRA. - If 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: (MSUREFIRE-102) Prevent XML parser problems by changing default forkMode and childDelegation settings
[ http://jira.codehaus.org/browse/MSUREFIRE-102?page=all ] Brett Porter updated MSUREFIRE-102: --- Assign To: Brett Porter Summary: Prevent XML parser problems by changing default forkMode and childDelegation settings (was: Latest surefire code causes XML parser problems) > Prevent XML parser problems by changing default forkMode and childDelegation > settings > - > > Key: MSUREFIRE-102 > URL: http://jira.codehaus.org/browse/MSUREFIRE-102 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Environment: Latest surefire as of May 1 > Reporter: Patrick Lightbody > Assignee: Brett Porter > Priority: Blocker > Fix For: 2.2 > > > With the latest releases surefire, the webwork tests ran just fine. > With the latest code in trunk, I get weird XML parser errors that only get > fixed once I set forkMode=once or childDelegation=false > See for yourself: > svn co https://svn.apache.org/repos/asf/incubator/webwork2 > cd webwork2 > mvn install > The error I get in various tests is: > javax.xml.parsers.FactoryConfigurationError: Provider for > javax.xml.parsers.SAXParserFactory cannot be found > at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) > at com.opensymphony.xwork.util.DomHelper.parse(DomHelper.java:86) -- This message is automatically generated by JIRA. - If 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: (MSUREFIRE-102) Prevent XML parser problems by changing default forkMode and childDelegation settings
[ http://jira.codehaus.org/browse/MSUREFIRE-102?page=all ] Brett Porter closed MSUREFIRE-102: -- Resolution: Fixed > Prevent XML parser problems by changing default forkMode and childDelegation > settings > - > > Key: MSUREFIRE-102 > URL: http://jira.codehaus.org/browse/MSUREFIRE-102 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Environment: Latest surefire as of May 1 > Reporter: Patrick Lightbody > Assignee: Brett Porter > Priority: Blocker > Fix For: 2.2 > > > With the latest releases surefire, the webwork tests ran just fine. > With the latest code in trunk, I get weird XML parser errors that only get > fixed once I set forkMode=once or childDelegation=false > See for yourself: > svn co https://svn.apache.org/repos/asf/incubator/webwork2 > cd webwork2 > mvn install > The error I get in various tests is: > javax.xml.parsers.FactoryConfigurationError: Provider for > javax.xml.parsers.SAXParserFactory cannot be found > at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) > at com.opensymphony.xwork.util.DomHelper.parse(DomHelper.java:86) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-124) site:run doesn't invoke site:site first
site:run doesn't invoke site:site first --- Key: MSITE-124 URL: http://jira.codehaus.org/browse/MSITE-124 Project: Maven 2.x Site Plugin Type: Bug Versions: 2.0-beta-5 Reporter: Alexandre Poitras Priority: Minor Attachments: SiteRunMojoPatch.patch site:run doesn't invoke site:site first so it's a little bit annoying to have to always have to type "mvn site:site site:run" instead of just "mvn site:run". Plus, it's confusing when you try out the site plugin for the first 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: (MSITE-124) site:run doesn't invoke site:site first
[ http://jira.codehaus.org/browse/MSITE-124?page=all ] Brett Porter closed MSITE-124: -- Assign To: Brett Porter Resolution: Won't Fix it's not meant to. site:run let's you view each page dynamically from the started jetty server, it doesn't use any of the generated files by site:site > site:run doesn't invoke site:site first > --- > > Key: MSITE-124 > URL: http://jira.codehaus.org/browse/MSITE-124 > Project: Maven 2.x Site Plugin > Type: Bug > Versions: 2.0-beta-5 > Reporter: Alexandre Poitras > Assignee: Brett Porter > Priority: Minor > Attachments: SiteRunMojoPatch.patch > > > site:run doesn't invoke site:site first so it's a little bit annoying to have > to always have to type "mvn site:site site:run" instead of just "mvn > site:run". Plus, it's confusing when you try out the site plugin for the > first 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] Created: (MNG-2273) task gives a bad pathId when downloading a deployed SNAPSHOT
task gives a bad pathId when downloading a deployed SNAPSHOT --- Key: MNG-2273 URL: http://jira.codehaus.org/browse/MNG-2273 Project: Maven 2 Type: Bug Components: Ant tasks Versions: 2.0.4 Reporter: Dan Fabulich Priority: Blocker Deploy a -SNAPSHOT build using the deploy:deploy-file goal. (Don't do it with the Ant task; that doesn't work, per bug MNG-2060.) The file will be deployed into a -SNAPSHOT directory, but the file itself will contain a build number, not the word SNAPSHOT. Now delete the SNAPSHOT from your local repository and attempt to use to acquire it. The task will claim to succeed, but the pathId will contain an incorrect file path. For example, I deployed selenium-server-0.7.2-SNAPSHOT.jar; on the remote repo it was called selenium-server-0.7.2-20060505.015135-1.jar. When the Ant task pulled it into my local repo it was in selenium-server\0.7.2-SNAPSHOT\selenium-server-0.7.2-20060505.015135-1.jar. But finally when I ran the Ant task, the classpath it gave me pointed to selenium-server\0.7.2-20060505.015135-1\selenium-server-0.7.2-20060505.015135-1.jar, which is clearly wrong. -- This message is automatically generated by JIRA. - If 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: (MPANTLR-8) Upgrade to antlr 2.7.6
[ http://jira.codehaus.org/browse/MPANTLR-8?page=all ] Lukas Theussl closed MPANTLR-8: --- Assign To: Lukas Theussl Resolution: Fixed > Upgrade to antlr 2.7.6 > -- > > Key: MPANTLR-8 > URL: http://jira.codehaus.org/browse/MPANTLR-8 > Project: maven-antlr-plugin > Type: Improvement > Reporter: Arnaud Heritier > Assignee: Lukas Theussl > Priority: Minor > Fix For: 1.2.2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
