+1 if we can get my name in there, looks like I forgot to commit it when I added myself in there :)
jesse On 1/28/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
All right. Who's responsible for fixing this? Can I help? I have two plugin releases waiting for that and if there's anything I can do to speed this up, let me know. Thanks, Séphane On 1/28/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 27 Jan 07, at 1:21 PM 27 Jan 07, Brett Porter wrote: > > > > > On 28/01/2007, at 2:51 AM, Jason van Zyl wrote: > > > >> 1) Be in one place not an admixture of something in the parent POM > >> and something elsewhere. It's too confusing to know where things > >> come from. Unfortunately the help:effecective-pom command doesn't > >> provide the source for the bits and pieces merged in. > > > > This only affects source + javadoc plugins, and because they are in > > the parent POM, and because the release plugin uses that profile, > > they'll be duplicated. So I agree... but we can't do it yet. > > > > Sure we can: > > 1) Use a completely new profile > 2) Warn people in the next release of the release plugin > > We can make the old work and encourage the new. > > >> 2) Lock down every version of everything used which the bit in the > >> parent POM currently doesn't do which leads to erratic behavior. > > > > I already answered your concern here: http://mail- > > archives.apache.org/mod_mbox/maven-dev/200701.mbox/% > > [EMAIL PROTECTED] > > > > If someone has built then they are ok. When you go to do a release > and it pulls in these plugin that are not locked down then you get > screwed in the middle of a release. > > > I wish I'd heard your continued objections then, rather than wait > > for a release to raise them again. Anyway, I agree with the goal, > > but I don't think it's something we can do yet, and I think we need > > to consider a proper solution for all builds, not just ours. Your > > snippet doesn't meet this criteria completely either (only adding > > versions for the source and javadoc plugins). > > > >> That snippet should be used, we should deprecate the use the bits > >> in the parent POM, it should be removed from the parent POM for > >> 2.1 in addition to requiring the locking down of all versions of > >> plugins to provide stability. > > > > Only after the next release of the release plugin that makes this > > somewhat possible. > > No it's not, we use it as a profile. The old stuff works perfectly fine. > > > > > I'm not saying the POM is perfect, but it's better than what's in > > 7, and it allows us to actually make some releases now. > > Not without the whole intact profile. I don't want to release again > with something buried in the super POM. Other people will get the old > behavior which is fine. Having the complete profile isn't going to > hurt anyone else and stabilizes our releases. > > > > > > > - Brett > > > > --------------------------------------------------------------------- > > 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]
-- jesse mcconnell [EMAIL PROTECTED]
