On 24/04/2007, at 2:18 AM, Jason van Zyl wrote:
On 23 Apr 07, at 8:06 PM 23 Apr 07, Brett Porter wrote:
This sounds reasonable to me, but I think there's lots of things
that work on the assumption of one pom per g/a/v. So the attached
artifact should also get a new artifact ID
A new id if you are going to deploy separate artifacts, or the
original id and never deploying differently i.e. if you choose to
uber and change the POM you must always do that. If someone chooses
to always deploy like that is the standard way the world deals with
that artifact not changing it is fine.
Makes sense - so that's a different packaging too, I assume. This
would be a better alternative to the WAR and EAR scenarios
(currently, WAR is all or nothing). You can deprecate the artifact
type handler field that indicates if the deps are transitive or not
then.
However, what about rewriting the deps with a new scope instead?
(maybe 'included', maybe 'provided' already works). I think the
dependency information is useful to have, still - just want it
excluded from the resolution later on.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]