You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Hans Dockter <ma...@dockter.biz> on 2008/10/13 13:56:47 UTC
Generating a Maven pom from Ivy
Hi,
I have submitted code into the Gradle trunk for auto generating a
Maven pom descriptor file from an Ivy ModuleDescriptor. This code is
all on the Ivy API level. Not everything we want to implement is
implemented yet. We are happy to offer this code eventually to the
Apache Ivy project (there is some code in Ivy for generating a pom
out of ivy objects but this code is pretty limited and was not usable
for our purpose).
What our code does:
One challenge is how to map between configurations and scopes, as
dependencies can belong to more than one configuration. In our code
we allow to map a configuration to one and only one scope. Different
configurations can be mapped to more than one scope. One can assign
also a priority to a particular mapping. Let's look at a couple of
cases:
- A dependency belongs to only one configuration: The first thing we
check is whether there is a mapping for this configuration. If there
is none, the dependency is by default not added to the pom. By
setting the global property 'includeUnmappedConfigurations' to true
such a dependency would be added. If the configuration is mapped, the
scope mapping is clear and the dependency is added.
- A dependency belongs to more than one mapped configuration: If the
mapped configurations map to the same scope the situation is clear.
If the mapped configurations map to different scopes the
configuration mapping with the highest priority is chosen. If there
is more than one configuration with a highest priority and they map
to different scopes an exception is thrown.
Exclude Rules: Our code has an exclude rule converter. This converter
gets an Ivy exclude rule and returns a Maven exclude rule or null. If
null is returned the exclude rule is not reflected in the pom. The
current simple logic of the converter is, that it returns a non null
value if the Ivy exclude rule uses an exact matcher and the name as
well as the organization of the module is specified.
Functionality that is still missing:
- Integrating the new Ivy 'override' rules the same way as the
exclude rules.
- Artifact dependencies are not mapped yet.
- Fine grained customization
The last point I think is very important. Due to the more powerful
elements Ivy has and many , often subtle, differences between Ivy and
Maven, auto generation can't always produce the result that is
needed. What we want to enable is that the user can modify any
property of an auto generated Maven dependency element. Customization
should also allow to remove auto generated elements as well as add
new elements. One thing we want to provide is a conversion listener.
A hook would getdev all the created MavenDependency object and can
analyze and modify them. Alternatively such a hook can provide a
'query by example' filter to get only a subset of the generated
MavenDependency elements.
Feedback is welcome
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Generating a Maven pom from Ivy
Posted by Xavier Hanin <xa...@gmail.com>.
On Mon, Oct 13, 2008 at 1:56 PM, Hans Dockter <ma...@dockter.biz> wrote:
> Hi,
>
> I have submitted code into the Gradle trunk for auto generating a Maven pom
> descriptor file from an Ivy ModuleDescriptor. This code is all on the Ivy
> API level. Not everything we want to implement is implemented yet. We are
> happy to offer this code eventually to the Apache Ivy project (there is some
> code in Ivy for generating a pom out of ivy objects but this code is pretty
> limited and was not usable for our purpose).
>
> What our code does:
>
> One challenge is how to map between configurations and scopes, as
> dependencies can belong to more than one configuration. In our code we allow
> to map a configuration to one and only one scope. Different configurations
> can be mapped to more than one scope. One can assign also a priority to a
> particular mapping. Let's look at a couple of cases:
>
> - A dependency belongs to only one configuration: The first thing we check
> is whether there is a mapping for this configuration. If there is none, the
> dependency is by default not added to the pom. By setting the global
> property 'includeUnmappedConfigurations' to true such a dependency would be
> added. If the configuration is mapped, the scope mapping is clear and the
> dependency is added.
> - A dependency belongs to more than one mapped configuration: If the mapped
> configurations map to the same scope the situation is clear. If the mapped
> configurations map to different scopes the configuration mapping with the
> highest priority is chosen. If there is more than one configuration with a
> highest priority and they map to different scopes an exception is thrown.
>
> Exclude Rules: Our code has an exclude rule converter. This converter gets
> an Ivy exclude rule and returns a Maven exclude rule or null. If null is
> returned the exclude rule is not reflected in the pom. The current simple
> logic of the converter is, that it returns a non null value if the Ivy
> exclude rule uses an exact matcher and the name as well as the organization
> of the module is specified.
>
> Functionality that is still missing:
> - Integrating the new Ivy 'override' rules the same way as the exclude
> rules.
> - Artifact dependencies are not mapped yet.
> - Fine grained customization
>
> The last point I think is very important. Due to the more powerful elements
> Ivy has and many , often subtle, differences between Ivy and Maven, auto
> generation can't always produce the result that is needed. What we want to
> enable is that the user can modify any property of an auto generated Maven
> dependency element. Customization should also allow to remove auto generated
> elements as well as add new elements. One thing we want to provide is a
> conversion listener. A hook would getdev all the created MavenDependency
> object and can analyze and modify them. Alternatively such a hook can
> provide a 'query by example' filter to get only a subset of the generated
> MavenDependency elements.
>
> Feedback is welcome
What you already do seems pretty powerful and flexible, and your ideas to
improve it sounds even better. If the code is unit tested and commented, I'm
pretty sure the Ivy team would be happy to integrate it in Ivy core, to
replace the existing Ivy to Pom converter.
Xavier
>
> - Hans
>
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/
Re: Generating a Maven pom from Ivy
Posted by Hans Dockter <ma...@dockter.biz>.
On Oct 13, 2008, at 1:56 PM, Hans Dockter wrote:
> Hi,
>
> I have submitted code into the Gradle trunk for auto generating a
> Maven pom descriptor file from an Ivy ModuleDescriptor. This code
> is all on the Ivy API level. Not everything we want to implement is
> implemented yet. We are happy to offer this code eventually to the
> Apache Ivy project (there is some code in Ivy for generating a pom
> out of ivy objects but this code is pretty limited and was not
> usable for our purpose).
>
> What our code does:
>
> One challenge is how to map between configurations and scopes, as
> dependencies can belong to more than one configuration. In our code
> we allow to map a configuration to one and only one scope.
> Different configurations can be mapped to more than one scope.
I wanted to say: Different configurations can be mapped to the same
scope
<snip>
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org