You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Ca...@gebit.de on 2013/10/28 14:50:59 UTC

Review for IVY-1431?

Hi,

could have anyone have a look at the patch for 
https://issues.apache.org/jira/browse/IVY-1431 ? 
It fixes a problem with publishing modules with their original artifacts 
(e.g. *.pom).

There's even a testcase included :-)

Thanks,
Carsten

Re: Review for IVY-1431?

Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 30 oct. 2013 à 17:27, Carsten.Pfeiffer@gebit.de a écrit :

> Yes, the idea is to install the artifact just as it was downloaded. If it 
> was downloaded
> from an Ivy repository, you install the jar + the ivy.xml. If it was 
> downloaded from a Maven
> repository, you install jar, the original .pom. and the ivy.xml.
> 
> If you think that this depends too much on where the artifact originally 
> comes from, one could
> add an optional attribute to the install task "installOriginalMetadata" or 
> something like that, so that
> this would become an explicit action.
> 
> Any comment from a committer, perhaps? :-)

I understand Stephen's argument over properly supporting what you are trying to accomplish: making Ivy support install in a maven repository. But my fear is that it will be not easy to implement fully and reliably.

So I would prefer only supporting the sub-feature which is pushing the original artifact if any.

I'll comment on the jira issue about details of the patch.

Nicolas

> 
> Thanks
> Carsten
> 
> 
> 
> Von:    Stephen Haberman <st...@gmail.com>
> An:     dev@ant.apache.org
> Datum:  29.10.2013 04:04
> Betreff:        Re: Review for IVY-1431?
> 
> 
> 
> 
> 
>> So your proposal would be something like a task "makeallmissingpoms"?
> 
> Well, no, I was originally thinking that re-making all poms from the
> ivy.xml files would be preferable, so that the output would be as
> consistent as possible. Basically a transitive ivy:install+ivy:makepom.
> 
> So the pom files would be consistent, always canonically derived from
> the Ivy file, regardless of whether they came from an internal Maven
> repo or an internal Ivy repo.
> 
>> I think that it's actually quite important to not tamper with existing
>> metadata (i.e.  pom -> ivy.xml -> pom)
> 
> Yeah, I understand that makes sense for your scenario. You're basically
> using ivy:install to copy artifacts between Maven repos.
> 
> Hm. Yeah, it still seems a little weird, but I suppose if I was doing
> that, I'd want your behavior as well.
> 
> ...oh. It looks like .original files in the cache are only poms for the
> person who originally downloaded the file from Maven.
> 
> Like if I have two devs, A and B, and A installs commons-lang into our
> Ivy repo, his cache's .original is a pom. If B downloads commons-lang
> from our Ivy repo, his cache's .original is an Ivy file.
> 
> So, now if B goes back and he's the one that does the "ivy:install to
> maven" task that you want, his cache's original file isn't the pom.
> 
> Does this sound right? I think to make this a truly supported feature,
> you'd have to someone get the pom into the Ivy repo, and into every
> user's local Ivy cache, not just A's.
> 
> Otherwise the behavior changes depending on who runs what, and that is
> confusing (AFAICT/IMO).
> 
> - Stephen
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Review for IVY-1431?

Posted by Ca...@gebit.de.
Yes, the idea is to install the artifact just as it was downloaded. If it 
was downloaded
from an Ivy repository, you install the jar + the ivy.xml. If it was 
downloaded from a Maven
repository, you install jar, the original .pom. and the ivy.xml.

If you think that this depends too much on where the artifact originally 
comes from, one could
add an optional attribute to the install task "installOriginalMetadata" or 
something like that, so that
this would become an explicit action.

Any comment from a committer, perhaps? :-)

Thanks
Carsten



Von:    Stephen Haberman <st...@gmail.com>
An:     dev@ant.apache.org
Datum:  29.10.2013 04:04
Betreff:        Re: Review for IVY-1431?





> So your proposal would be something like a task "makeallmissingpoms"?

Well, no, I was originally thinking that re-making all poms from the
ivy.xml files would be preferable, so that the output would be as
consistent as possible. Basically a transitive ivy:install+ivy:makepom.

So the pom files would be consistent, always canonically derived from
the Ivy file, regardless of whether they came from an internal Maven
repo or an internal Ivy repo.

> I think that it's actually quite important to not tamper with existing
> metadata (i.e.  pom -> ivy.xml -> pom)

Yeah, I understand that makes sense for your scenario. You're basically
using ivy:install to copy artifacts between Maven repos.

Hm. Yeah, it still seems a little weird, but I suppose if I was doing
that, I'd want your behavior as well.

