Re: maven vs openmake mesiter
This is true - but the tree was available elsewhere, I think the help plugin had it for a while. A On 2 Apr 2008, at 00:39, Jason Chaffee wrote: Also, this may have been written before the dependency plugin had the current feature set. I know when I first started using maven2 and the dependency plugin, it only had copy, unpack, and a couple of other goals. It didn't have everything it has now. -Original Message- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2008 7:56 AM To: Maven Developers List Subject: Re: maven vs openmake mesiter Heh, it looks to me like people who have had bad experiences with maven but not known the tools that can help. The command "mvn dependency:tree" would have saved them a paragraph of rant at least! Andy On 31 Mar 2008, at 22:59, Jason van Zyl wrote: I have something written but it's not very nice. But we're obviously a threat as they make comparisons to us. A victim of our own success. I've also meant to follow up on when they started using the term "Mojo" which definitely confuses people. For the sister Maven project over at Codehaus called Mojo has been around quite a long time. So I just didn't want to be disappointed and I'm hoping that they didn't do it to confuse users. I am assuming not but I haven't looked up the dates. I will try to remove the barbs from my write-up, as their marketing I frankly find distasteful. But I'll try to be objective and publish it. On 31-Mar-08, at 2:18 PM, Jason Chaffee wrote: I came across OpenMake's meister over the weekend and wondered if anyone on this list has any experience with or any comparison with Maven? I was just curious what the maven community's impression/response would be because they claim to have maven-like features, but they also claim to go "above and beyond" maven in flexibility and features. http://www.openmakesoftware.com/Maven-VS-Meister/ 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] - 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]
Re: maven vs openmake mesiter
Heh, it looks to me like people who have had bad experiences with maven but not known the tools that can help. The command "mvn dependency:tree" would have saved them a paragraph of rant at least! Andy On 31 Mar 2008, at 22:59, Jason van Zyl wrote: I have something written but it's not very nice. But we're obviously a threat as they make comparisons to us. A victim of our own success. I've also meant to follow up on when they started using the term "Mojo" which definitely confuses people. For the sister Maven project over at Codehaus called Mojo has been around quite a long time. So I just didn't want to be disappointed and I'm hoping that they didn't do it to confuse users. I am assuming not but I haven't looked up the dates. I will try to remove the barbs from my write-up, as their marketing I frankly find distasteful. But I'll try to be objective and publish it. On 31-Mar-08, at 2:18 PM, Jason Chaffee wrote: I came across OpenMake's meister over the weekend and wondered if anyone on this list has any experience with or any comparison with Maven? I was just curious what the maven community's impression/response would be because they claim to have maven-like features, but they also claim to go "above and beyond" maven in flexibility and features. http://www.openmakesoftware.com/Maven-VS-Meister/ 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Benjamin Bentmann as Maven committer
+1 Andy On 18 Feb 2008, at 17:38, Lukas Theussl wrote: I'd like to propose giving commit access to Benjamin. During the last few months, he has provided patches in so many areas of Maven that I can't list them all here (various plugins, surefire, doxia,...), including documentation and translations, and he has not been afraid to actively discuss things on the dev list. I think he would make a great addition to our team. +1 -Lukas - 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: plexus classloader issue ?
Why are you trying to load the dependencies of another plugin instead
of specifying them yourself?
Andy
On 17 Oct 2007, at 16:31, nicolas de loof wrote:
Not sure to understand what you would like me to see in the dependency
plugin.
I get my unarchiver using plexus dependency mecanism :
/**
* @parameter expression="${
component.org.codehaus.plexus.archiver.UnArchiver#jsar}"
* @required
*/
private UnArchiver archiver;
With my other plugin defining a component in META-INF/plexus.xml :
org.codehaus.plexus.archiver.UnArchiver
jsar
org.codehaus.plexus.archiver.zip.ZipUnArchiver
This worked as expected when the unarchiver was defined in the
plugin that
uses the archiver, but not if the unarchiver is defined bu another
plugin. I
supose those plugins have separate classloaders.
Any workaround ?
2007/10/17, Brian E. Fox <[EMAIL PROTECTED]>:
Take a look at the dependency plugin for use of the unarchiver.
-Original Message-
From: nicolas de loof [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 17, 2007 10:33 AM
To: Maven Developers List
Subject: plexus classloader issue ?
Hello,
I've created a plugin that requires a plexus UnArchiver as
@component.
The expected Unarchiver is declared by another plugin, configured
as an
extensions.
All works fine when unit-testing the plugin using maven-test-harness,
but
when I try to use it from another project (it test) I get this
error :
Can not set org.codehaus.plexus.archiver.UnArchiver field
org.codehaus.mojo.javascript.AbstractCopyDependenciesMojo.archiver to
org.codehaus.plexus.archiver.zip.ZipUnArchiver
ZipUnArchiver implements UnArchiver ! So this seems to be a
classloader
issue. Do you have any idea what can be wrong in my config, or any
way
to
investigate ?
Nico.
-
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: pre-configuring self written plugins
Then I would configure the plugin in a group-specific parent pom. That way each team has it pre-configured the way they want. Andy On 20 Sep 2007, at 05:30, Jens Rapp wrote: i'm juggling with some svn repositories and pathes inside and outside them so i have several similar classes inside my mojo. because there are at least two small groups of people in my company which are using other repositories than the others, I need to configure them. But currently I don't know the svn server names. Original-Nachricht Datum: Wed, 19 Sep 2007 16:41:08 -0500 Von: "Wayne Fay" <[EMAIL PROTECTED]> An: "Maven Developers List" Betreff: Re: RE: pre-configuring self written plugins The defaults are in the source code, as you mentioned. Which will require compilation to change. So it sounds like your "requirements" cannot be met currently. Why don't you explain what exactly you're trying to achieve, and perhaps someone will have an alternate suggestion? Wayne On 9/19/07, Jens Rapp <[EMAIL PROTECTED]> wrote: well, i did this but i couldn't find where to set them- besides the declaration in the plugin's source code but i would have to recompile the plugin if those parameters are changed.. can you tell me where to find these defaults? Original-Nachricht Datum: Wed, 19 Sep 2007 09:33:01 -0400 Von: "Brian E. Fox" <[EMAIL PROTECTED]> An: "Maven Developers List" Betreff: RE: pre-configuring self written plugins Parameters in your plugins can have defaults. Take a look at any of the maven plugins for examples. -Original Message- From: Jens Rapp [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 8:29 AM To: dev@maven.apache.org Subject: pre-configuring self written plugins hi there! is there any way to pre-configure my own maven plugin so that i am able to create and modify a standard config without re-compiling? i don't want the users to be forced to configure some parameters by themselves. -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/ freemail --- -- 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] -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser - 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] -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - 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: [PROPOSAL] Local Repository Separation
It will most likely work in small development environments. What jason is saying is that it is not so likely to in corporate environments with more than one subnet. Andy On 1 Sep 2007, at 17:59, Nigel Magnay wrote: I guess ymmv, but I've never had zeroconf not work in development environments (we use the log4j zeroconf extensions all the time). Some services deliberately set hopcounts low if they're providing something particularly localized. Anyway - I wouldn't suggest it as the only mechanism (and it's something you could do as in a mojo), just something that becomes easier if you don't have inconsistent repository IDs. On 01/09/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: On 1 Sep 07, at 5:43 AM 1 Sep 07, Nigel Magnay wrote: A couple of really neat features, regardless of whether guids or some other identifying mechanism is used, would be 1) ability to use zeroconf (/bonjour) style networking to automatically configure your mirror settings In practice from experience I know that this doesn't often work very well as multi-cast is often suppressed on corporate networks, and multi-case DNS doesn't really work well across subnets. What does work well is DNSSD as you just need to make the DNS server browse- able, push SRV records into the system and then any tooling can find your configuration mechanism. This works very well, but so does just checking in a copy of Maven that a team uses and sharing the m2_home/ conf/settings.xml. But the DNSSD is very handy but we had to hack up the existing implementations to make it work probably. For this proposal I think it boils down to the ephemeral versus non. I think there is an easier way to do what is proposed. 2) for repositories themselves to contain a bit more metadata about the repository itself - what it does and doesn't contain for example. In one of our large builds, we have quite a lot of repositories, and the daily 'ask every repo if it has a new SNAPSHOT' was sped up considerably by configuring proximity to say 'no' to most paths. On 01/09/07, Stephen Connolly <[EMAIL PROTECTED]> wrote: Jerome Lacoste wrote: On 8/31/07, Brett Porter <[EMAIL PROTECTED]> wrote: Yeah, I meant to note that - I was thinking that this should be accompanied by a proposal to take care of the id ambiguity problems which we've discussed a couple of times before. I think URLs are still problematic (since you can often have different ones for the same location), though are a bit more robust than IDs. We could hash them to generate the directory name in the repository. What do others think? How are workspaces identified ? a hash of the current directory ? Something related to the project one is working on ? Something related to the current process ? Cheers, Jerome -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Would a better option be to have the repositories store a identifying GUID in their root URL. That way mirrors would pick up the same GUID and be identified as the same repository. Of course then there's the question, should an aggregating mirror return the GUIDs of all the repositories it aggregates or a unique hash. My feeling is it should return a unique hash, but maybe it could return information about it aggregating other repositories... thus: The repository-id.xml for an aggregate repository could be something like ACME Corp's Aggregated Proxy Repository 1234-663a-7766-aabbef45-3244 7688-364a-a7f6-1234567-f56e bcd3-5432-8899-9876543-acbd While repo1.maven.org could be: Maven Central Repository 7688-364a-a7f6-1234567-f56e And, say java.net2 (http://download.dev.java.net/maven/2) could be Java.net's Maven2 Repository bcd3-5432-8899-9876543-acbd The advantage I see is that existing clients will not be looking for the repository-id.xml file, so they won't care. If we can't find a repository-id.xml file for the repository, we generate a GUID on the client and store a mapping of URLs to GUIDs in a file in ~/.m2/ so that a user can control the mapping of these autogenerated GUIDs --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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: Using alternate pom files
I would have thought that a combination of classifiers and profiles with a decent DependencyManagement should do it. Make activating a profile at any level will change mydep-1.0 to mydep-1.0-jdk1.4 thoughout the tree. Of course you would need to be sure that the depManagement covered every single artifact that needs this treatment... Andy On 10 Sep 2007, at 18:51, Paul Gier wrote: Basically the problem with using profiles is that it really complicates how the transitive dependencies work. I have to make sure that the correct profiles are activated throughout the dependency tree. I added a comment about this to the jira issue: http://jira.codehaus.org/browse/MNG-3150 Since there is an existing feature to use an alternate pom file, it seems to make sense to me that a multi-module project should also be able to use this feature. Jason van Zyl wrote: On 7 Sep 07, at 9:31 AM 7 Sep 07, Paul Gier wrote: I submitted a small patch for this issue: http://jira.codehaus.org/browse/MNG-3150 The basic idea of it is to be able to use alternate pom.xml files in a multi-module project. Can someone with commit access take a look at this? It would really help with some of our projects if this can be added to a future release. Not sure this is a great idea. Why aren't you using profiles? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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]
Re: Doing alpha releases faster
Frequent, fast releases sure would help - but I am not sure they are always a good idea, say (as many do) that an API break is needed in the alpha code - I'm not sure that should pass by on the fast track, it could cause problems with those in the wrong time zone not being able to comment. Andy On 10 Sep 2007, at 17:59, Jason van Zyl wrote: Hi, For 2.1 I have been trying to lock down all the versions so that the dependencies are stable. When I need to fix something in classworlds, plexus, or modello, I just make the fix, install, test and if everything works deploy it and lock down the versions in the build and continue. I would like to do the same with maven-artifact and get a little more agile, and not force people to use a snapshot. For alphas I think it would be acceptable to get 3 +1s from PMC members and then push it out. For anything in beta or beyond it's the standard procedure, but pushing out an alpha or incremental release just takes too long and it is in those times of flux that the bugs in the snapshot mechanism bite you. I think this will also force us to start changing things to what they are. Doxia for example should probably be a beta, not an alpha. I want to be able to fix things in maven-artifact as using SNAPSHOTs is not good for external dependencies, but I don't want to be grounded for 3 days while I wait to release maven-artifact in order to pick up a stable set of changes. We can use timestamps too I suppose, but then what's the difference really. I just want to get the 2.1 release out faster. Maven artifact is simply no where near being usable for 2.1 and it's going to change as it will be one of the first proposals I will put on the table after the first series of alphas to fix the bugs, regressions, and usability. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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: Using Maven Artifact in 2.0.x
Yes, I would think it is a good plan to see as much shared between 2.0.x and 2.1 as possible, except the core codebase of course ;) Andy On 11 Sep 2007, at 03:40, Jason van Zyl wrote: Hi, How do people feel about trying to use maven-artifact in 2.0.x? The code has not changed, and backward compatibility will be maintained, and from Mark's trials it appears to work. Is this correct Mark? The ITs run using the decoupled version? The question is what are the criteria to decide if this is viable? 1) All plugins using the old artifacts must work (we need those smoke test projects in plugins) 2) Code must be binary compatible (easy to check with clirr) The only thing I can see as a problem right now is if people directly depend on maven-artifact-manager (would you guess that's the api?) then without a modification for the request of that would cause a problem. This needs to be fixed in 2.1 as well and I was just going to flip any requests for org.apache.maven:maven-artifact org.apache.maven:maven-artifact-manager org.apache.maven:maven-repository-metadata into a request for org.apache.maven.artifact:maven-artifact which containers everything required. A little artifact filter would do the trick. We are going to have to maintain backward compat in maven-artifact for a long time anyway because of plugins using it directly. We are going to have to support 2.0.x for a long time and having to maintain divergent copies of maven-artifact will very much suck ass. Maven 2.0.x is going to be used for a long time, and that's fine, but the easier to maintain the better. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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: [vote] release maven-verifier 1.1
+1 On 7 Sep 2007, at 07:17, Jason van Zyl wrote: Hi, I would like to release the maven-verifier as it's used as part of Maven's integration tests and would like to stop using the snapshot in order to prepare for the 2.1-alpha-1. The staging area is here: http://people.apache.org/~jvanzyl/maven-verifier-1.1-staging- repository/ There are no JIRA issues in the shared component, it just needs to be released. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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: [vote] bring shade-maven-plugin to apache
+1 I think anything that maven needs to bootstrap itself should be
considered core ;)
Andy
On 3 Sep 2007, at 03:37, Brian E. Fox wrote:
The shade-maven-plugin is currently in the codehaus mojo sandbox. This
plugin is used by maven core to package the uberjar for
distribution and
should be moved to the maven project.
Please vote {+1,0,-1], vote is open for 72 hrs.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
Oops, I just wrote something similar in the other vote thread. Agree entirely, but the enforcer is not the right place for it, perhaps a plugin-manager plugin or such. Andy On 2 Sep 2007, at 19:33, Arik Kfir wrote: Hi, As a heavy Maven **user**, what would be best for us is having some plugin (could be the enforcer, or another) automatically generate this configuration for us into the POM. Something along the lines of: mvn enforcer:lock-plugins This command will find the most appropriate version of relevant plugins and modify my POM(s) to explicitly specify them. Later on, I can either manually modify my POM when I want to upgrade a plugin, or run another command, e.g: mvn enforcer:update-all-plugins or: mvn enforcer:update-plugin -DgroupId=org.apache.maven.plugins-DartifactId=maven-jar-plugin -Dversion=latest/2.9.9.9 Current behavior should remain, if only not to upset the many non- enterprise users which use Maven more "lightly". HTH, Arik. On 9/2/07, Dan Tran <[EMAIL PROTECTED]> wrote: B Totally agree with Wayne here. -D On 9/2/07, Wayne Fay <[EMAIL PROTECTED]> wrote: [X] (B) Retain the current behaviour, but make using the enforcer a best practice to do the above, or some other control mechanism such as having the repository manager handle the available plugins I am thinking about the new user experience and winning more converts. As such, I think the current behavior is best. Once they get using Maven more seriously (and in corporate environments that know what they're doing), I think adding the Enforcer configuration and locking versions down will come naturally. But *requiring* it seems excessive -- unless we're doing that ourselves somewhere, with plugin packs or similar, then I feel better about it. Wayne - 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]
Re: [poll] Need for plugin packs / mixins for plugins
E) Specifying a a list of plugin versions in a pom snippet (better than plugin packs) is (as I see it) adding maintenance overhead that could become intrusive in some organisations. Why can we not just have a plugin (that maven suggests running if it seems missing version numbers) that updates your pom to specify the latest version of any plugins that are not currently stipulated. Running this on a parent pom in any organisation should eliminate the need for mixins or packs. On 2 Sep 2007, at 03:53, Brett Porter wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated "standard plugins", please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/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: [vote] adopt Continuum instance on zone as part of the project infrastructure
+1, deploying to snapshot repo would be good too. Andy On 21 Aug 2007, at 03:38, Brett Porter wrote: Hi, Continuum has been running on the zone for a while. Some people have been watching the results vigilantly, but others have probably missed them, or presumed them erroneous. There are builds that are failing because of errors that haven't been caught (and it's picking up a lot more now due to the plexus container changes). We obviously need a CI solution. I've been trying off and on to fix things, but it seems every time one gets done, another breaks :) With the exception of the weekend's hiccup due to SVN being down, I'm confident that Continuum is producing accurate results. The current failures all occur on my own development machine. It is already set up, I can add it to the infrastructure monitoring, and we have a couple of volunteers that will make sure it stays healthy and upgraded. I'm not sure if a vote is the right measure here, but I think it'd be good to get some agreement that we all should take notice of the messages to [EMAIL PROTECTED] from it. So, I vote to start paying attention to Continuum's complaints, and nagging people who break things :) If this carries, we can also start to investigate other useful things like automated snapshot deployment. This is a 72-hour vote, to be carried by simple majority of committers that vote (ie more +1's than -1's). [ ] +1 [ ] 0 [ ] -1 - Brett - 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: Functional tests for maven-assembly-plugin
It seems it was mistakenly compiled against the wrong version, I have corrected this in SVN, but not yet uploaded a new snapshot - the versions in svn and repository seem out of alignment... Is the beta-6-SNAPSHOT being run in a branch, or are the site plugin developers changing the version string when they deploy? cheers, Andy On 20 Aug 2007, at 08:10, James William Dumay wrote: Brett, I'm running it here on JDK 1.4. Seems maven-site-plugin 2.0-beta-6-SNAPSHOT is JDK 1.5 only? ~James [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6- SNAPSHOT:attach-descriptor': Unable to find t he mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6- SNAPSHOT:attach-descriptor' in the plugin 'org.apache.maven.plugins:maven-site-plugin' org/apache/maven/plugins/site/SiteDescriptorAttachMojo (Unsupported major.minor version 49.0) On Mon, 2007-08-20 at 16:44 +1000, Brett Porter wrote: They all passed for me locally. John - how often do you want these running in CI? every commit, or a forced nightly build? - Brett On 20/08/2007, at 4:41 PM, James William Dumay wrote: Hey guys, As far as I can tell the integration tests are failing for the maven-assembly-plugin Can the IT's please get a build in ci soon? Thanks James On Fri, 2007-08-17 at 13:38 +1000, Brett Porter wrote: Correct. Given they take about 20 minutes, I think we'd want this on a less frequent schedule, though. John? wdyt? - Brett On 17/08/2007, at 1:25 PM, James William Dumay wrote: Hey Stéphane, That worked for me! Thanks heaps :) Are they being actively ran in Continuum ? I checked yesterday and that build seemed only to run the goals "clean install" Thanks James On Thu, 2007-08-16 at 09:29 +0200, Stephane Nicoll wrote: Howdy Atlassian folks, On 8/16/07, James William Dumay <[EMAIL PROTECTED]> wrote: Hey guys, It seems that the functional tests for the maven-assembly-plugin are not being used. There is nothing in the pom file that gets them to run and they are not being compiled. Have you double checked ;-) mvn -Pintegration-tests integration-test HTH, Stéphane Just like to know whats happening so I can test my additional functionality. Cheers -- James William Dumay <[EMAIL PROTECTED]> Atlassian Software Systems -- -- - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Capture all plugin-friendly APIs/facades in single maven-api artifact
I agree also, publicising a restricted API has got to be a useful thing for outside developers. I was trying to do the same with the plexus container but clearly that did not go so well! Andy On 15 Aug 2007, at 16:13, John Casey wrote: The only problem here is that the expression evaluator is meant to give access to build state, not components in the system...which is why the @component annotation is handled in a completely parallel subsystem. Obviously, plugins _can_ access basically any component in the container (which I'm a little queasy about too, I'll admit)...but it's much, much harder to document a free-for-all system like this, rather than restricting the documentation and interfaces of approved components to a distinct artifact/sub-website/etc. -john On Aug 15, 2007, at 10:59 AM, Brian E. Fox wrote: The expressionEvaluator already has a decent api for getting at most stuff (as demonstrated in the enforcer rules...especially the requirePluginVersionDefined rule), the trouble is you have to know what component you want or expression is available. Currently this is only accessible by reading the code and/or debugging maven itself. --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Move the maven-antlr-plugin to the mojo project
+1 Andy On 14 Jul 2007, at 16:33, Vincent Siveton wrote: Hi, The last release (beta) of maven-antlr-plugin was more than two years ago. We did some small enhancements. http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&pid=11123&fixfor=12931 A release could be done shortly but I would like to move the maven-antlr-plugin and maven-antlr3-plugin (in sandbox) to Mojo project. During the last year, I am the main committer on this project. Recently, David Holroyd provided a new plugin that supports Antlr v3, and submitted some patches. Unfornately, he is not an ASF committer. I could take care of David's patches but I think it should be good to give a new life of this project in the Mojo land. It would be more easy to give access to David, so he could maintain it as he wants. Vote is open for the usual 72 hrs. [ ] +1 [ ] 0 [ ] -1 Cheers, Vincent - 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: [vote] Release Maven Javadoc Plugin 2.3
+1 Andy On 16 Jul 2007, at 19:36, Vincent Siveton wrote: Hi, I would like to release the Maven Javadoc Plugin 2.3. The last release has been about 6 months ago. We solved around 30 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11138&styleName=Html&version=13304 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&pid=11138&status=1 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc- plugin-2.3/ Staging repo: http://people.apache.org/~vsiveton/staging-repo/ Site: http://maven.apache.org/plugins/maven-javadoc-plugin/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Cheers, Vincent - 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: Maven 2.1-alpha-1?
+1, though perhaps finishing the Taxonomy pages first might be a plan as I am sure an alpha of 2.1 will draw in new faces? Andy On 11 Jul 2007, at 16:15, John Casey wrote: Hi everyone, We've been trying for quite a long time to get into a mode of faster, more incremental releases. However, when it comes to actually doing this, we seem married to the idea of pushing out impressive feature lists with new releases. I'd like to call an end to that practice, and start pushing out a 2.1-alpha-1 release of Maven. No, it's not perfect. No, it doesn't have even the beginnings of some of the features we'd like to have in 2.1 eventually. Yes, there will be some regressions. But after all, this would be the first alpha release of the 2.1 minor version...so it's expected to be more of a quick sketch, and lacking some (perhaps important) details. 2.1-SNAPSHOT already has some interesting new capabilities. I'm sure I can't name them all, but I know that personally, I've enabled custom profile activators and the ability to preview the build plan before it's executed, among other things. We've (primarily Jason) been steadily improving the embedder support, and that's gotten pretty damn good at this point, too. I for one would like to start getting some feedback about the stuff we're working on out here, and I think putting together a packaged distribution is the best way to go about that. What do others think? -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/buildchimp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resource filtering thoughts...
It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.
Andy
On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
Yep. That's the #1 issue.I've completely given up on
trying to
get the string "${pom.version}" outputted into the file.
Ok, but why are you filtering a file with that in there? Do you need
filtering at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that solve
your
problem?
It has to do with creating an archtype. The pom.xml that we want
the archtype to create needs to have certain versions pushed in,
but other things in the pom should be left as is (or allow us to
escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template. (actually, that's what an
archtype is anyway). For those, we need the ability to not have
some thing substituted in.
Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can use
the velocity escaping mechanisms to leave certain expressions
untouched.
So for the short run I think updating archetype itself is the safest..
Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.
Depends on how we'll be escaping I guess..
-- Kenney
Dan
The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not. Kind of like:
(pseudocode, not sure on the velocity syntax)
#if ${pom.version}.indexOf("SNAPSHOT") != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with (1)
and instead of making "simple" the default if not specified in
the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the "Resource" object that the resources plugin uses
is maven-model defined. Not something that's extensible as that
requires a schema change.I suppose what COULD work well is to
add: velocityResources = List
configuration to the resources plugin (and if list is empty, look
for the default of src/main/velocity) and use that.In that
case,
"regular" resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration. A bit inconsistent, but acceptable.
After thinking about this a bit more, I wonder if it makes more
sense to just create a "maven-velocity-plugin" and ignore resources
all-together? That would be super quick to write.(I'd still
like
to see the escaping issue fixed. :-) We already have the
plexus
VelocityComponent. Would take very little work to wire it into a
plugin.
Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven
2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.
Well, if there's a good reason to change the schema then I'm all
for it. Maybe we should just add again to
dependencies
and resource sets, so the resource plugin can look at the
resourceset property 'filterType' or something, if it's set.
Either way, changes to the model won't happen until 2.1.
So, what's the problem with the filtering?
Getting any of the normal pom properties outputted to the target
file seems to be impossible.
-
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 command
Re: [VOTE] release maven-plugin-testing-harness 1.1
+1 On 9 Jul 2007, at 00:37, Brian E. Fox wrote: There have been tons of enhancements to the plugin testing harness since the last release in April. Several plugins require the new version before release. Tag: https://svn.apache.org/repos/asf/maven/shared/tags/maven-plugin- testing- harness-1.1 Staged at: http://people.apache.org/~brianf/staging-repository Vote is open for 72hrs, please +1/+0/-1 +1 Thanks, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate maven-patch-plugin from sandbox and release version 1.0
+1 Andy On 6 Jul 2007, at 16:08, John Casey wrote: Hi all, Jesse and I have been working on a patch plugin that I migrated over from mojo.codehaus.org into the ASF sandbox, and we feel it's ready for a release. I've prepared the documentation for a code grant on this project, and all the appropriate information should be committed in the plugin directory. The plugin is stable, has decent documentation, and even an integration-test suite. Therefore, I'd like to call a vote to graduate the patch plugin from the Maven sandbox, and do a 1.0 release. Please +1/+0/-1. I'll let this go for 72 hours. The release is staged at: http://people.apache.org/~jdcasey/stage/repo (repository) http://people.apahce.org/~jdcasey/stage/sites/maven-patch-plugin (site) Here's my +1. Thanks to Jesse for helping me get the plugin to this point. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Migrate ArchetypeNG to Apache & commit privs for Raphael
+1 good plan, Andy On 29 Jun 2007, at 07:28, Jason van Zyl wrote: Hi, After a fews weeks of sorting out some niggly details the new code new by default will produce a functional archetype without user intervention, and projects can be generated with the old and new archetype plugins. I asked that Raphael make some additions which generate the old and new descriptors so that anyone who had nailed down versions of their plugins by turning off updates will still be able to use new archetypes with the plugin they have on hand. You can still optionally enter interactive mode and the code is working well from the users perspective. The code can be refactored incrementally but will be a big improvement for users. I think Raphael has done a very good job and I think it's now ready to bring over here. I've been using the code for the last week trying it out with a Maven integration test archetype and it's working well. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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: [VOTE] Release Maven 2.0.7 (take 2)
+1 fixes my issues On 17 Jun 2007, at 18:47, Jason van Zyl wrote: Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=10500&styleName=Html&version=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ Thanks, Jason. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.7
I just noticed that the dav deploy is still broken (as in 2.0.6 I think) not a new problem, just checking folk were aware. Andy On 15 Jun 2007, at 14:17, Jason van Zyl wrote: On 15 Jun 07, at 6:09 AM 15 Jun 07, Brett Porter wrote: Can we restart the vote once this is sorted out? I have no idea which svn rev we are voting on any more, or who checked and voted for which. It is sorted out, I was planning on releasing it today. What's the problem? - Brett On 15/06/2007, at 10:56 PM, Brian E. Fox wrote: Ok, the last one I tested was Wed night. In that case +1. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, June 15, 2007 8:53 AM To: Maven Developers List Subject: Re: [VOTE] Release Maven 2.0.7 On 15 Jun 07, at 5:36 AM 15 Jun 07, Brian E. Fox wrote: Where are we on the 2.0.7 vote? It seems like there are some issues requiring a new RC such as licenses and notices, but I've lost track. The original RC was technically ok on my builds. I've updated them all, the licenses are fixed. This was with the source distribution so I just remade it, I didn't rebuild. I already fixed and closed the issues Brett was having and that I rebuilt and redeployed on Wednesday. Everything is still fine. -Original Message- From: Mark Hobson [mailto:[EMAIL PROTECTED] Sent: Friday, June 15, 2007 8:01 AM To: Maven Developers List Subject: Re: [VOTE] Release Maven 2.0.7 On 15/06/07, Andrew Williams <[EMAIL PROTECTED]> wrote: Am I the only one getting a test failure on IT0002 with the 2.0.7 bundle? junit.framework.AssertionFailedError: Expected file was not found: / Users/aje/.m2/repository/org/apache/maven/its/maven-core-it- support/ 1.0/maven-core-it-support-1.0.jar (yes, I did install the maven-core-it-support - but seems that / Users/ aje/.m2/repository/org/apache/maven/its/maven-core-it-support/ does not exist) Nope, I get it too - see my mail to dev regarding r546719. Mark --- -- 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] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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: svn commit: r547666 - /maven/core-integration-testing/trunk/core-integration-testing-support/build.sh
Apologies, you are quite right. Andy On 15 Jun 2007, at 14:08, Jason van Zyl wrote: On 15 Jun 07, at 5:59 AM 15 Jun 07, Andrew Williams wrote: Hmm, I think it is installing them, but under the wrong groupId. No, the old ones are deployed in the remote repository. The invoker plugin is broken. Andy On 15 Jun 2007, at 13:54, [EMAIL PROTECTED] wrote: Author: jvanzyl Date: Fri Jun 15 05:54:11 2007 New Revision: 547666 URL: http://svn.apache.org/viewvc?view=rev&rev=547666 Log: o little script to install all the support artifacts, as the invoker plugin doesn't seem to be doing it anymore. Added: maven/core-integration-testing/trunk/core-integration-testing- support/build.sh (with props) Added: maven/core-integration-testing/trunk/core-integration- testing-support/build.sh URL: http://svn.apache.org/viewvc/maven/core-integration-testing/ trunk/core-integration-testing-support/build.sh?view=auto&rev=547666 == --- maven/core-integration-testing/trunk/core-integration-testing- support/build.sh (added) +++ maven/core-integration-testing/trunk/core-integration-testing- support/build.sh Fri Jun 15 05:54:11 2007 @@ -0,0 +1,8 @@ +#!/bin/sh + +v="1.0 1.1 1.1-old-location 1.2 1.3 1.4" + +for i in $v +do + ( cd $i; mvn install ) +done Propchange: maven/core-integration-testing/trunk/core-integration- testing-support/build.sh -- svn:eol-style = native Propchange: maven/core-integration-testing/trunk/core-integration- testing-support/build.sh -- svn:executable = * Propchange: maven/core-integration-testing/trunk/core-integration- testing-support/build.sh -- svn:keywords = "Author Date Id Revision" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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: [VOTE] Release Maven 2.0.7
Thanks, that script does sort it for me :) Andy On 15 Jun 2007, at 13:55, Jason van Zyl wrote: On 15 Jun 07, at 4:58 AM 15 Jun 07, Andrew Williams wrote: Am I the only one getting a test failure on IT0002 with the 2.0.7 bundle? junit.framework.AssertionFailedError: Expected file was not found: /Users/aje/.m2/repository/org/apache/maven/its/maven-core- it-support/1.0/maven-core-it-support-1.0.jar (yes, I did install the maven-core-it-support - but seems that / Users/aje/.m2/repository/org/apache/maven/its/maven-core-it- support/ does not exist) You have to install all the support plugins and artifacts, and someone seems to have broke the invoker which installs the support artifacts. But once it's installed the ITs are fine. I added the tiny script I used here: http://svn.apache.org/repos/asf/maven/core-integration-testing/ trunk/core-integration-testing-support/ John, might you take a look? Maybe fix the invoker and release it? Andy On 13 Jun 2007, at 06:12, Jason van Zyl wrote: Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=10500&styleName=Html&version=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ Thanks, Jason. - 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] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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: svn commit: r547666 - /maven/core-integration-testing/trunk/core-integration-testing-support/build.sh
Hmm, I think it is installing them, but under the wrong groupId. Andy On 15 Jun 2007, at 13:54, [EMAIL PROTECTED] wrote: Author: jvanzyl Date: Fri Jun 15 05:54:11 2007 New Revision: 547666 URL: http://svn.apache.org/viewvc?view=rev&rev=547666 Log: o little script to install all the support artifacts, as the invoker plugin doesn't seem to be doing it anymore. Added: maven/core-integration-testing/trunk/core-integration-testing- support/build.sh (with props) Added: maven/core-integration-testing/trunk/core-integration- testing-support/build.sh URL: http://svn.apache.org/viewvc/maven/core-integration-testing/ trunk/core-integration-testing-support/build.sh?view=auto&rev=547666 == --- maven/core-integration-testing/trunk/core-integration-testing- support/build.sh (added) +++ maven/core-integration-testing/trunk/core-integration-testing- support/build.sh Fri Jun 15 05:54:11 2007 @@ -0,0 +1,8 @@ +#!/bin/sh + +v="1.0 1.1 1.1-old-location 1.2 1.3 1.4" + +for i in $v +do + ( cd $i; mvn install ) +done Propchange: maven/core-integration-testing/trunk/core-integration- testing-support/build.sh -- svn:eol-style = native Propchange: maven/core-integration-testing/trunk/core-integration- testing-support/build.sh -- svn:executable = * Propchange: maven/core-integration-testing/trunk/core-integration- testing-support/build.sh -- svn:keywords = "Author Date Id Revision" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.7
Am I the only one getting a test failure on IT0002 with the 2.0.7 bundle? junit.framework.AssertionFailedError: Expected file was not found: / Users/aje/.m2/repository/org/apache/maven/its/maven-core-it-support/ 1.0/maven-core-it-support-1.0.jar (yes, I did install the maven-core-it-support - but seems that /Users/ aje/.m2/repository/org/apache/maven/its/maven-core-it-support/ does not exist) Andy On 13 Jun 2007, at 06:12, Jason van Zyl wrote: Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=10500&styleName=Html&version=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ Thanks, Jason. - 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]
Re: Maven Project Website JIRA
Yeah, sounds like a plan On 7 Jun 2007, at 14:59, Brian E. Fox wrote: +1 -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 4:41 AM To: Maven Developers List Subject: Maven Project Website JIRA For folks like myself, Eric, Tim and Brett who are looking at cleaning up the website and integration with the wiki I think it would be a good idea to create the JIRA project for now. There is really no place for users to raise complaints about the organization of the site and anything we have done in the past is not listed anywhere for review. I think a project can be made now and it would be used if only by the four of us. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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]
Re: [VOTE] Release maven-idea-plugin 2.1
+1 On 4 Jun 2007, at 23:04, Dennis Lundberg wrote: Hi, I'd like to release maven-idea-plugin 2.1. There are 12 issues fixed in this version and the last release was made over a year ago. Release Notes: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11135&styleName=Html&version=12618 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-idea- plugin-2.1/ Staged at: http://people.apache.org/~dennisl/staging-repository-idea-plugin/ The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - 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: Please test Surefire 2.3.1 pre-release
This is on OSX, on just about all projects. I nuked the SNAP from my local just now and it pulled a new one, which does not fail. My apologies if this was fixed a couple of days back, I must have not got the update. Andy On 26 May 2007, at 02:50, Brett Porter wrote: Ok, need more info: - Platform? - what version of 2.3.1-SNAPSHOT do you have? Does it work with the latest (I fixed one windows related bug yesterday) - does it work if you add -Dsurefire.useSystemClassLoader = false? - Is this on a project I can test it on? Thanks, Brett On 25/05/2007, at 10:25 PM, Andrew Williams wrote: happens in both 2.0.x (2.0.5 to be precise) and 2.1 . Andy On 25 May 2007, at 00:54, Brett Porter wrote: Looks like a conflict with plexus-utils. If you're using Maven 2.1-SNAPSHOT, I'm going with you're fault (there's still a known issue with hiding there, right?); if you are using 2.0.x I'm going with my fault :) - Brett On 25/05/2007, at 2:55 AM, Andrew Williams wrote: Well, I don't know if I did something wrong, but since this email went out (possibly a few hours before) my tests all fail. I have to pin the surefire plugin to 2.3 for them to pass. Everything seems to fail with the following message: - Exception in thread "main" java.lang.NoClassDefFoundError: org/ codehaus/plexus/util/cli/StreamConsumer - There is no stack available. I will try to trace this later, but right now I wondered if it rang any bells at your end. Andy On 24 May 2007, at 12:29, Brett Porter wrote: Hi, The surefire 2.3.1 release vote is imminent, so I'd like to ask people to test the latest build. I'm particularly interested in those: - who can't use 2.3 because of a regression since 2.2 - who currently use 2.3 on Windows - who use different types of classloading configuration in tests To test the release, add the following to your pom: maven-surefire-plugin 2.3.1-SNAPSHOT If you want to download the snapshot, add the following snapshot repository to your POM: http://people.apache.org/repo/ m2-snapshot-repository Alternatively, you can build from source: http://svn.apache.org/ repos/asf/maven/surefire/branches/surefire-2.3.x Thanks! - Brett -- --- 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] - 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]
Re: Please test Surefire 2.3.1 pre-release
happens in both 2.0.x (2.0.5 to be precise) and 2.1 . Andy On 25 May 2007, at 00:54, Brett Porter wrote: Looks like a conflict with plexus-utils. If you're using Maven 2.1- SNAPSHOT, I'm going with you're fault (there's still a known issue with hiding there, right?); if you are using 2.0.x I'm going with my fault :) - Brett On 25/05/2007, at 2:55 AM, Andrew Williams wrote: Well, I don't know if I did something wrong, but since this email went out (possibly a few hours before) my tests all fail. I have to pin the surefire plugin to 2.3 for them to pass. Everything seems to fail with the following message: - Exception in thread "main" java.lang.NoClassDefFoundError: org/ codehaus/plexus/util/cli/StreamConsumer - There is no stack available. I will try to trace this later, but right now I wondered if it rang any bells at your end. Andy On 24 May 2007, at 12:29, Brett Porter wrote: Hi, The surefire 2.3.1 release vote is imminent, so I'd like to ask people to test the latest build. I'm particularly interested in those: - who can't use 2.3 because of a regression since 2.2 - who currently use 2.3 on Windows - who use different types of classloading configuration in tests To test the release, add the following to your pom: maven-surefire-plugin 2.3.1-SNAPSHOT If you want to download the snapshot, add the following snapshot repository to your POM: http://people.apache.org/repo/m2-snapshot- repository Alternatively, you can build from source: http://svn.apache.org/ repos/asf/maven/surefire/branches/surefire-2.3.x Thanks! - Brett - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please test Surefire 2.3.1 pre-release
Well, I don't know if I did something wrong, but since this email went out (possibly a few hours before) my tests all fail. I have to pin the surefire plugin to 2.3 for them to pass. Everything seems to fail with the following message: - Exception in thread "main" java.lang.NoClassDefFoundError: org/ codehaus/plexus/util/cli/StreamConsumer - There is no stack available. I will try to trace this later, but right now I wondered if it rang any bells at your end. Andy On 24 May 2007, at 12:29, Brett Porter wrote: Hi, The surefire 2.3.1 release vote is imminent, so I'd like to ask people to test the latest build. I'm particularly interested in those: - who can't use 2.3 because of a regression since 2.2 - who currently use 2.3 on Windows - who use different types of classloading configuration in tests To test the release, add the following to your pom: maven-surefire-plugin 2.3.1-SNAPSHOT If you want to download the snapshot, add the following snapshot repository to your POM: http://people.apache.org/repo/m2-snapshot- repository Alternatively, you can build from source: http://svn.apache.org/ repos/asf/maven/surefire/branches/surefire-2.3.x Thanks! - Brett - 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: Dep to same artifact in different versions
On 26 Apr 2007, at 13:20, Jörg Schaible wrote: Hi Jason, Therefore the slots. The project itself can introduce them, if two major versions can be used at same time. Think about a hypothetical commons-logging 2.0 (it is discussed) that might have a different API. I am quite sure Jakarta folks will ensure that 2.x and 1.x series can be used at the same time - simply because even in the Maven repo itself ~ 2000 artifacts depend on it. Without something like the slots, you will never be able to create a new Maven-based project using JCL 2.x ... Well kick me if I am wrong, but is this not where well managed projects use deprecation and wrappers around the new code to work from the old API? I know plexus and classworlds are trying to for backwards compatibility. What rule states that commons-logging 2.0 cannot contain the api from commons-logging 1.0 with deprecated marks? I doubt that everytime someone wants to change their API they would much rather do that than make a mutually exclusive, thusly cohabitable, API for the new version. Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne
Well, I am available just about any time, so I shan't put my free times on the calendar, it will just take up space :) Andy On 25 Apr 2007, at 19:10, Jason van Zyl wrote: Cool, John setup a calendar and if we all put available times there then I can propose some meeting times. With a little notice there is no problem getting space at the Terracotta offices. They have a big conference room with whiteboards we can use and they are fine with giving us the room for a couple days. So we can definitely do a BOF there and some working sessions. Thanks, Jason. On 25 Apr 07, at 12:14 PM 25 Apr 07, Carlos Sanchez wrote: I'll be at J1 too On 4/25/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, We can certainly continue any discussions from ApacheCon at JavaOne and I have chatted with the folks at Terracotta and they would be happy to put us up for a couple days in one of their conference rooms where we can work and hold a BOF if we so choose. We can also have a conference room for a 2-3 days in succession so we have a place to continue discussions once things get started. So again we might want to put up a calendar and let people slot in their available times and I will schedule the rooms at TC. They are not that far from Moscone centre and we can easily get there quickly by cab, I can probably organize some transportation as well. Thanks to the folks at Terracotta as it's generally hard to get facilities setup where people can actually work. There's room for 10-15 people so folks should probably sign up soon, or let me know. I know for sure that myself, Eric Redmond, Kenney Westerhof, Andy Williams, John Casey, and Brett Porter will be present. If we select a date for a BOF then I can definitely schedule that. It would be a great opportunity for any users in the area to come out as it will probably be the highest concentration of core committers on record! :-) Just ping me if you're interested in attending something so I can make arrangements with Steve Harris at Terracotta. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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]
Re: [VOTE] Release Clover plugin v2.4 - Take 2
+1 On 15 Apr 2007, at 19:55, Vincent Massol wrote: Hi, As Mike Perham pointed out the Clover license for the release clover plugin (ie v2.3) has expired. Thus the urgency to release version 2.4. Here's the release notes for 2.4: ** Bug * [MCLOVER-45] - Excluded files should be added to compiled sources * [MCLOVER-53] - Clover plugin installs clover instrumented source in local repository * [MCLOVER-66] - The report goal doesn't support a user- provided Clover license * [MCLOVER-68] - XDoclet plugin executes before the Clover plugin in the lifecycle forked by the latter ** Improvement * [MCLOVER-38] - Allow check Mojo to be overriden by a failOnViolation parameter in the same way PMD and Checkstyle can * [MCLOVER-65] - Clover license has expired ** Task * [MCLOVER-67] - Remove deprecated licenseFile configuration parameter The plugin is staged at http://people.apache.org/~vmassol/maven- staging/ Here's my +1 Thanks -Vincent - 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: Remove auto-resolution of plugin versions from Maven 2.1
Actually, that is an interesting point, it could include that. Enterprise is aimed more at the development cycle, but that could easily include a "known stable and compatible with this toolset" maven release. Andy On 13 Apr 2007, at 14:01, David Roussel wrote: Hmm, that's a good idea. A Maven distribution based on a given Maven release. Is this like what "Maven Enterprise" will be? John Casey wrote: Sure, my only point was that without this (and the standard packaging definitions) _nothing_ will work...it's just a gut-level uneasiness, not necessarily a big problem. On a side note, I think it'd be neat to provide a maven distro that has a small internal repo with the latest releases of the plugins in the pom and jar lifecycles...maybe with the packaging/super-POM in there too...then, you could always override and get from central. That would make Maven almost offline-proof right out of the box... -john On 4/12/07, Hayes, Peter <[EMAIL PROTECTED]> wrote: Right I get that. That would be pretty annoying. Maybe instead of a parent POM, an import facility could be used that can grab the same centralized POM (Multiple-inheritance almost :-). To John's comment, I don't see this being a big offline challenge as this centralized POM would be a released version that could safely be cached in a local repository, like any other artifact, i.e. it would follow the snapshot / release methodology. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 10:10 AM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Same here. -Original Message- From: Stephane Nicoll [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 9:02 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Won't work every time. We have a corporate pom, it's pretty much stable and it won't change often. All our projects inherit from that one, it will be a pain to update everything every time we would want to upgrade some plug-ins. Stéphane On 4/12/07, Hayes, Peter <[EMAIL PROTECTED]> wrote: I'd like to give my 2 cents on this issue. Would it be possible to maintain a super POM on repo1 that contains a vetted set of plugin versions and then version that POM appropriately based on new releases of core plugins? Then it would simply be an inclusion of a specific parent version in a project POM that would control which plugins to take. I think this is what people probably do internally but if it is maintained on repo1, it would save a lot of work for a lot of people. Peter -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:40 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 If I need a specific version (usual to workaround a known issue) then I specify it in the the pom. Otherwise I want the latest. This is the current problem, where builds are done with undetermined versions. (ie the version for dev a might not match dev b) For snapshot builds if I will use specified, then latest. For a released build, I want the pom to be transformed and fully locked down so that the build is reproducible. And I don't want to do that manually. I would expect that my snapshot builds to be exactly the same as the eventual release build for that version. The last thing I need is release to decide for me which versions to use. I do want to do it manually, because I want to try out each new plugin before I bless it and allow it into the build process for the rest of the team. I've had too many occurrences where a plugin change breaks my build (I'm ok with that, it's necessary for forward progress). By manually vetting a plugin, it gives me a chance to make any adjustments needed. It's no different than how we upgrade Maven itself: I have used enforcer to lock my build to 2.0.5 until I can get all the depMgt straightened out and then I will move everyone forward. --- -- 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] - 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] -- View this mess
Re: [VOTE] maven-remote-resources-plugin 1.0-alpha-5
+1 On 12 Apr 2007, at 18:13, Daniel Kulp wrote: I'd like to release version 1.0-alpha-5 of the maven-remote-resources-plugin. This resolves one critical bug, but also adds some new features to make it a bit more usable. Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0- alpha-5 ** Bug * [MRRESOURCES-18] - Error when no 'inceptionYear' is specified in POM ** Improvement * [MRRESOURCES-19] - Bundle mojo only looks for txt and vm files * [MRRESOURCES-20] - Support for binary resources * [MRRESOURCES-21] - Supplement the data model used by Velocity Staging area: http://people.apache.org/~dkulp/stage_remoteresources/ Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote- resources-plugin-1.0-alpha-5/ -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - 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: [Vote] Move plugin site.xml up to Maven or Shared
apart from the css glitch it seems good. Andy On 8 Apr 2007, at 04:12, Brian E. Fox wrote: I moved the site stuff up to the main maven pom. I staged the maven main site here: http://people.apache.org/~brianf/maven/ I think this is pretty good. I also staged a shared component to see how it looks by inheriting the info here: http://people.apache.org/~brianf/enforcer/ The problem is that the shared component page now is setting class="externalLink" for most of the links in the header. This class has extra right padding and messes it up. I'm not familiar enough yet with the site and related tech to know how to fix this. It seems like changing the skin isn't what we want, somehow we need to tell site not to make these externalLinks. Also, the plugin and shared sites should have the version and published date as they currently do. However when you add the breadcrumbs, you can't seem to force them to be on the far left. I think the version and published date should be to the right of the breadcrumbs to make everything consistent. Pointers? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Saturday, April 07, 2007 10:04 PM To: Maven Developers List Subject: Re: [Vote] Move plugin site.xml up to Maven or Shared Makes sense. Another option is to have those links in the bottom of the left nav on every site too. I'm not against either of those solutions, as long as the links section isn't too bloated. I can certainly see the merits in consistency of the header section. - Brett On 08/04/2007, at 11:56 AM, Brian E. Fox wrote: I agree they may be irrelevant for most plugins. However, the more consistent the header, the more tied together everything feels. I actually am always jumping around from section to section (almost always a maven.apache.org page open in a tab already) and it's nice to have those links right there all the time. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Saturday, April 07, 2007 9:47 PM To: Maven Developers List Subject: Re: [Vote] Move plugin site.xml up to Maven or Shared I definitely agree with the breadcrumbs on the left. I don't mind where the publish date goes as long as it's consistent (maybe bottom is more suitable/traditional). For the links, I find them to be too noisy with all the subprojects. On the main site these were put into the left nav. I think these links are intended to be used for contextual links - how often are you on a plugin site and decide to go to Continuum? So maybe the main site contains those links (though I'd be happy to aggregate frameworks under one link to a subpage), but the plugin sites just link to the things relevant to that plugin (eg, the release site links to the scm site, as does continuum, etc). The breadcrumbs really look after the main navigation from there. WDYT? On 06/04/2007, at 11:03 PM, Brian E. Fox wrote: I will make the changes and stage the main site before pushing it out. What are we doing with the links that are present on plugins but not on the main site? It seems to me that they should be the same in both locations (either with or without). I think it makes sense for them to be the same. What's the delta? The plugins (not the plugins list page, but the plugins themselves) page has all the maven tech on the right (Maven 1.x |Maven 2.x | Maven 2.x Plugins | Continuum | SCM | Wagon | JXR | Doxia). It does not have the "cookies" or "track marks" in the top left. They have the Last Published on the left. Example: http://maven.apache.org/plugins/maven-resources-plugin/ The main maven pages do not list and of the maven tech stuff. The Published date is on the right instead. On the left are the track marks "Apache > Maven" Example: http://maven.apache.org/ It would make the most sense to me is to have track marks on all pages in the top left followed by the publish date. Then have the maven- tech on the top right. This presents a consistent navigation experience throughout the entire site. - 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] - 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 comm
Re: [VOTE] Release maven-skins pom 3
+1 On 3 Apr 2007, at 21:36, Dennis Lundberg wrote: Hi, I'd like to release maven-skins pom 3. This is in preparation of a patch release of maven-stylus-skin. Since it is not possible to use the release-plugin to release a parent pom like this one, I'm offering you a diff between the last release and the proposed new release, instead of something staged. Diff: http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml? r1=517329&r2=389094&diff_format=h The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - 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: [Vote] Move plugin site.xml up to Maven or Shared
[X] Move to Maven Pom, with the note that extra site.xmls might be nice for breadcrumbs and extra links etc. Andy On 3 Apr 2007, at 03:39, Brian E. Fox wrote: Currently only plugins get a nice looking skin that matches the main maven.apache.org page because the site.xml exists in the plugin project. Other things like shared get a homely looking default skin. I see two options here: 1. Move the site.xml up to the maven pom. This is preferred so that all submodules of maven can get the standard skin and override it if they choose. 2. Copy the site.xml over to the shared pom. This is less intrusive but doesn't cover all submodules that come along. Vote: [ X ] Move to Maven Pom [ ] Copy to shared Vote is open for 72 hrs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Ant Tasks 2.0.6
+1 Andy On 4/1/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, The staging repository is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/ The uber jar that people will want to try is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/org/apache/maven/maven-ant-tasks/2.0.6/ Road map: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&&pid=11533&fixfor=13351&sorter/field=issuekey&sorter/ order=DESC Thanks, Jason. - 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: War plugin and Overlays handling
On 21 Mar 2007, at 07:04, Stephane Nicoll wrote: Hi, On 3/21/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: Will the use of this new overlay cause the transitive dependencies of the overlayed wars to be resolved and included? I currently construct wars that I intend to be used as overlays by excluding all the jars. I do this to avoid conflicts but also to reduce the size in the repository. Unfortunately because I'm using a very old version of mwar, I have to manually keep my war project dependencies synchronized. If these transitive dependencies from the wars are automatically pulled in, then I think it's safe to also exclude WEB-INF/lib by default from the overlays. I think we'll have an excellent solution at that point. The proposition sticks to a simple overlay which does not resolve the transitive dependencies, that's a very good point. We could even put a default exclude on WEB-INF/* for overlays that are not the current build (?). This will also solves the issues of people having multiple time the same dep with a different minor versions in the resulting war. Erm, does that not mean that all classes from other wars will be omitted? Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Splitting the stable and unstable repositories
Not entirely sure I agree with this point. Another level of complexity to get round this issue? surely if folk have any problems they can use dependencyManagement and pluginManagement to solve the same issue? I know plenty of folk who barely know why to separate snapshot from release repositories, I think adding another split will just raise the bar of easy adoption... Andy On 29 Mar 2007, at 00:46, Brett Porter wrote: Hi, I didn't want to pin the assembly plugin vote to this, but it seemed like a good opportunity to bring this up. I'd like to propose we split the stable repository from the unstable repository (which would be where alphas, betas and rcs get deployed), and make this a documented best practice. This would not be a concept change in Maven (at least, yet - it could be something to consider in the versioning in future): it's simply two types of release repositories. The stable one would be included in Maven by default, the unstable/pre-release one would not. You'd have to add the repository to your project. I would suggest this for future additions to central, but leave anything currently there in place for backwards compat. I think this is a good all round concept, but there is a particular practical problem that we should do this for: unpinned plugin versions. In the specific example of the assembly plugin - if you don't request a version (ie, use latest release), or you said [2.1,), then you'll get the 2.2-beta-1 release which is presumably less stable than 2.1. The same rationalisation would apply to ranges used in any dependency, but thats the biggest use case I can think of that affects people today. It would allow us to do more regular test releases of the plugins. Thoughts? - Brett - 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: [VOTE] Release Maven 2.0.6
+1 I have discovered a very small issue with it to do with bad error messages but it is not regression, so I say go ahead too. Issue filed in JIRA set for 2.0.7 ;) Andy On 27 Mar 2007, at 03:55, Jason van Zyl wrote: Hi, The roadmap is here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&pid=10500&fixfor=13010 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/ Staging repository: http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/ org/apache/maven/maven-core/2.0.6/ Thanks, Jason. - 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: [VOTE] maven-dependency-plugin 2.0-alpha-4 AND maven-dependency-analyzer 1.0-alpha-2
+1 Andy On 25 Mar 2007, at 06:21, Brian E. Fox wrote: I'd like to release maven-dependency-plugin:2.0-alpha-4 and the shared maven-dependency-analyzer 1.0-alpha-2 that it depends on. Tags: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency- plug in-2.0-alpha-4/ http://svn.apache.org/repos/asf/maven/shared/tags/maven-dependency- analy zer-1.0-alpha-2/ Staged at: http://people.apache.org/~brianf/staging-repository Changes: Fixed several issues related to the new analyze and analyze-dep-mgt goals: Release Notes - Maven 2.x Dependency Plugin - Version 2.0-alpha-4 ** Bug * [MDEP-72] - "IllegalArgumentException: Cannot accept visitor on URL" when project contains a non-jar (e.g. zip) dependency * [MDEP-73] - dependency:analyze in a packaging=pom project should skip, not die or produce a redundant report * [MDEP-74] - dependencies in test scope are not handled properly by analyze * [MDEP-77] - dependency:analyze is reporting impossible results * [MDEP-78] - analyze-dep-mgt has the labels reversed * [MDEP-79] - index out of bounds exception on analyze against maven-war-plugin ** Improvement * [MDEP-76] - It would be nice to analyze dependencyManagement exclusions as well as versions Vote is open for 72 hours. +1 - 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: Test failure on trunk
I assumed that there was a leak or something weird and that it would get addressed. I have certainly seen it compile and test fine without it before, recently too, so I know it is possible... Andy On 22 Mar 2007, at 15:46, Thierry Lach wrote: Any reason why this couldn't just be added permanently? On 3/22/07, Andrew Williams <[EMAIL PROTECTED]> wrote: I sometimes get that problem too, when I see it I insert the following into the section of continuum's root pom.xml org.apache.maven.plugins maven-surefire-plugin -Xmx512m org.apache.maven.plugins maven-compiler-plugin true 128m 512m Andy On 19 Mar 2007, at 22:59, Graham Leggett wrote: > Emmanuel Venisse wrote: > >> how many memory is allocated to the build? Normally the default is >> enough. > > No idea - checked out a pristine copy of trunk as of an hour or two > ago, and did an mvn install. > > Is there somewhere where memory allocations are set, perhaps in a > pom file? > > Regards, > Graham > --
Re: Whats wrong with Maven at the moment - maven-site-plugin fails!
+1 very useful for sane defaults to be around, and I think maven is the right context to have them set. Andy On 22 Mar 2007, at 14:54, Jason van Zyl wrote: On 22 Mar 07, at 10:41 AM 22 Mar 07, Daniel Kulp wrote: On Thursday 22 March 2007 10:28, Jason van Zyl wrote: Sure, once I'm done with some 2.0.6 stuff I finish off Doxia stuff. I might look at the Wagon permissions because it's becoming infinitely irritating. I have several settings.xml files for testing various things and, of course, the one I used didn't have the perm entries. Geronimo keeps running into this over and over as well. Yea!!! Seriously, we ended up putting a cron job on our internal repository that every 15 minutes goes through and resets all the permissions to something sane. I got too fed up with developers not setting things correctly. I kind of decided it was easier to let them just do the wrong thing and have a process that automatically fixes it. I am thinking that we leave Wagon policy agnostic and I'll just push the change into Maven so that it pops in some sane defaults. These are the policies that we want for Maven deployment. Not everyone using Wagon may want this set by default but I think it's a sensible default for Maven deployments. Jason. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - 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]
Re: Test failure on trunk
I sometimes get that problem too, when I see it I insert the following into the section of continuum's root pom.xml org.apache.maven.plugins maven-surefire-plugin -Xmx512m org.apache.maven.plugins maven-compiler-plugin true 128m 512m Andy On 19 Mar 2007, at 22:59, Graham Leggett wrote: Emmanuel Venisse wrote: how many memory is allocated to the build? Normally the default is enough. No idea - checked out a pristine copy of trunk as of an hour or two ago, and did an mvn install. Is there somewhere where memory allocations are set, perhaps in a pom file? Regards, Graham --
Re: maven-enforcer-plugin
Much better - properly extensible too :)
Andy
On 21 Mar 2007, at 18:13, Jason Dillon wrote:
Hey, this occurred to me last night...
Why not have one goal, enforcer:enforce, then abstract the things
to enforce into rules...
public interface EnforcementRule {
void execute();
}
And then configure...
...
...
[1.3,1.6]
[2.0.5)
IIUC if have 'EnforcementRule[] rules;' in your mojo and you define
impls of EnforcementRule like RequireJavaVersion and
RequireMavenVersion in the same package, then plexus should inject
the instances of the right class into the array.
Then the mojo is really simple, can execute any kind of rules from
it... and folks can use the implementation="" stuff to inject their
own rules too if needed. Then the goal basically executes the
rules and then based on if they pass/fail do something about it
(fail the build, warn, etc.).
--jason
On Mar 20, 2007, at 4:19 PM, Brian E. Fox wrote:
Personally I have not problem adding extra execution per thing
I want to enforce. IMO that is much clearer and simplifies
the implementing mojo.
Potentially yes, but it's also a performance issue invoking the
plugin
extra times. In my situation, I have about 100+ modules that would be
doing this. If I can figure out how to make it execute only once per
execution no matter where the build is started, then I think
separating
them is logical. In fact, if this is possible, I think it's a
requirement.
Funny... most folks I know don't use version ranges. We
(geronimo) tried to use them at one point for our specs, but
key plugins (like the idea plugin) don't support it.
I don't think that most folks using M2 are familiar with
ranges... nor do they use them... and when those who do use
them... usually tend to find out they don't work so well.
Fair enough. I think I discovered why they don't work in many cases
while trying to use them.
The OS stuff falls into the same boat, why reinvent a syntax when
one
already exists?
Ya, I hear ya... it was just a comment... and more about how
the range syntax hurts my brain more than anything ;-) Just
looking at a range its not really easy to tell what it
means... where IMO the 1.0+ and 1.0* syntax is relatively
clear w/o having to go read a syntax mapping table ;-)
Although I am not a fan of the implementation, the syntax is logical
once you understand it. Not entirely covering all scenarios, but
certainly enough for this. I don't think the 1.0+, 1.0* is enough to
handle all cases.
Consider 2.1. Perhaps there is a regression in backwards
compatibility
in the first build. Someone may want to say 2.0.6 < x < 2.1 || x >
2.1
(in otherwords greater than 2.0.6 but not 2.1.0. You can do this with
the current specification. I'm not sure that any expression
language is
going to be completely natural and support enough use cases... If
that's
true, then this one is as good as any. I could be convinced otherwise
though if there are some alternatives that can be pointed out.
Does anyone else have an opinion?
(btw, I anticipated exactly this disussion, which is why I put out
the
RFC)
-
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: [VOTE] Release maven-plugin-plugin 2.3
+1 Andy On 19 Mar 2007, at 22:43, Dennis Lundberg wrote: Hi, I'd like to release maven-plugin-plugin-2.3. There is only one issue fixed for this release, but it's an important one. It adds support for @since tags for mojo parameters. This is an important improvement to our plugin documentation: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&pid=11139&fixfor=13114 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-plugin- plugin-2.3/ Staged at: http://people.apache.org/~dennisl/staging-repository-plugins/ A SNAPSHOT has been deployed to our snapshot-repository. The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - 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: [vote] Merge 2.1-lifecycle-refactor branch back to maven trunk
little late, but a big +1 from me too Andy On 16 Mar 2007, at 16:51, John Casey wrote: Hi everyone, I've performed a fairly significant refactoring of the lifecycle executor on the 2.1-lifecycle-refactor branch. The changes allow Maven to construct a build plan before execution begins in earnest, which contains all of the mojos and their configurations and is then rendered to a List for iteration and execution. This opens up a whole new world of possibility for controlling builds, not to mention build-process debugging and discovery. I've run the integration tests on this branch, and it seems that everything is working well. I'd like to merge this branch back to trunk, but since it's such a large refactor, I thought it appropriate to vote on it first, in an effort to help us maintain a stable trunk. I've parked binaries, javadocs (of maven-core, where the big changes are), and two design PNG images out here: http://people.apache.org/~jdcasey/maven-drops/2.1-lifecycle-refactor Also, if you want to see the new build plan in action, install the lifecycle plugin: http://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven- lifecycle-plugin and run the following command with the binaries above: mvn lifecycle:build-plan -Dtasks=clean,install If you'd like to see the configurations for the mojos, use this: mvn lifecycle:build-plan -Dtasks=clean,install -DextendedInfo=true Please peruse and let me know what you think. I'll give it 72h; please vote +1/+0/-1. Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Commit privs for Ralph Goers
+1 Andy On 17 Mar 2007, at 22:33, Jason van Zyl wrote: Hi, As part of the massive overhaul that was MNG-1577 I wanted to also to ask for commit privs for Ralph. Much of my recent work has been with Patrick on getting MNG-1577 into the codebase, but Ralph also did a great deal of work and when looking at the last patch I committed to the documentation it reminded me of the initial conversation I had with Ralph at ApacheCon when he offered the first version of the patch. Again, this was not a trivial patch and though I don't typically ask for commit privs based on a patch this was a long drawn out effort that required a lot of work and is exceptional. Ralph is a committer on Cocoon and think he would make a fine committer here. +1 Thanks, Jason. - 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: [Vote] Release maven-dependency-analyzer 1.0-alpha-1 shared component
+1 Andy On 17 Mar 2007, at 22:35, Jerome Lacoste wrote: On 3/17/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: I'd like to release the alpha 1 version of this shared component. The analyzer scans through your class files and produces a list of dependencies declared but not used, dependencies used but not declared, and dependencies actually used. Maven-dependency-plugin 2.0- alpha-3 will provide a mojo to expose the analyzer. +1 (happy user) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working toward 2.0.6
That would probably be helpful thanks, that will certainly get it recorded. Andy On 16 Mar 2007, at 18:14, Brian E. Fox wrote: Should we file a 2.0.6 defect for this and link it to PLX-287? Technically something needs to happen in Maven for this to get fixed (ie update the pom) -Original Message- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 1:06 PM To: Maven Developers List Subject: Re: Working toward 2.0.6 This is now fixed in the latest plexus, which is being used in 2.1- SNAPSHOT. We are currently trying to figure if it is feasible to update the 2.0.x branch at this time. Andy On 16 Feb 2007, at 16:30, Brian E. Fox wrote: Since this is a plexus issue, I might be grasping, but we are still struggling with PLX-287. I haven't been able to produce a test set because it seems to only occur in very large complicated build. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, February 15, 2007 6:55 PM To: Maven Developers List Subject: Working toward 2.0.6 Hi, So that no one can accuse of resting on our laurels time to start planning for 2.0.6. Not sure what the best way is to gather the issues to work on but it would be nice to gather them in the next week or so, and then work the next three weeks to resolve them and do another release in 4 weeks. We can try the voting thing like we do with the plugins, or people can bring up issues and it's first come first serve. You can pick from here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&&pid=10500&resolution=-1&fixfor=13141&sorter/ field=priority&sorter/order=DESC Or if you know that an issue has been the wrong fix version tell us. Project with full test cases that can be easily absorbed will be taken before anything else anything else. If these are for fixes and you have unit tests that's great, or if you prefer to create an integration test then to make this easier I have created a self- contained, fully working of example of our integration tests: http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/ core-integration-test-sample or http://idisk.maven.org/jvanzyl/Public/maven-integration-tests/core- integration-test-sample.zip Anyone who produces an integration using this form I guarantee your patches will go to the front of the line. I know that many people contribute time to fix things and are frustrated when we don't apply patches, but it also very frustrating for us to try and piece together comments and bits of code cobbled together in JIRA. I'm hoping that this will help. Our integration testing strategy is not fully fleshed out but what's in that example is what we are using today and them being all the same as we can move them all forward together when we improve it. Even for issue where you don't have a solution providing a test where we can at least accurately reproduce the problem is immensely helpful. I will make an archetype of this example but I wanted to get this mail out to get the ball rolling for 2.0.6 so you can take the svn checkout or the zip. I have not forgotten about poor MNG-1577 :-) Jason. - 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] - 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: [VOTE] maven-remote-resources-plugin 1.0-alpha-4
+1 On 16 Mar 2007, at 17:16, Daniel Kulp wrote: Following the "release often" mantra... :-( Several projects have hit "Critical" bugs that is causing builds to fail when using the remote-resources plugin.1.0-alpha-4 contains no new functionality. It just fixes the two critical bugs. Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0- alpha-4 ** Bug * [MRRESOURCES-14] - Running the process goal fails if there is no target directory * [MRRESOURCES-15] - ClassCast Exception happens when depending on the snapshot artifacts -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - 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: Working toward 2.0.6
This is now fixed in the latest plexus, which is being used in 2.1- SNAPSHOT. We are currently trying to figure if it is feasible to update the 2.0.x branch at this time. Andy On 16 Feb 2007, at 16:30, Brian E. Fox wrote: Since this is a plexus issue, I might be grasping, but we are still struggling with PLX-287. I haven't been able to produce a test set because it seems to only occur in very large complicated build. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, February 15, 2007 6:55 PM To: Maven Developers List Subject: Working toward 2.0.6 Hi, So that no one can accuse of resting on our laurels time to start planning for 2.0.6. Not sure what the best way is to gather the issues to work on but it would be nice to gather them in the next week or so, and then work the next three weeks to resolve them and do another release in 4 weeks. We can try the voting thing like we do with the plugins, or people can bring up issues and it's first come first serve. You can pick from here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&&pid=10500&resolution=-1&fixfor=13141&sorter/ field=priority&sorter/order=DESC Or if you know that an issue has been the wrong fix version tell us. Project with full test cases that can be easily absorbed will be taken before anything else anything else. If these are for fixes and you have unit tests that's great, or if you prefer to create an integration test then to make this easier I have created a self- contained, fully working of example of our integration tests: http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/ core-integration-test-sample or http://idisk.maven.org/jvanzyl/Public/maven-integration-tests/core- integration-test-sample.zip Anyone who produces an integration using this form I guarantee your patches will go to the front of the line. I know that many people contribute time to fix things and are frustrated when we don't apply patches, but it also very frustrating for us to try and piece together comments and bits of code cobbled together in JIRA. I'm hoping that this will help. Our integration testing strategy is not fully fleshed out but what's in that example is what we are using today and them being all the same as we can move them all forward together when we improve it. Even for issue where you don't have a solution providing a test where we can at least accurately reproduce the problem is immensely helpful. I will make an archetype of this example but I wanted to get this mail out to get the ball rolling for 2.0.6 so you can take the svn checkout or the zip. I have not forgotten about poor MNG-1577 :-) Jason. - 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]
Re: [VOTE] Commit Privs for Patrick Schneider
Are non-binding votes allowed for priv votes? If so +1 Andy On 16 Mar 2007, at 14:44, Jason van Zyl wrote: Hi, Patrick has, for at least a couple months, been working on MNG-1577, has written extensive tests, changed and altered patches for anything and everything that's been asked of him. He worked with Mike and Ralph discussing the problem, getting the patches prepared and in for this fix, ultimately arriving at a solution that makes Maven a far more reliable system. He's been great to work with and he never relented and patched and patched and patched. He is now intimately familiar with Maven's dependency mechanism and he would be a great addition to the team in helping us sort out more artifact related problems :-) +1 Thanks, Jason. - 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: [vote] MNG-1577 as the default behavior
+1, I agree with Kenney that folk will be able to remove a lot of workaround snippets from their poms, the sooner the better. Andy On 16 Mar 2007, at 11:48, Kenney Westerhof wrote: I think it won't break builds at all. I think that people have lots of workarounds in their poms right now to overcome this problem - specifying transitive dependencies directly, which they don't directly use, but just to enforce that version being used. I've done so myself quite a few times. Those builds will not fail since the extra dependency will be redundant. What could be a possible usecase where a build will break? I agree with the fact that we need to test this thorougly. Our integration tests are way too simplistic to test this so we definitely need to test this against 'real life' complex builds. The best way to do that I think is to apply it to 2.0.x and let people test it on their builds for a while. If it's breaking more than it fixes we can always roll back before the release. -- Kenney Brett Porter wrote: -1, at this point. I'd like to look at some specific test cases to see how badly it might break a build - so I could be convinced. No matter how bad the existing behaviour, it is consistent once in place. I think it's unacceptable to drop this into a .0.x release, no matter what the release notes say. Even if it makes it better for new builds, the people that have their current one mysteriously break will be rightly livid. I think we suffered this a little earlier when we enforced order when it wasn't deterministic - I think this would be more confusing than in that instance. Our users must be able to trust point releases are safe upgrades. Let's start moving on putting out 2.1 milestone releases instead. - Brett On 16/03/2007, at 11:33 AM, Jason van Zyl wrote: Hi, After working with it a little this week I would like to propose to make MNG-1577 behavior introduced the default. Builds are completely and totally unpredictable without this behavior. The behavior in 2.0.5 is fundamentally broken. To are totally prey to any dependency introduced by a dependency which makes no sense and completely counter intuitive. I stabilized a massive build this week simply by using the behavior present in the 2.0.x branch. I don't think we're doing anyone any favors leaving the old behavior in. After watching a disaster be recovered by using this new behavior I feel that the patch should go in as is and become the default behavior. This puts the user in control which is the way it should be. I propose we make this the default behavior. Can anyone think of a case where this degree of control would break an existing build? This patch saved my bacon this week, I think this behavior makes a world of difference to users. Jason. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r515406 - /maven/continuum/trunk/continuum-release/src/main/resources/META-INF/plexus/components.xml
Yes, I know this I just did not explain well :-p On 16 Mar 2007, at 07:30, Emmanuel Venisse wrote: ok, we need it :( it is called by a component in maven deps. Emmanuel Emmanuel Venisse a écrit : I don't misunderstand. I just say that the component declared in maven dep is with 'maven' role-hint and we need to use it instead of re-declaring the component. I'll revert your patch. We'll use the 'default' role-hint when we'll use the latest maven- project. Emmanuel Andrew Williams a écrit : You misunderstand it's purpose. I am not defining a dependency, but rather re-declaring the component. That is a copy of the "maven" hinted component as "default". The latest maven-project uses "default" so this is a temporary measure. Does that make sense? Andy On 15 Mar 2007, at 22:41, Emmanuel Venisse wrote: Handy, I think this patch is wrong, we need to use this component with 'maven' role-hint because it's this component declared in maven- project. Emmanuel [EMAIL PROTECTED] a écrit : Author: handyande Date: Tue Mar 6 17:17:11 2007 New Revision: 515406 URL: http://svn.apache.org/viewvc?view=rev&rev=515406 Log: We need this component declaration for now, as the released components were on non-default role-hints, but the impl expects a default, so we provide it. This can be removed once continuum gets a 2.1-SNAP maven dep Modified: maven/continuum/trunk/continuum-release/src/main/resources/ META-INF/plexus/components.xml Modified: maven/continuum/trunk/continuum-release/src/main/ resources/META-INF/plexus/components.xml URL: http://svn.apache.org/viewvc/maven/continuum/trunk/ continuum-release/src/main/resources/META-INF/plexus/ components.xml?view=diff&rev=515406&r1=515405&r2=515406 == --- maven/continuum/trunk/continuum-release/src/main/resources/ META-INF/plexus/components.xml (original) +++ maven/continuum/trunk/continuum-release/src/main/resources/ META-INF/plexus/components.xml Tue Mar 6 17:17:11 2007 @@ -314,6 +314,25 @@ + + + org.apache.maven.artifact.metadata.ArtifactMetadataSourceole> + default + org.apache.maven.project.artifact.MavenMetadataSou rce + + + org.apache.maven.project.MavenProjectBuilderrole> + + + org.apache.maven.artifact.factory.ArtifactFactory + + + org.apache.maven.artifact.repository.metadata.RepositoryMeta dataManager +> + + + +
Re: svn commit: r515406 - /maven/continuum/trunk/continuum-release/src/main/resources/META-INF/plexus/components.xml
You misunderstand it's purpose. I am not defining a dependency, but rather re-declaring the component. That is a copy of the "maven" hinted component as "default". The latest maven-project uses "default" so this is a temporary measure. Does that make sense? Andy On 15 Mar 2007, at 22:41, Emmanuel Venisse wrote: Handy, I think this patch is wrong, we need to use this component with 'maven' role-hint because it's this component declared in maven- project. Emmanuel [EMAIL PROTECTED] a écrit : Author: handyande Date: Tue Mar 6 17:17:11 2007 New Revision: 515406 URL: http://svn.apache.org/viewvc?view=rev&rev=515406 Log: We need this component declaration for now, as the released components were on non-default role-hints, but the impl expects a default, so we provide it. This can be removed once continuum gets a 2.1-SNAP maven dep Modified: maven/continuum/trunk/continuum-release/src/main/resources/ META-INF/plexus/components.xml Modified: maven/continuum/trunk/continuum-release/src/main/ resources/META-INF/plexus/components.xml URL: http://svn.apache.org/viewvc/maven/continuum/trunk/continuum- release/src/main/resources/META-INF/plexus/components.xml? view=diff&rev=515406&r1=515405&r2=515406 = = --- maven/continuum/trunk/continuum-release/src/main/resources/ META-INF/plexus/components.xml (original) +++ maven/continuum/trunk/continuum-release/src/main/resources/ META-INF/plexus/components.xml Tue Mar 6 17:17:11 2007 @@ -314,6 +314,25 @@ + + + org.apache.maven.artifact.metadata.ArtifactMetadataSourcerole> + default + org.apache.maven.project.artifact.MavenMetadataSource + + + org.apache.maven.project.MavenProjectBuilder + + + org.apache.maven.artifact.factory.ArtifactFactory + + + org.apache.maven.artifact.repository.metadata.RepositoryMetadat aManager +> + + + +
Re: "Component returned which is not the same manager" ?
I have looked at the code for the 1.0-alpha-9-stable and it is considerably different. In fact the bug that I fixed is not present (as far as I can see) in that version... If perhaps someone could replicate it in that version then I could look into it. Andy On 13 Mar 2007, at 15:07, Jason van Zyl wrote: On 13 Mar 07, at 6:53 AM 13 Mar 07, Andrew Williams wrote: It is possible that the error was slowing things down, as returning the wrong manager could cause a tree to be traversed rather than returning the first leaf. Getting it into 2.0.6 is not very likely, as it is cutting edge container which I don't think is slated to move to the 2.0.x branch. I will investigate further and see what can be done. I create a 1.0-alpha-9-stable branch so maybe we could slip it in there. I just wanted to use the exact same container with a detailed errata of what we fixed. The properties converter is the only thing that's different right now, any change we could wedge this fix in there too? Jason. Andy On 13 Mar 2007, at 12:58, Brian E. Fox wrote: Thanks Andy! When you found the problem, does it make sense that it was causing my builds to slow down even when I disabled the warning output? Is there any chance we can get this in 2.0.6? -Original Message----- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 7:17 AM To: Maven Developers List Subject: Re: "Component returned which is not the same manager" ? I fixed this last week, and is now released in plexus-containers 1.0- alpha-19. This fix is present in maven-2.1-SNAPSHOT also. Andy On 27 Feb 2007, at 14:47, Brian E. Fox wrote: I've been seeing this forever, it's very annoying. It significantly slows down our build when this happens, something along the lines of 20 -> 40 minutes (100% increase). I thought it was because of all the logging so I recompiled that jar to remove the warning but it is still slow when it happens. I think it could be that since the object isn't returned to the correct manager, it isn't able to reuse them correctly and results in an explosion of object creation. The original issue is: http://jira.codehaus.org/browse/PLX-287 -Original Message- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 6:21 AM To: Maven Developers List Subject: Re: "Component returned which is not the same manager" ? This is a plexus bug, registered on JIRA already. Not sure if anyone knows what is causing it, but there is one possible related change being looked into I believe. A On 27 Feb 2007, at 02:39, Jason Dillon wrote: Anyone know what this means? [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.JdkPrefixProfileAct iva t [EMAIL PROTECTED] I'm seeing a tone of these in the Geronimo build... seems to happen randomly from build to build. I ran one build and did not see this, then I started up a new build and I see like 1000x of these? Anyone know? --jason -- --- 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] - 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] - 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: "Component returned which is not the same manager" ?
Hmm, yes there is a good chance I could fix it on the branch, I will get that sorted. Andy On 13 Mar 2007, at 15:07, Jason van Zyl wrote: On 13 Mar 07, at 6:53 AM 13 Mar 07, Andrew Williams wrote: It is possible that the error was slowing things down, as returning the wrong manager could cause a tree to be traversed rather than returning the first leaf. Getting it into 2.0.6 is not very likely, as it is cutting edge container which I don't think is slated to move to the 2.0.x branch. I will investigate further and see what can be done. I create a 1.0-alpha-9-stable branch so maybe we could slip it in there. I just wanted to use the exact same container with a detailed errata of what we fixed. The properties converter is the only thing that's different right now, any change we could wedge this fix in there too? Jason. Andy On 13 Mar 2007, at 12:58, Brian E. Fox wrote: Thanks Andy! When you found the problem, does it make sense that it was causing my builds to slow down even when I disabled the warning output? Is there any chance we can get this in 2.0.6? -Original Message----- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 7:17 AM To: Maven Developers List Subject: Re: "Component returned which is not the same manager" ? I fixed this last week, and is now released in plexus-containers 1.0- alpha-19. This fix is present in maven-2.1-SNAPSHOT also. Andy On 27 Feb 2007, at 14:47, Brian E. Fox wrote: I've been seeing this forever, it's very annoying. It significantly slows down our build when this happens, something along the lines of 20 -> 40 minutes (100% increase). I thought it was because of all the logging so I recompiled that jar to remove the warning but it is still slow when it happens. I think it could be that since the object isn't returned to the correct manager, it isn't able to reuse them correctly and results in an explosion of object creation. The original issue is: http://jira.codehaus.org/browse/PLX-287 -Original Message- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 6:21 AM To: Maven Developers List Subject: Re: "Component returned which is not the same manager" ? This is a plexus bug, registered on JIRA already. Not sure if anyone knows what is causing it, but there is one possible related change being looked into I believe. A On 27 Feb 2007, at 02:39, Jason Dillon wrote: Anyone know what this means? [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.JdkPrefixProfileAct iva t [EMAIL PROTECTED] I'm seeing a tone of these in the Geronimo build... seems to happen randomly from build to build. I ran one build and did not see this, then I started up a new build and I see like 1000x of these? Anyone know? --jason -- --- 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] - 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] - 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: "Component returned which is not the same manager" ?
It is possible that the error was slowing things down, as returning the wrong manager could cause a tree to be traversed rather than returning the first leaf. Getting it into 2.0.6 is not very likely, as it is cutting edge container which I don't think is slated to move to the 2.0.x branch. I will investigate further and see what can be done. Andy On 13 Mar 2007, at 12:58, Brian E. Fox wrote: Thanks Andy! When you found the problem, does it make sense that it was causing my builds to slow down even when I disabled the warning output? Is there any chance we can get this in 2.0.6? -Original Message- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 7:17 AM To: Maven Developers List Subject: Re: "Component returned which is not the same manager" ? I fixed this last week, and is now released in plexus-containers 1.0- alpha-19. This fix is present in maven-2.1-SNAPSHOT also. Andy On 27 Feb 2007, at 14:47, Brian E. Fox wrote: I've been seeing this forever, it's very annoying. It significantly slows down our build when this happens, something along the lines of 20 -> 40 minutes (100% increase). I thought it was because of all the logging so I recompiled that jar to remove the warning but it is still slow when it happens. I think it could be that since the object isn't returned to the correct manager, it isn't able to reuse them correctly and results in an explosion of object creation. The original issue is: http://jira.codehaus.org/browse/PLX-287 -----Original Message- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 6:21 AM To: Maven Developers List Subject: Re: "Component returned which is not the same manager" ? This is a plexus bug, registered on JIRA already. Not sure if anyone knows what is causing it, but there is one possible related change being looked into I believe. A On 27 Feb 2007, at 02:39, Jason Dillon wrote: Anyone know what this means? [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.JdkPrefixProfileActiv a t [EMAIL PROTECTED] I'm seeing a tone of these in the Geronimo build... seems to happen randomly from build to build. I ran one build and did not see this, then I started up a new build and I see like 1000x of these? Anyone know? --jason - 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] - 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]
Re: "Component returned which is not the same manager" ?
I fixed this last week, and is now released in plexus-containers 1.0- alpha-19. This fix is present in maven-2.1-SNAPSHOT also. Andy On 27 Feb 2007, at 14:47, Brian E. Fox wrote: I've been seeing this forever, it's very annoying. It significantly slows down our build when this happens, something along the lines of 20 -> 40 minutes (100% increase). I thought it was because of all the logging so I recompiled that jar to remove the warning but it is still slow when it happens. I think it could be that since the object isn't returned to the correct manager, it isn't able to reuse them correctly and results in an explosion of object creation. The original issue is: http://jira.codehaus.org/browse/PLX-287 -Original Message- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 6:21 AM To: Maven Developers List Subject: Re: "Component returned which is not the same manager" ? This is a plexus bug, registered on JIRA already. Not sure if anyone knows what is causing it, but there is one possible related change being looked into I believe. A On 27 Feb 2007, at 02:39, Jason Dillon wrote: Anyone know what this means? [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.JdkPrefixProfileActiva t [EMAIL PROTECTED] I'm seeing a tone of these in the Geronimo build... seems to happen randomly from build to build. I ran one build and did not see this, then I started up a new build and I see like 1000x of these? Anyone know? --jason - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble w/ the Plexus app and on Tomcat r516446
There is a mismatch of plexus component api and container-default by the looks of things, unless there is some code in archiva that uses the removed getComponentKey() method. Andy On 11 Mar 2007, at 20:04, Wendy Smoak wrote: On 3/11/07, Brett Porter <[EMAIL PROTECTED]> wrote: This occurs when you use an older database that was on jpox 1.1.4, and run it under the new stuff, unfortunately. You probably need to start over with your users database. Thanks. That fixed it for Tomcat (once I figured out where the databases were hiding-- I had set derby.system.home to keep them out of $TOMCAT_HOME/bin.) The Plexus runtime still won't work though: The error with Plexus is jvm 1| WrapperSimpleApp: Encountered an error running main: java.lang.NoSuch MethodError: org.codehaus.plexus.component.repository.ComponentDescriptor.getCom ponentKey()Ljava/lang/String; jvm 1| java.lang.NoSuchMethodError: org.codehaus.plexus.component.repository .ComponentDescriptor.getComponentKey()Ljava/lang/String; Does that look familiar to anyone? -- Wendy
Re: Problems with the int / long conversion?
Hm, it is an error with the jdo2 snapshot release I was using, so a
false alarm for now ;)
On 7 Mar 2007, at 01:20, Andrew Williams wrote:
Digging in to continuum I get these errors in continuum-store, is
it related to the recent int -> long updates?
Andy
javax.jdo.JDOFatalInternalException: The key value passed to
construct a SingleFieldIdentity of type
"javax.jdo.identity.IntIdentity" for class
"org.apache.maven.continuum.model.project.ProjectGroup" is of an
incorrect type ("java.lang.Long") - should be "Integer".
at org.jpox.util.AIDUtils.getNewSingleFieldIdentity
(AIDUtils.java:154)
at org.jpox.AbstractPersistenceManager.newObjectIdInstance
(AbstractPersistenceManager.java:2397)
at org.codehaus.plexus.jdo.PlexusJdoUtils.getObjectById
(PlexusJdoUtils.java:336)
at org.codehaus.plexus.jdo.PlexusJdoUtils.getObjectById
(PlexusJdoUtils.java:304)
at
org.apache.maven.continuum.store.JdoContinuumStore.getObjectById
(JdoContinuumStore.java:765)
at
org.apache.maven.continuum.store.JdoContinuumStore.getProjectGroupWith
BuildDetailsByProjectGroupId(JdoContinuumStore.java:1239)
at
org.apache.maven.continuum.store.ContinuumStoreTest.testDeleteGroupBui
ldDefinition(ContinuumStoreTest.java:884)
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 junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:
124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
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.apache.maven.surefire.junit.JUnitTestSet.execute
(JUnitTestSet.java:213)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest
Set(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
(AbstractDirectoryTestSuite.java:163)
at org.apache.maven.surefire.Surefire.run(Surefire.java:84)
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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
(SurefireBooter.java:244)
at org.apache.maven.surefire.booter.SurefireBooter.main
(SurefireBooter.java:814)
Re: Can't build continuum
codehaus-snapshots seems to be in the continuum pom already. the alpha-8-SNAPSHOT should already be deployed. I have just deployed it again in case there was a problem with the metadata. Andy On 7 Mar 2007, at 01:20, Arnaud HERITIER wrote: Hi guys, I can't build continuum because of a missing dependency for a SNAPSHOT in plexus. Is there someone who can fix it ? Must I add a repository for plexus snapshots ? [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Failed to resolve artifact. GroupId: org.codehaus.plexus ArtifactId: plexus-appserver Version: 2.0-alpha-8-20070305.092843-9 Reason: Downloaded file does not exist: E:\Data\maven-2\repository\org\codehaus\plexus\plexus-appserver\2.0- alpha-8-SNAPSHOT\plexus- appserver-2.0-alpha-8-20070305.092843- 9.pom.tmp org.codehaus.plexus:plexus-appserver:pom:2.0- alpha-8-20070305.092843-9 from the specified remote repositories: codehaus.org (http://snapshots.repository.codehaus.org/), central (http://repo1.maven.org/maven2), apache.plugin.snapshots ( http://people.apache.org/maven-snapshot-repository), people.apache.org (http://people.apache.org/repo/m2-snapshot- repository), codehaus.plugin.snapshots (http://snapshots.maven.codehaus.org/ maven2), codehaus.snapshots (http://snapshots.repository.codehaus.org/), apache.snapshots (http://people.apache.org/repo/m2-snapshot- repository) [INFO] -- -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 8 seconds [INFO] Finished at: Wed Mar 07 02:17:23 CET 2007 [INFO] Final Memory: 3M/6M [INFO] -- -- Thanks Arnaud
Re: Maven's ArtifactMetadataSource's bad role-hint
OK, that is done. The change should not affect anything not using plexus-container- default < alpha-19-SNAPSHOT, which includes the core maven build atm, as I have not upgraded it. Want more testing done first :) Andy On 5 Mar 2007, at 01:56, Brett Porter wrote: I agree - it's going to enable plugins that reference it successfully by role alone now to continue working. However, something may reference it directly by the maven role- hint: I suggest a subclass with not modifications except the alternate role-hint be made (and deprecated) for that case. - Brett On 04/03/2007, at 3:18 AM, Andrew Williams wrote: Are there an objections, or reasons not to change the role-hint of MavenMetadataSource in maven-project from "maven" to "default". The latest plexus code (will shortly...) be more strict on hints and no longer allow components to grab "whatever is configured", if a hint exists it must be honoured (but "default" is the, erm, default). This means that if switched to "default" then plugins could continue to use it as now without stating which hint they want. Andy - 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]
Re: Maven's ArtifactMetadataSource's bad role-hint
Yes, it does add "default". I think Jason was referring to the use of CDC irrespective if whether hints were in or not. After all, CDC does not need a hint at all, and the container will fill the blanks at runtime. Andy On 5 Mar 2007, at 08:56, Trygve Laugstøl wrote: Jason van Zyl wrote: On 4 Mar 07, at 3:18 AM 4 Mar 07, Andrew Williams wrote: Are there an objections, or reasons not to change the role-hint of MavenMetadataSource in maven-project from "maven" to "default". I think that's fine, but we should also annotating all the plexus components and I think we can make this work with the bootstrap in much the same way we get modello to work. This will save much aggravation, it will then all be generated and adjustments to the CDC where required will make this much less painful. I'd rather not change all the source code. IMO the container should just add "default" as the role hint. As far as I can this will be required to keep compatibility with existing components. -- Trygve - 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: Maven's ArtifactMetadataSource's bad role-hint
I had a more cunning plan... I can just advertise it over both hints in the components.xml (works in the tests I have done here :) ). Andy On 5 Mar 2007, at 01:56, Brett Porter wrote: I agree - it's going to enable plugins that reference it successfully by role alone now to continue working. However, something may reference it directly by the maven role- hint: I suggest a subclass with not modifications except the alternate role-hint be made (and deprecated) for that case. - Brett On 04/03/2007, at 3:18 AM, Andrew Williams wrote: Are there an objections, or reasons not to change the role-hint of MavenMetadataSource in maven-project from "maven" to "default". The latest plexus code (will shortly...) be more strict on hints and no longer allow components to grab "whatever is configured", if a hint exists it must be honoured (but "default" is the, erm, default). This means that if switched to "default" then plugins could continue to use it as now without stating which hint they want. Andy - 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]
Re: svn commit: r514383 - /maven/plugins/trunk/maven-plugin-plugin/pom.xml
just out of interest, what part of 2.0.5 is required now? Andy On 4 Mar 2007, at 11:28, [EMAIL PROTECTED] wrote: Author: dennisl Date: Sun Mar 4 03:27:56 2007 New Revision: 514383 URL: http://svn.apache.org/viewvc?view=rev&rev=514383 Log: o Update prerequisites to 2.0.5. Modified: maven/plugins/trunk/maven-plugin-plugin/pom.xml Modified: maven/plugins/trunk/maven-plugin-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-plugin- plugin/pom.xml?view=diff&rev=514383&r1=514382&r2=514383 == --- maven/plugins/trunk/maven-plugin-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-plugin-plugin/pom.xml Sun Mar 4 03:27:56 2007 @@ -36,7 +36,7 @@ 2001 -2.0.4 +2.0.5 JIRA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven's ArtifactMetadataSource's bad role-hint
Are there an objections, or reasons not to change the role-hint of MavenMetadataSource in maven-project from "maven" to "default". The latest plexus code (will shortly...) be more strict on hints and no longer allow components to grab "whatever is configured", if a hint exists it must be honoured (but "default" is the, erm, default). This means that if switched to "default" then plugins could continue to use it as now without stating which hint they want. Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Apache parent pom 4
+1 On 1 Mar 2007, at 17:22, Carlos Sanchez wrote: anything pending to do in the apache pom? there are some mistakes in the version 3 like organization name that propagates to all apache projects. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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: [vote] Trying to use standard versioning
+1 On 2 Mar 2007, at 02:20, Jason van Zyl wrote: Hi, The impetus for this is wanting to release the surefire plugin that has a tiny bug in it. We are versioning our Maven release major.minor.micro so why don't we do the same with our plugin and treat everything like we're going to do small incremental releases like we should be doing. I would like to change all the versions on plugin to follow the major.minor.micro format starting with the surefire plugin. Thanks, Jason. - 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]
Java5 requirement?
Am I the only one seeing this or is continuum now requiring Java5? /Coding/continuum/continuum-webapp/src/main/java/org/apache/maven/ continuum/web/view/jsp/ui/SubmitCancelTag.java:[27,-1] cannot access javax.servlet.http.HttpServletRequest bad class file: /Users/aje/.m2/repository/javax/servlet/servlet-api/ 2.5/servlet-api-2.5.jar(javax/servlet/http/HttpServletRequest.class) class file has wrong version 49.0, should be 48.0 Andy
Re: "Component returned which is not the same manager" ?
This is a plexus bug, registered on JIRA already. Not sure if anyone knows what is causing it, but there is one possible related change being looked into I believe. A On 27 Feb 2007, at 02:39, Jason Dillon wrote: Anyone know what this means? [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.JdkPrefixProfileActivat [EMAIL PROTECTED] I'm seeing a tone of these in the Geronimo build... seems to happen randomly from build to build. I ran one build and did not see this, then I started up a new build and I see like 1000x of these? Anyone know? --jason - 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: svn commit: r511667 - /maven/continuum/trunk/continuum-rpc-client/pom.xml
Reverted. Can someone look at fixing this the correct way then? I would like to use this code. Andy On 26 Feb 2007, at 12:53, Emmanuel Venisse wrote: This patch isn't correct because the rpc client doesn't need enhanced classes. We need to generate model classes for the rpc client without enhancement. Please, revert your patch. Emmanuel Andrew Williams a écrit : The SampleClient fails to run without it. Caused by: java.lang.NoClassDefFoundError: javax/jdo/spi/ PersistenceCapable at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java: 251) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at org.codehaus.mojo.exec.ExecJavaMojo $IsolatedClassLoader.loadClass(ExecJavaMojo.java:265) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at org.apache.maven.continuum.rpc.ProjectsReader.readProjects (ProjectsReader.java:79) at org.apache.maven.continuum.rpc.SampleClient.main(SampleClient.java: 51) ... 23 more A On 26 Feb 2007, at 08:49, Emmanuel Venisse wrote: Why? we don't use it in the rpc client. [EMAIL PROTECTED] a écrit : Author: handyande Date: Sun Feb 25 16:07:34 2007 New Revision: 511667 URL: http://svn.apache.org/viewvc?view=rev&rev=511667 Log: rpc client need jdo2 too Modified: maven/continuum/trunk/continuum-rpc-client/pom.xml Modified: maven/continuum/trunk/continuum-rpc-client/pom.xml URL: http://svn.apache.org/viewvc/maven/continuum/trunk/ continuum-rpc-client/pom.xml? view=diff&rev=511667&r1=511666&r2=511667 === === --- maven/continuum/trunk/continuum-rpc-client/pom.xml (original) +++ maven/continuum/trunk/continuum-rpc-client/pom.xml Sun Feb 25 16:07:34 2007 @@ -70,5 +70,9 @@ commons-httpclient 2.0.2 + + org.codehaus.plexus + plexus-jdo2 +
Re: Maven banner?
I must admit I was very tempted to put that back in. Perhaps not exactly the same logo, make a change in the 2.1 tree :) I wondered also if I could tie it to some colour logging work I have up my sleeve so we could colour the "a" of Maven like the official logo. Any objections? Andy On 15 Feb 2007, at 04:05, Jason Dillon wrote: What happened to the banner when executing Maven? I'm glad its not there by default, but I'd like to turn it on for remote builds so that my logs capture what version of Maven was used. Maybe a '--banner' flag or something? Or maybe a new goal on the help plugin, to show maven version, and some settings like os and java version fluff? --jason - 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: [vote] Release Maven Surefire 2.3
Maybe a couple of hours too late, sorry. +1 Andy On 23 Feb 2007, at 08:52, Brett Porter wrote: Please vote for the release of Surefire 2.3. This now includes the API, providers, plugin and report plugin. [ ] +1 [ ] 0 [ ] -1 Staged at: http://people.apache.org/~brett/release-staging-repo/ Vote is open for 72 hours. Release notes: ** Bug * [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName directories after mvn test * [SUREFIRE-53] - context classloader not always reset to original values * [SUREFIRE-54] - Remove use of parent classloader in surefirebooter but keep TestNG support working * [SUREFIRE-99] - Surefire plugin fails if JUnit is not available * [SUREFIRE-101] - Plugin not longer sets system properties when forking is on and debugging information is not correct * [SUREFIRE-105] - Documentation link on website does not point to surefire parameter docs * [SUREFIRE-106] - Classloading problem for getting a resource * [SUREFIRE-113] - surefire-providers-2.0.pom contains strange dependencies which generate error * [SUREFIRE-114] - Surefire plugin throws NoSuchMethodException when errors occur during TestSetup decorator * [SUREFIRE-120] - When you a JUnit TestSuite (with no test methods), no tests are run * [SUREFIRE-122] - With forkmode once, XML reports are cumulative * [SUREFIRE-123] - SurefireBooter can initialize classloader with badly formed URLs * [SUREFIRE-125] - Surefire finds test classes but ignores test methods and configuration methods with TestNG and includes tag * [SUREFIRE-127] - Wrong issue-site URL on website * [SUREFIRE-263] - Source repository information on the web site is out of date ** Improvement * [SUREFIRE-31] - support junit 4.0 * [SUREFIRE-134] - Display location of test failures/errors on summary * [SUREFIRE-135] - when fork is enabled, Surefire should use the same JVM running Maven (i.e. use java.home sysprop), rather than expecting java to be in the system PATH * [SUREFIRE-138] - Add option to redirect stdout from tests to a file ** New Feature * [SUREFIRE-129] - add a property to skip tests execution (but not tests compilation) ** Task * [SUREFIRE-133] - Review Plugin Documentation Note: a 2.4 release is being worked on immediately to resolve some issues with TestNG. This release is being made available to users having the above problems before that work begins. Cheers, Brett - 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]
Continuum in Enterprise
I have a problem with continuum booted in Maven Enterprise (alsp happens with continuum-plexus-runtime). When I try to add a m2 project by uploading the pom I get: 2007-01-31 19:02:45,283 [SocketListener0-2] INFO DispatcherUtils- Unable to find 'webwork.multipart.saveDir' property setting. Defaulting to javax.servlet.context.tempdir 2007-01-31 19:02:45,292 [SocketListener0-2] ERROR DispatcherUtils- Error setting character encoding to 'UTF-8' - ignoring. java.lang.IllegalStateException: getReader() or getInputStream() called at org.mortbay.jetty.servlet.ServletHttpRequest.setCharacterEncoding (ServletHttpRequest.java:602) at javax.servlet.ServletRequestWrapper.setCharacterEncoding (ServletRequestWrapper.java:112) at com.opensymphony.webwork.dispatcher.DispatcherUtils.prepare (DispatcherUtils.java:392) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter (FilterDispatcher.java:160) at org.mortbay.jetty.servlet.WebApplicationHandler $CachedChain.doFilter(WebApplicationHandler.java:821) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage (PageFilter.java:118) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter (PageFilter.java:52) at org.mortbay.jetty.servlet.WebApplicationHandler $CachedChain.doFilter(WebApplicationHandler.java:821) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter (ActionContextCleanUp.java:88) at org.mortbay.jetty.servlet.WebApplicationHandler $CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch (WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle (WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service (HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext (HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle (HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection (SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle (ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run (ThreadPool.java:534) 2007-01-31 19:02:45,316 [SocketListener0-2] INFO Interceptor:exceptionLogging - Error ocurred during execution org.apache.maven.continuum.ContinuumException: Error reading POM at org.apache.maven.continuum.web.action.AddMavenTwoProjectAction.doExecute (AddMavenTwoProjectAction.java:83) at org.apache.maven.continuum.web.action.AddMavenProjectAction.execute (AddMavenProjectAction.java:128) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.opensymphony.xwork.DefaultActionInvocation.invokeAction (DefaultActionInvocation.java:364) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly (DefaultActionInvocation.java:216) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercep t(DefaultWorkflowInterceptor.java:168) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept (MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionInvocation.java:188) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept (ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept (MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionInvocation.java:188) at org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationIn terceptor.intercept(ForceContinuumConfigurationInterceptor.java:62) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionInvocation.java:188) at org.codehaus.plexus.security.ui.web.interceptor.PolicyEnforcementInterce ptor.intercept(PolicyEnforcementInterceptor.java:65) at com.opensymphony.xwork.DefaultActionInvocation.invoke (DefaultActionInvocation.java:188) at org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor. intercept(SecureActionInterceptor.java:145) at com.
Re: proxying was: two 500 errors
OK, I can finally replicate it. We are working on fixing it now - related to some recent appserver fixes I believe. It should be working fine when executed as mvn jetty:run Andy On 29 Jan 2007, at 20:11, Wendy Smoak wrote: On 1/29/07, Andrew Williams <[EMAIL PROTECTED]> wrote: Are you using bretts latest changes for archiva to use the latest plexus container? I re-build at last changed revision 500951 (which includes brett's plexus version number changes.) Same thing, error 500 on any /repository url. Here's another stack trace and list of Plexus jars: http://wiki.wsmoak.net/cgi-bin/wiki.pl?Maven/ArchivaError20070129 -- Wendy
Re: Feature request: per-module local version in profile
So you want to alter the versions that you rely on without altering the pom? surely that breaks the idea of repeatable builds? Andy Mark Lundquist wrote: Andrew Williams wrote: have you tried referring to a snapshot build using it's full build identifier (date etc)? that has worked for me in some situations in the past. "Referring to"? No touching the pom, that's my requirement :-) I'm looking for a solution, not a kludge that might help in some situations. I already know how to kludge it by swapping pom changes in and out (see my OP), the point here is to make that unnecessary. cheers, —ml— - 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: Feature request: per-module local version in profile
have you tried referring to a snapshot build using it's full build identifier (date etc)? that has worked for me in some situations in the past. Andy Mark Lundquist wrote: Hi Ralph, fancy meeting you here :-)... Ralph Goers wrote: I have one issue with this. Typically, at least in the environment I work in (which uses Maven 1), the version would be something like 1.0.1 only when that version had been released. When doing any modifications the version should become 1.0.2-SNAPSHOT until the next release is performed. No -- you're talking about versions in the poms, which are controlled resources. I am talking about modifications that are *strictly local* to a user's personal build. Indeed the mechanism that I'm proposing would apply to artifacts that already have a SNAPSHOT version from the repository, e.g. the local artifact version for my "foobar" build would become "1.0.2-SNAPSHOT-foobar" or whatever. You aren't supposed to tack on things like a Jira number. No, not in a published artifact... but that's not what I'm talking about. I'm trying to uniquify the artifacts within my own local repo so that I can have multiple builds sharing a local repo and not interfering with each other. SNAPSHOT should be sufficient to tell maven how to behave. It's not. Did you read the scenario from my original post? I don't think SNAPSHOT is even in view here. Do you think it's currently possible to build two different instances of a project (e.g. one w/ local modifications and one without) on the same machine without them stomping on each other in the repository, (a) without touching any other controlled resource (such as a pom :-) not directly related to the modification in question (i.e., that I would not include in a patch file), and (b) in a location-based way (i.e. that doesn't require me to remember to say some kind of "maven -Dblah.blah"? If so, please tell me how! :-) cheers, —ml— - 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: [vote] release maven-changelog-plugin 2.0
+1 Dennis Lundberg wrote: Hi, I'd like to release the changelog. It has not had a release since it moved from Codehaus, so this will be the first release at Apache. A lot of issues have been resolved for 2.0 as can be seen in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11211&fixfor=12471 There are still 2 open issues, but I don't think they should hold back a release: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=11211&fixfor=-1 Revision: 497994 A snapshot has been deployed to the Apache snapshot repo: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-changelog-plugin/2.0-SNAPSHOT/maven-changelog-plugin-2.0-20070119.230232-7.jar The one thing left to do is to decide which parent pom to use. Currently maven-plugins-8-SNAPSHOT is used as a parent. Either we go back to maven-plugins-7 or release maven-plugins-8. WDYT? The vote will be open for 72 hours. Here is my +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 -X output
It is back now :) Patrick Schneider wrote: Yeah... I saw this right after I sent that last email... http://jira.codehaus.org/browse/MNG-2351 Sorry! On 1/15/07, Brett Porter <[EMAIL PROTECTED]> wrote: I think -X just doesn't work at all on trunk - right? It's not deliberate, just logging changes that need fixing. On 16/01/2007, at 9:34 AM, Patrick Schneider wrote: > Did the indented list of dependencies in the debug output go away > in the > trunk? 2.0.x would give a list like: > > [DEBUG] com.test:project-a:jar:1.0-SNAPSHOT (applying version: 1.0- > SNAPSHOT > ;) > [DEBUG] com.test:project-a:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] junit:junit:jar:3.8.1:compile (applying version: > 3.8.1;applying > scope: test) > [DEBUG] junit:junit:jar:3.8.1:compile (selected for compile) > [DEBUG] commons-beanutils:commons-beanutils:jar:1.7.0:compile > (applying > version: 1.7.0;) > [DEBUG] commons-beanutils:commons-beanutils:jar:1.7.0:compile > (selected > for compile) > [DEBUG] commons-logging:commons-logging:jar:1.0.3:compile > (selected for > compile) > > Thanks, > > > Patrick - 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: [vote] Collapse Maven permission groups
-0 it might be nice to have access to everything once you join, but it seems handy to have an acl of all those writing to the various areas. On 8 Jan 2007, at 23:50, Brett Porter wrote: Hi, Since there was no objection to calling a vote, as discussed in the proposal, I'd like to call a vote on this. To see the proposal and discussion: http://mail-archives.apache.org/ mod_mbox/maven-dev/200612.mbox/%3c67FC84B5-4510-469B-AEC1- [EMAIL PROTECTED] Vote to operate as - requiring 2/3rds of the PMC to vote (13), with a majority within those votes for it to pass (ie, add them all and if the result is > 0). Other votes would be welcome with reasons as advisory, but not binding. - Votes can be changed at any time before result is posted. - Vote is open for at least 72 hours, completing once enough have voted after that. - There are two different +1 options. If there is a majority for "collapse all groups" against both other options, then it will pass. If it fails, then all votes will be transferred to the "retain subproject access restrictions" and recounted. The proposal is to collapse all access groups into a single ACL for Maven, with the following list of 37 committers: Fabrice Bellingard, David Blevins, John Casey, Maria Ching, Joakim Erdfelt, Dan Fabulich (pending), Brian Fox, Fabrizio Giustina, Arnaud Heritier, Jeff Jensen, Shinobu Kawai, Milos Kleint, Trygve Laugstol, Felipe Leme, Dennis Lundberg, Vincent Massol, Jesse McConnell, Stephane Nicoll, Mike Perham, Brett Porter, Edwin Punzalan, Daniel Rall, Allan Ramirez, Carlos Sanchez, Vincent Siveton, Wendy Smoak, Torbjorn Smorgrav, James Strachan, Chris Stevenson, Rahul Thakur, Lukas Theussl, John Tolentino, Dan Tran, Emmanuel Venisse, Kenney Westerhof, Andrew Williams, Henri Yandell, and Jason van Zyl. The alternate proposal is to retain subproject access restrictions, so the groups will be (PMC members removed, as they retain access to all areas): maven=wsmoak,felipeal,jjensen,shinobu,dlr,mkleint,handyande,epunzalan, aramirez,dantran,chrisjs,brianf,bellingard,oching (/maven-1,/ components,/plugins,/archetype,/core-integration-testing,/jxr,/ release,/skins,/resources,/release-testing) doxia=dblevins archiva=bayard,epunzalan,oching continuum=dblevins,rinku scm=dantran,smorgrav wagon= surefire= All of the above groups will have access to: /pom, /project, / site, /shared in this proposal, so it is essentially to collapse the @maven group, making the permission groups match the existence of a corresponding dev lists. [ ] +1 for the full proposal - collapse all groups (implies a vote for the next option if vote doesn't pass) [ ] +1 for the partial proposal - retain subproject access restrictions [ ] 0 abstain from vote [ ] -1 do not alter the current permissions Cheers, Brett - 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: Moving site plugin webapp to another plugin
+1 On 11 Jan 2007, at 04:49, Jason van Zyl wrote: Can we put the webapp stuff that's currently in the site plugin in another plugin so that when you simply want to generate your site you don't drag down Jetty and all its dependencies? It really is something unexpected and isn't something most would associate with just generating a site. The functionality is cool, I just think it belong in another plugin. Jason. - 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: calling vote for 2.0.5
+1 Andy On 10 Jan 2007, at 22:20, Jason van Zyl wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - 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: svn commit: r490254 - /maven/plugins/trunk/maven-project-info-reports-plugin/pom.xml
Seems to be related to http://jira.codehaus.org/browse/MNG-2731 I am trying to trace through it but the tests are not behaving at all :( A On 6 Jan 2007, at 14:44, Vincent Siveton wrote: Thanks Kenney. I have a NPE now in MPIR for plexus-i18n:1.0-beta-7-SNAPSHOT If I roll back to 1.0-beta-6 in MPIR, all works. Need to investigate... Cheers, Vincent java.lang.NullPointerException at org.codehaus.plexus.i18n.DefaultI18N.getBundle (DefaultI18N.java:141) at org.codehaus.plexus.i18n.DefaultI18N.getString (DefaultI18N.java:206) at org.apache.maven.report.projectinfo.ProjectIndexPageReport.getName(Pr ojectIndexPageReport.java:43) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.locateReports (AbstractSiteRenderingMojo.java:544) 2007/1/6, Kenney Westerhof <[EMAIL PROTECTED]>: I deployed that yesterday (about 20 hours ago or so). Are you still having problems? Vincent Siveton wrote: > Hi, > > 2006/12/25, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: >> Author: jvanzyl >> Date: Mon Dec 25 20:31:42 2006 >> New Revision: 490254 >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=490254 >> Log: >> o updating to latest released parent >> > > [SNIP] > >> @@ -99,7 +98,7 @@ >> >> org.codehaus.plexus >> plexus-i18n >> - 1.0-beta-6 >> + 1.0-beta-7-SNAPSHOT >> > > It seems that 1.0-beta-7-SNAPSHOT is not deployed yet on any snapshot > repos. > Back from holidays so I maybe missed something... > > Cheers, > > Vincent > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Follow-up on some issues
I think this was fixed earlier in the week - is your checkout up to date? Andy Jason van Zyl wrote: On 3 Jan 07, at 2:01 AM 3 Jan 07, Franz Allan Valencia See wrote: Good day, MNG-2692, MNG-2699 and MNG-2700 all refers to the same problem. That is after building maven from trunk and using the the resulting assembly (from maven-cli), "mvn.bat" does not work (because it's looking fro classworld-* instead of plexus-classworld-* as in "mvn" script file). It's a simple fix actually and both 2692 and 2699 have patches ready for it. Sure, push them in JIRA and assign them to myself or Andy. We have been pushing in new classworlds and plexus but we don't use Windows heavily. I only installed it a few weeks ago in Parallels so fire away! Jason. Thanks, Franz - 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: [vote] release maven-eclipse-plugin
your wish is etc... plexus-utils 1.4-alpha-1 released :) Andy Fabrizio Giustina wrote: Thanks Jason, could I ask you to take care of the plexus-utils stuff? Should be the only non-maven dependency needed for this release, I could take care of the rest... the plexus release should be solved independently from this vote. fabrizio On 12/11/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: +1 Go for it, I will help you release and move stuff. I question is far from settled as to integration testing but the eclipse plugin release needs to be made. I'll be doing nothing but releases from now until the new year it seems so I can help you with anything related to m2. Jason. On 11 Dec 06, at 5:02 AM 11 Dec 06, Fabrizio Giustina wrote: > I was already planning to start a vote, so a +1 from me since we > already waited too long and added so many changes and enhancements > lately. > > Anyway, as usual there are a couple of things that need to be done > before: > - license headers needs to be updated and added where missing > - we will have to wait till the remote-resources-plugin is released > (but this should happen soon) > > And a bigger issue (the reason why I was delaying this vote): > - there are a few (!) shared components used for testing that need to > be release as well: > org.apache.maven.shared:maven-test-tools:1.0-SNAPSHOT > org.apache.maven.shared:maven-plugin-testing-tools:1.0-SNAPSHOT > org.apache.maven.shared:maven-plugin-testing-harness:1.0-beta-2- > SNAPSHOT > > plus: > - org.apache.maven.shared:maven-test-tools is still in the sandbox and > it requires a release version of: > org.codehaus.plexus:plexus-utils:1.4-SNAPSHOT > > - org.apache.maven.shared:maven-plugin-testing-tools is in the sandbox > too and depends on the following snapshots: > org.apache.maven.shared:maven-repository-builder > org.apache.maven.shared:maven-invoker > > and more: > - maven-repository-builder is still in the sandbox too and depends on > a snapshot version of > org.apache.maven.shared:maven-common-artifact-filters > > ... so, this vote should also mean moving 3 artifacts out of the > sandbox and release other 6 artifacts (not counting the plexus one)? > I think we really need to do this bunch of release (even marking some > components as beta or even alpha), so for me this is an unconditional > +1 for everything: we need a way out from this mess... > > > fabrizio > > > On 12/11/06, Graham Leggett <[EMAIL PROTECTED]> wrote: >> Hi all, >> >> I would like to propose the release of the maven-eclipse-plugin. This >> will bring the eclipse:make-artifacts goal into a non snapshot >> release. >> >> Regards, >> Graham >> -- >> >> >> > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] maven release process ( gpg / javadoc / site / source / remote-resources ) plugins.
+1 to all
Andy
Fabrizio Giustina wrote:
a +1 for all of them, we really need a release at this point
there is only something left that needs to be fixed before the
release: documentation for the gpg plugin needs to be rewritten, I see
that the usage guide refers to the "Genesis Tools Plugin for Maven 2",
to a "Java Version Control" goal and so on...
fabrizio
On 12/10/06, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
After a chat with Jason about the new release process / staging / etc...
I feel it is time to get a release out for the following plugins.
maven-gpg-plugin 1.0
maven-javadoc-plugin 2.2
maven-site-plugin 2.0
maven-source-plugin 2.0.2
maven-remote-resources-plugin 1.0
This will allow for the following ...
* release staging.
* gpg signing of all artifacts.
* ${artifactId}-${version}-sources.jar creation
* ${artifactId}-${version}-javadoc.jar creation
* Proper inclusion of the Apache LICENSE and NOTICE files.
I would like to call a vote on getting the 5 crucial plugins released in
a non-SNAPSHOT form.
Once these plugins are in place, the top level parent poms (maven-parent
and apache) can be updated to make these processes standard for all
releases.
To kick things off ...
+1 maven-gpg-plugin
+1 maven-javadoc-plugin
+1 maven-site-plugin
+1 maven-source-plugin
+1 maven-remote-resources-plugin
- Joakim Erdfelt
-
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]
Re: Where are plug-in classpaths resolved?
Yup, these changes are in trunk now :) Andy Jason van Zyl wrote: On 6 Dec 06, at 8:18 PM 6 Dec 06, Brett Porter wrote: DefaultPluginManager is the place to look. You are looking for the creation of a child plexus container, and jar resources being added to that. On the code we're about to merge into trunk the container creation is now gone. It's the same place in the DefaultPluginManager but we are now creating a Realm per component which is a Realm per plugin (maven plugin = plexus component). So there is no multiple container creation per run of Maven. This code is about to be merged to trunk if it is not already. Jason. On 07/12/2006, at 10:20 AM, Wendell Beckwith wrote: Can a dev comment on http://jira.codehaus.org/browse/MANTRUN-51 and/or http://jira.codehaus.org/browse/MANTRUN-63 since I'm pretty sure their one and the same? This is such an issue to work around that previously I got around it by breaking my command invocation into 2 separate mvn invocations through our build server, but now I want to conditionally activate a profile and this bug negates that capability. I realize people are busy but if I can be pointed to the code location(s) that resolves plug-in classpaths then I can see about creating a patch. Wb - 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]
Plexus container and classworlds API in trunk
the maven.new branch which contained the work to get maven up to the latest and greatest plexus container and classworlds has been branched to trunk. The tests all pass and bootstrapping works here, please bug Jason or I if there appears to be any problems with this substantial change. Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r482676 - in /maven/plugins/trunk/maven-changelog-plugin: pom.xml src/test/java/org/apache/maven/plugin/changelog/stubs/ScmProviderStub.java
fair point - if you are imminently making the release I suppose it makes sense ;) Andy Brett Porter wrote: Yes, it's just a pain to change it only to change it back again when a release is imminent. - Brett On 06/12/2006, at 8:59 PM, Andrew Williams wrote: Not really - I'm with Dan here, if we are working to a beta-4 release surely it should be 1.0-beta-4-SNAPSHOT. That way there is no confusion as to what version to release. Then when 1.0 is ready it can be dropped up to the 1.0 level. Is this not the behavior documented in BBwM? Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r482676 - in /maven/plugins/trunk/maven-changelog-plugin: pom.xml src/test/java/org/apache/maven/plugin/changelog/stubs/ScmProviderStub.java
Not really - I'm with Dan here, if we are working to a beta-4 release surely it should be 1.0-beta-4-SNAPSHOT. That way there is no confusion as to what version to release. Then when 1.0 is ready it can be dropped up to the 1.0 level. Is this not the behavior documented in BBwM? Andy Emmanuel Venisse wrote: the release will be beta-4, but the version is maven-scm poms is actually 1.0-SNAPSHOT and I won't change them before the release. When I'll release, I'll set the version to beta-4 and not 1.0. The next version will be 1.0-SNAPSHOT. Hope it's clear now :) Emmanuel Dan Tran a écrit : i am confused here. beta-4 or 1.0? -D On 12/5/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: yes, it will be 1.0-beta-4, but actually, it's 1.0-SNAPSHOT. Emmanuel Dennis Lundberg a écrit : > Did you mean for the version of Maven SCM to be 1.0-SNAPSHOT? > > Shouldn't that be 1.0-beta-4-SNAPSHOT judging by the messages on the > scm-dev list? > - 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]
Surefire plugin merge
Just a note to explain: I created the sandbox module "surefire-plugin-merge" to try merging the two maven surefire plugins into the surefire codebase as discussed before. The reason it is not straight forward is that when the maven-surefire- plugin is enabled is that maven detects a circular dependency. The code is here to try and resolve this before it goes back to surefire trunk. Andy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release MWAR Plugin
+1 Andy Vincent Siveton wrote: Late, but here's my +1 Vincent 2006/11/28, Stephane Nicoll <[EMAIL PROTECTED]>: +1 Stéphane On 11/28/06, John Tolentino <[EMAIL PROTECTED]> wrote: > Hi Everyone, > > The latest version (2.0.2-SNAPSHOT) of the maven-war-plugin is now > deployed to the snapshot repo. We'll also have the license stuff > resolved before doing any release. > > For your reference of features included in this release: > http://www.nabble.com/Planning-a-release-of-Maven-War-Plugin-tf2714187s177.html > > I now like to call a vote for Releasing the Maven WAR Plugin. > > 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] - 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]
