You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Pa...@nokia.com on 2008/03/27 00:42:24 UTC
resolve behaviour in Main.main() does not properly account for useOrigin
Hi,
I'm running Ivy through the command line and my current requirement with
Ivy is not to download and cache artifacts. I tried setting useOrigin on
the command line but it seems like it may not be accounted for. Please
note my inline comments below:
ResolveOptions resolveOptions = new
ResolveOptions().setConfs(confs)
.setValidate(validate);
// This call to resolve does not account for any use of useOrigin it
seems, thus it attempts to download dependencies to the cache
ResolveReport report = ivy.resolve(ivyfile.toURL(),
resolveOptions);
if (report.hasError()) {
System.exit(1);
}
ModuleDescriptor md = report.getModuleDescriptor();
if (confs.length == 1 && "*".equals(confs[0])) {
confs = md.getConfigurationsNames();
}
if (line.hasOption("retrieve")) {
String retrievePattern =
settings.substitute(line.getOptionValue("retrieve"));
if (retrievePattern.indexOf("[") == -1) {
retrievePattern = retrievePattern +
"/lib/[conf]/[artifact].[ext]";
}
// Here the option is checked by this is not reached, and is for a
different purpose anyway
ivy.retrieve(md.getModuleRevisionId(), retrievePattern,
new RetrieveOptions()
.setConfs(confs).setSync(line.hasOption("sync"))
.setUseOrigin(line.hasOption("useOrigin")));
Am I missing anything here?
thanks
paul
Re: useOrigin and caching of files
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Apr 9, 2008 at 6:42 AM, <Pa...@nokia.com> wrote:
> >No, because useOrigin is only an hint to the cache
> >implementation. Those resources can't be used at their
> >original location (after resolve, artifacts must be available
> >as files, so only files can't be used from their original
> >location). Hence even with useOrigin="true" Ivy will actually
> >download and cache the remote resources and use the original
> >location of the "local"
> >artifacts (local can be actually a network accessible filesystem).
>
> Xavier,
>
> Related to your comment above, if we have repositories that are not
> local and cannot easily be represented as a filesystem, but also the
> content cannot or should not be downloaded and cached as you describe,
> what options are there for dealing with that? As I mentioned, we are
> interested in using Ivy but our content in many situations is way to
> large to have Ivy handle in its normal manner.
If you use the Ivy API rather than Ivy ant tasks, you can disable download
of artifacts (with the resolve option you've only found). But the question
is what to you want to do with the result. Usually the post resolve
operations require to access to artifacts as files, that's why Ivy makes
this part of the resolve process. But maybe if we learn more about your use
case we may see a benefit of improving Ivy to support it.
>
>
> Is there any way to fake artifacts being available as files? Or prevent
> that happening during resolve? Could Ivy be enhanced in any way to
> handle this kind of use case?
You can fake artifacts if you want, it's pretty easy to generate an empty
file or a file containing the actual remote location of the artifact. Once
again, it only depends on what you later need to do with your artifacts.
>
>
> Would it be possible to do a custom download via an event hook and then
> have Ivy report the files are available?
I don't think you need an event hook, you can use a custom resolver for
this. The resolver can launch a custom download in a separate thread and
report to Ivy core engine that it has done its job.
>
> When I first started reading about Ivy I made the assumption that
> resolve was purely about determining if all the dependencies are
> available and where they could be obtained from, but it seems it is a
> little more complex than that.
Indeed, the resolve process both resolve dependencies and download artifacts
to cache. As I said you can disable the download from the API, and then call
the download with the API too. But this is not possible using existing
tasks, and it would be a big change in Ivy behavior to support this in tasks
(eg what happen if you call a post resolve task like cachepath if you
disabled artifact download during resolve?).
Xavier
>
>
> Thanks for all the assistance!
>
> paul
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
useOrigin and caching of files
Posted by Pa...@nokia.com.
>No, because useOrigin is only an hint to the cache
>implementation. Those resources can't be used at their
>original location (after resolve, artifacts must be available
>as files, so only files can't be used from their original
>location). Hence even with useOrigin="true" Ivy will actually
>download and cache the remote resources and use the original
>location of the "local"
>artifacts (local can be actually a network accessible filesystem).
Xavier,
Related to your comment above, if we have repositories that are not
local and cannot easily be represented as a filesystem, but also the
content cannot or should not be downloaded and cached as you describe,
what options are there for dealing with that? As I mentioned, we are
interested in using Ivy but our content in many situations is way to
large to have Ivy handle in its normal manner.
Is there any way to fake artifacts being available as files? Or prevent
that happening during resolve? Could Ivy be enhanced in any way to
handle this kind of use case?
Would it be possible to do a custom download via an event hook and then
have Ivy report the files are available?
When I first started reading about Ivy I made the assumption that
resolve was purely about determining if all the dependencies are
available and where they could be obtained from, but it seems it is a
little more complex than that.
Thanks for all the assistance!
paul
Re: resolve behaviour in Main.main() does not properly account for useOrigin
Posted by Xavier Hanin <xa...@gmail.com>.
On Mon, Apr 7, 2008 at 7:33 PM, <Pa...@nokia.com> wrote:
>
>
> >
> >Mmm, ok, I understand now, it's a problem of responsibilities:
> >the resolver is responsible for calling the associated cache
> >manager to actually download (or not) the artifacts.
>
> If that is the case I am a bit confused by the what happens in the
> resolve stack trace:
>
> org.apache.ivy.Main at localhost:2843 (may be out of synch)
> Thread [main] (Suspended (entry into method download in
> BasicResolver))
>
> GraceResolver(BasicResolver).download(Artifact[], DownloadOptions) line:
> 573
> ResolveEngine.downloadArtifacts(ResolveReport,
> Filter, DownloadOptions) line: 341
> ResolveEngine.resolve(ModuleDescriptor,
> ResolveOptions) line: 285
> ResolveEngine.resolve(URL, ResolveOptions) line:
> 191
> Ivy.resolve(URL, ResolveOptions) line: 506
> Main.main(String[]) line: 235
>
> In ResolveEngine.resolve(ModuleDescriptor, ResolveOptions) there is:
>
> if (options.isDownload()) {
> Message.verbose(":: downloading artifacts ::");
>
> downloadArtifacts(report, options.getArtifactFilter(),
> (DownloadOptions) new
> DownloadOptions().setLog(options.getLog()));
> }
>
> Shouldn't specifying "useOrigin" result in options.isDownload()
> returning false?
No, because useOrigin is only an hint to the cache implementation. Those
resources can't be used at their original location (after resolve, artifacts
must be available as files, so only files can't be used from their original
location). Hence even with useOrigin="true" Ivy will actually download and
cache the remote resources and use the original location of the "local"
artifacts (local can be actually a network accessible filesystem).
Xavier
>
>
>
> So it's
> >normal that your resolver download method is called. Have a
> >look at BasicResolver#download(Artifact[] artifacts,
> >DownloadOptions options) implementation for an example of how
> >this can be done. BTW, most of the time extending
> >BasicResolver (or even one of its subclasses like
> >RepositoryResolver) is the best option. In Ivy resolvers have
> >a lot of responsibilities which aren't easy to get right
> >without relying on the base implementation we provide.
> >
> >Xavier
> >
> >>
> >>
> >> Thanks
> >>
> >> paul
> >>
> >>
> >> >-----Original Message-----
> >> >From: ext Xavier Hanin [mailto:xavier.hanin@gmail.com]
> >> >Sent: Thursday, March 27, 2008 4:57 AM
> >> >To: ivy-user@ant.apache.org
> >> >Subject: Re: resolve behaviour in Main.main() does not properly
> >> >account for useOrigin
> >> >
> >> >Usage of useOrigin has changed with Ivy 2, now it's the cache which
> >> >is responsible for telling if it's configured in useOrigin mode or
> >> >not, and not the resolve operation. To preserve backward
> >> >compatibility, we have thus deprecated "useOrigin" in resolve.
> >> >
> >> >Though the command line version of Ivy should still accept the now
> >> >depcreated useOrigin argument, and take it into account.
> >> >The lines responsible to handle this are:
> >> > if (line.hasOption("useOrigin")) {
> >> > ivy.getSettings().useDeprecatedUseOrigin();
> >> > }
> >> >
> >> >This changes the default value of useOrigin which should be taken
> >> >into account in the cache implementation. But we may have a bug due
> >> >to the recent change...
> >> >
> >> >To track this down, could you please provide the version of Ivy you
> >> >use, and your debug log (running with -debug) on a simple case?
> >> >
> >> >Xavier
> >> >
> >> >On Thu, Mar 27, 2008 at 12:42 AM, <Pa...@nokia.com> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I'm running Ivy through the command line and my current
> >requirement
> >> >> with Ivy is not to download and cache artifacts. I tried setting
> >> >> useOrigin on the command line but it seems like it may not be
> >> >> accounted for. Please note my inline comments below:
> >> >>
> >> >> ResolveOptions resolveOptions = new
> >> >> ResolveOptions().setConfs(confs)
> >> >> .setValidate(validate);
> >> >>
> >> >> // This call to resolve does not account for any use of useOrigin
> >> >> it seems, thus it attempts to download dependencies to the cache
> >> >> ResolveReport report = ivy.resolve(ivyfile.toURL(),
> >> >> resolveOptions);
> >> >> if (report.hasError()) {
> >> >> System.exit(1);
> >> >> }
> >> >> ModuleDescriptor md = report.getModuleDescriptor();
> >> >>
> >> >> if (confs.length == 1 && "*".equals(confs[0])) {
> >> >> confs = md.getConfigurationsNames();
> >> >> }
> >> >> if (line.hasOption("retrieve")) {
> >> >> String retrievePattern =
> >> >> settings.substitute(line.getOptionValue("retrieve"));
> >> >> if (retrievePattern.indexOf("[") == -1) {
> >> >> retrievePattern = retrievePattern +
> >> >> "/lib/[conf]/[artifact].[ext]";
> >> >> }
> >> >>
> >> >> // Here the option is checked by this is not reached, and
> >is for a
> >> >> different purpose anyway
> >> >> ivy.retrieve(md.getModuleRevisionId(),
> >> >retrievePattern,
> >> >> new RetrieveOptions()
> >> >>
> >> >.setConfs(confs).setSync(line.hasOption("sync"))
> >> >>
> >.setUseOrigin(line.hasOption("useOrigin")));
> >> >>
> >> >>
> >> >> Am I missing anything here?
> >> >>
> >> >> thanks
> >> >>
> >> >> paul
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >Xavier Hanin - Independent Java Consultant
> >http://xhab.blogspot.com/
> >> >http://ant.apache.org/ivy/ http://www.xoocode.org/
> >> >
> >>
> >
> >
> >
> >--
> >Xavier Hanin - Independent Java Consultant
> >http://xhab.blogspot.com/
> >http://ant.apache.org/ivy/
> >http://www.xoocode.org/
> >
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: resolve behaviour in Main.main() does not properly account for useOrigin
Posted by Pa...@nokia.com.
>
>Mmm, ok, I understand now, it's a problem of responsibilities:
>the resolver is responsible for calling the associated cache
>manager to actually download (or not) the artifacts.
If that is the case I am a bit confused by the what happens in the
resolve stack trace:
org.apache.ivy.Main at localhost:2843 (may be out of synch)
Thread [main] (Suspended (entry into method download in
BasicResolver))
GraceResolver(BasicResolver).download(Artifact[], DownloadOptions) line:
573
ResolveEngine.downloadArtifacts(ResolveReport,
Filter, DownloadOptions) line: 341
ResolveEngine.resolve(ModuleDescriptor,
ResolveOptions) line: 285
ResolveEngine.resolve(URL, ResolveOptions) line:
191
Ivy.resolve(URL, ResolveOptions) line: 506
Main.main(String[]) line: 235
In ResolveEngine.resolve(ModuleDescriptor, ResolveOptions) there is:
if (options.isDownload()) {
Message.verbose(":: downloading artifacts ::");
downloadArtifacts(report, options.getArtifactFilter(),
(DownloadOptions) new
DownloadOptions().setLog(options.getLog()));
}
Shouldn't specifying "useOrigin" result in options.isDownload()
returning false?
So it's
>normal that your resolver download method is called. Have a
>look at BasicResolver#download(Artifact[] artifacts,
>DownloadOptions options) implementation for an example of how
>this can be done. BTW, most of the time extending
>BasicResolver (or even one of its subclasses like
>RepositoryResolver) is the best option. In Ivy resolvers have
>a lot of responsibilities which aren't easy to get right
>without relying on the base implementation we provide.
>
>Xavier
>
>>
>>
>> Thanks
>>
>> paul
>>
>>
>> >-----Original Message-----
>> >From: ext Xavier Hanin [mailto:xavier.hanin@gmail.com]
>> >Sent: Thursday, March 27, 2008 4:57 AM
>> >To: ivy-user@ant.apache.org
>> >Subject: Re: resolve behaviour in Main.main() does not properly
>> >account for useOrigin
>> >
>> >Usage of useOrigin has changed with Ivy 2, now it's the cache which
>> >is responsible for telling if it's configured in useOrigin mode or
>> >not, and not the resolve operation. To preserve backward
>> >compatibility, we have thus deprecated "useOrigin" in resolve.
>> >
>> >Though the command line version of Ivy should still accept the now
>> >depcreated useOrigin argument, and take it into account.
>> >The lines responsible to handle this are:
>> > if (line.hasOption("useOrigin")) {
>> > ivy.getSettings().useDeprecatedUseOrigin();
>> > }
>> >
>> >This changes the default value of useOrigin which should be taken
>> >into account in the cache implementation. But we may have a bug due
>> >to the recent change...
>> >
>> >To track this down, could you please provide the version of Ivy you
>> >use, and your debug log (running with -debug) on a simple case?
>> >
>> >Xavier
>> >
>> >On Thu, Mar 27, 2008 at 12:42 AM, <Pa...@nokia.com> wrote:
>> >
>> >> Hi,
>> >>
>> >> I'm running Ivy through the command line and my current
>requirement
>> >> with Ivy is not to download and cache artifacts. I tried setting
>> >> useOrigin on the command line but it seems like it may not be
>> >> accounted for. Please note my inline comments below:
>> >>
>> >> ResolveOptions resolveOptions = new
>> >> ResolveOptions().setConfs(confs)
>> >> .setValidate(validate);
>> >>
>> >> // This call to resolve does not account for any use of useOrigin
>> >> it seems, thus it attempts to download dependencies to the cache
>> >> ResolveReport report = ivy.resolve(ivyfile.toURL(),
>> >> resolveOptions);
>> >> if (report.hasError()) {
>> >> System.exit(1);
>> >> }
>> >> ModuleDescriptor md = report.getModuleDescriptor();
>> >>
>> >> if (confs.length == 1 && "*".equals(confs[0])) {
>> >> confs = md.getConfigurationsNames();
>> >> }
>> >> if (line.hasOption("retrieve")) {
>> >> String retrievePattern =
>> >> settings.substitute(line.getOptionValue("retrieve"));
>> >> if (retrievePattern.indexOf("[") == -1) {
>> >> retrievePattern = retrievePattern +
>> >> "/lib/[conf]/[artifact].[ext]";
>> >> }
>> >>
>> >> // Here the option is checked by this is not reached, and
>is for a
>> >> different purpose anyway
>> >> ivy.retrieve(md.getModuleRevisionId(),
>> >retrievePattern,
>> >> new RetrieveOptions()
>> >>
>> >.setConfs(confs).setSync(line.hasOption("sync"))
>> >>
>.setUseOrigin(line.hasOption("useOrigin")));
>> >>
>> >>
>> >> Am I missing anything here?
>> >>
>> >> thanks
>> >>
>> >> paul
>> >>
>> >>
>> >
>> >
>> >--
>> >Xavier Hanin - Independent Java Consultant
>http://xhab.blogspot.com/
>> >http://ant.apache.org/ivy/ http://www.xoocode.org/
>> >
>>
>
>
>
>--
>Xavier Hanin - Independent Java Consultant
>http://xhab.blogspot.com/
>http://ant.apache.org/ivy/
>http://www.xoocode.org/
>
Re: resolve behaviour in Main.main() does not properly account for useOrigin
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Apr 2, 2008 at 10:38 PM, <Pa...@nokia.com> wrote:
> Hi,
>
> I'm using the latest beta 2 release.
>
> Attached is a sample settings file and the debug log from running:
>
> org.apache.ivy.Main -conf
> F:\helium\svn\helium-next\helium\config\ivy\ivy_settings_build_area.xml
> -ivy Z:\output\temp_build_files\ivy\ivy_file.ivy.xml S60 -useOrigin
> -debug
>
> Note that the settings file has:
>
> <caches basedir="c:\helium\cache" useOrigin="true"/>
>
> also, and yet the test resolver still has its download() method called
> ("TestResolver.download() start"). This currently just returns null,
> which causes the exception. Now of couse we can implement the download()
> method properly but we still would not want to download any data to the
> cache, because it is too large.
Mmm, ok, I understand now, it's a problem of responsibilities: the resolver
is responsible for calling the associated cache manager to actually download
(or not) the artifacts. So it's normal that your resolver download method is
called. Have a look at BasicResolver#download(Artifact[] artifacts,
DownloadOptions options) implementation for an example of how this can be
done. BTW, most of the time extending BasicResolver (or even one of its
subclasses like RepositoryResolver) is the best option. In Ivy resolvers
have a lot of responsibilities which aren't easy to get right without
relying on the base implementation we provide.
Xavier
>
>
> Thanks
>
> paul
>
>
> >-----Original Message-----
> >From: ext Xavier Hanin [mailto:xavier.hanin@gmail.com]
> >Sent: Thursday, March 27, 2008 4:57 AM
> >To: ivy-user@ant.apache.org
> >Subject: Re: resolve behaviour in Main.main() does not
> >properly account for useOrigin
> >
> >Usage of useOrigin has changed with Ivy 2, now it's the cache
> >which is responsible for telling if it's configured in
> >useOrigin mode or not, and not the resolve operation. To
> >preserve backward compatibility, we have thus deprecated
> >"useOrigin" in resolve.
> >
> >Though the command line version of Ivy should still accept the
> >now depcreated useOrigin argument, and take it into account.
> >The lines responsible to handle this are:
> > if (line.hasOption("useOrigin")) {
> > ivy.getSettings().useDeprecatedUseOrigin();
> > }
> >
> >This changes the default value of useOrigin which should be
> >taken into account in the cache implementation. But we may
> >have a bug due to the recent change...
> >
> >To track this down, could you please provide the version of
> >Ivy you use, and your debug log (running with -debug) on a simple case?
> >
> >Xavier
> >
> >On Thu, Mar 27, 2008 at 12:42 AM, <Pa...@nokia.com> wrote:
> >
> >> Hi,
> >>
> >> I'm running Ivy through the command line and my current requirement
> >> with Ivy is not to download and cache artifacts. I tried setting
> >> useOrigin on the command line but it seems like it may not be
> >> accounted for. Please note my inline comments below:
> >>
> >> ResolveOptions resolveOptions = new
> >> ResolveOptions().setConfs(confs)
> >> .setValidate(validate);
> >>
> >> // This call to resolve does not account for any use of useOrigin it
> >> seems, thus it attempts to download dependencies to the cache
> >> ResolveReport report = ivy.resolve(ivyfile.toURL(),
> >> resolveOptions);
> >> if (report.hasError()) {
> >> System.exit(1);
> >> }
> >> ModuleDescriptor md = report.getModuleDescriptor();
> >>
> >> if (confs.length == 1 && "*".equals(confs[0])) {
> >> confs = md.getConfigurationsNames();
> >> }
> >> if (line.hasOption("retrieve")) {
> >> String retrievePattern =
> >> settings.substitute(line.getOptionValue("retrieve"));
> >> if (retrievePattern.indexOf("[") == -1) {
> >> retrievePattern = retrievePattern +
> >> "/lib/[conf]/[artifact].[ext]";
> >> }
> >>
> >> // Here the option is checked by this is not reached, and is for a
> >> different purpose anyway
> >> ivy.retrieve(md.getModuleRevisionId(),
> >retrievePattern,
> >> new RetrieveOptions()
> >>
> >.setConfs(confs).setSync(line.hasOption("sync"))
> >> .setUseOrigin(line.hasOption("useOrigin")));
> >>
> >>
> >> Am I missing anything here?
> >>
> >> thanks
> >>
> >> paul
> >>
> >>
> >
> >
> >--
> >Xavier Hanin - Independent Java Consultant
> >http://xhab.blogspot.com/ http://ant.apache.org/ivy/
> >http://www.xoocode.org/
> >
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: resolve behaviour in Main.main() does not properly account for useOrigin
Posted by Pa...@nokia.com.
Hi,
I'm using the latest beta 2 release.
Attached is a sample settings file and the debug log from running:
org.apache.ivy.Main -conf
F:\helium\svn\helium-next\helium\config\ivy\ivy_settings_build_area.xml
-ivy Z:\output\temp_build_files\ivy\ivy_file.ivy.xml S60 -useOrigin
-debug
Note that the settings file has:
<caches basedir="c:\helium\cache" useOrigin="true"/>
also, and yet the test resolver still has its download() method called
("TestResolver.download() start"). This currently just returns null,
which causes the exception. Now of couse we can implement the download()
method properly but we still would not want to download any data to the
cache, because it is too large.
Thanks
paul
>-----Original Message-----
>From: ext Xavier Hanin [mailto:xavier.hanin@gmail.com]
>Sent: Thursday, March 27, 2008 4:57 AM
>To: ivy-user@ant.apache.org
>Subject: Re: resolve behaviour in Main.main() does not
>properly account for useOrigin
>
>Usage of useOrigin has changed with Ivy 2, now it's the cache
>which is responsible for telling if it's configured in
>useOrigin mode or not, and not the resolve operation. To
>preserve backward compatibility, we have thus deprecated
>"useOrigin" in resolve.
>
>Though the command line version of Ivy should still accept the
>now depcreated useOrigin argument, and take it into account.
>The lines responsible to handle this are:
> if (line.hasOption("useOrigin")) {
> ivy.getSettings().useDeprecatedUseOrigin();
> }
>
>This changes the default value of useOrigin which should be
>taken into account in the cache implementation. But we may
>have a bug due to the recent change...
>
>To track this down, could you please provide the version of
>Ivy you use, and your debug log (running with -debug) on a simple case?
>
>Xavier
>
>On Thu, Mar 27, 2008 at 12:42 AM, <Pa...@nokia.com> wrote:
>
>> Hi,
>>
>> I'm running Ivy through the command line and my current requirement
>> with Ivy is not to download and cache artifacts. I tried setting
>> useOrigin on the command line but it seems like it may not be
>> accounted for. Please note my inline comments below:
>>
>> ResolveOptions resolveOptions = new
>> ResolveOptions().setConfs(confs)
>> .setValidate(validate);
>>
>> // This call to resolve does not account for any use of useOrigin it
>> seems, thus it attempts to download dependencies to the cache
>> ResolveReport report = ivy.resolve(ivyfile.toURL(),
>> resolveOptions);
>> if (report.hasError()) {
>> System.exit(1);
>> }
>> ModuleDescriptor md = report.getModuleDescriptor();
>>
>> if (confs.length == 1 && "*".equals(confs[0])) {
>> confs = md.getConfigurationsNames();
>> }
>> if (line.hasOption("retrieve")) {
>> String retrievePattern =
>> settings.substitute(line.getOptionValue("retrieve"));
>> if (retrievePattern.indexOf("[") == -1) {
>> retrievePattern = retrievePattern +
>> "/lib/[conf]/[artifact].[ext]";
>> }
>>
>> // Here the option is checked by this is not reached, and is for a
>> different purpose anyway
>> ivy.retrieve(md.getModuleRevisionId(),
>retrievePattern,
>> new RetrieveOptions()
>>
>.setConfs(confs).setSync(line.hasOption("sync"))
>> .setUseOrigin(line.hasOption("useOrigin")));
>>
>>
>> Am I missing anything here?
>>
>> thanks
>>
>> paul
>>
>>
>
>
>--
>Xavier Hanin - Independent Java Consultant
>http://xhab.blogspot.com/ http://ant.apache.org/ivy/
>http://www.xoocode.org/
>
Re: resolve behaviour in Main.main() does not properly account for useOrigin
Posted by Xavier Hanin <xa...@gmail.com>.
Usage of useOrigin has changed with Ivy 2, now it's the cache which is
responsible for telling if it's configured in useOrigin mode or not, and not
the resolve operation. To preserve backward compatibility, we have thus
deprecated "useOrigin" in resolve.
Though the command line version of Ivy should still accept the now
depcreated useOrigin argument, and take it into account. The lines
responsible to handle this are:
if (line.hasOption("useOrigin")) {
ivy.getSettings().useDeprecatedUseOrigin();
}
This changes the default value of useOrigin which should be taken into
account in the cache implementation. But we may have a bug due to the recent
change...
To track this down, could you please provide the version of Ivy you use, and
your debug log (running with -debug) on a simple case?
Xavier
On Thu, Mar 27, 2008 at 12:42 AM, <Pa...@nokia.com> wrote:
> Hi,
>
> I'm running Ivy through the command line and my current requirement with
> Ivy is not to download and cache artifacts. I tried setting useOrigin on
> the command line but it seems like it may not be accounted for. Please
> note my inline comments below:
>
> ResolveOptions resolveOptions = new
> ResolveOptions().setConfs(confs)
> .setValidate(validate);
>
> // This call to resolve does not account for any use of useOrigin it
> seems, thus it attempts to download dependencies to the cache
> ResolveReport report = ivy.resolve(ivyfile.toURL(),
> resolveOptions);
> if (report.hasError()) {
> System.exit(1);
> }
> ModuleDescriptor md = report.getModuleDescriptor();
>
> if (confs.length == 1 && "*".equals(confs[0])) {
> confs = md.getConfigurationsNames();
> }
> if (line.hasOption("retrieve")) {
> String retrievePattern =
> settings.substitute(line.getOptionValue("retrieve"));
> if (retrievePattern.indexOf("[") == -1) {
> retrievePattern = retrievePattern +
> "/lib/[conf]/[artifact].[ext]";
> }
>
> // Here the option is checked by this is not reached, and is for a
> different purpose anyway
> ivy.retrieve(md.getModuleRevisionId(), retrievePattern,
> new RetrieveOptions()
> .setConfs(confs).setSync(line.hasOption("sync"))
> .setUseOrigin(line.hasOption("useOrigin")));
>
>
> Am I missing anything here?
>
> thanks
>
> paul
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/