...oh. It looks like .original files in the cache are only poms for the
person who originally downloaded the file from Maven.

Like if I have two devs, A and B, and A installs commons-lang into our
Ivy repo, his cache's .original is a pom. If B downloads commons-lang
from our Ivy repo, his cache's .original is an Ivy file.

So, now if B goes back and he's the one that does the "ivy:install to
maven" task that you want, his cache's original file isn't the pom.

Does this sound right? I think to make this a truly supported feature,
you'd have to someone get the pom into the Ivy repo, and into every
user's local Ivy cache, not just A's.

Otherwise the behavior changes depending on who runs what, and that is
confusing (AFAICT/IMO).

- Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org



Re: Review for IVY-1431?

Posted by Stephen Haberman <st...@gmail.com>.
> So your proposal would be something like a task "makeallmissingpoms"?

Well, no, I was originally thinking that re-making all poms from the
ivy.xml files would be preferable, so that the output would be as
consistent as possible. Basically a transitive ivy:install+ivy:makepom.

So the pom files would be consistent, always canonically derived from
the Ivy file, regardless of whether they came from an internal Maven
repo or an internal Ivy repo.

> I think that it's actually quite important to not tamper with existing
> metadata (i.e.  pom -> ivy.xml -> pom)

Yeah, I understand that makes sense for your scenario. You're basically
using ivy:install to copy artifacts between Maven repos.

Hm. Yeah, it still seems a little weird, but I suppose if I was doing
that, I'd want your behavior as well.

...oh. It looks like .original files in the cache are only poms for the
person who originally downloaded the file from Maven.

Like if I have two devs, A and B, and A installs commons-lang into our
Ivy repo, his cache's .original is a pom. If B downloads commons-lang
from our Ivy repo, his cache's .original is an Ivy file.

So, now if B goes back and he's the one that does the "ivy:install to
maven" task that you want, his cache's original file isn't the pom.

Does this sound right? I think to make this a truly supported feature,
you'd have to someone get the pom into the Ivy repo, and into every
user's local Ivy cache, not just A's.

Otherwise the behavior changes depending on who runs what, and that is
confusing (AFAICT/IMO).

- Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Antwort: Re: Review for IVY-1431?

Posted by Ca...@gebit.de.
Hi Stephen,

thanks for having a look and your remarks.

I think that it's actually quite important to not tamper with existing 
metadata (i.e.
pom -> ivy.xml -> pom). If makepom could be instructed to recreate the 
original
pom instead creating a "similar" one, that would be fine, of course.

So your proposal would be something like a task "makeallmissingpoms"? I.e.
go through a module and all its dependencies, and create a pom for every 
module
that does not have one?

Thanks,
Carsten



Von:    Stephen Haberman <st...@gmail.com>
An:     "Ant Developers List" <de...@ant.apache.org>
Datum:  28.10.2013 16:21
Betreff:        Re: Review for IVY-1431?




Hi Carsten,

IANAC (I am not a commiter), but I saw your patch go by and had a few
thoughts.

I understand that, for your from-Maven dependencies, there are .pom
around already, but that seems like luck--what about other dependencies
you're pulling in that didn't come from Maven? That don't have existing
poms?

I think a more general solution would be to have ivy:install support
using the ivy:makepom functionality to systematically make POMs for
your module + all of the dependencies directly from their Ivy files.

Yes, this would cause round-tripping from original POM -> Ivy file ->
derived POM, such that original POM may != derived POM, but I think
conceptually this "install into repo with POMs for *all* artifacts" is
a better feature for Ivy than "install into repo with POMs for only
the artifacts that happen to already have them".

That said, your approach sounds great for your specific setup, but it
seems like a little bit of a hack and not very general to me.

- Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org



Re: Review for IVY-1431?

Posted by Stephen Haberman <st...@gmail.com>.
Hi Carsten,

IANAC (I am not a commiter), but I saw your patch go by and had a few
thoughts.

I understand that, for your from-Maven dependencies, there are .pom
around already, but that seems like luck--what about other dependencies
you're pulling in that didn't come from Maven? That don't have existing
poms?

I think a more general solution would be to have ivy:install support
using the ivy:makepom functionality to systematically make POMs for
your module + all of the dependencies directly from their Ivy files.

Yes, this would cause round-tripping from original POM -> Ivy file ->
derived POM, such that original POM may != derived POM, but I think
conceptually this "install into repo with POMs for *all* artifacts" is
a better feature for Ivy than "install into repo with POMs for only
the artifacts that happen to already have them".

That said, your approach sounds great for your specific setup, but it
seems like a little bit of a hack and not very general to me.

- Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org