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 13:12:09 GMT
On 5/10/07, Jarosław Wypychowski <J.Wypychowski@icm.edu.pl> wrote:
>
> Hello again.
>
> As You suggested this is now in JIRA (IVY-497)
>
> > Well, the problem of your solution is that it makes IvyContext depend on
> an
> > Ant class, which we have to avoid to keep Ivy core independent of Ant.
> Sure - it was a proof of my concept
>
> > So I see two possible solutions:
> > * keep IvyContext as is, and set ANT_PROJECT_CONTEXT_KEY to a Stack
> instead
> > of a Project. In this case all classes dealing with
> ANT_PROJECT_CONTEXT_KEY
> > will have to be aware it's a Stack. Maybe adding a static method like
> > getCurrentProject() in IvyTask could centralize all the management of
> this
> > Stack.
> > * add methods to manage a Stack in IvyContext, because other classes may
> > have to deal with the same kind of problem. We could add a push, pop and
> > peek method, and use these methods instead of set and get from IvyTask,
> > AntCallTrigger and AntBuildTrigger.
> > Centralizing the management in IvyTask can make sense in either case. I
> have
> > a slight preference for the second one for its reusability, but it's
> only a
> > slight preference.
> I liked the second one better as well.
>
> Added
> void IvyContext.push(String,Object)
> Object IvyContext.pop(String)
> Object IvyContext.top(String)


Any reason why you chose top instead of peek (which is the name used in
java.util.Stack, and is thus pretty well known)?

they are kept without weakrefs.


Indeed, I think when you use a stack you are responsible for calling pop as
many times as push.

void IvyTask.execute() throws BuildException
> abstract void IvyTask.doExecute() throws BuildException.
>
> tasks and triggers fixed accordingly.
>
> > using regular svn diff is appropriate. Please create a JIRA issue for
> > attaching the patch, it's better to track the problem and to clear legal
> > issues while applying your patch (you have a box to check when attaching
> the
> > patch to allow us to apply it).
> Attached already. All rights granted. Review it whenever You like. The
> patch is done
> against latest trunk.


Great, thanks a lot!

Did not add additional JUnit test for it but it works in my environment
> and all current tests are passed.
>
> There is however a slight problem - this makes the API incompatible with
> 2.0.0-alpha-1. It is possible to make doExecute not abstract in IvyTask
> and therefore validate all the other tasks that are kept by people, but
> this can lead to hard to find errors.


breaking the API is not a major problem, Ivy 2.0 is already breaking a lot
of API, and we named our last release alpha because it is still subject to
API break (I tihnk we warn users against that in the release notes). So I
prefer having things like this, we may even declare execute final to make
sure it isn't overridden improperly. I'll review your patch soon and apply
it.

Xavier

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