ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From coconut forcoconuts <coconut4cocon...@yahoo.com>
Subject RE: [DISC] details of task library concept
Date Sat, 26 May 2001 13:32:48 GMT

--- Jose Alberto Fernandez <j_a_fernandez@yahoo.com>
wrote:
> > From: Conor MacNeill
> [mailto:conor@cortexebusiness.com.au]
> >
> > >
> > > How do you find the classes used in your task's
> code. Today
> > there are
> > plenty
> > > of tasks that make calls or inherit from the
> classes of other tasks:
> > <java>
> > > uses the code from <exec> when fork="yes". And
> plenty more examples.
> > There
> > > is no reason to forbid a task developer from
> calling in their tasks,
> > other
> > > tasks provided in other libraries. You will have
> to be able
> > to especify
> > > where these other classes are when you load the
> classes for
> > the new task,
> > > and not when you configure the task.
> > >
> >
> > Jose, I believe that many of these needs will be
> met by
> > providing java and
> > external command execution *services* within the
> core. In
> > other words I
> > don't think a task should have to create another
> task to get at these
> > services. The practice in Ant-1 of casting the
> result of
> > Project.createTask() to specific task types is
> plainly
> > dangerous in the
> > face of the user's ability to redefine the tasks.
> >
> 
> I agree completely with you here. createTask() is
> the wrong way of doing
> things.
> And that was exactly my point. For example, I was
> planning on writing a task
> that syncronizes two directories. That is it make
> certain that both ar
> exactly the same.
> Well this is just an application of the <copy> task
> (to pudate anything that
> exists,
> and the application of the <delete> task on those
> thing that do not exist
> anymore.
> 
> The way to write (in Java) this task. Is to is to
> internally create an
> instance of the class defining the Copy task (not
> using createTask) but
> doing "new Copy()" which is the class I want. fill
> up the parameters for it,
> using its well known API. And calling its exec()
> method which is also well
> defined.
> 
> Here the users ability to rename tasks, has nothing
> to do witht the issue
> because I am working at the Java level. But is I
> cannot instantiate the
> class because of the classpath, I am screwed
> (forgive my language) or I need
> to ship a copy of the Copy class as part of my jar
> and then only God will
> know the inconsistencies we can ge into.
> 
> All because we are actively trying to forbid people
> on using the code
> written by others (so much for the concept of
> reusability and not
> reinventing the wheel).
> 
> > If you were to be able to create Tasks at will,
> and I'm not
> > sure that will
> > be the case in Ant-2*, then I believe you should
> use the same
> > contract the
> > Ant core must use in dealing with such tasks - the
> Task interface (and
> > reflection).You should not cast to a particular
> subclass. If
> > you adhere to
> > these rules, then you should be able to manipulate
> other
> > tasks regardless
> > of what classloader has been used to load them
> since the Task
> > interface
> > itself will come though the loader used to load
> the Ant core.
> >
> 
> I want to use the Java class directly, I do not want
> to make people spend
> their afternoon  writing catching statements to
> fence about exception in
> reflection. This just creates obscure and unreadable
> code.
> 
> Take a look at half of the tasks in Ant-1 and think
> about how they would
> look like if every individual task had to reinvent
> everything or use
> reflection to be able to access the capabilities
> already offerend by other
> tasks. That is what you are asking for library code
> and there is  no reason
> whatsoever to treat core tasks any different.
> 
> The only thing I am asking is for tasklibs to be
> able to specify a classpath
> with dependencies and such.
> 
> 
> > If you choose to subclass another task, then that
> is OK, it
> > just means that
> > the base class will be loaded twice, once of its
> own task in its
> > classloader and once in you task's classloader.
> The core will
> > not consider
> > them to be the same class and nor should you.
> >
> 
> The point is that to find it, first we need to have
> a way to specify where
> it is.
> 
> Jose Alberto
> 
> > Conor
> >
> > (*)
> > Your ability to create a task in Ant-2 will
> require that class to be
> > initialized with a TaskContext and it may be that
> a Task
> > itself does not
> > have sufficient information to create such a
> context.
> >
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Mime
View raw message