ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Optional tasks
Date Wed, 10 Oct 2001 12:08:45 GMT
On Wed, 10 Oct 2001 19:59, Jose Alberto Fernandez wrote:
> > > How about external libraries being required?
> >
> > I think we should go with the standard java mechanisms for "Optional
> > Packages" (see jdk1.3 docs) combined with the ancient Class-Path: foo.jar
> > approach. This is what all new APIs are moving towards and is fairly
> > flexible. About the only irritating thing is that there is no standard to
> > say 2.0 is incompatible with 1.0 version of same library ;(
>
> I would like to explore this more.
> To start with, if this mechanism is so good, why aren't we using it in ANT
> already? 

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.

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?

> Why is our shell/batch script putting things in the CLASPATH?

why do we use batch scripts?

> Following this line, the correct thing to do would be to specify all the
> jar dependencies for ANT core in ant.jar itself and let the JVM made up the
> classpath. Hence we would be able to just do "java -jar $HOME/bin/ant.jar
> $@" or equivalent.

The JVM does not implement that. Go read the Optional Package spec - it is up 
to developer to do it. The new servlet and EJB APIs require container 
implement it IIRC so we should see more vendors using it. 

> In any case, in ANT, any additional jars should be declared in the
> classpath of the tasks (which are not core) that need it.

today - yes. Tomorrow I don't see any reason for that. The type library can 
declare it's own dependencies and leave the container to determine the best 
way to satisfy the dependencies. I don't see a good reason why the user 
should have to deal with semi-difficuly problems (like ClassPath management) 
when it can be automated.

> > > <tasklib name="lib1" location="mydir/mytasks.jar" />
> >
> > I am also -1 on specifying location. We should just give name of library
> > and it can be searched for on type.lib.path or whatever.
>
> The problem with this approach is the assumption that every ANT user has
> administration rights over its ANT installation. Although that may be the
> case in most cases, there are shops that have automounted /bin directories
> reflecting the standard of the shop. In such cases not be able to declare
> things outside the predefined locations is a problem. Which I presume is a
> problem people have with JVM extensions also. What do you do on
> shared/globally-administered environments.

Anyone who allows JVM extensions should be shot, burnt and stabbed ;) They 
are evil and the cause of pain in most cases. As a matter of fact almost all 
applications I write reset the "java.ext.dirs" variable to something 
harmless. 

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.

> I have had projects where local tasks are build as part of the project,
> since these tasks need to be made available to end-users, they should be
> build into a library and used within the same project. Just like I can do
> with individual taskdefs today.

I see importing a library and taskdefs as different beasts. Importing a 
library happens prioir to build file being "executed" and uses the search 
path etc. While taskdef does it at runtime and could theoretically load a 
tasklib file. That I don't mind using a location. However the import elements 
at top of build file definetly should not use a location/url/filename in my 
mind.

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.

> Notice by the way that in my above syntax the attribute "name" was a way to
> declare namespaces, to use to avoid clashing. We could definetly use
> something else, if we really think this type of namespace support is really
> useful.  am not completely sure at this point.

I largely like it but I am comfortable with XML. As a few people (Conor?) 
pointed out it is less intuitive and much more complex if you are forced to 
use namespaces for tasks (aswell as for aspects, and perhaps for inter build 
file referencing and ...).

-- 
Cheers,

Pete

--------------------------------------------------
 The fact that nobody understands you doesn't 
 mean you're an artist.
--------------------------------------------------

Mime
View raw message