ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Optional tasks
Date Thu, 11 Oct 2001 09:37:57 GMT
On Thu, 11 Oct 2001 01:03, Jose Alberto Fernandez wrote:
> From: "Peter Donald" <>
> > Ant started as a 3 hour hack on a plane (at a time when the Optional
> > Package spec didn't exist?). It takes a considerable investment of effort
> > to implement Optional Package management. Is it any surprise why it is
> > not used? We don't even clearly separate bewteen container and task.
> Well, the excuse of the 3 hour hack should not be applying anymore. After
> all We are here after more than a year (2?) and at least 4 official
> releases. :-)

possibly though we are still living with many of the early choices.

> If using this feature is so complicated, do we expect library
> writers to deal with the complication or are you proposing solving it for
> them? I am really not sure if I understand your argument here.

it is container writers that have to write it not library developers. The 
whole point of this system is to remove complexity from build file writers, 
users AND task file writers ;) However us ant-dev peeps have to suffer 
through hellish complexity instead ;)

> > Look at other specs that weren't hacks but were thought out. Servlet 1.0
> > had clear separation between container and servlet - yet it took till
> > servlet 2.3 to get Optional Package handling. Why is that?
> I would say that a big part of the problem is that the JVM people did a
> very bad job on educating the rest of the Java Standards on how Optional
> Packages where supposed to work or be managed, so everyone did its own hack
> with the classpath.

Perhaps. I think it is because there is no inherently any decent versioning 
in java and they chose to ignore the lessons learnt via Shared librarys/DLLs 
on all native platforms. But then again some would call me cynical ;)

> This seem to say that the JVM will do all the work. Granted, I am not sure
> how is this suppose to work with UserDefined ClassLoaders, but that does
> not aply to ant.jar since that ar is started by the JVM.

What they used to call Extensions are now called Optional Packages. They seem 
to like renaming stuff. I am not sure where you got that blurb from but the 
jdk1.3 stuff has it documented. Specifically I am looking at using stuff that 
places data in manifest like

Extensions-required: junit
junit-Specification-Name: org.junit
junit-Specification-Version: 3.7

> > The type.lib.path can be extended by user the same way that the header
> > (or library) serach path for gcc can be extended. Perhaps it could be as
> > simple as
> >
> > ant -L ~/my/ant/lib/path
> >
> > However in reality you would usually define a OS environment variable to
> > extend it. Probably something like
> >
> > export
> > ANT_LIB_PATH=~/ant-ext/lib:/opt/some-local-tool:/usr/local/another/local/
> >tool
> >
> > or whatever.
> So we are just moving or incrementing the issue of managing the CLASSPATH
> to also managing some other ANT_LIB_PATH. Not too much of an improvement.
> My wish would be for ANT not requiring any special manipulation of
> CLASSPATH nor any aditional environment variables.

Theres not much you can do about that. Didn't you punt it to the build file 
writer? Most people will ever have to deal with this because there will be 
reasonable default. I haven't come across a project yet where the reasonable 
defaults would not suffice.

> This is just a possible interpretation. I do not see why there should be
> any difference between declaring tasks and declaring a group of tasks.

nor me ;)

> I
> seems to me quite arbitrary to make such distinction. To me both should act
> at the same time.

The distinction I make is between how they are declared. Using an import is 
much more typesafe. In fact that ant-lint I was talking about ages would be 
possible in this case. However as soon as you build a self-modifying 
execution (which runtime taskdefs essentially are) it becomes almost 
impossible to validate the ant build file.

> > However I would suggest that if you are building and then using tasks you
> > should probably break them into two projects and make one depend on the
> > other.
> Well usually these types of task use part of the project functionality to
> perform its job, that is why there are there and are not some generic tool
> somewhere else. Dividing the build process just because some tasks cannot
> be used in the project just creates arbitrary complexity. To me the
> semantics should be just the same as for <taskdef>.

Taskdef should still exist - however I only see it as needed when ant is 
failing to do it's job and provide a general enough set of 
tasks/infrastructure ;) But they are not equivelent to importing type 



Sorry, I forgot to take my medication today.

View raw message