On Mon, 19 Sep 2005, Brett Porter wrote:
> Hi,
>
> Some opinions needed. Currently we have a problem in: MNG-895 (cannot
> add resources to a profile).
>
> Basically, profiles operate identically to inheritence, and so resources
> are not merged through inheritence, but if they do exist in the parent
> they are inherited (eg src/main/resources from the super POM).
>
> So, this seems a bit inconsistent to me. If you have 0 resources you get
> the parent, if you have 1 you don't. But if you enable merging you have
> no way to turn off inherited resources like src/main/resources.
>
> To me, I don't see why resources should be inherited at all except to
> apply that default, especially since ${basedir}/my-resources in the
> parent actually doesn't point to teh parent's basedir but the
> subprojects basedir. Furthermore, with aggregation, its possible that
> new resource roots would be introduced for the parent and not the children.
>
> Options:
> 1. handle profiles differently (merge resources, but don't merge for
> inheritence)
> 2. merge for inheritence and profiles (we can probably live with it
> because the extra directories will just be ignored in the children)
> 3. keep as is (inherit resources element if there is none in the
> subproject, but don't merge, profiles would need to redefine resources)
> 4. turn off inheritence of resources altogether (src/main/resources
> would be applied as a default after the fact if the end result is empty).
Resource inheritance from a normal pom seems useless to me since the
paths are totally different (other project). Specifying default
directories for an entire project tree (for users that don't conform to
the maven2 directory layout) is nice for pom readability, but bad for
the maven2 directory layout acceptance (i think the m2 directory layout is
very flexible and allows for extension, so everybody should adopt it :))
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?)
If people want to specify different resource sets using profiles, they
are probably different directories, or different filters.
If the default resources location is present, then those resources should
be included regardless of profiles.
If the profile's resources section specifies a different directory, it's
added, and if it specifies the same directory ('key'), but different
include/exclude patterns, it's likely the user intented to exclude
some resources or include some new ones. We can't force them to split up
according to directories, but this is safest. If we 'augment' the
includes/excludes, we would need a second set of include/exclude
parameters to the DirectoryScanner (override-*): if normally the resource
was excluded, but the override specifies otherwise, include it, and the
opposite. Technically hard, but intuitive.
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
