ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: [DISC] details of task library concept
Date Thu, 24 May 2001 03:23:28 GMT
> From: Peter Donald [mailto:donaldp@apache.org]
>
> At 03:26 AM 5/24/01 +0100, Jose Alberto Fernandez wrote:
> >Half of the task in Ant one either do that or use some
> supporting class
> >designed for some other task. The tipical example are the
> classes belonging
> >to <exec>. <java> uses them for the fork=yes option, and
> many others do the
> >same.
>
> Exec and java style classes will be built in the framework
> which you will
> be able to use. There will also be tasks that do the same
> thing but offer
> interface to TOM as well.
>

Well, since this is the first time I heard of having a TOM and how it is
suppose to work (your vision) it will all ddepend on the details.

> >Others need to manufacture or fill-in parameter types to
> pass to other
> >classes and those parmameters have different custom types (not just
> >strings).
>
> That is nothing that can't be done with proposed solution.
>

The question os how easy will all that be. Are going to have typed
attributes as we have today or are you thinking on moving away from that due
to TOM?

If we keep them, which I hope we will since I like the use of strong typing
as oppose to loose interfaces, can I pass my file attribute to another task
requiring files, or do I need to go through strings due to this TOM.

> >So, what sort of services are you talking about? will making
> a copy of a set
> >of files be a service? Will compiling files be one? Will executing
> >something? Will deleting?
> >
> >If they are, what differentiates them from the tasks? Why do
> we need both?
>
> The ones that have been discussed from memory were things like
>
> Execute, Java, FileScanner, *Scanner, *Sets, Dependency
> checking, mapping etc.
>

A pattern I use alot, is for out tasks to extend the <java> task. With that,
we only need to add attributes reflecting the different options and you can
quickly have a task that interfaces a command-line tool.

Will I be able to do that or will I need to write only delegation patterns.
The advantage of extending is that you get for free all the features of
<java>: fork, -Doptions, etc, etc. Which they are needed in many cases or
for certain runs.

> All other task like things you need should be done via the TOM.
>
> >> I'm not sure how that is going to work. Show me the syntax
> >> you see. We are
> >> talking about the automatic deployment of tasks here, right?
> >> The classpath
> >> can be specified as a relative classpath in the Jar's manifest.
> >>
> >
> >Not necessarily automatic loading of tasks. (I do not
> beleive I want on
> >every execution of a buildfile for project A to load every
> single task ever
> >written that I think I may ever some day need. so, first let
> me give you
> >examples of manual loading:
>
> deployment != loading
>

still, why should I be mocking around with P4 is I use CVS. Why should I be
locking at weblogic if I use websphere, etc, etc.

> deployment means placing item in registry so that when it needs to be
> instantiated it can be (at which point it will be loaded).
> Lazy loading is
> of course done for performances sake.
>
> >
> >	<tasklib name="A" file="lib/A.tsk">
> >		<classpath path="....."/> <!-- the path to add
> to classloader -->
> >	</tasklib>
> >
> >alternatively, we could add multiple .tsk files on the same
> classloader:
> >
> >	<tasklib name="B" >
> >		<classpath path="....."/>
> >		<fileset dir="lib">
> >			<include name="*.tsk" />
> >		</fileset>
> >	</tasklib>
>
> Thats just creating one task library nade of multiple .tsk files.
>

Well at the end of the day what the user wants is <tasks>.

> >Now, the automatic deployment of tasks is done by the
> implicit application
> >of the following:
> >
> >	<tasklib name="" >
> >		<fileset dir="${ant.home}">
> >			<include name="lib/*.tsk" />
> >			<include name="ext/*.jar" />
> >			<include name="ext/*.tsk" />
> >		</fileset>
> >	</tasklib>
>
> no it is not. The auto deploy feature will load each .tsk into own
> classloader.
>

did not know a vote had occurred. In any case, the sintax I propose allows
for both. As I said that is a separate discussion, my point is with how much
power we can put on the basic capability.

> >What and from where the rule is including things, exactly, is another
> >question. But the point is that all get loaded using the
> same classloader
> >and hence they all see each other. If I have conflicting
> libraries I just do
> >not put them in the ANT_HOME library but specify them manually.
>
> Thats not something I would ever wish on anybody. Having just
> gone through
> .so hell and having much expereince with .dll and .jar hell I
> would pity
> anyone who has to do this for anything great size.
>

So how are you going to resolve having the same task name being used by two
different .tsk files? A classloader is not going to help you with that.

> >Finally, you could envision having <tasklib> declarations as
> part of the
> >antlib.xml in the .tsk file. That way a task can specify internal
> >dependencies, that is why I was saying that maybe
> ${ant.home}, ${basedir}
> >and maybe some others should be available inside antlib.xml
> (or whatever we
> >call it).
>
> Unlikely to ever happen - especially when these details can
> be specified
> via Ant-Class-Path or similar manifest entry.

Yet another feature that does not exists, with a syntax different from XML.
What does having this in the manifest entry gives you that having it in the
XML descriptor does not.

BTW, ejbs do not use Class-Path for dependencies they use XML. so I am not
comming up with something never heard before. We do I need to maintain two
files when I can do with just one.

>It will be up
> to the runtime
> to do searching and porefixing of directories or whatever. The one
> difficulty I see with this is loading tools.jar (or
> equivelent) which will
> in turn need to be done by reflection still. (tools.jar is
> different as it
> is not on classpath but is in a well known place that you can
> not move).
>
Yeap, there will be this special case, and that special case and then ...

Cheers,

Jose Alberto


Mime
View raw message