Mailing-List: contact taglibs-dev-help@jakarta.apache.org; run by ezmlm
Message-Id: <200101100625.BAA10733@chmls06.mediaone.net>
Subject: Re: [VOTE] Ant Taglib Update, Committer, Taglib Documenting,   Ja   
	karta  Taglib  App
From: Scott "M." Stirling <sstirling@mediaone.net>
To: taglibs-dev@jakarta.apache.org
In-Reply-To: <005001c07ab8$8af11380$22a5b5d8@lokitech.com>
References: <200101100021.TAA26237@chmls06.mediaone.net>  
	<005001c07ab8$8af11380$22a5b5d8@lokitech.com>
Content-Type: text/plain
Date: 10 Jan 2001 01:23:57 -0500
Mime-Version: 1.0

I'm with you.  You're thinking along the same lines I was when I first
started thinking about this.  Need more details.  

> In my mind one of the greatest things about Ant is the Task API.  As every
> function (or task, if you will) in ant follows this API, we write a tag that
> uses the Task API rather than trying to create tags that duplicate each
> function.  This means you can very quickly get ALL of ant's power and when
> people add new Ant tasks, they can immediately use it with this tag project.

Exactly.  I noticed the parallelism between the Task API and the Tag API
and that got me thinking about using the tasks as tags.  But as soon as
I tried to think about making all tags be tasks, or interfacing with Ant
directly, I ran into problems which made me think it would be much
easier to start with implementing tasks as tags, re-using logic but
fitting it into the tag API and Web app context.  And then there's the
two different goals of using tasks arbitrarily in a JSP, like any old
tag; and using them within the context of an Ant Project, and fitting
them into targets.  Two different environments and two different
intentions.

Everything in Ant is tied to a Project.  There's no way to use most
tasks without providing the context of a Project.  Methods in the
Project class are used to do things like resolve file paths and set
logging properties in many of the tasks.  I kind of stopped there
because my first priority was to make tasks re-usable from JSP without
requiring all of Ant to be instantiated or "dealt with."  I pulled the
file resolution logic from Project and put it in a utility class in the
tag library.

Think a little about other things like Exceptions and logging.  This is
not a rhetorical suggestion, but a real one.  How can we in a nice neat
way, override Ant's logger to log to the ServletContext?  And how to
handle all/most BuildExceptions?  Have to catch and rethrow everything
as JspExceptions or JspTagExceptions.

Those are a couple of the issues involved.  They need some thought.

Scott S.


On 09 Jan 2001 22:49:04 -0500, Serge Knystautas wrote:
> ----- Original Message -----
> From: "Scott M. Stirling" <sstirling@mediaone.net>
> 
> 
> > OK, that's reasonable.  My only hesitation on it was that unless the
> > javac task is implemented, you can't really "build" anything.
> >
> > God forbid the project be allowed to experiment and grow a little before
> > getting all wrapped up in the name.  I'm surprised it's such an issue.
> > Kinda blows the spirit of the endeavor out of the water.  Was I supposed
> > to implement all of Ant overnight?  I thought the fact that it was a JSP
> > taglib was enough to differentiate it from the actual Ant tool.
> >
> > Scott
> 
> Not that my vote counts, but I would vote that this tag library be called
> ant.  Which leads into my suggestion on how to approach this tag in the
> first place (trying to quickly move away from the name debate...)
> 
> In my mind one of the greatest things about Ant is the Task API.  As every
> function (or task, if you will) in ant follows this API, we write a tag that
> uses the Task API rather than trying to create tags that duplicate each
> function.  This means you can very quickly get ALL of ant's power and when
> people add new Ant tasks, they can immediately use it with this tag project.
> Here's the basic idea...
> 
> You would have a single AntTaskTag class that would look at the task=""
> attribute on the tag to instantiate the appropriate Ant task class.  It
> would then also set any other attributes on that Task class, just like ant
> does (using reflection).
> 
> Say you are using the chmod task in ant, and in your build.xml file, you
> have...
> 
> <chmod file="${dist}/start.sh" perm="ugo+rx" />
> 
> Ant instantiates the Chmod task and calls the setter methods setFile(String)
> and setPerm(String).  Our Ant tag would look like this...
> 
> <ant:task task="chmod" file="${dist}/start.sh" perm="ugo+rx" />
> 
> The ant tag would instantiate the appropriate Chmod task class (from the
> task attr.) and call the appropriate setter methods.
> 
> The big downside to this approach is that your attribute definitions in your
> TLD become enormous and almost meaningless and the list of setter methods in
> AntTaskTag becomes similarly enormous and meaningless. BUT!!! you can write
> a AntTaskTagExtraInfo that valids the attributes for the task at translation
> time, and by using reflection, you don't have to hardcode anything there
> either.  AntTaskTagExtraInfo would find the Ant task class based on the
> tag's task attribute, and then for the other attributes, it would look for
> setter methods on the task class.  In the above example, AntTaskTagExtraInfo
> could look at the attributes passed, find the Chmod task, and check for the
> existance of setFile and setPerm methods, thereby still giving you a way to
> enforce some kind of checking during JSP translation (compilation).
> 
> I haven't mentioned how nesting would work, but I think again by mimicing
> how ant works, this would be reasonably easy to duplicate.
> 
> So what about this approach?  I think this is a nice and quick way to get
> all of the power of ant into taglibs without writing tasks from scratch.
> 
> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/