On Mon, 19 Sep 2005, Brett Porter wrote:
> Kenney Westerhof wrote:
>
> Maven is about encouraging patterns, but not necessarily our patterns.
> Hopefully people will use the defaults for simplicity, but if a company
> standard is in force that should be easy too.
Ofcourse, I totally agree. But now it seems that the most easy to read
poms are those for projects that adhere to 'our' standards. If we don't
inherit parent's settings (maybe only useful to inherit if the parent has
packaging pom?) people are forced to re-specify those locations in each
pom.
> >I'd say: use the parent pom's directory value as a default if none is
> >specified (inherit, don't merge), and augment the resources set using
> >profiles (merge). That would be.... 1 ?
> >(Although 3 is almost the same - profile redefine resources means
> >overriding?)
> >
> >
> You're combining 1 and 4.
>
> 1 is where the profile (merged) behaves differently to inheritence (not
> merged, but inherited as a whole) where 3 is where they behave the same
> way (no merge for either, but inherited as a whole)
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.
[snip]
> That sounds reasonable. That given, I'd really prefer we merge
> everything (including inheritence and the super POM). I think it is
> useful for us to be able to say profiles behave identically to
> inheritence (not just from a technical perspective). It's easy to
> explain, allows all the features, shouldn't have negative side effects
> if you end up with extras (as they just get ignored when they don't
> exist), and allows setting a company standard. I definitely agree we can
> merge the in/excludes list for a directory as you and John suggested (I
> realise now this is different to just aggregating the different
> resources sets because of the precedence of excludes).
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.
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.
-- Kenney
>
> So... that leads me to 2 now.
>
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
