ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Filtering optional dependencies of a pom module
Date Wed, 16 Jan 2008 13:29:03 GMT
On Jan 16, 2008 2:04 PM, Hans Dockter <mail@dockter.biz> wrote:

> Hi Xavier,
>
> On Jan 15, 2008, at 7:00 PM, Xavier Hanin wrote:
>
> > On Jan 15, 2008 5:39 PM, Hans Dockter <mail@dockter.biz> wrote:
> >
> >>
> >> On Jan 7, 2008, at 2:01 PM, Xavier Hanin wrote:
> >>
> >>> On Jan 5, 2008 7:59 PM, Hans Dockter <mail@dockter.biz> 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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message