Kenney Westerhof wrote: >Hm.. I meant to say: profiles are inherited AND merged (inheritance has >to either replace values (override) or merge them), whereas I think the >build information is project local and should not be merged, but possibly >only used for specifying defaults. > > Right, so we agree on that, but I'm firmly in favour for making it behave identically to inheritence. So I'd like to apply it to both.
>I agree.. except, the following is not possible then: > >PARENT: > resource dir not specified (and no resources present; no need > for resources here), so: > resource dir = src/main/resources (from the built-in root pom) > >CHILD (extends parent) > resource dir = specified explicitly as src/main/default-resources > profile A: > resource dir specified as src/main/resources > >Using your scheme the resources from profile A, even though that >profile is not activated, are included (the filters aren't applied). > >But this is about the only problem I can see: a parent defines >a default resource dir (either inherited from the root pom, or >explicitly), >and a child chooses to specify another resource dir as a default, >and uses the same directory name for a resource specified in a profile. > > > I think there are downsides either way. This one is pretty rare, and worked around by either using a different name, or putting it into the default with excludes **/**. >As it was not intended in the child to use that resource dir, it'll get >used. This complicates things for users as they need knowledge of parent >resource dirs to know what to specify and where. > > The more I think about it, knowledge of parent isn't such a bad thing (As long as you are insulated from changes in some ways). So... are we agreeing on (2) or do you think we need to differ the behaviour of profiles and inheritence? Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
