ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: [DISC] details of task library concept
Date Tue, 22 May 2001 23:12:41 GMT
> From: jglick@sunpraha.Czech.Sun.COM
> >
> > 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?

If someone does not want its task to be subclassed then it should declare it
final. Otherwise, there is no way to stoping anyone from subclassing any
class of any sort in the Java programming language. This is a feature of the
language. It is best to embrase it than to try to build a wal around it that
it can be jumped anyway.

> (How do you know their task
> library is even
> available? or the same version you were expecting?)

How do you know the JDBC driver you use in your DB application is available?
How do you know if the version is compatible with the one you tested your
code with?

>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.

This is not the Java way of doing things. And I definetly thing the worst
thing we can do is trying to fight against the features of the language.

> (By the way consider making loading of the task classes lazy,
> this would
> substantially reduce Ant's startup time I think.)
> Stefan:
> > > * 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).

So, how do I refer in the jar Class-Path to a jars and derectories relative
to my build directory? Or are you telling me that <tasks> in libraries
cannot use anything that resides on my projects directory structure?

This is exactly why I want to be able to pass property information to the
task library.
So that they can take local info from the build into account. I think it is
a good question to ask whether to allow passing/inheriting any property, or
whether we can come up with a particular subset that makes sense. My example
is for being able to pass a classpath for project specific stuff, but one
could say we could have a <classpath> parameter added to <tasklib> to
acheive the same. Are there other interesting properties.

> 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.

My point on the description issue is that I do not think ANT should force
people to use some particular documentation mechanism or standard. Not
JavaHelp, nor HTML nor anything else. That should be upto the task writer to
decide how it should be provided.

Certaintly the href attribute does not need to be HTTP nor pointing to some
external location, you could have something like href="jar:docs/index.xml"
which will indicate the file is inside the Jar. In either case, I think we
should just is the URL factories provided by Java to do this. If you have
other factories, you can just define them and put them in the jar and the
JDK should pick them up. (Or some other similar mechanism of out own

Jose Alberto

View raw message