You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by md...@us.britannica.com on 2001/01/10 00:58:20 UTC
RE: [VOTE] Ant Taglib Update, Committer, Taglib Documenting, Ja
karta Taglib App
Actually I was going to suggest "build" as the taglib name. It seems like
the most accurate synopsis of the tag's functionality. Especially since the
tag has such a unique contract, a descriptive name would be helpful.
> -----Original Message-----
> From: Scott "M." Stirling [mailto:sstirling@mediaone.net]
> Sent: Tuesday, January 09, 2001 5:51 PM
> To: taglibs-dev@jakarta.apache.org
> Subject: Re: [VOTE] Ant Taglib Update, Committer, Taglib Documenting,
> Jakarta Taglib App
>
>
> On 09 Jan 2001 15:33:27 -0600, Glenn Nielsen wrote:
> > I'll second the point that the taglib should have a name
> different from Ant
> > to avoid confusion.
> >
> > Glenn
>
>
> All right, I read Hans B.'s post on this too. I like the name Gnat
> Taglib. It's short enough to be a prefix if someone wants to use it,
> it's got three of the letters of Ant in it, and it denotes a smaller
> insect even than Ant.
>
> What say ye? I definitely don't like something as prosaic as "File
> taglib," and I don't think there's a single word to sum up
> the taglib's
> intent. The closest I can think of is "Build Util Taglib" or
> something.
>
>
> Scott Stirling
> West Newton, MA
>
Build Taglib query (erstwhile Ant taglib)
Posted by "Scott M. Stirling" <ss...@mediaone.net>.
If I renamed all packages, docs, and so forth from ant-tags/Ant taglib to build/Build taglib, would that be acceptable to people?
On that note, I've noticed a slight potential problem, which will
probably come up again eventually, so a new file naming convention may
be in order -- naming the project "build" means there would be a
directory named "build" in the CVS, next to all the other taglib
directories. Fine in CVS, but if you download and unpack it from a dist
file or even via CVS, it looks like it might be a more generic build
directory. I've noticed the convention of short, one-word names for all
the taglibs -- no hyphens, no underscores. Seems like a diectory named
"build-tags," "buildtags," or "buildtasks" would be clearer since many
people automatically think a directory named "build" is a build
directory of some sort. The convention so far is that the name of the
taglib is the name of the directory, I think.
BTW, I've asked the Ant Dev group about the Ant-->JSP integration
question . As I said, there's no easy answer for how to do it (yet).
However, I am looking at using Avalon and perhaps one of the proposed
Ant 2.0 frameworks, called Myrmidon, to implement the full integration
of a JSP taglib with Ant.
--
Scott Stirling
West Newton, MA
Re: [VOTE] Ant Taglib Update, Committer, Taglib Documenting, Ja
karta Taglib App
Posted by "Scott M. Stirling" <ss...@mediaone.net>.
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" <ss...@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/
Re: [VOTE] Ant Taglib Update, Committer, Taglib Documenting, Ja karta Taglib App
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Scott M. Stirling" <ss...@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/
RE: [VOTE] Ant Taglib Update, Committer, Taglib Documenting, Ja
karta Taglib App
Posted by "Joseph B. Ottinger" <jo...@epesh.com>.
And yes, Scott, we expected you to build everything - not just Ant -
overnight.
/me carefully notes that his form tag library, desperately needing
rewrite, went without updates for months until recently... and the
rewrite's still not done.
On 9 Jan 2001, Scott M. Stirling wrote:
> 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
>
> On 09 Jan 2001 17:58:20 -0600, wrote:
> > Actually I was going to suggest "build" as the taglib name. It seems like
> > the most accurate synopsis of the tag's functionality. Especially since the
> > tag has such a unique contract, a descriptive name would be helpful.
> >
> > > -----Original Message-----
> > > From: Scott "M." Stirling [mailto:sstirling@mediaone.net]
> > > Sent: Tuesday, January 09, 2001 5:51 PM
> > > To: taglibs-dev@jakarta.apache.org
> > > Subject: Re: [VOTE] Ant Taglib Update, Committer, Taglib Documenting,
> > > Jakarta Taglib App
> > >
> > >
> > > On 09 Jan 2001 15:33:27 -0600, Glenn Nielsen wrote:
> > > > I'll second the point that the taglib should have a name
> > > different from Ant
> > > > to avoid confusion.
> > > >
> > > > Glenn
> > >
> > >
> > > All right, I read Hans B.'s post on this too. I like the name Gnat
> > > Taglib. It's short enough to be a prefix if someone wants to use it,
> > > it's got three of the letters of Ant in it, and it denotes a smaller
> > > insect even than Ant.
> > >
> > > What say ye? I definitely don't like something as prosaic as "File
> > > taglib," and I don't think there's a single word to sum up
> > > the taglib's
> > > intent. The closest I can think of is "Build Util Taglib" or
> > > something.
>
-----------------------------------------------------------
Joseph B. Ottinger joeo@epesh.com
http://epesh.com/ IT Consultant
RE: [VOTE] Ant Taglib Update, Committer, Taglib Documenting, Ja
karta Taglib App
Posted by "Scott M. Stirling" <ss...@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
On 09 Jan 2001 17:58:20 -0600, wrote:
> Actually I was going to suggest "build" as the taglib name. It seems like
> the most accurate synopsis of the tag's functionality. Especially since the
> tag has such a unique contract, a descriptive name would be helpful.
>
> > -----Original Message-----
> > From: Scott "M." Stirling [mailto:sstirling@mediaone.net]
> > Sent: Tuesday, January 09, 2001 5:51 PM
> > To: taglibs-dev@jakarta.apache.org
> > Subject: Re: [VOTE] Ant Taglib Update, Committer, Taglib Documenting,
> > Jakarta Taglib App
> >
> >
> > On 09 Jan 2001 15:33:27 -0600, Glenn Nielsen wrote:
> > > I'll second the point that the taglib should have a name
> > different from Ant
> > > to avoid confusion.
> > >
> > > Glenn
> >
> >
> > All right, I read Hans B.'s post on this too. I like the name Gnat
> > Taglib. It's short enough to be a prefix if someone wants to use it,
> > it's got three of the letters of Ant in it, and it denotes a smaller
> > insect even than Ant.
> >
> > What say ye? I definitely don't like something as prosaic as "File
> > taglib," and I don't think there's a single word to sum up
> > the taglib's
> > intent. The closest I can think of is "Build Util Taglib" or
> > something.
RE: [VOTE] Ant Taglib Update, Committer, Taglib Documenting, Ja
karta Taglib App
Posted by "Joseph B. Ottinger" <jo...@epesh.com>.
I'm not a committer or anything, but I like "build" as the name.
On Tue, 9 Jan 2001 mdelagra@us.britannica.com wrote:
> Actually I was going to suggest "build" as the taglib name. It seems
> like the most accurate synopsis of the tag's functionality. Especially
> since the tag has such a unique contract, a descriptive name would be
> helpful.
>
> > -----Original Message-----
> > From: Scott "M." Stirling [ mailto:sstirling@mediaone.net
> <ma...@mediaone.net> ]
> > Sent: Tuesday, January 09, 2001 5:51 PM
> > To: taglibs-dev@jakarta.apache.org
> > Subject: Re: [VOTE] Ant Taglib Update, Committer, Taglib Documenting,
> > Jakarta Taglib App
> >
> >
> > On 09 Jan 2001 15:33:27 -0600, Glenn Nielsen wrote:
> > > I'll second the point that the taglib should have a name
> > different from Ant
> > > to avoid confusion.
> > >
> > > Glenn
> >
> >
> > All right, I read Hans B.'s post on this too. I like the name Gnat
> > Taglib. It's short enough to be a prefix if someone wants to use it,
> > it's got three of the letters of Ant in it, and it denotes a smaller
> > insect even than Ant.
> >
> > What say ye? I definitely don't like something as prosaic as "File
> > taglib," and I don't think there's a single word to sum up
> > the taglib's
> > intent. The closest I can think of is "Build Util Taglib" or
> > something.
> >
> >
> > Scott Stirling
> > West Newton, MA
> >
>
>
-----------------------------------------------------------
Joseph B. Ottinger joeo@epesh.com
http://epesh.com/ IT Consultant