Mailing-List: contact taglibs-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <C3843BD1B83DD2119D79000092A7BAD405F4895B@platinum.allaire.com>
From: Scott Stirling <sstirling@allaire.com>
To: "'taglibs-dev@jakarta.apache.org'" <taglibs-dev@jakarta.apache.org>
Subject: RE: [VOTE] Ant Taglib Update, Committer, Taglib Documenting, Jaka
	 rta Taglib  App [long]
Date: Tue, 9 Jan 2001 13:08:20 -0500 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Good questions.  I'll try my best to address them, but everyone else will
have to consider these questions to some extent.

I've thought about these problems, of course, and of even trying to
coordinate with the Ant Project group (which I monitor daily and participate
in occasionally) on the tag library.  But for now, I don't want to get tied
up in all the Ant 2.0 proposals and conflicts.  Nor did I want to sit around
while that process unfolded.

The name thing is a good one.  What else should we call it?  I don't want
people to be confused about the real Ant, and the Ant  Task JSP tag library.
I myself switch back and forth from calling it the Ant Taglib or the Ant
Task Taglib.  But to use the Ant name seemed the most obvious thing when the
idea occurred to me.

As for questions regarding plans, compatibility with Ant, and purpose,
please hear me out.  (I stated some of this in the HTML Overview for the Ant
Taglib, and I on this list before I started working on the implementation.)

- I have no intention of slavishly keeping up with Ant, such as tying the
taglib tightly to the Ant dev cycle or release cycle, or bending over
backwards to do something in JSP that makes no sense, but that might make
perfect sense for the Ant tool proper.

- It's not an a priori conclusion in my mind that the Ant tasks should all
be available or would all be useful as JSP tags.  And I (or someone else)
may well want to have a tag in the Ant taglib that wouldn't make as much
sense in the actual Ant.  A directory listing tag is one I've thought of
that would fit well in the taglib but not be that useful in Ant.  I don't
know.  Many tasks should have different behavior when they are used as JSP
tags.  See Overview below for more on that point.

- I intend to implement all the JSP tags with the same attributes, names and
behavior as the Ant tool, as closely as possible or exactly whenever
possible.  Again, this relates to the issue of two ways to use/implement
these tags, which is addressed below, and the fact that sometimes a JSP tag
should act like a JSP tag (logging to ServletContext, being thread safe,
throwing JspTagExceptions, etc.).

- I intend to only implement the most recent (1.3 alpha) version of the Ant
tags -- i.e., I didn't think it worth bothering with deprecated tasks or
syntax.

For the rest, especially the two main ways to do this whole taglib, and how
it will relate to Ant 2.0 (and possibly Ant 1.x), here's the Overview of the
taglib in the HTML doc:

"The Ant tag library is modeled after and based on the Ant build tool,
re-using code from the Ant code base when possible. [description of Ant and
its history omitted]..."

"This JSP tag library can be used to perform a variety of Ant tasks. There
are a couple of goals in mind for it, corresponding to a couple of ways to
use the Ant tasks as implemented in a JSP tag library."

"One goal of this tag library is to make all (give or take a few) of the Ant
tasks available as stand-alone JSP custom actions, and to convert Ant
behaviors to JSP behaviors where appropriate. Examples of changes to make
the Ant tasks more like JSP tags are 1) treating the default output stream
as JspWriter instead of System.out, and 2) throwing JspTagExceptions in
places where an Ant task would throw a BuildException. Examples of changes
that make the tasks work as standalone custom actions are 1) there is no
need for a full Ant <project> or even a <target> in order to use the tasks
as individual tags, and 2) tasks can take sub-elements where appropriate,
such as property or fileset elements."

"The second goal of this tag library is to interface with the full Ant
capabilities via JSP, i.e., full Projects. In this case you may be able to
take a build.xml file and enclose it in a JSP custom action, or generate (or
modify) one on the fly, include it from an external source, and so on. This
latter goal will hopefully be made easy by an interface provided by a future
version of Ant itself, which will allow a JSP custom action to tie into Ant
with a minimum of effort on the JSP side."

"The ability to use Ant tasks as stand-alone custom actions was chosen as
the first goal to implement, leaving the latter goal to a future time
(hopefully not to distant) when Ant 2.0 is fleshed out and underway."

Best regards,

Scott Stirling
Allaire Corporation

> -----Original Message-----
> From: Michael.Smith@epiphany.com [mailto:Michael.Smith@epiphany.com]
> Sent: Tuesday, January 09, 2001 12:30 PM
> To: taglibs-dev@jakarta.apache.org
> Subject: RE: [VOTE] Ant Taglib Update, Committer, Taglib Documenting,
> Jaka rta Taglib App
> 
> 
> I have one problem with your "Ant" taglib:  the name.  
> 
> I'm concerned that the "Ant" taglib will not remain 
> completely compatible
> with the actual Jakarta Ant project (especially since it 
> doesn't actually
> use Ant for its implementation).  Will all the tasks in Jakarta Ant be
> provided in the taglib?  All the attributes for each of those 
> tasks (with no
> extra attributes)?  What about the notion of targets and 
> dependencies?  With
> Ant 2.0, there may be some notion of cross project 
> dependencies.  Will this
> jave a JSP tag that amounts to a jsp include or something 
> like that?  Is
> this taglib just creating a JSP version of the build.xml 
> file?  Is that
> necessary?
> 
> If it's not 100% compatible, I can't justify it using the Ant 
> name, and can
> only imagine the confusion it may cause.  Don't get me wrong, 
> I think that
> file manipulation stuff (gzip, mkdir, etc.) is probably a 
> good idea for a
> tag library.  I can also see a *long term* Ant tag library, 
> but not until
> Ant 2.0 is solidified.  Ant then the tag library would just 
> be manipulations
> of running an *actual* ant (with a seprate build.xml file or 
> build.ant or
> whatever it ends up being) and retrieving/displaying the results.
> 
> I'm not a committer on the Jakarta Taglibs project (or 
> Jakarta Ant for that
> matter), so I don't have a binding vote, but here's my take anyway:
> 
> +0 for adding the proposed "ant" taglib
> -1 for using the "ant" name for the taglib
> 
> regards,
> michael