On 16/09/05, John Casey <[EMAIL PROTECTED]> wrote: > Basically, there was a problem with the release plugin, wherein a > profile with an empty resources list was overriding the default > resources list from the super-POM. It's not really another use case for > the merge vs. override discussion, but it did highlight part of the > resource handling during profile injection, which is why I referred it > to 895. To fix this bug, I just put in a piece of code to check whether > the profile's resources list is empty (in addition to a null check) > before it overrode the model resources. I haven't addressed the override > vs. merge topic yet. > > Sorry for the false alarm! :)
No worries, I was just interested as to what had linked these two issues together :) > P.S. My personal view on this is that profiles are meant primarily for > augmentation, and secondarily for overriding...this would lead me to > conclude that resource lists should be merged wherever the resource keys > don't conflict (what's the key for a resource? probably it's dir). > That's the way I'm leaning for implementing/fixing 895, but I'd like to > solicit as much feedback as I can. -J I'd certainly agree - I don't see much in a profile that shouldn't be merged with it's POM. If a user wishes to override something in their POM within a profile, then couldn't the part that needs to be overridden be moved out into a separate profile? Thus allowing them to be switched on or off as appropriate. As Brett said the inheritance rules for profiles are the same as extending, so I guess if profiles never overrode then we'd need different strategies here. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
