[jira] Created: (CONTINUUM-609) Continuum deployment repository
Continuum deployment repository --- Key: CONTINUUM-609 URL: http://jira.codehaus.org/browse/CONTINUUM-609 Project: Continuum Type: Improvement Components: Core system Reporter: Brett Porter Fix For: 1.0.3 What I was thinking of was having Continuum be configured to have a repository that is the default location for deploying JARs to and that can be served up without requiring an additional web server. This would make configuration of a snapshot repository much simpler. I'm thinking this wouldn't be required in the POM at all - that even though the goals are clean install, that Continuum would deploy to this repository itself after the build completed successfully. Using deploy wouldn't be desirable because you might accidentally wind up deploying a release which is probably not what you want. I was thinking this is purely a deployment repository, so would not be the local repository for continuum at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-608) Script gets cut off when building a shell project
[ http://jira.codehaus.org/browse/CONTINUUM-608?page=all ] Mang Lau updated CONTINUUM-608: --- Attachment: build.bat Script gets cut off when building a shell project - Key: CONTINUUM-608 URL: http://jira.codehaus.org/browse/CONTINUUM-608 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: Windows XP Pro SP2 Reporter: Mang Lau Attachments: build.bat When building a shell project, the shell script exits prematurely after Maven finishes. This means that nothing else can be executed after the Maven build is successful. It seems that Continuum is receiving the Maven exit code right after Maven ends and cuts off (does not execute) the rest of the script code. I don't think this should be happening as you can't perform post-build tasks such as copying the build elsewhere or tagging it in CVS. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-610) Add section about building recursively from parent to FAQ and provide more information on adding shell projects
Add section about building recursively from parent to FAQ and provide more information on adding shell projects --- Key: CONTINUUM-610 URL: http://jira.codehaus.org/browse/CONTINUUM-610 Project: Continuum Type: Improvement Components: Documentation Reporter: Mang Lau Priority: Minor Attachments: site-changes.patch Updated the following: about.fml - updated How do I write documentation for Continuum? section faq.fml - added section about building recursively from parent *Note:* I had the same [issue|http://jira.codehaus.org/browse/CONTINUUM-506] as Dennis when generating the site. getting started - index.apt - provided more detail on adding shell projects -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[continuum build branches/continuum-1.0.x - FAILED - checkout] Tue Feb 28 02:00:01 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060228.020001.txt
[jira] Commented: (CONTINUUM-426) cannot add project using url with authentication (https)
[ http://jira.codehaus.org/browse/CONTINUUM-426?page=comments#action_59622 ] Dan Allen commented on CONTINUUM-426: - I have more details. The problem does not lie with the https authentication, but rather with maven2 itself. As it turns out, our project uses the reactor and hence has multi modules. The default command to checkout the project is mvn scm:checkout However, this fails because it cannot find the pom files in the nested modules because they haven't been checkout out yet (chicken before the egg problem). To fix this, the maven2 developers informed me that I should be using the -N flag for non-recursive, which would allow the source to be checked out, and then built. mvn -N scm:checkout Is there anyway to make this the default for a continuum checkout? cannot add project using url with authentication (https) Key: CONTINUUM-426 URL: http://jira.codehaus.org/browse/CONTINUUM-426 Project: Continuum Type: Bug Components: Web interface Versions: 1.0 Environment: continuum 1.0 on linux Reporter: Dan Allen Original Estimate: 2 days Remaining: 2 days There seems to be no possible way for me to get continuum to accept an svn url in the following format: http://[username]:[EMAIL PROTECTED]/repos/svn/project/trunk/pom.xml I continually get Invalid url or pom.xml cannot be found errors. In this case, the pom.xml is a parent with several sub modules. If I attempt to import a local pom.xml, I get the error that /tmp/summit-2 cannot be found for each pom.xml in a sub module. I have beat my head against a way, trying tricks such as checking out into /tmp/summit-2, then importing and eventually I can force continuum to find my files doing some commandline checkouts, but it is WAY to much work for a regular user. SUGGESTION: It would be nice to have an editor similar to the one you get when editing a project's information on the import screen. It would make life a whole bunch easier just to be able to enter values for all the relevant fields and then watch continuum attempt a checkout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [vote] Release Maven-SCM 1.0 final
Hi Emmanuel, It seems everyone is happy with this vote given the time and feedback so far. I'm going to review this tomorrow before adding a +1. I'm sorry I didn't dedicate time to it sooner. Is it possible that the code can be stabilised for 24 hours before actually cutting the release to give everyone a chance to run the tests locally? Thanks, Brett Emmanuel Venisse wrote: Hi everyone, I'd like to release 1.0 final of Maven-SCM. All APIs are stable since a long time and we didn't find any blocker issues since 1.0-beta-2 release. The list of issues fixed are : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10527fixfor=12346 We have now 3 issues that i will fix before the release. I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, Emmanuel
RE: [vote] Release Maven-SCM 1.0 final
What about removing all depricated classes and methods before releasing version 1.0? Regards Torbjørn
Re: [vote] Release Maven-SCM 1.0 final
The code is stable (need to apply patch of Torbjorn for bazaar and Mike's patch for Perforce) I want to create a pure java provider for cvs (with only checkout command for now), this point require to split actual cvs provider in cvs-commons and cvs-exe like i done it for svn provider, but actual code won't change. I'll send a mail on the list when all will be ready. pure java svn provider is in sandbox and won't be release with 1.0 but in march when javasvn 1.0.4 will be release. I tested it this morning with a snapshot version of javasvn and TCK and it works fine. Emmanuel Brett Porter a écrit : Hi Emmanuel, It seems everyone is happy with this vote given the time and feedback so far. I'm going to review this tomorrow before adding a +1. I'm sorry I didn't dedicate time to it sooner. Is it possible that the code can be stabilised for 24 hours before actually cutting the release to give everyone a chance to run the tests locally? Thanks, Brett Emmanuel Venisse wrote: Hi everyone, I'd like to release 1.0 final of Maven-SCM. All APIs are stable since a long time and we didn't find any blocker issues since 1.0-beta-2 release. The list of issues fixed are : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10527fixfor=12346 We have now 3 issues that i will fix before the release. I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, Emmanuel
RE: [vote] Release Maven-SCM 1.0 final
I'll wrap up the remaining update/changelog issue tonight. -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Monday, February 27, 2006 7:00 AM To: scm-dev@maven.apache.org Subject: Re: [vote] Release Maven-SCM 1.0 final The code is stable (need to apply patch of Torbjorn for bazaar and Mike's patch for Perforce) I want to create a pure java provider for cvs (with only checkout command for now), this point require to split actual cvs provider in cvs-commons and cvs-exe like i done it for svn provider, but actual code won't change.
[jira] Created: (WAGONSSH-41) CLONED FOR CODE REVISION -SSH transport hangs on large transfers
CLONED FOR CODE REVISION -SSH transport hangs on large transfers Key: WAGONSSH-41 URL: http://jira.codehaus.org/browse/WAGONSSH-41 Project: wagon-ssh Type: Bug Versions: 1.0-alpha-6 Reporter: John Casey Assigned to: John Casey Fix For: 1.0-alpha-7 (1.0-alpha-6 needs to be released and a7 added as a new version) executeCommand( cd + path + ; unzip -o + zipFile.getName() + ; rm -f + zipFile.getName() ); This code hangs when the zip is large. The problem is that the process's outputstream is not read so eventually it fills its buffer and the process hangs. My fix? Add -q to unzip's arguments so that it does not spew tons of output. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (WAGONSSH-36) SSH transport hangs on large transfers
[ http://jira.codehaus.org/browse/WAGONSSH-36?page=all ] John Casey closed WAGONSSH-36: -- Resolution: Fixed fixed. Implemented proposed modification to the unzip command line. SSH transport hangs on large transfers -- Key: WAGONSSH-36 URL: http://jira.codehaus.org/browse/WAGONSSH-36 Project: wagon-ssh Type: Bug Versions: 1.0-alpha-6 Reporter: Mike Perham Assignee: John Casey Fix For: 1.0-alpha-7 (1.0-alpha-6 needs to be released and a7 added as a new version) executeCommand( cd + path + ; unzip -o + zipFile.getName() + ; rm -f + zipFile.getName() ); This code hangs when the zip is large. The problem is that the process's outputstream is not read so eventually it fills its buffer and the process hangs. My fix? Add -q to unzip's arguments so that it does not spew tons of output. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPASPECTJ-17) Update to aspectj 1.2.1
[ http://jira.codehaus.org/browse/MPASPECTJ-17?page=comments#action_59540 ] stephane bouchet commented on MPASPECTJ-17: --- Hi, I am using 3.3-SNAPSHOT version and i am not having this warning anymore. Maybe this is due to the 1.5.0 version of AspectJ ? I think you can Close this issue. Update to aspectj 1.2.1 --- Key: MPASPECTJ-17 URL: http://jira.codehaus.org/browse/MPASPECTJ-17 Project: maven-aspectj-plugin Type: Bug Versions: 3.2 Reporter: stephane bouchet Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 When using aspectj plugin with the last aspectjrt jar, there is a warning saying the expected version is 1.2. I am using the jar overriding mechanism, and my aspectjrt.jar version is 1.2.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPASPECTJ-17) Update to aspectj 1.2.1
[ http://jira.codehaus.org/browse/MPASPECTJ-17?page=all ] Lukas Theussl closed MPASPECTJ-17: -- Resolution: Fixed Update to aspectj 1.2.1 --- Key: MPASPECTJ-17 URL: http://jira.codehaus.org/browse/MPASPECTJ-17 Project: maven-aspectj-plugin Type: Bug Versions: 3.2 Reporter: stephane bouchet Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 When using aspectj plugin with the last aspectjrt jar, there is a warning saying the expected version is 1.2. I am using the jar overriding mechanism, and my aspectjrt.jar version is 1.2.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPASPECTJ-24) failonerror support
[ http://jira.codehaus.org/browse/MPASPECTJ-24?page=all ] Lukas Theussl closed MPASPECTJ-24: -- Resolution: Fixed failonerror support --- Key: MPASPECTJ-24 URL: http://jira.codehaus.org/browse/MPASPECTJ-24 Project: maven-aspectj-plugin Type: Wish Versions: 3.2 Reporter: Shinobu Kawai Yoshida Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 Attachments: MPASPECTJ-24-xdocs.patch, MPASPECTJ-24.patch It would be great if the plugin supported the failonerror attribute. cf. http://www.eclipse.org/aspectj/doc/released/devguide/antTasks-iajc.html#d0e1506 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPASPECTJ-19) Add messageHolderClass property
[ http://jira.codehaus.org/browse/MPASPECTJ-19?page=all ] Lukas Theussl closed MPASPECTJ-19: -- Resolution: Fixed Add messageHolderClass property --- Key: MPASPECTJ-19 URL: http://jira.codehaus.org/browse/MPASPECTJ-19 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: Matt Smith Fix For: 4.0 Attachments: MPASPECTJ-19-2.txt, MPASPECTJ-19.txt from the iajc ant task documentation: Specify a class to use as the message holder for the compile process. The entry must be a fully-qualified name of a class resolveable from the task classpath complying with the org.aspectj.bridge.IMessageHolder interface and having a public no-argument constructor. Adding the ability to use a messageHolderClass requires two changes: 1) add maven.aspectj.messageHolderClass property and associated attribute messageHolderClass 2) add maven.dependency.classpath to the ant task def Please see the attached 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNGECLIPSE-83) Hiding of runtime scope
[ http://jira.codehaus.org/browse/MNGECLIPSE-83?page=all ] Eugene Kuleshov closed MNGECLIPSE-83: - Resolution: Won't Fix Feel free to reopen if you'd have concrete examples. Hiding of runtime scope --- Key: MNGECLIPSE-83 URL: http://jira.codehaus.org/browse/MNGECLIPSE-83 Project: Maven 2.x Extension for Eclipse Type: Sub-task Reporter: Tuomas Kiviaho Assignee: Eugene Kuleshov The Maven2 dependencies library get's bloated since runtime scope is included as well. After all the plugin is providing build path support so compile and provided plus most likely test since Eclipse can't tell the difference (and system) should be enough. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSITE-95) Lack of leading / in the siteurl value strips off the first char in the submodules' name after being staged.
[ http://jira.codehaus.org/browse/MSITE-95?page=all ] Vincent Siveton closed MSITE-95: Assign To: Vincent Siveton Resolution: Won't Fix This problem comes from Wagon project in the PathUtils.basedir(String) method, around line 369. You should define a valid url. Lack of leading / in the siteurl value strips off the first char in the submodules' name after being staged. Key: MSITE-95 URL: http://jira.codehaus.org/browse/MSITE-95 Project: Maven 2.x Site Plugin Type: Bug Reporter: Prasad Kashyap Assignee: Vincent Siveton Priority: Critical Attachments: test-parent.zip site:stage goal. Multi-module project. When the dist..Mgmtsiteurl element is used, if the value does not have a leading slash, then the first char of every submodule under the final staging dir is stripped off. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPMD-17) Add report summary
Add report summary -- Key: MPMD-17 URL: http://jira.codehaus.org/browse/MPMD-17 Project: Maven 2.x Pmd Plugin Type: Improvement Reporter: Nick Giles Priority: Minor Add a summary of the PMD report to the top of the report page, in the same manner as Checkstyle. This should include information such as the total number of violations, number of violations by priority, and optionally number of violations by file and rule -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPMD-17) Add report summary
[ http://jira.codehaus.org/browse/MPMD-17?page=comments#action_59550 ] Nick Giles commented on MPMD-17: I'll look into making the changes necessary, but the main problem looks like being that the report is generated using a listener, not by returning and evaluating the Report object. Add report summary -- Key: MPMD-17 URL: http://jira.codehaus.org/browse/MPMD-17 Project: Maven 2.x Pmd Plugin Type: Improvement Reporter: Nick Giles Priority: Minor Add a summary of the PMD report to the top of the report page, in the same manner as Checkstyle. This should include information such as the total number of violations, number of violations by priority, and optionally number of violations by file and rule -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Wayne Fay wrote: However, the CDDL source code license ensures we **can** download the proper source, build/unit test, package, bundle with poms, and deploy **those** executables from the repo. This is an important difference. That's why I originally said: Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Any more comments? :-) That would be progress. One thing to check is how much difference is there between a JAR made that way and a released JAR. In an ideal world. apart from manifest data, there would be no difference. But if there is a difference, there is a risk that something wont work, and then who is left fielding the problems? Maybe the artifacts should be published with a groupId that indicates it was rebuilt or something, so that glassfish-rebuilt-jta-1.0.3.jar is clearly different from jta-1.0.3.jar. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MNG-2113) Could I please submit these plugins as a new mojo project, csharp?
[ http://jira.codehaus.org/browse/MNG-2113?page=all ] Brett Porter moved MOJO-304 to MNG-2113: Workflow: Maven New (was: Maven) Key: MNG-2113 (was: MOJO-304) Project: Maven 2 (was: Mojo) Could I please submit these plugins as a new mojo project, csharp? -- Key: MNG-2113 URL: http://jira.codehaus.org/browse/MNG-2113 Project: Maven 2 Type: New Feature Reporter: Chris Stevenson Attachments: csharp.zip Hi I'd like to submit this source as a new mojo project under the title csharp. It contains several plugins plus several custom builds of existing dotnet projects, which I have mavenised. Any problems please email me, chris.stevenson at gmail dot nospam com. Thanks, Chris -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2113) Could I please submit these plugins as a new mojo project, csharp?
[ http://jira.codehaus.org/browse/MNG-2113?page=all ] Brett Porter updated MNG-2113: -- Component: Sandbox Could I please submit these plugins as a new mojo project, csharp? -- Key: MNG-2113 URL: http://jira.codehaus.org/browse/MNG-2113 Project: Maven 2 Type: New Feature Components: Sandbox Reporter: Chris Stevenson Attachments: csharp.zip Hi I'd like to submit this source as a new mojo project under the title csharp. It contains several plugins plus several custom builds of existing dotnet projects, which I have mavenised. Any problems please email me, chris.stevenson at gmail dot nospam com. Thanks, Chris -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
This is exactly why I said we might not want to distribute as javax.*. I am definitely concerned about ongoing maintenance etc. Ideally we'd get the Glassfish project themselves to build the Jars and submit to Maven repo. They are using Ant and Maven1 for their build process, so they are familiar with the Maven repo concept. I will compile the sources, compare each to the binaries distributed by Glassfish, and report back later today... Wayne On 2/27/06, Steve Loughran [EMAIL PROTECTED] wrote: Wayne Fay wrote: However, the CDDL source code license ensures we **can** download the proper source, build/unit test, package, bundle with poms, and deploy **those** executables from the repo. This is an important difference. That's why I originally said: Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Any more comments? :-) That would be progress. One thing to check is how much difference is there between a JAR made that way and a released JAR. In an ideal world. apart from manifest data, there would be no difference. But if there is a difference, there is a risk that something wont work, and then who is left fielding the problems? Maybe the artifacts should be published with a groupId that indicates it was rebuilt or something, so that glassfish-rebuilt-jta-1.0.3.jar is clearly different from jta-1.0.3.jar. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Result: [vote] Release Maven 2.0.3
Binding: 9 (John, Jason, Vincent, Brett, Lukas, Emmanuel, Kenney, Arnaud, Carlos) Non-Binding: 6 (Brian, Fabrizio, Mike, Vincent S, Stephane, Allan) HOWEVER, there has been quite a bit of talk about some issues that should be included in this release. For that reason, I'm going to work on them for a few more days, and call another vote. I'd like to have as many interested parties on board as possible, especially since all of the dissenters to this vote have brought up good points. :-) From the vote thread, here are the issues and their respective status: MNG-1317 - Emmanuel has no problem on WinXP, but this has not been verified or marked fixed. Can anyone help us verify/fix this? MNG-1415 - I haven't had time to look at this, beyond the proposed fix in the issue itself...which seems sane to me. I just want to be sure that (a) I can duplicate the issue on my linux box, and (b) the fix actually works cleanly. I don't anticipate problems here, but haven't had time to integrate that fix yet. WAGONSSH-36 This is fixed in SVN, and will be released in wagon-ssh-1.0-alpha-7, which will be included in Maven 2.0.3. The reason I haven't released this new version of wagon-ssh yet is that we're still looking at a possible fix for WAGONSSH-40. WAGONSSH-40 Not sure where this got brought into the release discussion (probably on IRC), but this is another of those important bugs on SSH, and we should probably try to get the fix into 2.0.3 if we can (particularly since SSH is the de facto standard for doing Maven deployments right now). I haven't had time to look at this one either, but plan to take a look tonight if I can. If anyone else has some time that they could use to document the steps to reproduce, or even better, submit a fix, I'd be grateful for the help. (no JIRA) Setting plugin parameters on the command line I spent a good deal of time trying to reproduce this on Friday, with Brian Fox's help, and our conclusion was that this was not a bug in Maven. If someone can submit a test case we can use - filed in a jira issue, preferably - then I'll consider this a blocker for 2.0.3. Otherwise, I'm going to consider this some sort of user-environment problem and move on. MNG-2054 MNG-2068 As Brian mentioned, he uncovered two other jira issues which were fixed for 2.0.3, but which hadn't been marked as fixed. I've incorporated two new integration tests - it0096 and it0097, respectively - to test these cases. Thanks for doing the legwork on that, Brian. So, that's the status as of this morning. I'm going to try to set aside some time tonight and tomorrow to get these outstanding issues fixed if I can, and will probably call another vote on Thursday or Friday. I'd like to get this release out early next week, since it's going to be holding up a release of Continuum soon. Thanks, John John Casey wrote: Hi, I think it's time to release Maven 2.0.3. This release will incorporate 21 resolved JIRA issues, including some critical fixes for Continuum and users of the embedder. The full listing of fixes can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=12107 The remaining open issues are reminders for the site publishing process which should accompany this binary release. If you're interested, you can take the current release candidate for a test drive. The RC tarball is at: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-756) swift-parser is a java general library to parse SWIFT messages
swift-parser is a java general library to parse SWIFT messages -- Key: MAVENUPLOAD-756 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-756 Project: maven-upload-requests Type: Task Reporter: Miguel Griffa -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-349) Hibernate 3.1.2 transaction API dependency has a wrong scope
Hibernate 3.1.2 transaction API dependency has a wrong scope Key: MEV-349 URL: http://jira.codehaus.org/browse/MEV-349 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Alexandre Poitras Hibernate 3.1.2 transaction API dependency (javax.transaction.jta) has no scope defined. It should be provided since it is an official J2EE api and I don't want it to be included in my archive. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Here's the complete list of javax apis included with Glassfish, based on a 233mb source code CVS checkout... javax.activation javax.servlet.jsp.jstl javax.resource (connector) javax.enterprise.deploy (deployment) javax.ejb javax.security.jacc javax.jms javax.mail javax.management.j2ee javax.persistence javax.servlet.jsp (jsr-152, JSP 2.0) javax.servlet.http (jsr-154, Servlet 2.4) javax.servlet.jsp (jsr-245, JSP 2.1) javax.transaction Obviously, verifying all the class files from the binary distribution vs what I compile out of CVS will be a bit of a chore. Don't suppose anyone has a method for comparing the contents of two file system trees? I can extract the class files from their distribution, build from source myself, and compare the file sizes etc assuming I can find a simple comparison process. Wayne On 2/27/06, Wayne Fay [EMAIL PROTECTED] wrote: This is exactly why I said we might not want to distribute as javax.*. I am definitely concerned about ongoing maintenance etc. Ideally we'd get the Glassfish project themselves to build the Jars and submit to Maven repo. They are using Ant and Maven1 for their build process, so they are familiar with the Maven repo concept. I will compile the sources, compare each to the binaries distributed by Glassfish, and report back later today... Wayne On 2/27/06, Steve Loughran [EMAIL PROTECTED] wrote: Wayne Fay wrote: However, the CDDL source code license ensures we **can** download the proper source, build/unit test, package, bundle with poms, and deploy **those** executables from the repo. This is an important difference. That's why I originally said: Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Any more comments? :-) That would be progress. One thing to check is how much difference is there between a JAR made that way and a released JAR. In an ideal world. apart from manifest data, there would be no difference. But if there is a difference, there is a risk that something wont work, and then who is left fielding the problems? Maybe the artifacts should be published with a groupId that indicates it was rebuilt or something, so that glassfish-rebuilt-jta-1.0.3.jar is clearly different from jta-1.0.3.jar. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-29) Plug-In does not run behind Proxy/Firewall (where M2 itself does)
[ http://jira.codehaus.org/browse/MNGECLIPSE-29?page=comments#action_59562 ] Eric commented on MNGECLIPSE-29: Hello, I am also seeing this issue. It would seem that running M2 from Eclipse my settings.xml is not being parsed from my Windows home directory. It is parsed correctly if I run mvn from the command line in Cygwin. This is potentially a wonderful product - we're all hoping to see this fixed soon. You can let me know if there is anything I can do to help. Plug-In does not run behind Proxy/Firewall (where M2 itself does) - Key: MNGECLIPSE-29 URL: http://jira.codehaus.org/browse/MNGECLIPSE-29 Project: Maven 2.x Extension for Eclipse Type: Bug Versions: 0.0.3 Environment: Windows (probably ANY behind a Proxy or Firewall) Reporter: Werner Keil Assignee: Dmitri Maximovich Priority: Minor Fix For: 1.0.0 Attachments: pom.xml Time Spent: 30 minutes Remaining: 0 minutes While Maven 2 on its own runs the same goal (test) from the command line without errors the Plug-in for Eclipse fails trying to update itself or some other dependency: [DEBUG] Found 0 components to load on start [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and Settings\username\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level settings from: 'C:\Documents and Settings\username\workspace\32\mtest\conf\settings.xml' [DEBUG] Building Maven user-level settings from: 'C:\Documents and Settings\username\.m2\settings.xml' [DEBUG] mtest:mtest:jar:1.0.1-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1 (selected for compile) [INFO] [INFO] Building mtest [INFO]task-segment: [test] [INFO] [DEBUG] maven-resources-plugin: resolved to version 2.1 from repository central [DEBUG] Found 0 components to load on start [DEBUG] maven-compiler-plugin: resolved to version 2.0 from repository central [DEBUG] Found 0 components to load on start [DEBUG] maven-surefire-plugin: resolved to version 2.0 from repository central [DEBUG] Found 0 components to load on start [DEBUG] org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.1 (selected for runtime) [DEBUG] commons-io:commons-io:jar:1.0 (selected for runtime) [DEBUG] junit:junit:jar:3.8.1 (selected for runtime) [DEBUG] Skipping disabled repository snapshots [DEBUG] Trying repository central org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for execution of 'resources:resources'. at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:554) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:508) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:494) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:307) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:439) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:383) at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:71) Caused by: org.apache.maven.plugin.PluginConfigurationException: Error configuring: org.apache.maven.plugins:maven-resources-plugin. Reason: Cannot resolve plugin dependencies at org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:650) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:541) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:394) ... 8 more Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: Error transferring file org.apache.maven:maven-model:2.0:jar from the specified remote repositories: snapshots (http://snapshots.maven.codehaus.org/maven2), central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:150) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:64) at org.apache.maven.plugin.DefaultPluginManager.resolveCoreArtifacts(DefaultPluginManager.java:682) at org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:639) ... 10 more Caused
[jira] Assigned: (WAGONSSH-40) sftp:// repository crashes build on failed download
[ http://jira.codehaus.org/browse/WAGONSSH-40?page=all ] John Casey reassigned WAGONSSH-40: -- Assign To: John Casey sftp:// repository crashes build on failed download --- Key: WAGONSSH-40 URL: http://jira.codehaus.org/browse/WAGONSSH-40 Project: wagon-ssh Type: Bug Versions: 1.0-alpha-6 Reporter: Stephen Duncan Jr Assignee: John Casey When using sftp:// for an internal repository, when a download fails, an error is thrown, and the build quits, even though the file is a) available in the central repository, or b) optional (downloaidng sources using Eclipse plugin). Previously, when using scp with another machine, this never happened. Here's the error on downloading: $ mvn install [INFO] Scanning for projects... [INFO] [INFO] Building Trouble Tickets Portlet [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: sftp://cdciecm.je.jfcom.mil/var/www/maven2/org/springframework/spring-core/1.2.6/spring-core-1.2.6.pom No such file at com.jcraft.jsch.ChannelSftp.throwStatusError(Unknown Source) at com.jcraft.jsch.ChannelSftp.cd(Unknown Source) at org.apache.maven.wagon.providers.ssh.SftpWagon.getIfNewer(SftpWagon.java:275) at org.apache.maven.wagon.providers.ssh.SftpWagon.get(SftpWagon.java:335) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:369) 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:3 86) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:351) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:282) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:309) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:2 23) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:2 11) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:1 82) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1120) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:369) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47 2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.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(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)
[jira] Commented: (WAGONSSH-40) sftp:// repository crashes build on failed download
[ http://jira.codehaus.org/browse/WAGONSSH-40?page=comments#action_59563 ] John Casey commented on WAGONSSH-40: it seems to happen when the directory doesn't exist, and we try to CD to it. I'm looking into the jsch api to see whether we can LS that directory first, or something... sftp:// repository crashes build on failed download --- Key: WAGONSSH-40 URL: http://jira.codehaus.org/browse/WAGONSSH-40 Project: wagon-ssh Type: Bug Versions: 1.0-alpha-6 Reporter: Stephen Duncan Jr Assignee: John Casey When using sftp:// for an internal repository, when a download fails, an error is thrown, and the build quits, even though the file is a) available in the central repository, or b) optional (downloaidng sources using Eclipse plugin). Previously, when using scp with another machine, this never happened. Here's the error on downloading: $ mvn install [INFO] Scanning for projects... [INFO] [INFO] Building Trouble Tickets Portlet [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: sftp://cdciecm.je.jfcom.mil/var/www/maven2/org/springframework/spring-core/1.2.6/spring-core-1.2.6.pom No such file at com.jcraft.jsch.ChannelSftp.throwStatusError(Unknown Source) at com.jcraft.jsch.ChannelSftp.cd(Unknown Source) at org.apache.maven.wagon.providers.ssh.SftpWagon.getIfNewer(SftpWagon.java:275) at org.apache.maven.wagon.providers.ssh.SftpWagon.get(SftpWagon.java:335) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:369) 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:3 86) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:351) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:282) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:309) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:2 23) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:2 11) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:1 82) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1120) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:369) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47 2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.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(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at
[jira] Closed: (MEV-348) javax.comm API - upload in iBiblio
[ http://jira.codehaus.org/browse/MEV-348?page=all ] Carlos Sanchez closed MEV-348: -- Assign To: Carlos Sanchez Resolution: Fixed javax.comm API - upload in iBiblio -- Key: MEV-348 URL: http://jira.codehaus.org/browse/MEV-348 Project: Maven Evangelism Type: Wish Components: Missing POM Reporter: Subhash Chandran Assignee: Carlos Sanchez Attachments: javax-comm-3.0u1.pom Request for - the Java Communications 3.0 API to be part of the iBiblio repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-349) Hibernate 3.1.2 transaction API dependency has a wrong scope
[ http://jira.codehaus.org/browse/MEV-349?page=all ] Carlos Sanchez closed MEV-349: -- Assign To: Carlos Sanchez Resolution: Duplicate Dupe of MEV-320 Hibernate 3.1.2 transaction API dependency has a wrong scope Key: MEV-349 URL: http://jira.codehaus.org/browse/MEV-349 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Alexandre Poitras Assignee: Carlos Sanchez Hibernate 3.1.2 transaction API dependency (javax.transaction.jta) has no scope defined. It should be provided since it is an official J2EE api and I don't want it to be included in my archive. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MNG-2114) Could I please submit these plugins as a new mojo project, csharp?
[ http://jira.codehaus.org/browse/MNG-2114?page=all ] Trygve Laugstol moved MOJO-316 to MNG-2114: --- Component: (was: sandbox) Plugin Requests Workflow: Maven New (was: Maven) Key: MNG-2114 (was: MOJO-316) Project: Maven 2 (was: Mojo) Could I please submit these plugins as a new mojo project, csharp? -- Key: MNG-2114 URL: http://jira.codehaus.org/browse/MNG-2114 Project: Maven 2 Type: New Feature Components: Plugin Requests Reporter: Chris Stevenson Assignee: Brett Porter Attachments: csharp.zip Hi I'd like to submit this source as a new mojo project under the title csharp. It contains several plugins plus several custom builds of existing dotnet projects, which I have mavenised. Any problems please email me, chris.stevenson at gmail dot nospam com. Thanks, Chris -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-757) add jipCam to Maven2 central repo
add jipCam to Maven2 central repo - Key: MAVENUPLOAD-757 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-757 Project: maven-upload-requests Type: Task Reporter: Jason Thrasher http://jipcam.sourceforge.net/downloads/jipcam-0.9-ALPHA-SNAPSHOT-bundle.jar http://jipcam.sourceforge.net http://jipcam.sourceforge.net/team-list.html jipCam provides a Java Media Framework based datasource to read from different Internet Protocol based video cameras. A computer with Java, and the Java Media Framework, can install jipCam as a JMF protocol handler to allow an IP-based camera's video to become available for processing in JMF. This library is intended for use by developers seeking to build applications using IP-based video cameras on a Java platform. Maven rocks! Please upload! thanks, Jason -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPDASHBOARD-36) Add three jelly scripts JavaNCSS aggregators
Add three jelly scripts JavaNCSS aggregators Key: MPDASHBOARD-36 URL: http://jira.codehaus.org/browse/MPDASHBOARD-36 Project: maven-dashboard-plugin Type: New Feature Reporter: Miguel Fernandez Attachments: javancssccn.zip JavaNCSS aggregator: Extracts the average of CCN from JavaNCSS raw file. JavaNCSS aggregator: Calculate the pass rate of functions with a ccn less than 10 of CCN from JavaNCSS raw file. JavaNCSS aggregator: Extracts the number of functions with a ccn greater than 10 of CNN from JavaNCSS raw 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result: [vote] Release Maven 2.0.3
I'll try to test the patch on WinXP tomorrow for MNG-1317, but i'll can't test it on windows 2000 Emmanuel John Casey a écrit : Binding: 9 (John, Jason, Vincent, Brett, Lukas, Emmanuel, Kenney, Arnaud, Carlos) Non-Binding: 6 (Brian, Fabrizio, Mike, Vincent S, Stephane, Allan) HOWEVER, there has been quite a bit of talk about some issues that should be included in this release. For that reason, I'm going to work on them for a few more days, and call another vote. I'd like to have as many interested parties on board as possible, especially since all of the dissenters to this vote have brought up good points. :-) From the vote thread, here are the issues and their respective status: MNG-1317 - Emmanuel has no problem on WinXP, but this has not been verified or marked fixed. Can anyone help us verify/fix this? MNG-1415 - I haven't had time to look at this, beyond the proposed fix in the issue itself...which seems sane to me. I just want to be sure that (a) I can duplicate the issue on my linux box, and (b) the fix actually works cleanly. I don't anticipate problems here, but haven't had time to integrate that fix yet. WAGONSSH-36 This is fixed in SVN, and will be released in wagon-ssh-1.0-alpha-7, which will be included in Maven 2.0.3. The reason I haven't released this new version of wagon-ssh yet is that we're still looking at a possible fix for WAGONSSH-40. WAGONSSH-40 Not sure where this got brought into the release discussion (probably on IRC), but this is another of those important bugs on SSH, and we should probably try to get the fix into 2.0.3 if we can (particularly since SSH is the de facto standard for doing Maven deployments right now). I haven't had time to look at this one either, but plan to take a look tonight if I can. If anyone else has some time that they could use to document the steps to reproduce, or even better, submit a fix, I'd be grateful for the help. (no JIRA) Setting plugin parameters on the command line I spent a good deal of time trying to reproduce this on Friday, with Brian Fox's help, and our conclusion was that this was not a bug in Maven. If someone can submit a test case we can use - filed in a jira issue, preferably - then I'll consider this a blocker for 2.0.3. Otherwise, I'm going to consider this some sort of user-environment problem and move on. MNG-2054 MNG-2068 As Brian mentioned, he uncovered two other jira issues which were fixed for 2.0.3, but which hadn't been marked as fixed. I've incorporated two new integration tests - it0096 and it0097, respectively - to test these cases. Thanks for doing the legwork on that, Brian. So, that's the status as of this morning. I'm going to try to set aside some time tonight and tomorrow to get these outstanding issues fixed if I can, and will probably call another vote on Thursday or Friday. I'd like to get this release out early next week, since it's going to be holding up a release of Continuum soon. Thanks, John John Casey wrote: Hi, I think it's time to release Maven 2.0.3. This release will incorporate 21 resolved JIRA issues, including some critical fixes for Continuum and users of the embedder. The full listing of fixes can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=12107 The remaining open issues are reminders for the site publishing process which should accompany this binary release. If you're interested, you can take the current release candidate for a test drive. The RC tarball is at: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MRELEASE-81) The site hasn't been republished since October 16th
The site hasn't been republished since October 16th --- Key: MRELEASE-81 URL: http://jira.codehaus.org/browse/MRELEASE-81 Project: Maven 2.x Release Plugin Type: Bug Versions: 2.0-beta-4 Reporter: Alexandre Poitras Priority: Trivial Fix For: 2.0-beta-3 The site hasn't been republished since October 16th so all the scm url's are wrong. People who want the last version will have a hard time figuring where are the sources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MRELEASE-81) The site hasn't been republished since October 16th
[ http://jira.codehaus.org/browse/MRELEASE-81?page=comments#action_59567 ] Alexandre Poitras commented on MRELEASE-81: --- Forget the fix version, my mistake. The site hasn't been republished since October 16th --- Key: MRELEASE-81 URL: http://jira.codehaus.org/browse/MRELEASE-81 Project: Maven 2.x Release Plugin Type: Bug Versions: 2.0-beta-4 Reporter: Alexandre Poitras Priority: Trivial Fix For: 2.0-beta-3 The site hasn't been republished since October 16th so all the scm url's are wrong. People who want the last version will have a hard time figuring where are the sources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-758) Jsch release 0.1.25 is available
Jsch release 0.1.25 is available Key: MAVENUPLOAD-758 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-758 Project: maven-upload-requests Type: Bug Reporter: Wayne Fay The latest build of Jsch in the Maven2 repo is 0.1.21. The Jsch project has released a few newer builds since then. Their latest is 0.1.25. http://www.ibiblio.org/maven2/jsch/jsch/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2009) Add new integrationTestSourceDirectory element in the POM model
[ http://jira.codehaus.org/browse/MNG-2009?page=comments#action_59571 ] Jochen Wiedmann commented on MNG-2009: -- Wouldn't it be better to finally have something like source directorysrc/main/java/directory typemain/type !-- May be test, or integration-test -- /source I find this easier to handle and to enhance than adding new tags all the time. Add new integrationTestSourceDirectory element in the POM model - Key: MNG-2009 URL: http://jira.codehaus.org/browse/MNG-2009 Project: Maven 2 Type: Task Components: POM Reporter: Vincent Massol This is to support the new surefire:integration-test mojo (MSUREFIRE-50). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSITE-96) SiteMojo generate an unclosed div class=section tag.
SiteMojo generate an unclosed div class=section tag. Key: MSITE-96 URL: http://jira.codehaus.org/browse/MSITE-96 Project: Maven 2.x Site Plugin Type: Bug Reporter: Alexandre Poitras Priority: Minor SiteMojo generate an unclosed div class=section tag. Yann Le Du seems to have located the problem, I'll copy his answer here : I think your problem is with the About page (index.html). This page is generated in maven-site-plugin. In SiteMojo.java [2] , generateIndexPage(), there is indeed a div class=section generated by section1() that is not closed with section1_() . The generated html is not valid xhtml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-758) Jsch release 0.1.25 is available
[ http://jira.codehaus.org/browse/MAVENUPLOAD-758?page=comments#action_59573 ] Carlos Sanchez commented on MAVENUPLOAD-758: Please read http://maven.apache.org/guides/mini/guide-ibiblio-upload.html Jsch release 0.1.25 is available Key: MAVENUPLOAD-758 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-758 Project: maven-upload-requests Type: Bug Reporter: Wayne Fay The latest build of Jsch in the Maven2 repo is 0.1.21. The Jsch project has released a few newer builds since then. Their latest is 0.1.25. http://www.ibiblio.org/maven2/jsch/jsch/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-757) add jipCam to Maven2 central repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-757?page=all ] Carlos Sanchez closed MAVENUPLOAD-757: -- Assign To: Carlos Sanchez Resolution: Won't Fix We don't upload snapshots to iBiblio add jipCam to Maven2 central repo - Key: MAVENUPLOAD-757 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-757 Project: maven-upload-requests Type: Task Reporter: Jason Thrasher Assignee: Carlos Sanchez http://jipcam.sourceforge.net/downloads/jipcam-0.9-ALPHA-SNAPSHOT-bundle.jar http://jipcam.sourceforge.net http://jipcam.sourceforge.net/team-list.html jipCam provides a Java Media Framework based datasource to read from different Internet Protocol based video cameras. A computer with Java, and the Java Media Framework, can install jipCam as a JMF protocol handler to allow an IP-based camera's video to become available for processing in JMF. This library is intended for use by developers seeking to build applications using IP-based video cameras on a Java platform. Maven rocks! Please upload! thanks, Jason -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-756) swift-parser is a java general library to parse SWIFT messages
[ http://jira.codehaus.org/browse/MAVENUPLOAD-756?page=comments#action_59577 ] Carlos Sanchez commented on MAVENUPLOAD-756: Please read groupId policies http://maven.apache.org/guides/mini/guide-ibiblio-upload.html swift-parser is a java general library to parse SWIFT messages -- Key: MAVENUPLOAD-756 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-756 Project: maven-upload-requests Type: Task Reporter: Miguel Griffa -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MEV-350) ehcache pom for ehcache 1.2 beta 4 broken
[ http://jira.codehaus.org/browse/MEV-350?page=all ] Carlos Sanchez moved MAVENUPLOAD-755 to MEV-350: Group ID: ehcache Bundle URL: (was: http://notrequired) Artifact ID: ehcache Version: 1.2beta4 Key: MEV-350 (was: MAVENUPLOAD-755) Project: Maven Evangelism (was: maven-upload-requests) ehcache pom for ehcache 1.2 beta 4 broken - Key: MEV-350 URL: http://jira.codehaus.org/browse/MEV-350 Project: Maven Evangelism Type: Task Reporter: Greg Luck Attachments: ehcache-1.2beta4.pom The pom for ehcache-1.2beta4 is broken. Trying to use it gives: [WARNING] POM for 'ehcache:ehcache:pom:1.2beta4' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: Duplicated tag: 'groupId' (position: START_TAG seen ...dependency\n groupId... @20:16) A corrected one is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-350) ehcache pom for ehcache 1.2 beta 4 broken
[ http://jira.codehaus.org/browse/MEV-350?page=all ] Carlos Sanchez closed MEV-350: -- Assign To: Carlos Sanchez Resolution: Fixed ehcache pom for ehcache 1.2 beta 4 broken - Key: MEV-350 URL: http://jira.codehaus.org/browse/MEV-350 Project: Maven Evangelism Type: Task Reporter: Greg Luck Assignee: Carlos Sanchez Attachments: ehcache-1.2beta4.pom The pom for ehcache-1.2beta4 is broken. Trying to use it gives: [WARNING] POM for 'ehcache:ehcache:pom:1.2beta4' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: Duplicated tag: 'groupId' (position: START_TAG seen ...dependency\n groupId... @20:16) A corrected one is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-754) new version to upload, groupId=org.tango-project artifactId=tango-icon-theme version=0.7.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-754?page=all ] Carlos Sanchez closed MAVENUPLOAD-754: -- Assign To: Carlos Sanchez Resolution: Fixed new version to upload, groupId=org.tango-project artifactId=tango-icon-theme version=0.7.0 -- Key: MAVENUPLOAD-754 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-754 Project: maven-upload-requests Type: Task Reporter: Michael Heuer Assignee: Carlos Sanchez The Tango Desktop Project exists to create a consistent user experience for free and Open Source software with graphical user interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MAVENUPLOAD-757) add jipCam to Maven2 central repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-757?page=all ] Jason Thrasher reopened MAVENUPLOAD-757: That makes sense. Here's the 0.9.0 release bundle, non-snapshot: http://jipcam.sourceforge.net/downloads/jipcam-0.9.0-bundle.jar I'm not sure of your tracker ettiquite, so I'm just reopening the issue. Let me know if I should create a new one. add jipCam to Maven2 central repo - Key: MAVENUPLOAD-757 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-757 Project: maven-upload-requests Type: Task Reporter: Jason Thrasher Assignee: Carlos Sanchez http://jipcam.sourceforge.net/downloads/jipcam-0.9-ALPHA-SNAPSHOT-bundle.jar http://jipcam.sourceforge.net http://jipcam.sourceforge.net/team-list.html jipCam provides a Java Media Framework based datasource to read from different Internet Protocol based video cameras. A computer with Java, and the Java Media Framework, can install jipCam as a JMF protocol handler to allow an IP-based camera's video to become available for processing in JMF. This library is intended for use by developers seeking to build applications using IP-based video cameras on a Java platform. Maven rocks! Please upload! thanks, Jason -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-758) Jsch release 0.1.25 is available
[ http://jira.codehaus.org/browse/MAVENUPLOAD-758?page=all ] Wayne Fay updated MAVENUPLOAD-758: -- Attachment: jsch-0.1.25.jar Jsch release 0.1.25 is available Key: MAVENUPLOAD-758 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-758 Project: maven-upload-requests Type: Bug Reporter: Wayne Fay Attachments: jsch-0.1.25.jar The latest build of Jsch in the Maven2 repo is 0.1.21. The Jsch project has released a few newer builds since then. Their latest is 0.1.25. http://www.ibiblio.org/maven2/jsch/jsch/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-726) Please upload Canoo WebTest Release 1168
[ http://jira.codehaus.org/browse/MAVENUPLOAD-726?page=all ] Carlos Sanchez closed MAVENUPLOAD-726: -- Assign To: Carlos Sanchez Resolution: Fixed Please upload Canoo WebTest Release 1168 Key: MAVENUPLOAD-726 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-726 Project: maven-upload-requests Type: Task Reporter: Matt Raible Assignee: Carlos Sanchez Please upload latest version of Canoo WebTest. This depends on a 20060131 build of HtmlUnit, which I've created a bundle for as well: http://static.raibledesigns.com/downloads/htmlunit-1.8-SNAPSHOT-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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-758) Jsch release 0.1.25 is available
[ http://jira.codehaus.org/browse/MAVENUPLOAD-758?page=all ] Wayne Fay updated MAVENUPLOAD-758: -- Attachment: jsch-0.1.25.pom Jsch release 0.1.25 is available Key: MAVENUPLOAD-758 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-758 Project: maven-upload-requests Type: Bug Reporter: Wayne Fay Attachments: jsch-0.1.25.jar, jsch-0.1.25.pom The latest build of Jsch in the Maven2 repo is 0.1.21. The Jsch project has released a few newer builds since then. Their latest is 0.1.25. http://www.ibiblio.org/maven2/jsch/jsch/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-748) Upload request for ldaptemplate
[ http://jira.codehaus.org/browse/MAVENUPLOAD-748?page=all ] Carlos Sanchez closed MAVENUPLOAD-748: -- Assign To: Carlos Sanchez Resolution: Fixed Upload request for ldaptemplate --- Key: MAVENUPLOAD-748 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-748 Project: maven-upload-requests Type: Task Reporter: Alexandre Poitras Assignee: Carlos Sanchez Attachments: ldaptemplate-1.0-rc1-bundle.jar attached http://sourceforge.net/projects/ldaptemplate/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-758) Jsch release 0.1.25 is available
[ http://jira.codehaus.org/browse/MAVENUPLOAD-758?page=comments#action_59583 ] Wayne Fay commented on MAVENUPLOAD-758: --- Sorry about that Carlos. I have packaged and attached the required files. I chose not to include the sources, as that resulted in a doubling of the Jsch jar size. Just didn't seem worth it to me. Let me know if you need anything more. Jsch release 0.1.25 is available Key: MAVENUPLOAD-758 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-758 Project: maven-upload-requests Type: Bug Reporter: Wayne Fay Attachments: jsch-0.1.25.jar, jsch-0.1.25.pom The latest build of Jsch in the Maven2 repo is 0.1.21. The Jsch project has released a few newer builds since then. Their latest is 0.1.25. http://www.ibiblio.org/maven2/jsch/jsch/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-749) Please upload DWR-1.1-rc1 to the global Maven 2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-749?page=comments#action_59585 ] Carlos Sanchez commented on MAVENUPLOAD-749: where is the upload bundle? Please upload DWR-1.1-rc1 to the global Maven 2 repo Key: MAVENUPLOAD-749 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-749 Project: maven-upload-requests Type: Task Reporter: Julien Dubois This is the latest version of DWR, thank you for uploading it. In this release : - We release the sources as well as the binaries (mvn source:jar repository:bundle-create) - We greatly improved dependency management, by using the optional/ tag -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Result: [vote] Release Maven 2.0.3
Update: WAGONSSH-40 is fixed, and wagon-ssh-1.0-alpha-7 has been released. Also, the pom.xml for Maven 2.0.3-SNAPSHOT is updated to use this new version. Also, would it be possible for someone with Win2K to look at MNG-1317? I'm going to be trying to knock out MNG-1415 next. Thanks, John John Casey wrote: Binding: 9 (John, Jason, Vincent, Brett, Lukas, Emmanuel, Kenney, Arnaud, Carlos) Non-Binding: 6 (Brian, Fabrizio, Mike, Vincent S, Stephane, Allan) HOWEVER, there has been quite a bit of talk about some issues that should be included in this release. For that reason, I'm going to work on them for a few more days, and call another vote. I'd like to have as many interested parties on board as possible, especially since all of the dissenters to this vote have brought up good points. :-) From the vote thread, here are the issues and their respective status: MNG-1317 - Emmanuel has no problem on WinXP, but this has not been verified or marked fixed. Can anyone help us verify/fix this? MNG-1415 - I haven't had time to look at this, beyond the proposed fix in the issue itself...which seems sane to me. I just want to be sure that (a) I can duplicate the issue on my linux box, and (b) the fix actually works cleanly. I don't anticipate problems here, but haven't had time to integrate that fix yet. WAGONSSH-36 This is fixed in SVN, and will be released in wagon-ssh-1.0-alpha-7, which will be included in Maven 2.0.3. The reason I haven't released this new version of wagon-ssh yet is that we're still looking at a possible fix for WAGONSSH-40. WAGONSSH-40 Not sure where this got brought into the release discussion (probably on IRC), but this is another of those important bugs on SSH, and we should probably try to get the fix into 2.0.3 if we can (particularly since SSH is the de facto standard for doing Maven deployments right now). I haven't had time to look at this one either, but plan to take a look tonight if I can. If anyone else has some time that they could use to document the steps to reproduce, or even better, submit a fix, I'd be grateful for the help. (no JIRA) Setting plugin parameters on the command line I spent a good deal of time trying to reproduce this on Friday, with Brian Fox's help, and our conclusion was that this was not a bug in Maven. If someone can submit a test case we can use - filed in a jira issue, preferably - then I'll consider this a blocker for 2.0.3. Otherwise, I'm going to consider this some sort of user-environment problem and move on. MNG-2054 MNG-2068 As Brian mentioned, he uncovered two other jira issues which were fixed for 2.0.3, but which hadn't been marked as fixed. I've incorporated two new integration tests - it0096 and it0097, respectively - to test these cases. Thanks for doing the legwork on that, Brian. So, that's the status as of this morning. I'm going to try to set aside some time tonight and tomorrow to get these outstanding issues fixed if I can, and will probably call another vote on Thursday or Friday. I'd like to get this release out early next week, since it's going to be holding up a release of Continuum soon. Thanks, John John Casey wrote: Hi, I think it's time to release Maven 2.0.3. This release will incorporate 21 resolved JIRA issues, including some critical fixes for Continuum and users of the embedder. The full listing of fixes can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=12107 The remaining open issues are reminders for the site publishing process which should accompany this binary release. If you're interested, you can take the current release candidate for a test drive. The RC tarball is at: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2115) Anchors Broken on Getting Started Guide
Anchors Broken on Getting Started Guide --- Key: MNG-2115 URL: http://jira.codehaus.org/browse/MNG-2115 Project: Maven 2 Type: Bug Components: Documentation: Guides Versions: documentation Reporter: Stephen Duncan Jr Priority: Minor On the Maven Getting Started Guide: http://maven.apache.org/guides/getting-started/index.html the links don't link to the sections properly. The anchors for the section have an extra # character. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Mon Feb 27 23:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060227.23.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060227.23.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2116) Add strict mode, to avoid any stubbing, dummying, etc. activities to account for missing data.
[ http://jira.codehaus.org/browse/MNG-2116?page=all ] John Casey updated MNG-2116: Fix Version: 2.1 Add strict mode, to avoid any stubbing, dummying, etc. activities to account for missing data. -- Key: MNG-2116 URL: http://jira.codehaus.org/browse/MNG-2116 Project: Maven 2 Type: New Feature Components: General Versions: 2.0.2 Reporter: John Casey Priority: Minor Fix For: 2.1 Currently, Maven will create a stub POM when it cannot find one on the remote repository. However, there are cases where we need to have the ability to verify that all the components of an application or some other type of build are present. Therefore, we need a strict mode for Maven, which will suppress any stubbing activities like this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSITE-96) SiteMojo generate an unclosed div class=section tag.
[ http://jira.codehaus.org/browse/MSITE-96?page=all ] Vincent Siveton closed MSITE-96: Assign To: Vincent Siveton Resolution: Fixed Corrected in SVN SiteMojo generate an unclosed div class=section tag. Key: MSITE-96 URL: http://jira.codehaus.org/browse/MSITE-96 Project: Maven 2.x Site Plugin Type: Bug Reporter: Alexandre Poitras Assignee: Vincent Siveton Priority: Minor SiteMojo generate an unclosed div class=section tag. Yann Le Du seems to have located the problem, I'll copy his answer here : I think your problem is with the About page (index.html). This page is generated in maven-site-plugin. In SiteMojo.java [2] , generateIndexPage(), there is indeed a div class=section generated by section1() that is not closed with section1_() . The generated html is not valid xhtml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2116) Add strict mode, to avoid any stubbing, dummying, etc. activities to account for missing data.
Add strict mode, to avoid any stubbing, dummying, etc. activities to account for missing data. -- Key: MNG-2116 URL: http://jira.codehaus.org/browse/MNG-2116 Project: Maven 2 Type: New Feature Components: General Versions: 2.0.2 Reporter: John Casey Priority: Minor Fix For: 2.1 Currently, Maven will create a stub POM when it cannot find one on the remote repository. However, there are cases where we need to have the ability to verify that all the components of an application or some other type of build are present. Therefore, we need a strict mode for Maven, which will suppress any stubbing activities like this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Mon Feb 27 23:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060227.231500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060227.231500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-749) Please upload DWR-1.1-rc1 to the global Maven 2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-749?page=comments#action_59588 ] Julien Dubois commented on MAVENUPLOAD-749: --- It's available via the bundle URL link :-) To be more precise : Bundle URL : http://julien.dubois.free.fr/dwr/dwr-1.1-rc1-bundle.jar Source URL : http://julien.dubois.free.fr/dwr/dwr-1.1-rc1-sources.jar Please upload DWR-1.1-rc1 to the global Maven 2 repo Key: MAVENUPLOAD-749 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-749 Project: maven-upload-requests Type: Task Reporter: Julien Dubois This is the latest version of DWR, thank you for uploading it. In this release : - We release the sources as well as the binaries (mvn source:jar repository:bundle-create) - We greatly improved dependency management, by using the optional/ tag -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
[ http://jira.codehaus.org/browse/MDEPLOY-25?page=all ] John Casey reopened MDEPLOY-25: --- deploy:deploy-file installs the file in the local repository too (but it should not do that) Key: MDEPLOY-25 URL: http://jira.codehaus.org/browse/MDEPLOY-25 Project: Maven 2.x Deploy Plugin Type: Bug Versions: 2.1 Reporter: Geoffrey De Smet Assignee: Allan Ramirez Priority: Minor Fix For: 2.2 Time Spent: 3 hours Remaining: 0 minutes deploy:deploy-file installs a jar in a remote repository, but currently also installs it in the local repository. I believe this is a bug, because it makes you wrongly believe that the remote repository is ok when you run local tests afterwards. If this is the desired behaviour, please notify it on the command line and the documentation of deploy:deploy-file When I installed a simple hello.jar in my remote repository, I also found it in my local repository (in my user dir) after this command: $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi toryId=springRichclientRepository -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor y [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Uploading: file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. 7.jar 6b uploaded [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading repository metadata for: 'artifact org.hello:hello' [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading project information for hello 0.7 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 [INFO] Final Memory: 2M/4M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MDEPLOY-21) Deploying an artifact from the local directory failed if the associated pom file is not renamed
[ http://jira.codehaus.org/browse/MDEPLOY-21?page=all ] John Casey reopened MDEPLOY-21: --- Deploying an artifact from the local directory failed if the associated pom file is not renamed --- Key: MDEPLOY-21 URL: http://jira.codehaus.org/browse/MDEPLOY-21 Project: Maven 2.x Deploy Plugin Type: Bug Versions: 2.0 Environment: PowerBook G4, Mac OS X 10.4.4, J2SDK1.5, Maven 2.0.2 Reporter: Romain Rouvoy Assignee: Allan Ramirez Fix For: 2.2 Original Estimate: 5 hours Remaining: 5 hours mvn deploy:deploy-file -Dfile=fractal-2.0.1.jar - DpomFile=fractal-2.0.1.pom -Durl=... -DrepositoryId=objectweb-release These files have been previously successfully copied to my local repository using a mvn install:install-file command. I execute the deploy command from the local repository. But I obdtain the following error: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] -- -- [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] -- -- [INFO] [deploy:deploy-file] Uploading: scp://forge.objectweb.org/var/lib/gforge/chroot/home/ groups/maven/htdocs/maven2/org/objectweb/fractal/fractal/2.0.1/ fractal-2.0.1.jar 11K uploaded [INFO] Retrieving previous metadata from objectweb-release [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Error installing artifact's metadata: Error installing metadata: Error rewriting POM /Users/rouvoy/.m2/repository/org/objectweb/fractal/fractal/2.0.1/ fractal-2.0.1.pom (No such file or directory) [INFO] -- -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 7 seconds [INFO] Finished at: Fri Jan 20 17:09:51 CET 2006 [INFO] Final Memory: 3M/5M [INFO] -- -- And my local pom file has been deleted by the mvn command :'-( In fact I can not use the default pom file generated by install-file to deploy. I need to rename it before deploying ... otherwise the rewriting of the pom file will failed :-( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MDEPLOY-21) Deploying an artifact from the local directory failed if the associated pom file is not renamed
[ http://jira.codehaus.org/browse/MDEPLOY-21?page=all ] John Casey closed MDEPLOY-21: - Resolution: Fixed Fix Version: 2.2 Deploying an artifact from the local directory failed if the associated pom file is not renamed --- Key: MDEPLOY-21 URL: http://jira.codehaus.org/browse/MDEPLOY-21 Project: Maven 2.x Deploy Plugin Type: Bug Versions: 2.0 Environment: PowerBook G4, Mac OS X 10.4.4, J2SDK1.5, Maven 2.0.2 Reporter: Romain Rouvoy Assignee: Allan Ramirez Fix For: 2.2 Original Estimate: 5 hours Remaining: 5 hours mvn deploy:deploy-file -Dfile=fractal-2.0.1.jar - DpomFile=fractal-2.0.1.pom -Durl=... -DrepositoryId=objectweb-release These files have been previously successfully copied to my local repository using a mvn install:install-file command. I execute the deploy command from the local repository. But I obdtain the following error: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] -- -- [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] -- -- [INFO] [deploy:deploy-file] Uploading: scp://forge.objectweb.org/var/lib/gforge/chroot/home/ groups/maven/htdocs/maven2/org/objectweb/fractal/fractal/2.0.1/ fractal-2.0.1.jar 11K uploaded [INFO] Retrieving previous metadata from objectweb-release [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Error installing artifact's metadata: Error installing metadata: Error rewriting POM /Users/rouvoy/.m2/repository/org/objectweb/fractal/fractal/2.0.1/ fractal-2.0.1.pom (No such file or directory) [INFO] -- -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 7 seconds [INFO] Finished at: Fri Jan 20 17:09:51 CET 2006 [INFO] Final Memory: 3M/5M [INFO] -- -- And my local pom file has been deleted by the mvn command :'-( In fact I can not use the default pom file generated by install-file to deploy. I need to rename it before deploying ... otherwise the rewriting of the pom file will failed :-( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MDEPLOY-25) deploy:deploy-file installs the file in the local repository too (but it should not do that)
[ http://jira.codehaus.org/browse/MDEPLOY-25?page=all ] John Casey closed MDEPLOY-25: - Resolution: Fixed Fix Version: 2.2 deploy:deploy-file installs the file in the local repository too (but it should not do that) Key: MDEPLOY-25 URL: http://jira.codehaus.org/browse/MDEPLOY-25 Project: Maven 2.x Deploy Plugin Type: Bug Versions: 2.1 Reporter: Geoffrey De Smet Assignee: Allan Ramirez Priority: Minor Fix For: 2.2 Time Spent: 3 hours Remaining: 0 minutes deploy:deploy-file installs a jar in a remote repository, but currently also installs it in the local repository. I believe this is a bug, because it makes you wrongly believe that the remote repository is ok when you run local tests afterwards. If this is the desired behaviour, please notify it on the command line and the documentation of deploy:deploy-file When I installed a simple hello.jar in my remote repository, I also found it in my local repository (in my user dir) after this command: $ mvn deploy:deploy-file -Dfile=hello.jar -DgroupId=org.hello -DartifactId=hello -Dversion=0.7 -Dpackaging=jar -Dreposi toryId=springRichclientRepository -Durl=file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repositor y [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [INFO] [deploy:deploy-file] Uploading: file:///D:/projects/sf/spring-richclient-mavenizer/pomResources/maven2repository/org/hello/hello/0.7/hello-0. 7.jar 6b uploaded [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading repository metadata for: 'artifact org.hello:hello' [INFO] Retrieving previous metadata from springRichclientRepository [INFO] Uploading project information for hello 0.7 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sun Feb 19 19:38:12 CET 2006 [INFO] Final Memory: 2M/4M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MDEPLOY-7) deploy plugin leaves unnecessary information in the deployed pom.xml
[ http://jira.codehaus.org/browse/MDEPLOY-7?page=all ] John Casey reopened MDEPLOY-7: -- deploy plugin leaves unnecessary information in the deployed pom.xml Key: MDEPLOY-7 URL: http://jira.codehaus.org/browse/MDEPLOY-7 Project: Maven 2.x Deploy Plugin Type: Bug Reporter: Jorg Heymans Assignee: Allan Ramirez ideally, during deployment, the deployed pom should be stripped of elements like build and distributionManagement IRC log : jorg Can someone enlighten me here : when i deploy an artifact (m2), why does the deployed plugin contain the build and distributionmanagement elements ? jorg s/plugin/artifact/ jorg surely these elements are only relevant to the deployer ? jesse in the pom that is in the jar? jorg no the one that is deployed alongside the jar jorg shall I jira this ? jesse hm, I think that is a bug similar to the one with stuff in the META-INF/maven file too jorg yeah that's what i figured too jesse might as well bug it jdcasey jorg: we're not cleaning up that pom at all, just sending it on...but it's a good point jorg jdcasey: you mean about the maven version ? jdcasey I mean about the build/distributionManagement stuff...or anything that makes it into the POM that's deployed jorg oh ok , yup i think the pom should be stripped of anything not dependency related jorg i'm using deploy plugin v2.0 jdcasey I think I agree that it should be stripped of the functional parts of the POM, but not the informational stuff...it will allow us to make a richer map of project info if we leave that stuff in jorg jdcasey: yes thinking of it that's what i meant .. anything build or deploy related can go jdcasey don't ask *how this got here, it just did. ;-) jorg hehe exactly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MDEPLOY-7) deploy plugin leaves unnecessary information in the deployed pom.xml
[ http://jira.codehaus.org/browse/MDEPLOY-7?page=all ] John Casey closed MDEPLOY-7: Resolution: Won't Fix Fix Version: 2.2 this was fixed in the release plugin. deploy plugin leaves unnecessary information in the deployed pom.xml Key: MDEPLOY-7 URL: http://jira.codehaus.org/browse/MDEPLOY-7 Project: Maven 2.x Deploy Plugin Type: Bug Reporter: Jorg Heymans Assignee: Allan Ramirez Fix For: 2.2 ideally, during deployment, the deployed pom should be stripped of elements like build and distributionManagement IRC log : jorg Can someone enlighten me here : when i deploy an artifact (m2), why does the deployed plugin contain the build and distributionmanagement elements ? jorg s/plugin/artifact/ jorg surely these elements are only relevant to the deployer ? jesse in the pom that is in the jar? jorg no the one that is deployed alongside the jar jorg shall I jira this ? jesse hm, I think that is a bug similar to the one with stuff in the META-INF/maven file too jorg yeah that's what i figured too jesse might as well bug it jdcasey jorg: we're not cleaning up that pom at all, just sending it on...but it's a good point jorg jdcasey: you mean about the maven version ? jdcasey I mean about the build/distributionManagement stuff...or anything that makes it into the POM that's deployed jorg oh ok , yup i think the pom should be stripped of anything not dependency related jorg i'm using deploy plugin v2.0 jdcasey I think I agree that it should be stripped of the functional parts of the POM, but not the informational stuff...it will allow us to make a richer map of project info if we leave that stuff in jorg jdcasey: yes thinking of it that's what i meant .. anything build or deploy related can go jdcasey don't ask *how this got here, it just did. ;-) jorg hehe exactly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MDEPLOY-19) Ability to deploy-file as classifier
[ http://jira.codehaus.org/browse/MDEPLOY-19?page=all ] John Casey reopened MDEPLOY-19: --- Ability to deploy-file as classifier Key: MDEPLOY-19 URL: http://jira.codehaus.org/browse/MDEPLOY-19 Project: Maven 2.x Deploy Plugin Type: New Feature Versions: 2.1 Environment: xp Reporter: Dan Tran Assignee: Allan Ramirez Fix For: 2.2 Attachments: MDEPLOY19.diff Time Spent: 2 hours Remaining: 0 minutes deploy-file currently does not support this option -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MEV-350) ehcache pom for ehcache 1.2 beta 4 broken
[ http://jira.codehaus.org/browse/MEV-350?page=all ] Greg Luck reopened MEV-350: --- I just tested this again with the my-app demo app. Ibibilo still has the broken POM. See the log below. -bash2.05b [EMAIL PROTECTED] ~/my-app % mvn compile [INFO] Scanning for projects... [INFO] [INFO] Building Maven Quick Start Archetype [INFO]task-segment: [compile] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: http://repo1.maven.org/maven2/ehcache/ehcache/1.2beta4/ehcache-1.2beta4.pom 1K downloaded [WARNING] POM for 'ehcache:ehcache:pom:1.2beta4' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: Duplicated tag: 'groupId' (position: START_TAG seen ...dependency\n groupId... @20:16) [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 6 seconds [INFO] Finished at: Tue Feb 28 09:34:27 EST 2006 [INFO] Final Memory: 2M/5M ehcache pom for ehcache 1.2 beta 4 broken - Key: MEV-350 URL: http://jira.codehaus.org/browse/MEV-350 Project: Maven Evangelism Type: Task Reporter: Greg Luck Assignee: Carlos Sanchez Attachments: ehcache-1.2beta4.pom The pom for ehcache-1.2beta4 is broken. Trying to use it gives: [WARNING] POM for 'ehcache:ehcache:pom:1.2beta4' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: Duplicated tag: 'groupId' (position: START_TAG seen ...dependency\n groupId... @20:16) A corrected one is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MDEPLOY-19) Ability to deploy-file as classifier
[ http://jira.codehaus.org/browse/MDEPLOY-19?page=all ] John Casey closed MDEPLOY-19: - Resolution: Fixed Fix Version: 2.2 Ability to deploy-file as classifier Key: MDEPLOY-19 URL: http://jira.codehaus.org/browse/MDEPLOY-19 Project: Maven 2.x Deploy Plugin Type: New Feature Versions: 2.1 Environment: xp Reporter: Dan Tran Assignee: Allan Ramirez Fix For: 2.2 Attachments: MDEPLOY19.diff Time Spent: 2 hours Remaining: 0 minutes deploy-file currently does not support this option -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Mon Feb 27 23:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060227.233000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060227.233000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Result: [vote] Release maven-deploy-plugin 2.2
Binding: 5 (John, Emmanuel, Brett, Jason, Lukas) Non-Binding: 2 (Vincent S and Brian) I've run the release, and cleaned up JIRA, and will be marking the release as closed in JIRA next. The site and repository should be updating within the next 4 hours. Cheers, John John Casey wrote: Hi, Allan Ramirez has been good enough to fix the remaining bugs filed against the maven-deploy-plugin. I think it's ready for a 2.2 release. This release will include fixes to address: * documentation * interpolated POM information making its way into the remote repository * deploy-file with a classifier * option to skip installation of an artifact in the local repo when using deploy-file mojo * deploy-file when install-file was previously executed for the same artifact Customary terms for the vote: +1/0/-1, 72h Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Mon Feb 27 23:45:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060227.234501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060227.234501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCM-165) PerforceChangeLogCommand needs to use the same clientspec as the update command
[ http://jira.codehaus.org/browse/SCM-165?page=comments#action_59591 ] Mike Perham commented on SCM-165: - Here's my understanding of the requirements: 1) Continuum needs to be able to run update/checkout and changelog in the same VM when running a build. Since this uses a persistent clientspec, the changelog command needs to reuse the same clientspec. That's what this bug is about and it should work with my changes 3 days ago. 2) The changelog mojo needs to be able to run the changelog command as a standalone feature. The command should default to NO clientspec but allow the user to pass in a clientspec on the command line. 3) The user should be able to run 'mvn scm:update scm:changelog' to get results similar to (1) and 'mvn scm:changelog' to get results similar to (2). Any comments? Any other usecases? PerforceChangeLogCommand needs to use the same clientspec as the update command --- Key: SCM-165 URL: http://jira.codehaus.org/browse/SCM-165 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Versions: 1.0 Reporter: John Didion Assignee: Mike Perham Priority: Critical Attachments: PerforceChangeLogCommand.diff, svn.diff The PerforceChangeLogCommand as written does not work if the update was done with the client spec generated by the checkout/update command. The attached diff will fix the 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: (MEV-350) ehcache pom for ehcache 1.2 beta 4 broken
[ http://jira.codehaus.org/browse/MEV-350?page=all ] Carlos Sanchez closed MEV-350: -- Resolution: Fixed It takes several hours to get the updated propagated to ibiblio ehcache pom for ehcache 1.2 beta 4 broken - Key: MEV-350 URL: http://jira.codehaus.org/browse/MEV-350 Project: Maven Evangelism Type: Task Reporter: Greg Luck Assignee: Carlos Sanchez Attachments: ehcache-1.2beta4.pom The pom for ehcache-1.2beta4 is broken. Trying to use it gives: [WARNING] POM for 'ehcache:ehcache:pom:1.2beta4' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: Duplicated tag: 'groupId' (position: START_TAG seen ...dependency\n groupId... @20:16) A corrected one is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - checkout] Tue Feb 28 00:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060228.00.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060228.00.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - checkout] Tue Feb 28 00:30:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060228.003002.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060228.003002.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (SUREFIRE-21) Use plexus-utils and get rid of the copied util files
[ http://jira.codehaus.org/browse/SUREFIRE-21?page=all ] Jason van Zyl closed SUREFIRE-21: - Resolution: Fixed Plexus utils is now used. Use plexus-utils and get rid of the copied util files -- Key: SUREFIRE-21 URL: http://jira.codehaus.org/browse/SUREFIRE-21 Project: surefire Type: Improvement Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 1.5.3 Might also need to push TeeStream into plexus utils. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-53) Make forked mode console output look the same as non-forked mode console output
[ http://jira.codehaus.org/browse/MSUREFIRE-53?page=all ] Jason van Zyl closed MSUREFIRE-53: -- Resolution: Fixed The output in forked mode is now the same as non-forked mode. Make forked mode console output look the same as non-forked mode console output --- Key: MSUREFIRE-53 URL: http://jira.codehaus.org/browse/MSUREFIRE-53 Project: Maven 2.x Surefire Plugin Type: Bug Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 2.1.3 Right now nothing comes out on the console which is confusing to users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (SUREFIRE-23) Output of tests in forked mode to file instead to System.out
[ http://jira.codehaus.org/browse/SUREFIRE-23?page=all ] Jason van Zyl closed SUREFIRE-23: - Resolution: Fixed The output in forked mode now matches that of non-forked mode. Output of tests in forked mode to file instead to System.out Key: SUREFIRE-23 URL: http://jira.codehaus.org/browse/SUREFIRE-23 Project: surefire Type: New Feature Versions: 1.5 Environment: windows xp, maven 2.0.1, surefire 1.5 Reporter: Michal Stochmialek Assignee: Jason van Zyl Fix For: 1.5.3 There is a need to use file for output of tests in the fork mode. According to sources, sys.err and sys.out of forked jvm are written to StringWriter. At the end there are put to System.out. I think it wouldn't be difficult, to put them to file instead to console. In result, output of builds won't be so messy... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-7) Targets for unit, integration and functional tests
[ http://jira.codehaus.org/browse/SUREFIRE-7?page=comments#action_59598 ] Jason van Zyl commented on SUREFIRE-7: -- This will be supported by maven's standard build lifecycle and not something to put in surefire itself. Surefire simply runs tests, it doesn't care what flavour. Targets for unit, integration and functional tests -- Key: SUREFIRE-7 URL: http://jira.codehaus.org/browse/SUREFIRE-7 Project: surefire Type: Improvement Environment: All platforms, Maven 2 beta 3 Reporter: larry Assignee: Jason van Zyl Fix For: 1.5.3 I could not find this functionality by reading the current documentation. I think it would be a good idea to have the following targets added to m2 and the surefire plugin: test:unit test:integration test:functional Currently I don't know how to separate these tests with Maven 2 beta 3. It is a good idea to separate the tests into different groups. Fast running and simple tests should be run when executing the test:unit target. Longer running should not be executed at every build just before deploy. Surefire could look for the tests in a default location. For example something like: src/main/test/java/**/unit/*Test.java src/main/test/java/**/integration/*Test.java src/main/test/java/**/functional/*Test.java These paths could also be specified in the pom.xml. Another possibility would be the possibility of defining your own groups in the pom. And execute them with for example m2 test:group unit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-7) Targets for unit, integration and functional tests
[ http://jira.codehaus.org/browse/SUREFIRE-7?page=all ] Jason van Zyl closed SUREFIRE-7: Resolution: Won't Fix Targets for unit, integration and functional tests -- Key: SUREFIRE-7 URL: http://jira.codehaus.org/browse/SUREFIRE-7 Project: surefire Type: Improvement Environment: All platforms, Maven 2 beta 3 Reporter: larry Assignee: Jason van Zyl Fix For: 1.5.3 I could not find this functionality by reading the current documentation. I think it would be a good idea to have the following targets added to m2 and the surefire plugin: test:unit test:integration test:functional Currently I don't know how to separate these tests with Maven 2 beta 3. It is a good idea to separate the tests into different groups. Fast running and simple tests should be run when executing the test:unit target. Longer running should not be executed at every build just before deploy. Surefire could look for the tests in a default location. For example something like: src/main/test/java/**/unit/*Test.java src/main/test/java/**/integration/*Test.java src/main/test/java/**/functional/*Test.java These paths could also be specified in the pom.xml. Another possibility would be the possibility of defining your own groups in the pom. And execute them with for example m2 test:group unit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Perforce provider RC
If you use the Perforce SCM provider, I would strongly urge you to test the latest version with your build or Continuum install. This is the release candidate for 1.0 and I would appreciate if someone would verify correct operation with Continuum. Here's the latest binary if you don't use SVN. http://www.perham.net/maven-scm-provider-perforce-1.0-beta-3-SNAPSHOT.ja r
[jira] Commented: (SCM-165) PerforceChangeLogCommand needs to use the same clientspec as the update command
[ http://jira.codehaus.org/browse/SCM-165?page=comments#action_59599 ] Mike Perham commented on SCM-165: - Posted a release candidate with my small changes to allow these usecases. I'm still afraid there will be edge cases I've missed - Emmanuel, can you point me to the changelog plugin and the documentation on how to use it so I can test it here? PerforceChangeLogCommand needs to use the same clientspec as the update command --- Key: SCM-165 URL: http://jira.codehaus.org/browse/SCM-165 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Versions: 1.0 Reporter: John Didion Assignee: Mike Perham Priority: Critical Attachments: PerforceChangeLogCommand.diff, svn.diff The PerforceChangeLogCommand as written does not work if the update was done with the client spec generated by the checkout/update command. The attached diff will fix the 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] Commented: (MSUREFIRE-45) The test attribute is incorrectly described
[ http://jira.codehaus.org/browse/MSUREFIRE-45?page=comments#action_59601 ] Jason van Zyl commented on MSUREFIRE-45: This is really the ant pattern matching code, so the docs should be updated. The test attribute is incorrectly described --- Key: MSUREFIRE-45 URL: http://jira.codehaus.org/browse/MSUREFIRE-45 Project: Maven 2.x Surefire Plugin Type: Improvement Reporter: Grégory Joseph Priority: Trivial Fix For: 2.1.3 The the surefire plugin describe its test parameter with Specify this parameter if you want to use the test regex notation to select tests to run. However, from what I see in the SurefirePlugin code, this is abusing the regex term, since it is concatening **/ + regex + .java, which doesn't look much like a standard regex. i.e, using the regex syntax, one would expect to set test to .*TestCase, but this doesn't work - *TestCase gives the expected results. All in all, I think this is just a matter of claryfiyng the doc - I haven't checked the surefire code itself, but from the results I get, I bet it doesn't use real regexes either. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSUREFIRE-45) The test attribute is incorrectly described
[ http://jira.codehaus.org/browse/MSUREFIRE-45?page=all ] Jason van Zyl closed MSUREFIRE-45: -- Resolution: Fixed Documentation has been update, when the site is deployed next you'll see it. The test attribute is incorrectly described --- Key: MSUREFIRE-45 URL: http://jira.codehaus.org/browse/MSUREFIRE-45 Project: Maven 2.x Surefire Plugin Type: Improvement Reporter: Grégory Joseph Priority: Trivial Fix For: 2.1.3 The the surefire plugin describe its test parameter with Specify this parameter if you want to use the test regex notation to select tests to run. However, from what I see in the SurefirePlugin code, this is abusing the regex term, since it is concatening **/ + regex + .java, which doesn't look much like a standard regex. i.e, using the regex syntax, one would expect to set test to .*TestCase, but this doesn't work - *TestCase gives the expected results. All in all, I think this is just a matter of claryfiyng the doc - I haven't checked the surefire code itself, but from the results I get, I bet it doesn't use real regexes either. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build trunk - SUCCESS - checkout] Tue Feb 28 01:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/trunk/continuum-20060228.010001.war Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060228.010001.txt
[maven2 build trunk - SUCCESS - update] Tue Feb 28 01:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060228.010001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060228.010001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-45) The test attribute is incorrectly described
[ http://jira.codehaus.org/browse/MSUREFIRE-45?page=comments#action_59603 ] Grégory Joseph commented on MSUREFIRE-45: - great :) The test attribute is incorrectly described --- Key: MSUREFIRE-45 URL: http://jira.codehaus.org/browse/MSUREFIRE-45 Project: Maven 2.x Surefire Plugin Type: Improvement Reporter: Grégory Joseph Priority: Trivial Fix For: 2.1.3 The the surefire plugin describe its test parameter with Specify this parameter if you want to use the test regex notation to select tests to run. However, from what I see in the SurefirePlugin code, this is abusing the regex term, since it is concatening **/ + regex + .java, which doesn't look much like a standard regex. i.e, using the regex syntax, one would expect to set test to .*TestCase, but this doesn't work - *TestCase gives the expected results. All in all, I think this is just a matter of claryfiyng the doc - I haven't checked the surefire code itself, but from the results I get, I bet it doesn't use real regexes either. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-756) swift-parser is a java general library to parse SWIFT messages
[ http://jira.codehaus.org/browse/MAVENUPLOAD-756?page=comments#action_59604 ] Miguel Griffa commented on MAVENUPLOAD-756: --- ok, I'll post a request for next version with group id changed. I'd like to suggest to change the text in the guide from a paragraph 'Some considerations about the groupId:' to something more accurate, like a section 'GroupId policiy' or similar. I think that enforcing a better group naming is great, but it does not have, IMHO, the required importance in the page. swift-parser is a java general library to parse SWIFT messages -- Key: MAVENUPLOAD-756 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-756 Project: maven-upload-requests Type: Task Reporter: Miguel Griffa -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-59) JUnitBattery dies when TestSuite has an anonymous inner class
[ http://jira.codehaus.org/browse/MSUREFIRE-59?page=comments#action_59605 ]
Jason van Zyl commented on MSUREFIRE-59:
Mike can you give me a little test case?
I just deployed a new snapshot which improves forking output so that may help.
JUnitBattery dies when TestSuite has an anonymous inner class
-
Key: MSUREFIRE-59
URL: http://jira.codehaus.org/browse/MSUREFIRE-59
Project: Maven 2.x Surefire Plugin
Type: Bug
Versions: 2.1.2
Reporter: Mike Perham
Fix For: 2.1.3
I have this method in my test suite:
{code}
private static File[] getWSDLFiles() {
URL directoryURL =
WSDLImportTestSuite.class.getResource(/com/webify/wsf/studio/core/wsdl/wsdls);
if (directoryURL != null) {
File directory = new File(directoryURL.getPath());
FilenameFilter filter = new FilenameFilter() {
public boolean accept(File dir, String name) {
return name.endsWith(.wsdl);
}
};
return directory.listFiles(filter);
}
else {
return null;
}
}
{code}
And surefire fails with this exception:
java.lang.NoSuchMethodException:
com.webify.wsf.studio.core.wsdl.WSDLImportTestSuite$1.init()
at java.lang.Class.getConstructor0(Class.java:1937)
at java.lang.Class.getConstructor(Class.java:1027)
at
org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
at
org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
at
org.apache.maven.surefire.battery.JUnitBattery.init(JUnitBattery.java:81)
at
org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
at
org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MRM-41) discover standalone POMs
[ http://jira.codehaus.org/browse/MRM-41?page=all ] Edwin Punzalan closed MRM-41: - Resolution: Fixed Committed the missing files. Sorry about that. discover standalone POMs Key: MRM-41 URL: http://jira.codehaus.org/browse/MRM-41 Project: Maven Repository Manager Type: Task Components: discovery Reporter: Brett Porter Assignee: John Tolentino Fix For: 1.0-alpha-1 Attachments: MRM-41-maven-repository-discovery.diff, MRM-41-maven-repository-discovery.diff, MRM-41-maven-repository-discovery.diff, repository-manager.diff Time Spent: 21 hours Remaining: 0 minutes where the pom is the artifact -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-756) swift-parser is a java general library to parse SWIFT messages
[ http://jira.codehaus.org/browse/MAVENUPLOAD-756?page=all ] Miguel Griffa closed MAVENUPLOAD-756: - Resolution: Incomplete groupid is invalid according to current policies, next version will be uploaded using proper bundle:create goal and having the groupid fixed swift-parser is a java general library to parse SWIFT messages -- Key: MAVENUPLOAD-756 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-756 Project: maven-upload-requests Type: Task Reporter: Miguel Griffa -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Tue Feb 28 01:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060228.013001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060228.013001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Tue Feb 28 01:45:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060228.014501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060228.014501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-91) create a second index with a subset of information, and have it compressed
[ http://jira.codehaus.org/browse/MRM-91?page=all ] Edwin Punzalan updated MRM-91: -- Assign To: Edwin Punzalan Remaining Estimate: 8 hours Original Estimate: 8 hours According to jason, its an index with the same output as what eu has created for the eclipse plugin create a second index with a subset of information, and have it compressed -- Key: MRM-91 URL: http://jira.codehaus.org/browse/MRM-91 Project: Maven Repository Manager Type: New Feature Components: indexing Reporter: Brett Porter Assignee: Edwin Punzalan Fix For: 1.0-alpha-1 Original Estimate: 8 hours Remaining: 8 hours required for the eclipse plugin. Will need to follow up with Jason on exactly what data is required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MJAVADOC-44) outputDirectory configuration clashes between javadoc:javadoc and javadoc:jar
[ http://jira.codehaus.org/browse/MJAVADOC-44?page=all ] Brett Porter updated MJAVADOC-44: - Fix Version: 2.0 Summary: outputDirectory configuration clashes between javadoc:javadoc and javadoc:jar (was: Ability to have different plugin configuration per goal) one of them needs to be renamed outputDirectory configuration clashes between javadoc:javadoc and javadoc:jar - Key: MJAVADOC-44 URL: http://jira.codehaus.org/browse/MJAVADOC-44 Project: Maven 2.x Javadoc Plugin Type: Bug Reporter: Chris Hagmann Fix For: 2.0 Curently it seems impossible to have a different plugin configuration per goal, only per phase. Simple use case for this requirement: I need to generate Javadoc with an output directory of target/mhave/docs/apidocs, and then also create a javadoc archive of the previously generated Javadoc, but this needs to go into target/dist. As the plugin maven-javadoc-plugin uses outputDirectory for both goals, I need to be able to have different plugin configurations. This is possible as long as they are attached to different lifecycle phases, but not if they are attached to the same lifecycle phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MJAVADOC-44) outputDirectory configuration clashes between javadoc:javadoc and javadoc:jar
[ http://jira.codehaus.org/browse/MJAVADOC-44?page=all ] Brett Porter closed MJAVADOC-44: Assign To: Brett Porter Resolution: Duplicate Fix Version: (was: 2.0) outputDirectory configuration clashes between javadoc:javadoc and javadoc:jar - Key: MJAVADOC-44 URL: http://jira.codehaus.org/browse/MJAVADOC-44 Project: Maven 2.x Javadoc Plugin Type: Bug Reporter: Chris Hagmann Assignee: Brett Porter Curently it seems impossible to have a different plugin configuration per goal, only per phase. Simple use case for this requirement: I need to generate Javadoc with an output directory of target/mhave/docs/apidocs, and then also create a javadoc archive of the previously generated Javadoc, but this needs to go into target/dist. As the plugin maven-javadoc-plugin uses outputDirectory for both goals, I need to be able to have different plugin configurations. This is possible as long as they are attached to different lifecycle phases, but not if they are attached to the same lifecycle phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MJAVADOC-58) additionalparam content should not be included in apostrophes on the commandline
[ http://jira.codehaus.org/browse/MJAVADOC-58?page=all ] Brett Porter closed MJAVADOC-58: Assign To: Brett Porter Resolution: Duplicate additionalparam content should not be included in apostrophes on the commandline -- Key: MJAVADOC-58 URL: http://jira.codehaus.org/browse/MJAVADOC-58 Project: Maven 2.x Javadoc Plugin Type: Bug Versions: 2.0-beta-3 Environment: W2k Reporter: Rik Graetke Assignee: Brett Porter We have written our own doclet that needs additional parameter/value-pairs on the command-line, which after all needs to look like this: javadoc -J-Xmx300m -J-Xms40m -J-ea -doclet de.mobilcom.javadoc.McDoclet -globaltagoverview 'system.property:w:2:System Prop.' ... I'm trying to configure javadoc-Plugin like this: ... docletde.mobilcom.javadoc.McDoclet/doclet additionalparam-globaltagoverview 'system.property:w:2:System Prop.'/additionalparam ... Running this, i receive an javadoc error invalid flag: -globaltagoverview Examining the options-file shows, that additionalparam resolved to: '-globaltagoverview 'system.property:w:2:System Prop.' ' on the command line which in fact is not working after manually removing the apostrophes everything is OK when running it as -globaltagoverview 'system.property:w:2:System Prop.' Additional Problem: trying additionalparam-J-ea/additionalparam puts the '-J-ea ' in the Option-File which as far as i know is not working for J-Options -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
