ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: SUMMARY: loading tasks from jars for Ant 1.5 summary feedback
Date Fri, 12 Oct 2001 15:45:06 GMT
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. 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.

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

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

> > > 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 ther is no way to start ANT, just because you put one too many jars in
the system. That sounds really bad to me.

> Tim
> 


Mime
View raw message