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]
