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 On 4/12/07, John Casey <[EMAIL PROTECTED]> wrote:
Let me see if I can address everything in the thread since the last time I looked...here goes: :-) 1. Locking down on release is dangerous IMO, because it implies that you might be making a change to the build behavior at release time. In other words, these particular versions may introduce a subtle problem that wasn't present for other builds, because the other builds were done without locked-down versions, and done on another dev's box (with a slightly different set of plugin versions; remember the -U timing!). You could say that this would be vetted out during the RC/voting process, but wouldn't it be better to make it part of the daily bread-and-butter routine, assuming we could make that routine a little easier to handle? 2. WRT specifying all versions for lifecycle plugins, I'd suggest the use of either (a) a lifecycle/packaging version that would specify each plugin's version, as was suggested on the users@ list; or, (b) a new piece of syntax to specify a set of plugin versions that are commonly used together. (A) wouldn't make much sense unless we externalized all of our packagings, IMO...which makes Maven sort of a lifeless hull without at least an initial internet connection. (B) gets you into the realm of maybe making these plugin-sets additive (specify multiple of them in the same POM), and maybe allowing them to provide configuration, etc...which is a whole new can of worms, I guess. 3. I think it's quite dangerous to keep on the track of having the common user use the current RELEASE meta-versions. We have to get out of this [ 1.0-2.0) mindset (where we're operating with basically the same feature-set and no breaks in compatibility from release to release). RELEASE is indiscriminate about compatibility rules, which means that any POM checked in that relies on RELEASE meta-versions may break in the future. This is compounded by the fact that new plugin versions are *never* detected unless (a) the plugin hasn't been used before, and isn't in the local repository, or (b) the user *chooses* to use -U...that means that for any two-member development team, unless they're invoking -U in synchrony there is a real potential for mismatched plugin versions. Wayne, your experiences wouldn't seem to be very encouraging for the idea of writing more/better documentation. Would a cheat-sheet or a FAQ that's well-organized help with these sorts of newbie problems? Dan/Carlos/Wayne/etc.: would it be reasonable to provide some nice plugins (maybe with GUIs where we can) that will help users choose what they need? Peter: WRT the parent POM residing in central, see my comment about the externalized packaging/lifecycle definitions...that would make Maven itself fairly limited if something happens on the network. Right now, it is possible (maybe a little tough, but possible) to use Maven offline...with an externalized parent, you'd have to have an update policy or a mechanism for specifying the root POM version, which would land you in a tricky spot WRT multimodule builds. I'm sure I've missed out on someone's comments, but I think that pretty well summarizes my thinking... -john On 4/12/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote: > > 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] > >
