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 - which also seems reasonable to
me. It's just a whole new artifact coming out of a single build, the
POM for which is autogenerated based on the original, if I understand
what you are proposing.
Is that right?
On 23/04/2007, at 2:36 AM, Jason van Zyl wrote:
Hi,
In the shade plugin I've added the capability to create a POM that
reflects what has been shaded. To correct the problem with the two
plexus JARs, I shaded one into the other so I have the single
plexus-default-container artifact again. So the idea being during
development modules are good, but for a user a single aggregate JAR
may be more convenient.
I am still of the opinion that if you have created N aggregate
artifacts for a given artifact that you should create a new POM to
reflect that. So in the example of the JAR I made for plexus. The
plexus-component-api artifact has been merged into the plexus-
container-default JAR so I removed that dependency from the
deployed artifact. I think this approach is far simpler then trying
to wrangle in something in the artifact code. I don't see how it
could be easily done when there are multiple aggregate artifacts
produced, and third party tools just grabbing the POM would have no
idea how to deal with excluding the right dependencies if it relied
on magic in maven-artifact.
So the general rule would become if you change the dependency
structure via some transformation then the deployed POM must
reflect this. I would prefer no magic and what you see in the POM
is what you get.
Anyone have any thoughts on this?
Jason.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
