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.
- which also seems reasonable to me.
Yup, definitely or you'll end up with a clusterbunny. I'm only doing
the first case up there where there is only one artifact coming out
of the build for use, it's just uber'd.
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?
Yup, that's right.
Jason.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
