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 02:28:22 GMT
See some comments:

From: "Tim Dawson" <tdawson@wamnet.com>

> In summary of the previous thread the proposal is now:
> 
> ------------
> 1. Deployment Descriptor
> 
> Specify a deployment descriptor for an antlib jar. This would reside in
> "meta-inf/antlib.xml" and have a simple structure:
> 
> <antlib version="1.0">
>    <task name="..." class="..."/>
>    <task name="..." class="..."/>
>    <type name="..." class="..."/>
>    <type name="..." class="..."/>
> </antlib>
> 
> NOTE: datatype shortened to "type" from previous proposal.


Fine.

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

> 3. JDK 1.1 Compatibility
> 
> Update the classloader to support getResources() under 1.1.
> 
> 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.

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

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.

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?

> 6. Optional.jar
> 
> Separate the definition of the optional tasks and types into the
> meta-inf/antlib.xml file in the optional.jar.
> 

Fine

> 7. Supporting Tasks
> 
> Supporting tasks for generating the antlib jar file and related
> documentation are out of scope for this proposal. Once this is approved,
> then we can begin the work on that.
> 

Fine.

> ------------
> 
> Due to the length of the previous thread, I think we need to start the vote
> over. Please reply with your +1, 0, or -1 vote to the group. OR, feel free
> to continue the thread if I've missed anything or until we get consensus.
> :-)
> 
> Thank you,
> 
> Tim
> 


Mime
View raw message