ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Dockter <>
Subject Re: Deploying to a Maven Repo with Ivy
Date Tue, 14 Oct 2008 13:40:34 GMT

On Oct 13, 2008, at 7:48 PM, Xavier Hanin wrote:

> On Mon, Oct 13, 2008 at 10:27 AM, Hans Dockter <>  
> wrote:
>> Hi,
>> I have started work to enable Ivy deploying to Maven repositories.
>> The first step has been pom generation. I know that Ivy has some  
>> code for
>> this but I found it rather inflexible and could not use it for my  
>> purposes.
>> The pom generation in Gradle works now and I will write more on  
>> this in
>> another posting. The Gradle team would be happy to contribute this  
>> code to
>> Ivy.
>> The next step is deploying, including deploying snapshots. Leaving  
>> aside
>> the question on how to integrate Maven deployment into the Ivy
>> resolver/repository framework. The rules for deployment, in  
>> particular
>> snapshot deployment are still somewhat mysterious to me (I have  
>> read the
>> thread 
>> to10444825.html).
>> The behavior is not documented and I guess can also be a changing  
>> target.
>> My question is: The Ivy team had to dive into the metadata stuff for
>> implementing the retrieval of snapshots. Is the logic how to  
>> modify the
>> metadata when deploying a new artifact (including snapshots) clear  
>> to you?
> The honest answer is no, this is not clear at least for me, I just  
> tried to
> make sure in the two main cases: when a specific version is given  
> to the
> snapshot, and when SNAPSHOT is used. The code to parse maven- 
> metadata.xml
> files is very simple, and can't be of any help in this case. I  
> guess the
> most reliable information can only come from Maven guys.

I'm wondering if it makes really sense to try to reengineer Maven here.

I think retrieving from Maven is very different from deploying to  
Maven. The ivy dependency DSL is more powerful and complex than the  
Maven one. So it is rather easy to integrate retrieval from Maven  
into the normal Ivy way of things. Deployment is the other way round  
which is harder to do. On the other hand, deployment is more  
decoupled than retrieval. There are no resolver chains which  
coordinate things, no conflict resolution, ...

I had a look at the Maven ant tasks and in how far they can be used  
to do the job. I think I will give them a try. In the first iteration  
I will use them programmatically with Ant. In the second iteration I  
might try to extract the relevant code but getting rid of the Ant  
dependency. The interesting task is the Ant deploy task. The question  
is how to integrate this with Ivy. I can imagine two ways of doing this:

1.) Creating a MavenUploadResolver which only offers publishing  
functionality. It would offer a convenient way to choose and  
configure the Maven upload protocol. It would for example throw an  
exception in the case a module has more than one artifact.  
Alternatively/complementary a user might specify which artifact  
should be deployed. Basically the resolver should try its best to do  
the job automatically. If unmappable Ivy concepts are used, it throws  
an exception. Alternatively the user can decide how to downgrade. One  
place where Maven is not inferior I think is the protocol layer. So  
Ivy users will be happy with this. I haven't worked with Ivy dynamic  
properties yet. It should be possible to apply them also to pom  
uploading. The Pom generator would have to take care of this.  
Snapshot handling we will get out of the box.

2.) Add a flag to the existing Ivy resolvers like 'uploadPom'. Under  
the hood we would do the same as in 1.). What we would do  
additionally is to try to figure out the Maven upload protocol from  
the information the resolver gives us.

I think I will start with 1.) and see how it works out. Later we  
could discuss about 2.).

I think deploying to a Maven repo is critical feature for Ivy. Using  
the Maven code for this would avoid a possible maintenance nightmare.  
It should be rather straight forward to implement and should give use  
100 percent compatibility. What do you think of this approach?

- Hans

Hans Dockter
Gradle Project lead

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message