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]
