This is getting pretty far afield from the original email in the
thread, but I'd say this is a perfect reason for separating the
statement of dependencies associated with a particular artifact on
the remote repository from the POM used to build it. We can (and do)
deploy the original POM used to build the project, but it also makes
a lot of sense IMHO to deploy some separate metadata describing the
dependencies that project used/required/specified during its build.
This means that any active profiles that inject dependencies would
have those dependencies included in the resulting dependency
statement. Likewise, "attached" artifacts such as assemblies could
include separate dependency metadata that would account for deps that
were included in the assembly itself...ditto shaded artifacts. In
cases where AspectJ debug aspects were woven into the artifact, the
aspectjrt dep would be included, but if not, the user doesn't have to
incur the extra overhead of that dependency.
-john
On Feb 12, 2008, at 10:39 AM, Brian E. Fox wrote:
We could deploy a "generated" POM that reflects the enabled profiles
and the
maven model used to build the artifact.
This won't work when the poms are used for inheritance out of the
repository. Suddenly a property meant to be resolved at build time to
something on the developer's machine is resolved to something on the
developer's machine who deployed the pom. Same with profiles.
Simplifying the pom simply for deployment has no benefit and takes
away
a lot.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
