On Oct 13, 2008, at 7:48 PM, Xavier Hanin wrote:
On Mon, Oct 13, 2008 at 10:27 AM, Hans Dockter <[EMAIL PROTECTED]>
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 http://www.nabble.com/understanding-SNAPSHOT-versions-
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
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
