The big problem with baking this stuff into a maven distro is the fact that a new maven release can hose your build, and make you gunshy about ever upgrading again. I suppose this is a counter-argument to my argument about how putting the parent pom + lifecycle defs on central would make the Maven distro a lifeless hull...
-j On 4/12/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
Maven already has the concept of super-pom with defaults, it makes sense to me to add the plugin versions as part of the defaults. You'd still have the problem of 2.1.0 may have different versions then 2.1.1 but at least you don't need to ask for each plugin. Then I'd remove the -U option and make plugin version mandatory in the pom. I think these are easy steps that would solve most of the trouble and later we can revisit other features, like writing the "default" versions to the pom during release process. Advanced users already know how to lock down plugin versions so I wouldn't worry to much about that case. 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] > > > > > -- 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]
