ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <tdaw...@wamnet.com>
Subject RE: SUMMARY: loading tasks from jars for Ant 1.5 summary feedback
Date Mon, 15 Oct 2001 11:28:01 GMT
> From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> Sent: Friday, October 12, 2001 10:45 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: SUMMARY: loading tasks from jars for Ant 1.5 summary
> feedback
> 
> 
> From: "Tim Dawson" <tdawson@wamnet.com>
> 
> > responses to Jose's comments inline...
> > 
> > > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> > > > 2. Startup Deployment
> > > > 
> > > > Alter Project.java to discontinue the use of the 
> > > defaults.properties files,
> > > > and instead do a 
> > > ClassLoader.getResources("meta-inf/antlib.xml"), and
> > > > process each of those on startup.
> > > > 
> > > > This will occur for any jar file found in the java startup 
> > > classpath.
> > > > Currently this means anything in ANT_HOME/lib, or ant.jar 
> > > and optional.jar.
> > > > In the future (ant2), who knows.  NOTE: This last point 
> > > will probably be
> > > > controversial, because people could put any third party 
> jars inside
> > > > ANT_HOME/lib.  If you don't like this, don't do it.  Lord 
> > > knows I won't.
> > > > :-)
> > > > 
> > > 
> > > I do not really like this one too much. As I said before I 
> > > prefer libraries other than core to be mentioned in the build 
> > > file so people know what they need.
> > 
> > does this include optional?  if so, under ant 1.5, how will 
> we manage to do
> > that when the getResources() will return both of the 
> deployment descriptors?
> > 
> 
> Yes, in my opinion it should include optional.jar. As with 
> respect to getResources() what I am advocating is not to use 
> it at all. 

ok... then how do we get the DD? (I've only ever used getResources()
to grab a resource other than a properties file from a jar)

I'm gonna need a few implementation pointers here...

> Moreover we should not be putting things in the 
> classpath at all. I still believe we should gear ANT to not 
> require changes in the CLASSPATH at all. Any real 
> dependencies of the core, should be defined and resolved by 
> core itself. Either by using Class-Path entry in the manifest 
> or some simillar means. Notice this is not extensions in the 
> traditional sense.

I can agree with that 100%.  Is using "Class-Path" controversial?
I haven't read any threads related to that.

I could see how it would be for the optional jar, because there
are so many different dependencies locked up in there, you'd have
to break it out into many smaller jars or else I'd have to have
the starteam.jar even though all I want is to use the junit task.

This would also affect the main jar file with the <style> task,
and possibly others.

> > while it has been a popular sentiment in this group to 
> prevent ant users
> > from doing "bad" things, sometimes its just simpler and 
> better to document
> > what the "right" way is, and state that if you do something 
> the "wrong" way
> > you may be screwed in the future, as will inevitably happen 
> to people doing
> > this once we get the ant launching classpath stuff straightened out.
> > 
> > > 
> > > > 3. JDK 1.1 Compatibility
> > > > 
> > > > Update the classloader to support getResources() under 1.1.
> > > > 
> 
> GetResources return URLs, are there in 1.1 URLConnection 
> implementations that understand the "jar:" protocol?

good point. I'd have to try it out.  how else would we get
the resource from the jar file?  I know its possible because
tomcat ran under 1.1.x... I guess I could just look at that
code. :-)

> > > > 4. Antlib Task
> > > > 
> > > > Add a new task "tasklib" which can be used to load a jar 
> > > file containing ant
> > > > tasks and datatypes.  A file attribute can specify a jar 
> > > file, or a nested
> > > > <path> element can be used as well.
> > > > 
> > > > e.g.
> > > >   <antlib file="foo.jar"/>
> > > >   <antlib>
> > > >     <classpath refid="main.classpath"/>
> > > >   </antlib>
> > > > 
> > > > The <antlib> task must appear inside a <target>.  NOTE: to

> > > avoid confusion,
> > > > I'll add that this is entirely possible. See other notes in 
> > > the thread that
> > > > discuss how to use taskdef inside a target.
> > > > 
> > > 
> > > Why does it need t be inside a <target>? I think that 
> > > <taskdef>, <typedef> and <antlib> should all work the same

> > > and be inside and outside targets, depending on when you know 
> > > the class or library will be ready for use.
> > 
> > well, I suppose it doesn't. I'm just lobbying in a few 
> threads that we
> > should remove the capability to have anything outside a 
> target. I think its
> > ugly and hackish to do it, and anyway its completely 
> unclear as to what's
> > allowed outside a target.
> > 
> 
> I only advacate that it should work like the other 
> declarating tasks. Uniformity is the point here.

agreed.

> > > > 5. Task Name Collisions
> > > > 
> > > > The antlib task must also provide the capability to 
> > > overrride the task names
> > > > defined in the deployment descriptor.  If a tasklib is 
> loaded and a
> > > > collision is detected without an alias, the build fails.
> > > > 
> > > > e.g.
> > > >   <antlib file="foo.jar">
> > > >     <taskalias libtask="task1" name="foo-task1"/>
> > > >     <typealias libtype="type1" name="foo-type1"/>
> > > >   </antlib>
> > > > 
> > > 
> > > I like things as simple as possible. One charasteristic of 
> > > ANT is that tasks and datatypes cannot have the same name, 
> > > since the namespace is the same. That means that there is no 
> > > reason for assuming that in one library you will have tasks 
> > > and types with the same name hence, we do not need to 
> > > diferenciate them for the purpose of aliasing. So we can 
> as well do:
> > > 
> > >     <antlib file="foo.jar">
> > >         <alias name="task1" as="fooTask1" />
> > >         <alias name="type1" as="fooType1" />
> > >     </antlib>
> > 
> > I much prefer "name" and "as" to my original "libtask" and "name"
> > attributes. Great idea!
> > 
> > As for dropping <taskalias> and <typealias> in favor of 
> just <alias>, yeah,
> > my primary concern was collisions between tasks and types 
> with the same
> > name. (Is this possible? it would be extremely bad form, IMHO)
> > 
> > > What this means is that users do not need to know if a 
> > > particular element is a task a type or in the future 
> > > something else. Unless of course one needs to know for its usage.
> > 
> > Since the alias isn't required, they presumably would 
> already know its usage
> > anyway.
> > 
> > > Question, what should be done in the case of collisions? 
> > > Which definition wins, the new library or the existing 
> declaration?
> > > Maybe we need an override attribute for the library 
> override="true".
> > > 
> > > How do you plan to resolve collisions if autoloading is supported?
> > 
> > I guess it wasn't specified, but I was thinking that 
> collisions would cause
> > a failure same as it would with a <antlib> without an alias.
> > 
> 
> But that would mean there is no way to start ANT, just because 
> you put one too many jars in the system. That sounds really bad to me.

ah, I see what you mean. if I dropped the jar file in I'd still get an
error whether or not I was planning to use it. that would be confusing.

the best approach is just to unsupport autoloading. I'm in support of that,
but can we get consensus around it?

Tim

Mime
View raw message