On Jan 16, 2008 2:04 PM, Hans Dockter <[EMAIL PROTECTED]> wrote: > Hi Xavier, > > On Jan 15, 2008, at 7:00 PM, Xavier Hanin wrote: > > > On Jan 15, 2008 5:39 PM, Hans Dockter <[EMAIL PROTECTED]> wrote: > > > >> > >> On Jan 7, 2008, at 2:01 PM, Xavier Hanin wrote: > >> > >>> On Jan 5, 2008 7:59 PM, Hans Dockter <[EMAIL PROTECTED]> wrote: > >>> > >>>> I have the following probably pretty common use case. It is an > >>>> issue > >>>> related to maven pom's. > >>>> > >>>> Let's say I declare a dependency on the groovy-all module. The > >>>> groovy- > >>>> all pom declares 9 optional dependencies. I need one of of the > >>>> optional dependencies for my usage scenario of groovy-all. If > >>>> you are > >>>> a Maven2 users there is no good way of dealing with this situation. > >>>> What you have to do, is to declare the optional dependency you want > >>>> as a first level dependency in your pom. How can I deal with > >>>> this in > >>>> Ivy? The module descriptor created out of the pom, has two > >>>> configurations I'm interested in. This is default (Maven's compile > >>>> and runtime scope) and optional (all dependencies declared optional > >>>> in the pom). Now I can do the following: > >>>> > >>>> <dependency org="org.codehaus.groovy" name="groovy-all" rev="1.5.1" > >>>> conf="compile->default,optional"/> > >>>> > >>>> This add all 9 optional dependencies to the compile configuration. > >>>> But I want only one. As I understand Ivy, I can only apply exclude > >>>> and include filtering to the master configuration. In this case > >>>> that > >>>> would mean I have to add 8 exclude statements to exclude the > >>>> unwanted > >>>> optional dependencies. Alternatively I could declare include > >>>> statements for all the required dependencies. Both is pretty > >>>> impractical. I would like to declare filters on the dependency > >>>> configuration, to say something like: include MODULE_X of OPTIONAL > >>> > >>> How is this different from the use of the include element when > >>> declaring the > >>> dependency? > >>> > >>> Xavier > >> > >> I think there has been a misunderstanding on my side regarding the > >> include element. I have missed the fact that In contrast to the > >> exclude element, include does not apply to the dependencies of a > >> dependency, but only to published artifacts of the dependency, right? > > > > Right. > > > > > >> > >> What I have in mind is an include for (first level) dependencies of a > >> dependency. I'm not sure if this is a good idea. I'm just looking for > >> a good solution for the use case described above. > > > > What could be done is make the include mechanism work for transitive > > dependencies, as the exclude mechanism does (but it used to work as > > include, > > only on artifacts from the direct dependency). But limiting this > > to first > > level dependencies is even another feature, I see the use case, but > > it makes > > things even more complex to handle and understand. When metadata > > need so > > much tweaking, I guess you should better rewrite the metadata, or > > define a > > new virtual module with fixed metadata. > > > > I see your point. And for any enterprise environment what you propose > is definitely the way to go. > > Yet I think almost any project, even simple ones, should have > dependency management.
Agreed. > For the developers of those simple projects, > creating there own repository might seem pretty heavy weight. For > those simple projects, sharp tools to manipulate the metadata on the > client side would be often quite handy. Indeed, that's why we already have stuff like the existing exclude/include/artifact mechanisms, and the transitive attribute. > And wouldn't it be funny, if > Ivy were much more capable to deal with Maven metadata, than Maven > itself :) I think it's already the case. Try to disable transitivity for a dependency, or exclude a set of transitive dependencies using a regular expression, or redefine the set of artifacts published by a module, including with the URL where the artifact is located... none of this is possible in maven AFAIK, and I don't even talk about the flexibility offered by configuration mapping. But I agree that providing even more control would be interesting, and thus we could improve the include mechanism. Xavier > > > - Hans > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
