Re: Vetting issues for 2.1-alpha-XX
Did the MNG-3586 is allready fixed or fix is delayed ? I got this mail : - Jason van Zyl updated MNG-3586: --- Fix Version/s: (was: 2.1-alpha-1) 2.1-alpha-2 -- Very annoying bug for those of us using m2eclipse 0.9.4 and have jaxws operation in their pom (since maven embedded failed during IDE operations). Regards 2008/7/4 Brett Porter [EMAIL PROTECTED]: On 04/07/2008, at 12:43 PM, Jason van Zyl wrote: I have chopped the issue list down to what I know I'm going to look at here: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10500fixfor=13143 If you want to add things you know you want to look at, go for it. I generally agree with the ones pushed back, they were what I was eyeing at pushing out once done with the others. There are 3 I think need to be fixed first: MNG-3366 (site generation is completely hosed) MNG-3281 (extensions don't work and there's no alternative) MNG-3576 (regression when using the assembly plugin) I'll move them back in. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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]
Re: Vetting issues for 2.1-alpha-XX
Here's some tips for folks trying to debug Maven/Plexus/Plugins in Eclipse. Using m2e you can actually debug/execute plugin _inside_ Eclipse. That means the plugin executes from the workspace in-situ. Extremely handy. http://docs.codehaus.org/display/M2ECLIPSE/Developing+and+debugging+Maven+plugins Did you also experiment m2eclipse to developp and debug maven 2.1 (in embedded and standalone mode ?) Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vetting issues for 2.1-alpha-XX
I was just looking at this Henri - though I'm not longer able to compile the provided test project so it's impossible to test. Can you review the project to help make it reproducible? Thanks, Brett On 04/07/2008, at 5:12 PM, Henri Gomez wrote: Did the MNG-3586 is allready fixed or fix is delayed ? I got this mail : - Jason van Zyl updated MNG-3586: --- Fix Version/s: (was: 2.1-alpha-1) 2.1-alpha-2 -- Very annoying bug for those of us using m2eclipse 0.9.4 and have jaxws operation in their pom (since maven embedded failed during IDE operations). Regards 2008/7/4 Brett Porter [EMAIL PROTECTED]: On 04/07/2008, at 12:43 PM, Jason van Zyl wrote: I have chopped the issue list down to what I know I'm going to look at here: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10500fixfor=13143 If you want to add things you know you want to look at, go for it. I generally agree with the ones pushed back, they were what I was eyeing at pushing out once done with the others. There are 3 I think need to be fixed first: MNG-3366 (site generation is completely hosed) MNG-3281 (extensions don't work and there's no alternative) MNG-3576 (regression when using the assembly plugin) I'll move them back in. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vetting issues for 2.1-alpha-XX
2008/7/4 Brett Porter [EMAIL PROTECTED]: I was just looking at this Henri - though I'm not longer able to compile the provided test project so it's impossible to test. Can you review the project to help make it reproducible? Done. Redone the test with m2eclipse 0.9.4 (using embedded) From file: C:\Documents and Settings\gomezhe\Bureau\sample-wsgen\pom.xml Reason: Failed to execute wsgen java.lang.NoClassDefFoundError: com/sun/mirror/apt/AnnotationProcessorFactory at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadRealmClass(ClassRealm.java:174) at org.codehaus.plexus.classworlds.strategy.DefaultStrategy.loadClass(DefaultStrategy.java:67) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:201) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at com.sun.tools.ws.WsGen.doMain(WsGen.java:69) at org.codehaus.mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:97) at org.codehaus.mojo.jaxws.MainWsGenMojo.execute(MainWsGenMojo.java:14) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223) at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176) at org.apache.maven.cli.MavenCli.main(MavenCli.java:63) at org.apache.maven.cli.MavenCli.main(MavenCli.java:52) Error stacktrace: org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.codehaus.mojo:jaxws-maven-plugin:1.10:wsgen': Mojo execution failed. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223) at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176) at org.apache.maven.cli.MavenCli.main(MavenCli.java:63) at org.apache.maven.cli.MavenCli.main(MavenCli.java:52) Caused by: org.apache.maven.plugin.PluginExecutionException: Mojo execution failed. at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:601) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498) ... 12 more Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute wsgen at org.codehaus.mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:102) at
Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1
On 04/07/2008, at 3:40 AM, John Casey wrote: Not to distract from the higher-level discussion, but I'd like to get into the nuts and bolts of MARTIFACT-25 a bit...in case someone beats me to it. We introduced a properties file that tracks resolution attempts for artifacts that weren't found on the remote repository, and I'd like to see if we can reuse that file/concept/code to handle artifacts that don't have accompanying POMs on the remote repo. It's a similar concept, so the two should dovetail relatively well, and require little code to accomplish the fix. This makes sense to me. So continue to expand on the update check manager to handle this case? The other alternative - which at one point we were doing - is to write out the stub POM into the local repository and retain that. It would simplify the code, but muddies the local repo content. I believe these have the same net effect, in that the artifact is never resolved a second time. Is that correct? The way I see it, the biggest hurdle for this issue is creating a [set of] good tests to circumscribe the issue and make sure it doesn't regress later. I don't think there's too many variations - the problem is only with missing POM files, right? Cheers, Brett My $0.02. -john Brett Porter wrote: Hi all, As I indicated a couple of weeks back, moving towards a 2.1 alpha release, I was looking at releasing an alpha of maven-artifact. Brian was able to locate the issue he was referring to a couple of weeks back about re-resolving (now MARTIFACT-25), so I've postponed. Once that's fixed, I think there should be no reason not to proceed with a release based on the thread we had back then. Are there any other issues that anyone sees as blocking moving forward with a release? I've done all the testing I was planning to already. Oleg, did you want to take this release, or shall I go ahead after that issue is sorted? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1
Are you dropping new files into the local repository or integrating this as part of the metadata? Do these files only work locally? Also in the case of 2.1 we should also consider just not allowing the state where there is no POM. Consider the artifact not complete without a POM. On 4-Jul-08, at 11:29 AM, Brett Porter wrote: On 04/07/2008, at 3:40 AM, John Casey wrote: Not to distract from the higher-level discussion, but I'd like to get into the nuts and bolts of MARTIFACT-25 a bit...in case someone beats me to it. We introduced a properties file that tracks resolution attempts for artifacts that weren't found on the remote repository, and I'd like to see if we can reuse that file/concept/code to handle artifacts that don't have accompanying POMs on the remote repo. It's a similar concept, so the two should dovetail relatively well, and require little code to accomplish the fix. This makes sense to me. So continue to expand on the update check manager to handle this case? The other alternative - which at one point we were doing - is to write out the stub POM into the local repository and retain that. It would simplify the code, but muddies the local repo content. I believe these have the same net effect, in that the artifact is never resolved a second time. Is that correct? The way I see it, the biggest hurdle for this issue is creating a [set of] good tests to circumscribe the issue and make sure it doesn't regress later. I don't think there's too many variations - the problem is only with missing POM files, right? Cheers, Brett My $0.02. -john Brett Porter wrote: Hi all, As I indicated a couple of weeks back, moving towards a 2.1 alpha release, I was looking at releasing an alpha of maven-artifact. Brian was able to locate the issue he was referring to a couple of weeks back about re-resolving (now MARTIFACT-25), so I've postponed. Once that's fixed, I think there should be no reason not to proceed with a release based on the thread we had back then. Are there any other issues that anyone sees as blocking moving forward with a release? I've done all the testing I was planning to already. Oleg, did you want to take this release, or shall I go ahead after that issue is sorted? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1
John - are you looking into this? Need it resolved for MNG-3185 Thanks, Oleg Brett Porter wrote: On 04/07/2008, at 3:40 AM, John Casey wrote: Not to distract from the higher-level discussion, but I'd like to get into the nuts and bolts of MARTIFACT-25 a bit...in case someone beats me to it. We introduced a properties file that tracks resolution attempts for artifacts that weren't found on the remote repository, and I'd like to see if we can reuse that file/concept/code to handle artifacts that don't have accompanying POMs on the remote repo. It's a similar concept, so the two should dovetail relatively well, and require little code to accomplish the fix. This makes sense to me. So continue to expand on the update check manager to handle this case? The other alternative - which at one point we were doing - is to write out the stub POM into the local repository and retain that. It would simplify the code, but muddies the local repo content. I believe these have the same net effect, in that the artifact is never resolved a second time. Is that correct? The way I see it, the biggest hurdle for this issue is creating a [set of] good tests to circumscribe the issue and make sure it doesn't regress later. I don't think there's too many variations - the problem is only with missing POM files, right? Cheers, Brett My $0.02. -john Brett Porter wrote: Hi all, As I indicated a couple of weeks back, moving towards a 2.1 alpha release, I was looking at releasing an alpha of maven-artifact. Brian was able to locate the issue he was referring to a couple of weeks back about re-resolving (now MARTIFACT-25), so I've postponed. Once that's fixed, I think there should be no reason not to proceed with a release based on the thread we had back then. Are there any other issues that anyone sees as blocking moving forward with a release? I've done all the testing I was planning to already. Oleg, did you want to take this release, or shall I go ahead after that issue is sorted? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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]
Re: Vetting issues for 2.1-alpha-XX
As part of getting adequate coverage for vetting, I have just asked Nigel and Justin who watch over the Hudson instance here at Apache to setup the Maven jobs we require for validation. They are running on Solaris which will be a good compliment to what we have running at Contegix. Hopefully this will be setup today and then we'll have Linux and Solaris dealth with in a reliable, automated way. I've asked Contegix to order a Mac Mini they will modify and put in our rack, and we will have a big machine that will run ESX coming soon as well so we'll be able to deal with different flavors of Windows and *nix. On 3-Jul-08, at 10:43 PM, Jason van Zyl wrote: I have chopped the issue list down to what I know I'm going to look at here: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10500fixfor=13143 If you want to add things you know you want to look at, go for it. But I would like to use a standard build for testing. I am going to use the version of Maven built by Hudson from the 2.1 build that's been cycling off from here: http://ci.sonatype.org/view/Maven%202.1x/job/Maven-2.1.x/ If we sync up on a version which we all use then we have a good chance of getting consistent results. I'm using the build from here to review the issues currently in the queue: http://ci.sonatype.org/view/Maven%202.1x/job/Maven-2.1.x/ws/maven-2.1.x/maven-distribution/target/ When issues are closed, another build can be done and we can use that one to carry on. I think this is the only sane way to work through the issues. The Hudson instance has been up the longest, it works more reasonably then anything else we've used, and John has been working on creating some release automation so the releases can be built on the same machine as well. For reliability and consistency I think this is a reasonable approach. A PowerEdge 2900 will land at Contegix shortly that has been provisioned to run ESX so that we can deal with Windows, Linux, BSD, and Solaris in an automated way. Contegix also said they could wire up a MAC mini if we wanted to automate OS X builds as well. The box is on Contegix's system, but any PMC member can get access to the machine and access to the support list if you need to contact support in the middle of the night. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Three people can keep a secret provided two of them are dead. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 2.x Eclipse Plugin - MECLIPSE-388
Hi Maven 2.0.9 has corrected classpath order, direct dependencies are first (and suborder is among declared entries). I think that thanks this very hopefilly improvement (bugfix imho ;)) maven eclipse plugin doesn't have to sort classpath. Generated .classpath should sorted entries amond order in pom.xml (and eg no push to first javax/java packages - if somebody wants it push first it could declared them first in pom.xml). Additional I guess Only JRE_CONTAINER can be last to give user ability to override default system libraries with provided in pom.xml (or it should be as same in core maven - jre libraries are first or last) -- Kamil
Re: [DISCUSS] Maven Team Conventions
Just a couple of comments... code.apt: ~~ * Using SVN properties like \$Id: \$ = Is it a wanted goal for all files like java or apt? I think this is helpful, though maybe optional. I don't really think it's good for the @version tag in Javadoc though. * Indentation: Always use 2 space indents and never use tabs! The two space rule is only for text files, right? We use 4 for Java in all indents, but the document doesn't indicate that. * Readingness: Specify code grouping members, if needed. For instance in a Mojo class, you could have: I've found these are used inconsistently and get out of date. Like all comments, someone should add them if they think they'll help, but as a general rule I'd omit this. jira.apt: I disagree on JIRA issues - for making release notes and keeping track I think it's best to have an issue whenever possible. BTW, I posted some conventions to this list in the past, maybe we could incorporate them: http://markmail.org/message/wfv2lw66i2gggnaq Thanks, Brett On 04/07/2008, at 7:00 AM, Vincent Siveton wrote: Hi folks, Following recent discussions on dev@ about POM style [1] and Jira versioning [2], I created several documents about our code style and conventions, jira and svn conventions. http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/developers/conventions It is for discussions and all comments are welcome :) Cheers, Vincent [1] http://www.nabble.com/-Proposal--Pom-Code-Style-(WAS-svn-commit%3A-r670264maven-plugins-trunk-maven-site-plugin-pom.xml)-td18083228.html [2] http://www.nabble.com/Re%3A--jira--Updated%3A-(MNG-3468)-FileSet-needs-a-toString()-method-to-properly-print-in-debug-mode-td18185825.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
