ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: [DISC] details of task library concept
Date Tue, 22 May 2001 14:51:14 GMT
Scattered comments. I am following this with interest as the design will
impact how smoothly GUIs like NetBeans are able to let users drop in new
tasklibs and start using them (or build them, for that matter).

Jose Alberto Fernandez wrote:
> >
> > I'm not a class loader expert and can only hope that breaking JDK 1.1
> > compatibility will make the whole class loader business a bit
> > easier. At first glance, they should probably be separate.
> >
> I think they should follow the current rules of <taskdef> with respect to
> classloaders.
> What happens otherwise if I define tasks by extending the classes of other
> tasks defined by other people in other task libraries?

Maybe you oughtn't do that to begin with. How do you know they really meant
their tasks to be subclassed? (How do you know their task library is even
available? or the same version you were expecting?) I would consider the
current behavior of <taskdef> questionable--if you mean to share classes, you
should declare it, and ideally the author of the original class should have
permitted it. Wasn't there some proposal for referencing classloader IDs to
explicitly permit reuse of classes? Or you could explicitly list the name of
the other task library as a code dependency.

(By the way consider making loading of the task classes lazy, this would
substantially reduce Ant's startup time I think.)

> > * Will each task library be assigned to an XML-Namespace to avoid
> > task-name clashes?

Agree with Wolf that the library should define the namespace, and with Stefan
that use of Class-Path is most standard for referencing extra libraries (JDK
handles it).

Also to Wolf--perhaps tasks should be loadable *only* from task files (not
unpacked)? This is not without precedent, people don't complain that their
form builder doesn't like unpacked JavaBeans. If you want to use
META-INF/antlib.xml or similar, it seems very odd to not have the stuff in a
JAR. Making a JAR is trivial anyway.

> I propose that <tasklib> itself does not require a specific extention name.

Seconded, lots of tools expect *.zip/*.jar and would get confused. On the
other hand there is some precedent with *.war and so on. Prefer *.ant to *.tsk
(you may want to include data types, ...).

>         <taskdef....>
>                 <description href="http://location/of/formated/docs">
>                         Here goes the short description for ANT help.
>                 </description>
>         </taskdef>

Or location within the JAR file? An idea--NetBeans modules permit links to
internal JavaHelp-format docs ("helpsets"), which has seemed to work well, and
might be useful for tasklibs the same way. Even if you don't have JavaHelp
available, its navigation files are pretty straightforward to parse manually
(simple XML DTD) and display in other ways as needed. And you could optionally
provide help IDs for individual tasks, which could be used in a GUI
environment. If you don't care about navigation, and want to do it all in
HTML, you just give a *.hs with nothing but a <homeID> and a reference to one
*.map with a single mapping entry to your HTML index page.


Jesse Glick   <>
NetBeans, Open APIs  <>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

View raw message