ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: "ant call trigger can only be used from an ant build" from ant build
Date Thu, 10 May 2007 09:10:45 GMT
On 5/10/07, Jarosław Wypychowski <J.Wypychowski@icm.edu.pl> wrote:
>
> Hello,
>
> 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.


OK, so not a Thread but a WeakReference problem. Interesting. And that's why
the problem is occuring in an undeterministic way, because it's related to
when the GC is called.

IvyContext{
> ...
> public Object get(String key) {
>         WeakReference ref = (WeakReference) _contextMap.get(key);
> //      System.out.println("ICTX GET "+key+" | "+ref
> +"|"+Thread.currentThread()+"|"+this);
>         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).

Indeed, this is really weird, since we do not leave the ant build.

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.


Yes, this is strange too, but it might be side effect on the GC only, GC
calls are not predictable, it may happen that it just change the memory
consumption.

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
>
> Ivy*(IvyTask){
> ...
>   execute(){
>         setProjectInContext
>         realwork
>         unsetProjectInContext
>   }
> ...
> }
> Unless there are things in the background of Ivy that last past the
> execute task and we need it to be Ant project aware.


No, nothing like that. For the ant project we can do something like this,
it's pretty easy because we are in control of all Ivy tasks, and clearly
know all entry points. We could do that by refactoring ivy tasks like that:

IvyTask {
execute() {
        setProjectInContext
        doExecute();
        unsetProjectInContext
  }
abstract doExecute();
}

then in all Ivy tasks we can rename execute to doExecute, when we're done.

The problem is that it will be very difficult to add a unit test for this
bug, since we do not really understand why the reference is lost. But at
least you are able to reproduce the problem, so maybe you would be the best
person to implement this fix, test it and submit a patch? :-)

Xavier

> 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:
> lib/
>         #static repository in the SVN
> build/
>         #local ivy cache
>         #temporary repo for integration things
> yadda-common/trunk/
>         # subproject with no internal deps
> yadda-services/trunk/
>         # subproject with yadda-commmon as internal dep
> DeskLight/trunk
>         #project with yadda-services as internal dep.
>
> ivysettings:
> <ivysettings>
> <!--  <properties file="build.properties"/>-->
>   <settings defaultResolver="yadda" defaultCache="${ivy.cache.dir}"/>
>   <triggers>
>     <ant-call target="trigger" event="pre-resolve-dependency"
> prefix="event."/>
>   </triggers>
>   <resolvers>
>     <chain name="yadda">
>       <filesystem name="local">
>          <ivy
> pattern="${ivy.repo.dir
> }/[organisation]/[module]/ivys/ivy-[revision].xml"/>
>          <artifact
> pattern="${ivy.repo.dir
> }/[organisation]/[module]/[type]s/[artifact]-[revision].[type]"/>
>       </filesystem>
>       <filesystem name="libraries">
>         <artifact
> pattern="${yadda.lib.repo}/bin/[artifact]-[revision].[ext]" />
>       </filesystem>
>     </chain>
>   </resolvers>
> </ivysettings>
>
> 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}"
> property="revision"/>
>   <if>
>     <not><isset property="revision"/></not>
>     <then>
>         <echo message="BUILDING"/>
>         <delete>
>           <fileset dir="../lib">
>              <include name="${module}-*"/>
>           </fileset>
>         </delete>
>         <ant dir="${root.dir}/${event.module}/trunk/build/"
> antfile="build.xml"  target="${event.module}.publish"
> inheritall="false">
>            <property name="mode" value="local"></property>
>          </ant>
>      </then>
>      <else>
>        <echo message="found revision for ${event.module} :
> ${revision}"/>
>      </else>
>    </if>
> </target>
>
> and the publication task depends on standard resolve,retrieve - and
> therefore is recursive from the point of view of build.
>
> Best Regards.
>
> --jw
>
> --
> Jaroslaw Wypychowski
> Interdyscyplinarne Centrum Modelowania Matematycznego i Komputerowego UW
> jarwyp@icm.edu.pl
>
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message