-----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]
