You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by "Rosen, Alex" <ar...@silverstream.com> on 2001/01/10 23:07:04 UTC
[PATCH] Clarifications to BuildLogger and DefaultLogger
(1) Clarified that constants for the message output levels are defined in
Project.java, and specified the relative verboseness of the constants.
(2) Explicitly set the default message level of DefaultLogger to MSG_ERR. It
was implicitly MSG_ERR (i.e. zero) before, but this makes it more obvious.
Alex
Compiling Myrmidon - note
Posted by Scott Stirling <ss...@mediaone.net>.
Pete,
This (below) does work. My mistake. I had downloaded the latest dev
version of Avalon, which was in my classpath. Changes in exceptions thrown
and whatever class getLogger() comes from were causing most of the compiler
problems.
Scott S.
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Thursday, January 11, 2001 1:17 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: Interfacing with Ant in JSP
[snip]
> should be able to
>
> > cd proposals/myrmidon
> > build.[sh|bat]
>
> Does this work - and if not whats the error ?
[snip]
Re: Interfacing with Ant in JSP
Posted by Peter Donald <do...@apache.org>.
At 01:00 11/1/01 -0500, Scott "M." Stirling wrote:
>Peter,
>
>This rocks! Thanks for this response. It's good someone else realizes
>this is a) a good idea (the abstract idea we're both hitting on), and b)
>not a piece of cake to re-use existing task classes without the Project
>context. So far the suggestions I've gotten from others have been of
>the "just do it this way..." variety, but no less half-baked than my own
>ideas.
;) kewl - unfortunately we are alone except for one other person thou ;) So
we will have to be extra loud ;)
>I'd heard of Avalon, but no clue what it was. I'm reading up on that at
>java.apache.org.
feel free to pop on list or mail if you have questions.
>I tried to just build myrmidon by executing the buildfile, but that
>didn't work. Looks like I need Avalon and maybe some other stuff to
>compile. Any hints appreciated. I have all the jars I need for
>building the latest Ant, Catalina, etc. So if it's a Jakarta project, I
>usually first try my luck with the existing CLASSPATH in my antrc., then
>start digging/asking.
should be able to
> cd proposals/myrmidon
> build.[sh|bat]
Does this work - and if not whats the error ?
>Anyway, a couple specific points answered below. I have some reading to
>do and then I'll catch up more.
;)
>On 11 Jan 2001 14:00:30 +1100, Peter Donald wrote:
>> At 09:46 10/1/01 -0500, Scott Stirling wrote:
>> >1. Make all (give or take a few) of the Ant tasks available as stand-alone
>> >JSP custom actions (no Project context required),
>>
>> Unfortunately we can't for Ant1.x for backwards compatability reasons but
>> thats precisely the thing I advocated ages ago when I first joined the ant
>> list - it was ignored then because it was so different but hopefully now I
>> have it in the myrmidon proposal it may get in ;)
>
>Well, I was looking at scenario 1 (below) and implementing tasks as JSP
>tags, completely ripped away from Ant and modified to be JSP tag handler
>classes instead of Tasks. So there's no backward compatibility issue in
>my mind. In a sense, the scenario 1 (below, from my first email) is
>almost like a fork of Ant, except it's not because it's more like a rape
>and pillage of Ant, leaving the carcass behind.
thats what I essentially did - it ended up being waay ugly thou and
difficult to maintain as I only nabbed the core tasks (copy/move etc) which
happen to get updated frequently ;)
>> >and 2) throwing JspTagExceptions
>> >in places where an Ant task would throw a BuildException.
>>
>> I am not sure this is the right thing to do. Are JspTagExceptions
>> RuntimeExceptions or just normal exceptions ?
>
>I think it's the right thing to do in the case where you want a task's
>functionality, but you want the exception thrown to be one from the JSP
>tag API. JspExceptions and their kids, JspTagExceptions, are regular
>Exceptions. BuildExceptions would be appropriate for the scenario 2,
>where Ant tasks are used in the more traditional, project /target
>/workspace-oriented manner.
Hmm okay - then that would break in myrmidon as currently the "work" is
done via Runnable interface so you can't declare non-runtime exceptions.
Perhaps a proxy could work in this case that essentially did
public void execute()
throws JSP...
{
try { task.run(); }
catch( final AntException ae )
{
throw new JSP...( "Exception: " + ae.getMessage() );
}
}
>> >and 2) task-tags can take sub-tags
>> >where appropriate, such as <property> or <fileset> elements.
>>
>> Have it implemented in myrmidon but I didn't check it in because it is
>> those evil if/else tags but I can check it in if you want ?
>
>I'd like to see that.
>
>Thanks again, Pete. You've given me some good food for thought.
I will check it in next time I am fiddling with it then ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Interfacing with Ant in JSP
Posted by "Scott M. Stirling" <ss...@mediaone.net>.
Peter,
This rocks! Thanks for this response. It's good someone else realizes
this is a) a good idea (the abstract idea we're both hitting on), and b)
not a piece of cake to re-use existing task classes without the Project
context. So far the suggestions I've gotten from others have been of
the "just do it this way..." variety, but no less half-baked than my own
ideas.
I'd heard of Avalon, but no clue what it was. I'm reading up on that at
java.apache.org.
I tried to just build myrmidon by executing the buildfile, but that
didn't work. Looks like I need Avalon and maybe some other stuff to
compile. Any hints appreciated. I have all the jars I need for
building the latest Ant, Catalina, etc. So if it's a Jakarta project, I
usually first try my luck with the existing CLASSPATH in my antrc., then
start digging/asking.
Anyway, a couple specific points answered below. I have some reading to
do and then I'll catch up more.
On 11 Jan 2001 14:00:30 +1100, Peter Donald wrote:
> At 09:46 10/1/01 -0500, Scott Stirling wrote:
> >1. Make all (give or take a few) of the Ant tasks available as stand-alone
> >JSP custom actions (no Project context required),
>
> Unfortunately we can't for Ant1.x for backwards compatability reasons but
> thats precisely the thing I advocated ages ago when I first joined the ant
> list - it was ignored then because it was so different but hopefully now I
> have it in the myrmidon proposal it may get in ;)
Well, I was looking at scenario 1 (below) and implementing tasks as JSP
tags, completely ripped away from Ant and modified to be JSP tag handler
classes instead of Tasks. So there's no backward compatibility issue in
my mind. In a sense, the scenario 1 (below, from my first email) is
almost like a fork of Ant, except it's not because it's more like a rape
and pillage of Ant, leaving the carcass behind.
> >converting Ant behaviors
> >to JSP behaviors where appropriate. Examples of changes to make Ant tasks
> >more like JSP tags are 1) output stream handling -- either JspWriter or
> >ServletContext.log() instead of System.out,
>
> Again this abstraction is done in myrmidon proposal via Logger abstraction.
Nice.
> >and 2) throwing JspTagExceptions
> >in places where an Ant task would throw a BuildException.
>
> I am not sure this is the right thing to do. Are JspTagExceptions
> RuntimeExceptions or just normal exceptions ?
I think it's the right thing to do in the case where you want a task's
functionality, but you want the exception thrown to be one from the JSP
tag API. JspExceptions and their kids, JspTagExceptions, are regular
Exceptions. BuildExceptions would be appropriate for the scenario 2,
where Ant tasks are used in the more traditional, project /target
/workspace-oriented manner.
> >and 2) task-tags can take sub-tags
> >where appropriate, such as <property> or <fileset> elements.
>
> Have it implemented in myrmidon but I didn't check it in because it is
> those evil if/else tags but I can check it in if you want ?
I'd like to see that.
Thanks again, Pete. You've given me some good food for thought.
Best regards,
Scott Stirling
West Newton, MA
Re: Interfacing with Ant in JSP
Posted by Peter Donald <do...@apache.org>.
At 09:46 10/1/01 -0500, Scott Stirling wrote:
>Hello,
>
>Basic idea is this: a JSP tag library that re-uses the Ant "task library."
welcome to my world - these are the sorts of things I have been partially
doing with a fork of Ant from ages back. I don't use JSP but I assume it is
a similar use case.
>1. Make all (give or take a few) of the Ant tasks available as stand-alone
>JSP custom actions (no Project context required),
Unfortunately we can't for Ant1.x for backwards compatability reasons but
thats precisely the thing I advocated ages ago when I first joined the ant
list - it was ignored then because it was so different but hopefully now I
have it in the myrmidon proposal it may get in ;)
>converting Ant behaviors
>to JSP behaviors where appropriate. Examples of changes to make Ant tasks
>more like JSP tags are 1) output stream handling -- either JspWriter or
>ServletContext.log() instead of System.out,
Again this abstraction is done in myrmidon proposal via Logger abstraction.
>and 2) throwing JspTagExceptions
>in places where an Ant task would throw a BuildException.
I am not sure this is the right thing to do. Are JspTagExceptions
RuntimeExceptions or just normal exceptions ?
>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,
again - have a look at myrmidon - it does that. The tasks don't know where
they are running. Some setups will be running in a cron-server, some in
ant-project, others in instalshield - and now still more in jsp pages ;)
>and 2) task-tags can take sub-tags
>where appropriate, such as <property> or <fileset> elements.
Have it implemented in myrmidon but I didn't check it in because it is
those evil if/else tags but I can check it in if you want ?
>2. 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, dynamically or
>statically include it from an external source, and so on.
right.
>So I'm fishing for ideas. I've thought of using reflection, of figuring out
>what's the minimum Project context that needs to be provided for tasks to be
>executed, and I've thought about waiting until Ant 2.0, when perhaps a very
>clean interface from external client apps would be in place.
Well have a look at mymidon. It is somewhat cleaner now than it used to be
and is based on Avalon framework. Theres minimal documentation and minimal
tasks but it should be able to do what you want. If not we can change it ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Interfacing with Ant in JSP
Posted by Scott Stirling <ss...@mediaone.net>.
Hello,
Basic idea is this: a JSP tag library that re-uses the Ant "task library."
I've proposed this on the Jakarta Taglib project, and gotten a lot of good
feedback. I've implemented several JSP tags that exactly mimic the names
and attributes of Ant tasks, but that act like JSP tags, i.e., logging to
the ServletContext and throwing JspTagExceptions.
So far I've done this by abstracting Task functionality from Project
context. The Ant taglib (a name some people have objected to unless there's
full compatibility with Ant, so I'm calling it the "build" library for now)
so far does not use the Ant infrastructure at all, except for some methods
I've pulled here and there for reuse (full credit to the Ant Project and the
appropriate Ant developers is in the code and in the docs). It's small and
light, but it's also only these tags so far: echo, fail, gzip, gunzip,
mkdir, touch, and tstamp.
Looking at the Task API, it's very parallel to the JSP Tag Extensions API.
And IMO, you Ant developers have written a lot of tasks whose user interface
(XML elements) look like well-planned JSP tags; primarily in that the
implementation of tasks is always well hidden from the user, and the user is
provided with a clean and friendly interface.
There are two things I'd like users to be able to do with Ant from JSP. The
first one was the easier one to begin with, and which I've already started.
But I actually started with the second one and gave up for a while. The
second is more of a challenge, and I could use some help. But if the second
could be done cleanly, it might make the first easier, but maybe not:
1. Make all (give or take a few) of the Ant tasks available as stand-alone
JSP custom actions (no Project context required), converting Ant behaviors
to JSP behaviors where appropriate. Examples of changes to make Ant tasks
more like JSP tags are 1) output stream handling -- either JspWriter or
ServletContext.log() 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) task-tags can take sub-tags
where appropriate, such as <property> or <fileset> elements.
2. 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, dynamically or
statically include it from an external source, and so on.
So I'm fishing for ideas. I've thought of using reflection, of figuring out
what's the minimum Project context that needs to be provided for tasks to be
executed, and I've thought about waiting until Ant 2.0, when perhaps a very
clean interface from external client apps would be in place.
Scott Stirling
West Newton, MA
Re: [PATCH] Clarifications to BuildLogger and DefaultLogger
Posted by Peter Donald <do...@apache.org>.
At 05:07 10/1/01 -0500, Rosen, Alex wrote:
>(1) Clarified that constants for the message output levels are defined in
>Project.java, and specified the relative verboseness of the constants.
>
>(2) Explicitly set the default message level of DefaultLogger to MSG_ERR. It
>was implicitly MSG_ERR (i.e. zero) before, but this makes it more obvious.
fixed - thanks.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*