You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/04/23 02:36:43 UTC
Tackling MNG-1452
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Tackling MNG-1452
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Tackling MNG-1452
Posted by Jason van Zyl <ja...@maven.org>.
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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Tackling MNG-1452
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Tackling MNG-1452
Posted by Daniel Kulp <dk...@apache.org>.
Jason,
Out of curiosity, how does the "create a new pom" thing work?
I'm mostly just curious in regards to the gpg signing. I want to make
sure the pom that is deployed matches what is signed.
Dan
On Sunday 22 April 2007 20:36, 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org