[Yanel-dev] Re: fixing Yanel's Maven dependencies handling

[Guillaume Déflache]

simon schrieb:
> Guillaume Déflache schrieb:
>> simon a écrit :
[...]
>>> to work around this problems i replaced fop with the newest version 
>>> within yanel. this seem to work fine. but it would be nicer if i 
>>> don't have to ;-)
>>
>> 0.95 is in principle supposed to be backward-compatible with 0.93, 
>> right? (Just asking to know if there is a official compatibility 
>> policy written somewhere, as by the version numbers only this is still 
>> admitted to be pre-1.0 and so maybe problematic as regards API 
>> compatibility, etc.)
> no idea.

http://xmlgraphics.apache.org/fop/0.95/upgrading.html says the API 
stabilized since 0.92 and from then on to 0.95 only methods deprecated 
in 0.92 were removed, so upgrading should be safe! :)


[...]
>> I guess our options are, from the hackiest to the most long-term 
>> beneficial one:
>>
>> 1) we add a fixed (see remarks above) FOP 0.95 POM and the 
>> corresponding artifacts in current Wyona's own repo at 
>> http://maven2.wyona.org/ (Simon, do you have write access to that?)
> not sure. and not sure this is sufficient since some of the libs are 
> declared in yanels dependencies file.
> apache-jakarta-commons-logging-1.0.4 is listed (at least) in yanels 
> dependencies file and also in the dependencies file of nutch and 
> testing-control resources.

Yeah, I guess 1) is not very different from 2) at that stage, because as 
you say the problems come from other broken POMs futher down the 
dependency graph anyway.


>> 2) you grab the dependencies directly from your own project hoping or 
>> else ensuring thanks to bug 7006's workaround that you don't get 
>> duplicated libraries but only the latest versions of them as should be
> this seems to be my problem.
> i have to delete:
> apache-jakarta-commons-io-1.2.jar
> apache-jakarta-commons-logging-1.0.4.jar
> commons-logging-1.0.4.jar
> xmlgraphics-commons-1.1.jar
> 
> and i don't understand the workaround of bug 7006.

You simply have to list the names of all the JARs you want to delete 
from WEB-INF/lib in the 'duplicated.libs' Ant build property.
Hacky (you may have to update this list every time you change any of 
your realms', your resource-types' or Yanel's dependencies) but works 
for "top-of-the-food-chain" user projects (for Yanel it cannot work in 
all situations e.g. with all sets of dependencies user projects will use).

You might also be able to use Maven's dependency exclusion mechanism for 
that purpose, although I haven't tried that yet: 
http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html 
(and again, this would also solve the problem only at the top-level, so 
that would not be a generic solution for Yanel).


>> 3) we start another /clean/ mirror of Maven main repo which would this 
>> time not be a 
>> one-time-copy-and-as-such-bound-to-be-always-somewhat-out-of-date of 
>> the Maven central repo, but some kind of actively-synchronized proxy 
>> of it, using for example "Dead Simple Maven Proxy" 
>> (<http://www.pdark.de/dsmp/>) as it's the only repository manager I 
>> know about (via 
>> http://blogs.exist.com/oching/2007/11/05/the-hype-about-repository-managers/ 
>> search there for "patches") that seems to be able to override POMs; 
>> the question remains if we can easily use both at the same time while 
>> in the repo transition phase.
> not sure about about this.
> 
> sorry, but it seems to me i don't understand this dependency management 
> stuff enough.

That's OK, it's hairy stuff! :) And for now it's only a (long term) 
plan, not much has been done in that direction unfortunately.


> i guess i should learn more about it.

Please don't hesitate to ask for clarifications here, and/or answer on 
other related threads, e.g. 
http://lists.wyona.org/pipermail/yanel-development/2009-September/004039.html 
and 
http://lists.wyona.org/pipermail/yanel-development/2009-October/004075.html

Cheers,
    Guillaume