I don't have committer access, but here I am with my "vote" and
comments on the proposal.
On Thu, 11 Oct 2001 16:24:36 -0500, Tim Dawson <[EMAIL PROTECTED]> wrote:
> 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.
Looks good to me.
> 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.
> :-)
OK.
> 3. JDK 1.1 Compatibility
>
> Update the classloader to support getResources() under 1.1.
OK.
> 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 come up with <antlib> and not use <taskdef>? They do the same
thing.
> 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>
How about if the user wants to override the definition of an already
defined task? Should we have an attribute "override" for <taskalias>
that specifies that overriding is required?
I would certainly like to have the ability to extend certain tasks by
implementing a derived class or an entirely new class.
> 6. Optional.jar
>
> Separate the definition of the optional tasks and types into the
> meta-inf/antlib.xml file in the optional.jar.
OK.
> 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.
Sounds good.
> 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.
> :-)
There's one more thing I'd like to see in this proposal. What happens
with tasks which depend on the existence of other jar files being
loaded?
One such example would be a <cocoon> task to run Cocoon2 from within
Ant to generate documentation. The task itself depends on the Cocoon
libraries being loaded. A WAR file instead of a JAR file would solve
this problem, as all the jar dependencies could be placed in
WEB-INF/lib. From an implementation perspective, we can borrow code
from Tomcat's classloader to implement it.
Any thoughts on this one?
Regards,
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://orion.rgv.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
