On Mon, Oct 13, 2008 at 1:56 PM, Hans Dockter <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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/
