ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarosław Wypychowski <>
Subject Re: "ant call trigger can only be used from an ant build" from ant build
Date Thu, 10 May 2007 08:24:52 GMT

Thanks for quick reply.

Dnia 10-05-2007, czw o godzinie 09:12 +0200, Xavier Hanin napisał(a):
> Well, I think we'd need more information about your build itself. As you
> have noticed, the context is attached to a thread local, but ant doesn't
> create threads that often. So maybe this is due to the way you call Ivy (and
> this is a bug in any case, but I'm just trying to narrow the problem).

I did some more research (dumping Thread.currentThread(),
IvyContext.getContext() and IvyContext.getContext().get(IvyTask.ANT...)
at miscellaneous places and narrowed it to the WeakReference keeping the
Project in the IvyContext._contextMap. As for Threads - all was going on
in a single thread.
public Object get(String key) {
	WeakReference ref = (WeakReference) _contextMap.get(key);
//	System.out.println("ICTX GET "+key+" | "+ref
	return ref == null ? null : ref.get();
With comment turned off the WeakReference is dead sometimes (though it
shouldn't be as the Ant Project for sure is still accessible by the main
Ant process). With comment turned on the WeakReference is alive when it
is expected to be alive and everything passes smoothly. 
Funny thing is that adding a comment in the getContext() new context
creation block also helps.

I'm not sure whether this is a problem with jvm or something else. The
WeakReference seems like a good idea to me for keeping Project, though
it might be stored directly with 

Unless there are things in the background of Ivy that last past the
execute task and we need it to be Ant project aware.

> What did you change in your own ivy version?
Added a random comment. But now it is more predictable.

> BTW, did you try with Ivy 1.4.1? We have done quite a lot of refactoring in
> Ivy 2.0, and it would help to know if it was working before or not.
No - and as for now it seems to me like no Ivy problem.

As for my build:
structure of the project:
	#static repository in the SVN
	#local ivy cache
	#temporary repo for integration things
	# subproject with no internal deps
	# subproject with yadda-commmon as internal dep
	#project with yadda-services as internal dep.

<!--  <properties file=""/>-->
  <settings defaultResolver="yadda" defaultCache="${ivy.cache.dir}"/>
    <ant-call target="trigger" event="pre-resolve-dependency"
    <chain name="yadda">
      <filesystem name="local">
      <filesystem name="libraries">
pattern="${yadda.lib.repo}/bin/[artifact]-[revision].[ext]" />

target trigger in both DeskLight and yadda-services:
<target name="trigger" depends="init">
  <var name="ivy.revision" unset="true"/>
  <var name="revision" unset="true"/>
  <ivy:findrevision organisation="${event.organisation}"
module="${event.module}" revision="${event.revision}"
    <not><isset property="revision"/></not>
        <echo message="BUILDING"/>
          <fileset dir="../lib">
             <include name="${module}-*"/>
        <ant dir="${root.dir}/${event.module}/trunk/build/"
antfile="build.xml"  target="${event.module}.publish"
           <property name="mode" value="local"></property>
       <echo message="found revision for ${event.module} :

and the publication task depends on standard resolve,retrieve - and
therefore is recursive from the point of view of build.

Best Regards.


Jaroslaw Wypychowski
Interdyscyplinarne Centrum Modelowania Matematycznego i Komputerowego UW

View raw message