I've discovered something weird in my Ivy cache. When you start from a clean cache, after a resolve, I have the following cache content:
\.ivy\cache\apache\commons-vfs\ivydata-20060920.properties \.ivy\cache\commons-vfs\commons-vfs\ivydata-20060920.properties The first one doesn't contain an artifact.resolver property, the second one does. My guess is that Ivy tries to load the artifact.resolver property from the first file, it doesn't find one there tries to find a resolver with name 'null' Any idea? Maarten ----- Original Message ---- From: Maarten Coene <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, May 24, 2007 9:02:16 PM Subject: Re: repository used by ivy Any idea why Ivy prints "unknown resolver null" when I build Ivy (see below) ? Another remark: is it normal that Ivy logs the eviction of commons-logging twice? Maarten [ivy:retrieve] :: resolving dependencies :: [ apache | ivy | [EMAIL PROTECTED] ] [ivy:retrieve] confs: [default, test] [ivy:retrieve] found [ ant | ant | 1.6.5 ] in ibiblio [ivy:retrieve] found [ commons-httpclient | commons-httpclient | 3.0 ] in ibiblio [ivy:retrieve] found [ junit | junit | 3.8.1 ] in ibiblio [ivy:retrieve] found [ commons-logging | commons-logging | 1.0.3 ] in ibiblio [ivy:retrieve] found [ commons-codec | commons-codec | 1.2 ] in ibiblio [ivy:retrieve] found [ commons-cli | commons-cli | 1.0 ] in ibiblio [ivy:retrieve] found [ commons-lang | commons-lang | 1.0 ] in ibiblio [ivy:retrieve] found [ oro | oro | 2.0.8 ] in ibiblio [ivy:retrieve] found [ commons-vfs | commons-vfs | 20060920 ] in ivy [ivy:retrieve] found [ commons-logging | commons-logging | 1.0.4 ] in ibiblio [ivy:retrieve] found [ slide | slide | 20050629.161100 ] in ivy [ivy:retrieve] found [ jdom | jdom | 1.0 ] in ibiblio [ivy:retrieve] found [ jsch | jsch | 0.1.25 ] in ibiblio [ivy:retrieve] found [ ant | ant-launcher | 1.6.5 ] in ibiblio [ivy:retrieve] found [ junit | junit | 3.8.2 ] in ibiblio [ivy:retrieve] :: resolution report :: [ivy:retrieve] :: evicted modules: [ivy:retrieve] [ commons-logging | commons-logging | 1.0.3 ] by [[ commons-logging | commons-logging | 1.0.4 ]] in [default] [ivy:retrieve] [ commons-logging | commons-logging | 1.0 ] by [[ commons-logging | commons-logging | 1.0.3 ]] in [default] [ivy:retrieve] [ junit | junit | 3.7 ] by [[ junit | junit | 3.8.1 ]] in [default] --------------------------------------------------------------------- | | modules || artifacts | | conf | number| search|dwnlded|evicted|| number|dwnlded| --------------------------------------------------------------------- | default | 15 | 1 | 0 | 3 || 12 | 0 | | test | 2 | 0 | 0 | 0 || 2 | 0 | --------------------------------------------------------------------- [ivy:retrieve] [ivy:retrieve] :: problems summary :: [ivy:retrieve] :::: ERRORS [ivy:retrieve] unknown resolver null [ivy:retrieve] unknown resolver null [ivy:retrieve] unknown resolver null [ivy:retrieve] [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS ----- Original Message ---- From: Xavier Hanin <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, May 24, 2007 9:15:48 AM Subject: Re: repository used by ivy On 5/24/07, Maarten Coene <[EMAIL PROTECTED]> wrote: > > ok, I'll commit my changes. > Could you take a look at them, because there is something wrong (although > it's working, the output says there are errors), but I don't know what it > is. I had some problems due to the cache inconsistent with the new settings, but when using a fresh cache it works properly. What I do to avoid this kind of problem is use a cache only for the Ivy build, by setting ivy.home like that for instance: "ant -Divy.home=.ivy" Then my ivy home and cache is relative to Ivy workspace and I can delete it safely. BTW the kind of problem we have when we share a cache among different settings is that we store the resolver which previously resolved a module, and so when we load it again with different settings in which this resolver doesn't exist we have an error message. The easiest way to get rid of that is remove the error message, because it isn't really an error. But when we'll actually review our cache management we could try to better manage that. I'm also not happy with the way I had to retrieve emma from the maven2 > repository. Maybe we should improve that too. You'll see what I mean when > you run the emma report. Yes, I now see what you mean, but the only way to do something better would be to override emma-ant metadata, because it doesn't depend on emma, which is really sad. Another thing I thought about before would be to be able to embed an ivy file (or only the dependencies section) in the post resolve inline tasks. Something like: <ivy:cachepath inline="true" pathid="emma.classpath"> <dependency org="emma" name="emma" rev="2.0.5312"/> <dependency org="emma" name="emma-ant" rev="2.0.5312" transitive="false" /> </ivy:cachepath> It's quite a lot of work to mimic the ivy file parsing within ant, unless we manage to leverage our parser... Anyway, was just an idea. btw, when I run the checkstyle report with the default Ant settings, we have > 21844 errors :-s Mmm, it'll be difficult to address them all, unless we use a tool. We could use eclipse code formatter to clean all the code base with good settings, it could make things much cleaner. But we need to synchronize to do this, because merging with the change will really be painful. I'll send another e-mail to talk about that. Xavier regards, > Maarten > > ----- Original Message ---- > From: Xavier Hanin <[EMAIL PROTECTED]> > To: [email protected] > Sent: Wednesday, May 23, 2007 11:58:03 PM > Subject: Re: repository used by ivy > > On 5/23/07, Maarten Coene <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > Hi, > > Ivy now downloads most of it's dependencies from > http://ivyrep.jayasoft.org/ > > In order to get checkstyle resolved, I've changed the settings to > download > > all dependencies (except commons-vfs and slide) from a maven2 repository > > using the POMs found there. > > > > If this is ok for you, I'll commit my changes. > > > This is really fine for me, it's much better like that. If we could get > rid > of ivyrep, it would be even better, but we'll have to fix our issue with > commons vfs release. > > Xavier > > If it's not ok, we'll need to find another way to resolve checkstyle... > > > > regards, > > Maarten > > > > > > > > > > > ____________________________________________________________________________________Shape > > Yahoo! in your own image. Join our Network Research Panel today! > > http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > > > > > > > -- > Xavier Hanin - Independent Java Consultant > Manage your dependencies with Ivy! > http://incubator.apache.org/ivy/ > > > > > > > ____________________________________________________________________________________Looking > for a deal? Find great prices on flights and hotels with Yahoo! FareChase. > http://farechase.yahoo.com/ > -- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/ ____________________________________________________________________________________Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php ____________________________________________________________________________________Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
