listModules is not very well named is it? With 3 different return types, including ModuleRevision, it would be silghtly more obvious to have revisions in there. It doesn't seem to do what I want anyhow, which is enumerating all the revisions for a module.
As for listRevisionEntries, it seems pretty obvious as to what it should do - returning 4x the results with different String object identifiers is not sane in any way. The arguments imply that it will be different from the String parameter method. To be explicit; when you search, you have to specify the resolver to use in the Organisation - which it then completely ignores and searches our slow sftp publishing resolver as well :(. Also note that this seems to affect ivy resolution through the normal ant targets: when using sftp (which is slow enough to notice) for resolution, removing the artifact pattern line doubles the speed (before retrieval/downloading). (Resolution through ant however only searches the resolver you specify). Thank you at least for not making IvySettings final: I now override addResolver to only allow the ones I care about in my code (my app's process is a subset of what the rest of the company needs, yet I still want the company ivysettings file to get other modifications). Cheers Stephen On Fri, Aug 24, 2012 at 11:12 PM, Maarten Coene <maarten_co...@yahoo.com>wrote: > Since these methods are not documented and are not used inside the Ivy > code, it's not clear to me what they should do. Changing their behaviour > could break existing tools using this API. > > I think you should use one of the SearchEngine#listModules(...) methods > instead. There you can also pass the resolver to search. > > > Maarten > > > > ________________________________ > From: Stephen Kestle <stephen.kes...@gmail.com> > To: dev@ant.apache.org > Sent: Friday, August 24, 2012 3:29 AM > Subject: Re: Why does SearchEngine.listRevisionEntries return 4-6x the > results it should? > > Further analysis shows that: > > It will be multiplied by: > * the number of resolvers in the ivy settings configuration > * the number of patters in the resolver <ivy pattern> and <artifact > pattern> > > I have 2 of each so it returns 4. I presume (although I won't check now) > that 2.3.0 "unpacks" the changed resolver making it 3x2. > > This seems like 2 bugs to me... > > SearchEngine.listOrganisations() loops over the resolvers. Presumably using > an OrganisationEntry with 1 specific resolver should not search over other > resolvers as well... > > When retrieving versions, the search should not look at the artifacts, just > the ivy files. >
