Re: resource inheritence
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My vote is for #1, for the following reasons:
I think it's really more important to consider the use cases of
profiles, rather than the simplicity of describing their use. Profiles
are supposed to be modifications per environment (whether that be source
env. like for system paths, or target env. like for 'test' server port,
etc.), so they should be small. If users need to add an auxilliary
resource location for a particular environment, or add one of a set of
resources depending on the target environment, I think it'd be insane to
require them to restate their entire set of resources in each
environmental permutation.
WRT inherit-all, I think that's asking for unexpected behavior. If the
user has repurposed src/main/resources for something their company
already has defined, then you've automatically got a problem with the
only solution to override the definition of that resource and exclude
everything - not very intuitive. I think we should leave magic like this
out.
IMO profiles and inheritance are not the same thing...they just happen
to *look* similar. That's not a reason to lump them together and treat
them as one, no matter how much it simplifies the documentation.
Actually, I'd really like to see the merge-vs-override decision
delegated to the user, with a sensible default...they could do this with
a mechanism similar to the one used to merge configurations now...XML
attributes. I understand that this would complicate the POM immensely,
which is why we'd have a sensible default behavior that is only
overridden in extreme circumstances. It's a low priority, but I think
it'd be nice to say "This is how the POM assembly works by default,
here's how to override it in certain places/circumstances."
My 2-cents, of course.
- -john
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).
|
| Thoughts?
|
| For me:
| 1. -1
| 2. +0
| 3. +1
| 4. -0
|
| - Brett
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDLtZkK3h2CZwO/4URAjLxAJ9wlaLwlCtryHlbTvUeCJvONW3bowCggs1n
qiGIJbT0XW3UPDUsOawK/4o=
=npFe
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resource inheritence
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]
Re: resource inheritence
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]
Re: resource inheritence
Kenney Westerhof wrote:
>Resource inheritance from a normal pom seems useless to me since the
>paths are totally different (other project).
>
Right, that's what I was getting at too.
>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 :))
>
>
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.
>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)
>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.
>
>
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).
So... that leads me to 2 now.
Cheers,
Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: resource inheritence
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]
resource inheritence
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).
Thoughts?
For me:
1. -1
2. +0
3. +1
4. -0
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
