RE: Remove auto-resolution of plugin versions from Maven 2.1
Apologies for the delayed response. I must've missed the message. I'd have to check with Andrus Adamchik, since he was the guy that had to keep fixing the POM. I know for certain that we've been bitten numerous times by the Geronimo folk though, both transitively and directly. We also got bit by the whole surefire/classloader issue, which the suggestions in this thread would take care of. For my own stuff, I've had to rely on SNAPSHOT for Selenium and Cargo, because either the released versions were broken in some way or didn't support newer releases of external software. At least in the case of Selenium, the authors know that they're released version is broken and their response is to just use SNAPSHOT. That's the sort of scenario I'd like to see avoided if possible. -- Kevin -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 5:24 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 I'm interested to know which snapshots bit you guys so hard? Was it a [set of] internal snapshots, or were they snapshots from Maven or some other OSS project that you depend on or use? If we start talking seriously about shorter dev cycles and milestone releases with less of a barrier to release (for alpha quality, for instance)...and start shunning snapshots as an acceptable mechanism for distributing pre-release code...would that have helped you all? -john On 4/12/07, Kevin Menard [EMAIL PROTECTED] wrote: I agree. I am suggesting that it's a little too easy to use SNAPSHOTs and that all that wonderful time maven was supposed to save you in preparing releases is trumped by the time it takes to just append -SNAPSHOT to a version number. Sure, it's people abusing it, but it's easy to abuse and looks like it's officially condoned as proper behavior. Things get even murkier when transitive dependencies are considered. So, I'm not suggesting dumping SNAPSHOT wholesale, but making it more difficult to distribute an artifact via SNAPSHOT (maybe require the end user to have to agree to use a new SNAPSHOT each time one is available or something). Maybe we'll just have to agree to disagree. I will say that this matter has bitten the Cayenne team a few times now, and we've come close to dumping maven altogether. It got to the point where we had to start pinning SNAPSHOTs by timestamp via a guess and check method. Perhaps the plugin Nigel suggested would help matters, though. -- Kevin -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 3:10 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Snapshots are a very good thing for internal development. It would be impossible to manage my builds without them. I think that people using snapshots of plugins are a symptom of another problem -- long release cycles. Just because people do bad things with snapshots doesn't mean snapshots should go away. It already takes a little effort to get at them, the snapshot repo isn't part of the super-pom, so if you go out of your way to get them, you should understand the consequences. It's like me picking up an unstable version of some jar and then complaining that it broke later and asking the creators to stop releasing unstable versions at all(that are clearly marked as such). People would then just go get the code anyway. -Original Message- From: Kevin Menard [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 1:09 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Right. My point is that regardless of what the original intention may have been, the current process facilitates laziness via SNAPSHOTs. Without them, incremental builds would be necessary, which would give fixed version numbers with known binaries. If the plan is to take actions to help prevent users from having things break on them, this may be easier than the path you outlined. -- Kevin - 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: Remove auto-resolution of plugin versions from Maven 2.1
A bit of a departure from the discussion, but still related . . . It may be worthwhile to rethink the whole SNAPSHOT system, too, then. Way too many plugins and dependencies sit in a SNAPSHOT limbo, presumably because it's simpler than cutting a release. And then SNAPSHOT to SNAPSHOT may break builds. In this case, the user has specified precisely the version he needs for his build (perhaps only SNAPSHOT has a particular bug fix), but he's still just as vulnerable to having the rug pulled out beneath him. -- Kevin -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 11:08 AM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 John, I think you've hit the nail on the head here. If you look at it this way, your plugins used are no different than dependencies. It's very dangerous to depend on the latest version of some jar from the repo, and likewise plugins. We don't default to grabbing the LATEST dependency, the same should be true for plugins. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 11:00 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 One thing I wanted to add: To me, it's critical to view your build script (or POM, or whatever binding you have to a build infrastructure) as a piece of the project code. The build - definition, shall we say? - is responsible for modifying your source code into a binary that works the way you would expect, and there are many options for the different steps involved in this process. This complexity means that there is a risk that the build process could introduce unexpected problems that may range from a file being out of place in the resulting binary, to a compiler option turned off that should be on, to using the wrong compiler. In other words, your build process is subject to bugs just like your project source code is, and needs to be tested alongside everything else. If you wait until release time to exercise a particular piece of this code, that's not so different from having a piece of code with absolutely no tests make it into your final binary. This is the biggest reason why I feel that locking down the POM at release time is dangerous. -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]
RE: Remove auto-resolution of plugin versions from Maven 2.1
Right. My point is that regardless of what the original intention may have been, the current process facilitates laziness via SNAPSHOTs. Without them, incremental builds would be necessary, which would give fixed version numbers with known binaries. If the plan is to take actions to help prevent users from having things break on them, this may be easier than the path you outlined. -- Kevin -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 12:59 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Snapshots are not intended to be depended on outside the context of the team working on it. Nothing released can ever had snapshot dependencies (on plugins or dependencies). I think what you are seeing is a symptom of longer release cycles. People need something fixed, they take a snapshot and move on. Unfortunately this is dangerous as you noted. We are working on getting tighter release cycles and I think it's starting to show recently. Here's how I deal with instances where I need a snapshot plugin in my corp build: 1. Checkout the code for the snapshot. 2. Build it, changing the version to something like 2.0-[companyname]-svnrev 3. If I have to patch the source at all, I take the whole thing and put it in my svn. If not, then the svnrev in the release points me back to where I got it in case I need it later. 4. Deploy it to my repos. 5. Use this now internally released version in my builds. It's a little extra work, especially when you get stuff that has further snapshot dependencies etc, but it is most definitely stable and reproducible. (even if our repo disappears). -Original Message- From: Kevin Menard [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 12:50 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 A bit of a departure from the discussion, but still related . . . It may be worthwhile to rethink the whole SNAPSHOT system, too, then. Way too many plugins and dependencies sit in a SNAPSHOT limbo, presumably because it's simpler than cutting a release. And then SNAPSHOT to SNAPSHOT may break builds. In this case, the user has specified precisely the version he needs for his build (perhaps only SNAPSHOT has a particular bug fix), but he's still just as vulnerable to having the rug pulled out beneath him. -- Kevin -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 11:08 AM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 John, I think you've hit the nail on the head here. If you look at it this way, your plugins used are no different than dependencies. It's very dangerous to depend on the latest version of some jar from the repo, and likewise plugins. We don't default to grabbing the LATEST dependency, the same should be true for plugins. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 11:00 AM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 One thing I wanted to add: To me, it's critical to view your build script (or POM, or whatever binding you have to a build infrastructure) as a piece of the project code. The build - definition, shall we say? - is responsible for modifying your source code into a binary that works the way you would expect, and there are many options for the different steps involved in this process. This complexity means that there is a risk that the build process could introduce unexpected problems that may range from a file being out of place in the resulting binary, to a compiler option turned off that should be on, to using the wrong compiler. In other words, your build process is subject to bugs just like your project source code is, and needs to be tested alongside everything else. If you wait until release time to exercise a particular piece of this code, that's not so different from having a piece of code with absolutely no tests make it into your final binary. This is the biggest reason why I feel that locking down the POM at release time is dangerous. -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
RE: Remove auto-resolution of plugin versions from Maven 2.1
I agree. I am suggesting that it's a little too easy to use SNAPSHOTs and that all that wonderful time maven was supposed to save you in preparing releases is trumped by the time it takes to just append -SNAPSHOT to a version number. Sure, it's people abusing it, but it's easy to abuse and looks like it's officially condoned as proper behavior. Things get even murkier when transitive dependencies are considered. So, I'm not suggesting dumping SNAPSHOT wholesale, but making it more difficult to distribute an artifact via SNAPSHOT (maybe require the end user to have to agree to use a new SNAPSHOT each time one is available or something). Maybe we'll just have to agree to disagree. I will say that this matter has bitten the Cayenne team a few times now, and we've come close to dumping maven altogether. It got to the point where we had to start pinning SNAPSHOTs by timestamp via a guess and check method. Perhaps the plugin Nigel suggested would help matters, though. -- Kevin -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 3:10 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Snapshots are a very good thing for internal development. It would be impossible to manage my builds without them. I think that people using snapshots of plugins are a symptom of another problem -- long release cycles. Just because people do bad things with snapshots doesn't mean snapshots should go away. It already takes a little effort to get at them, the snapshot repo isn't part of the super-pom, so if you go out of your way to get them, you should understand the consequences. It's like me picking up an unstable version of some jar and then complaining that it broke later and asking the creators to stop releasing unstable versions at all(that are clearly marked as such). People would then just go get the code anyway. -Original Message- From: Kevin Menard [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 1:09 PM To: Maven Developers List Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1 Right. My point is that regardless of what the original intention may have been, the current process facilitates laziness via SNAPSHOTs. Without them, incremental builds would be necessary, which would give fixed version numbers with known binaries. If the plan is to take actions to help prevent users from having things break on them, this may be easier than the path you outlined. -- Kevin - 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]
Sandbox question
Hi all, I have an immature jython plugin I've been working on that has largely been used internally. It looks like something that the sandbox could be useful for, but I'm debating the merits of just hosting it myself. I guess what would help me is understand what the sandbox provides. Is it just an SVN area? Where would plugin docs, site, etc. be hosted? Is there some sort of graduation path up to a fully supported plugin? Thanks, Kevin Kevin Menard Servprise International, Inc. 800.832.3823 x308 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sandbox question
Hi Brian, Thanks for the info. I am already an ASF committer (Cayenne project), but other than the initial message sent to the committers list regarding the sandbox, I couldn't find much more on it. I take it I can can just add my contribution to https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/ ? Is there a standard place to put the site docs or just my p.a.o account? Re: JIRA, how is that handled? It looks like all the maven JIRA items are hosted by codehaus . . . Thanks again, Kevin -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 9:47 AM To: Maven Developers List Subject: RE: Sandbox question Hi Kevin, The sandbox was created to give existing Apache committers a place to create plugins that may potentially be brought up to full released plugins. The benefits to putting them here are that the infrastructure with all the other plugins will be shared (Jira, Svn,Site etc) and it's the first place people look for plugins. If you aren't already an Apache committer, then an option would be to try the mojo project on codehaus (http://mojo.codehaus.org). This is where we host plugins that don't meet Apache licenses, or are developed by non-apache committers (or they choose to put it there for other reasons). The barriers to entry are lower in mojo, but you still need to be active for a while and submit plugins and patches via jira until you get voted in with full commit rights. Hosting a plugin yourself can certainly be easier in the short term, but you will get more exposure and potential users and developers on either of the 2 communities I mentioned. It's also easier to get your builds onto the central repository so people can easily use them. Hope that helps. --Brian -Original Message- From: Kevin Menard [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 8:05 AM To: dev@maven.apache.org Subject: Sandbox question Hi all, I have an immature jython plugin I've been working on that has largely been used internally. It looks like something that the sandbox could be useful for, but I'm debating the merits of just hosting it myself. I guess what would help me is understand what the sandbox provides. Is it just an SVN area? Where would plugin docs, site, etc. be hosted? Is there some sort of graduation path up to a fully supported plugin? Thanks, Kevin Kevin Menard Servprise International, Inc. 800.832.3823 x308 - 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]
