You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Erik Hatcher <ja...@ehatchersolutions.com> on 2002/03/01 12:16:54 UTC
Re: Determine target's name
Welcome to ant-user, Drew my friend! :) I was waiting to post on this
issue until others had gotten a chance to weigh in on it.
I have corresponded with Drew on this issue via private e-mail quite a bit
and have even pushed back on him with the same "give me a use-case" speech.
I certainly cannot do justice to his scenario by explaining it myself, but
the idea is that he wants to drop in sub-projects into his directory
structure and have them "auto-detected" and incorporated into a master build
routine automatically. Drew, is this accurate? Could you elaborate on your
scenario a bit if I'm not explaining it properly?
I have even pushed back on Drew to get involved with ant-dev to explain this
to everyone and to even make a patch and submit it. I have even prodded him
to write a "crawler" task to be bascially an <anton>.
After mulling this over a fair bit, I do believe his use-case is valid
(because I can't think of a reason to *not* provide the target name). While
some will say this is a slippery slope to Ant becoming a scripting language,
I don't think so. Why shouldn't Ant provide this context to to tasks? I
liken Ant to JSP/Taglibs a fair bit, and within a taglib you have access to
page, request, session, and application scope contexts. Is there a reason
Ant should not provide similar "scoping"? Taglibs are all about making
JSP's *not* scripty - to get rid of <% %> junk.
So, for the record, I am +1 on us adding the main target name being executed
to Ant (probably as "ant.target.name"). I'm CC'ing ant-dev. While Drew's
rant on ant-user was certainly harsh, he's been brewing this issue over with
me privately some in the past so he was not posting on this issue for the
first time, only for the first time on the list.
It may likely get veto'd by ant-dev. And I personally don't have the time
to make this change, so if it gets accepted, Drew, will you supply the patch
for it?
But, in the mean time, I have these requests/suggestions for Drew:
1) Why not make this change to a local copy of Ant yourself and save
yourself the trouble of writing your own build file generator? Then the
patch is ready, you'll learn the good/bad/ugly of Ant's source code, and you
can always run your own version of Ant forever! :)
2) If you do continue on the build file generator path (as others have done,
so you may be reinventing the wheel on this, check the archives of ant-dev),
would you submit it back to ant-dev at the very least for archive purposes,
or perhaps we even commit it to our CVS?
3) Question: how are you able to determine the target at run time with your
template pre-processor? You mean you are just able to supply it statically
into the generated build files, correct?
Erik
p.s. No offense to any other Java developers out there that I know
personally, but Drew is by far the sharpest and most innovative Java
developer/architect I've ever had the pleasure of working with. He is truly
"ahead of his time" architecturally and the things I've seen him build push
the envelope of my comprehension.
----- Original Message -----
From: "Drew Davidson" <dr...@eblox.com>
To: "Ant Users List" <an...@jakarta.apache.org>
Sent: Thursday, February 28, 2002 4:11 PM
Subject: Re: Determine target's name
> Diane Holt wrote:
>
> > --- Drew Davidson <dr...@eblox.com> wrote:
> > > Well if you want to reduce the maintenance burden then rm -fr * the
> > > whole repository.
> > >
> > > Ok, that was rude.
> >
> > [Additional barking deleted]
> >
> > Yes, it was -- but then, so was all the rest, so why single that one
out?
>
> I don't believe the rest of the post was rude, only that one comment, and
that
> was a joke (should have put :-) perhaps). The rest is a rational
explanation
> of what I feel is going on with ant development.
>
> > Recommendation: Recall the honey/vinegar adage and resubmit your
proposal
> > a bit more graciously. People working on open-source projects do it for
> > free, in their (usually exceedingly limited) free time, and the last
thing
> > they need is some snippy snide little rant being thrown at them.
>
> This proposal for determining target at runtime occurs extremely often on
the
> list and it shot down every time for what I see is no good reason; that is
the
> frustration that I feel. You are now entering a new excuse: we don't have
the
> time to do it right, so be grateful for what you are getting and shut up
with
> your annoying comments. Thanks, Diane. I believe that I will shut up
about
> this from now on.
>
> I'm giving up on trying to use ant directly, BTW (i.e hand-writing ant
build
> files). I am writing a templating preprocessor that will give me the
> functionality that I need that will output Ant XML and run that for the
> build. I am also able to determine the build target at runtime :-)
>
> - Drew
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Determine target's name
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 01 Mar 2002, Drew Davidson <dr...@eblox.com> wrote:
> Yes, this is accurate. I would like to have my source organized
> into logical groupings (such as packages, webapps, etc.) and have
> these auto-detected at runtime and passed to generic targets for
> "compile_and_copy_resources" and "build-web-app" and
> "deploy-web-app" rather than having to declare each one and
> <antcall> to the targets manually. Then I don't have to modify my
> build file every time I add a component.
Sounds at least a bit like
<http://jakarta.apache.org/ant/external.html#Configure>.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Determine target's name
Posted by Drew Davidson <dr...@eblox.com>.
Erik Hatcher wrote:
> Welcome to ant-user, Drew my friend! :) I was waiting to post on this
> issue until others had gotten a chance to weigh in on it.
>
> I have corresponded with Drew on this issue via private e-mail quite a bit
> and have even pushed back on him with the same "give me a use-case" speech.
> I certainly cannot do justice to his scenario by explaining it myself, but
> the idea is that he wants to drop in sub-projects into his directory
> structure and have them "auto-detected" and incorporated into a master build
> routine automatically. Drew, is this accurate? Could you elaborate on your
> scenario a bit if I'm not explaining it properly?
Yes, this is accurate. I would like to have my source organized into logical
groupings (such as packages, webapps, etc.) and have these auto-detected at
runtime and passed to generic targets for "compile_and_copy_resources" and
"build-web-app" and "deploy-web-app" rather than having to declare each one and
<antcall> to the targets manually. Then I don't have to modify my build file
every time I add a component.
Also (to Diane primarily) I have been talking with Erik quite a lot in the past
and I realize now that this was my first post on the subject to ant-user;
obviously the state that I was in from talking with Erik was inconsistent with
the perceived state on this list (it looks like I just jumped in and started
bitching). Diane, please don't take offense at my posts; from your perspective
there really was no justification for my immediate move to "rant".
I really do with to be constructive with ant, because I really enjoy using it
and it does a good job (and fast!) given it's current goals.
> I have even pushed back on Drew to get involved with ant-dev to explain this
> to everyone and to even make a patch and submit it. I have even prodded him
> to write a "crawler" task to be bascially an <anton>.
Certainly this is one way to go; it still requires knowing the target to
properly dispatch to the right target.
> After mulling this over a fair bit, I do believe his use-case is valid
> (because I can't think of a reason to *not* provide the target name). While
> some will say this is a slippery slope to Ant becoming a scripting language,
> I don't think so. Why shouldn't Ant provide this context to to tasks? I
> liken Ant to JSP/Taglibs a fair bit, and within a taglib you have access to
> page, request, session, and application scope contexts. Is there a reason
> Ant should not provide similar "scoping"? Taglibs are all about making
> JSP's *not* scripty - to get rid of <% %> junk.
Exactly so, wrt JSP. Perhaps if ant would be more like JSP in that regard (with
templates, iteration capable, etc.) I wouldn't have to graft this on the front
end with my custom stuff.
> So, for the record, I am +1 on us adding the main target name being executed
> to Ant (probably as "ant.target.name"). I'm CC'ing ant-dev. While Drew's
> rant on ant-user was certainly harsh, he's been brewing this issue over with
> me privately some in the past so he was not posting on this issue for the
> first time, only for the first time on the list.
>
> It may likely get veto'd by ant-dev. And I personally don't have the time
> to make this change, so if it gets accepted, Drew, will you supply the patch
> for it?
I can't promise anything but I'll look into it.
> But, in the mean time, I have these requests/suggestions for Drew:
>
> 1) Why not make this change to a local copy of Ant yourself and save
> yourself the trouble of writing your own build file generator? Then the
> patch is ready, you'll learn the good/bad/ugly of Ant's source code, and you
> can always run your own version of Ant forever! :)
I think that the current line of thinking on ant development is still
declarative, rather than scripting.
> 2) If you do continue on the build file generator path (as others have done,
> so you may be reinventing the wheel on this, check the archives of ant-dev),
> would you submit it back to ant-dev at the very least for archive purposes,
> or perhaps we even commit it to our CVS?
The template parser is, right now, a private thing that I use in my web
framework. Open sourcing it is definitely in my plan, but until that is
resolved I can't promise anything.
> 3) Question: how are you able to determine the target at run time with your
> template pre-processor? You mean you are just able to supply it statically
> into the generated build files, correct?
The pre-processor runs before it starts ant - you basically call my program
which calls ant so it knows the target list before passing it to ant.
> p.s. No offense to any other Java developers out there that I know
> personally, but Drew is by far the sharpest and most innovative Java
> developer/architect I've ever had the pleasure of working with. He is truly
> "ahead of his time" architecturally and the things I've seen him build push
> the envelope of my comprehension.
Thanks, Erik.
- Drew
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Determine target's name
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 1 Mar 2002, Erik Hatcher <ja...@ehatchersolutions.com>
wrote:
> It may likely get veto'd by ant-dev.
Like I said, it has been vetoed before - and I could send pointers
that would show that I supported adding this property but I don't want
to spoil anybody's fun in bashing me just because this time it has
been me who asked for a use case.
Not too difficult to find in ant-dev's archives.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Determine target's name
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Peter Donald" <pe...@apache.org>
> > It may likely get veto'd by ant-dev.
>
> It has already been vetoed, time and again and almost certainly will be
again.
Just for a quick re-hash, what is the (one sentence, maybe) strongest
argument against such a change?
Does anyone have quick pointers to an archive thread that details the
reasons not to do such a thing?
Thanks,
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Determine target's name
Posted by Peter Donald <pe...@apache.org>.
On Fri, 1 Mar 2002 22:16, Erik Hatcher wrote:
> It may likely get veto'd by ant-dev.
It has already been vetoed, time and again and almost certainly will be again.
> 2) If you do continue on the build file generator path (as others have
> done, so you may be reinventing the wheel on this, check the archives of
> ant-dev), would you submit it back to ant-dev at the very least for archive
> purposes, or perhaps we even commit it to our CVS?
One thing you may want to check out is Maven at
http://jakarta.apache.org/turbine/maven/
I haven't looked at it but I suspect that it is very close to what you want.
A brief look at it gave me the impression that it was very similar to the
templating ideas that I have been advocating for over a year. The difference
being that it uses Velocity rather than XSLT and comes with some
preconfigured templates.
If you do look into it I would love to hear what you think of it. I plan to
convert some Avalon files across to using it in the future (well at least if
it offers everythin I thiknk it offers).
--
Cheers,
Pete
*------------------------------------------------------*
| "Common sense is the collection of prejudices |
| acquired by age 18. " -Albert Einstein |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Determine target's name
Posted by Drew Davidson <dr...@eblox.com>.
Erik Hatcher wrote:
> Welcome to ant-user, Drew my friend! :) I was waiting to post on this
> issue until others had gotten a chance to weigh in on it.
>
> I have corresponded with Drew on this issue via private e-mail quite a bit
> and have even pushed back on him with the same "give me a use-case" speech.
> I certainly cannot do justice to his scenario by explaining it myself, but
> the idea is that he wants to drop in sub-projects into his directory
> structure and have them "auto-detected" and incorporated into a master build
> routine automatically. Drew, is this accurate? Could you elaborate on your
> scenario a bit if I'm not explaining it properly?
Yes, this is accurate. I would like to have my source organized into logical
groupings (such as packages, webapps, etc.) and have these auto-detected at
runtime and passed to generic targets for "compile_and_copy_resources" and
"build-web-app" and "deploy-web-app" rather than having to declare each one and
<antcall> to the targets manually. Then I don't have to modify my build file
every time I add a component.
Also (to Diane primarily) I have been talking with Erik quite a lot in the past
and I realize now that this was my first post on the subject to ant-user;
obviously the state that I was in from talking with Erik was inconsistent with
the perceived state on this list (it looks like I just jumped in and started
bitching). Diane, please don't take offense at my posts; from your perspective
there really was no justification for my immediate move to "rant".
I really do with to be constructive with ant, because I really enjoy using it
and it does a good job (and fast!) given it's current goals.
> I have even pushed back on Drew to get involved with ant-dev to explain this
> to everyone and to even make a patch and submit it. I have even prodded him
> to write a "crawler" task to be bascially an <anton>.
Certainly this is one way to go; it still requires knowing the target to
properly dispatch to the right target.
> After mulling this over a fair bit, I do believe his use-case is valid
> (because I can't think of a reason to *not* provide the target name). While
> some will say this is a slippery slope to Ant becoming a scripting language,
> I don't think so. Why shouldn't Ant provide this context to to tasks? I
> liken Ant to JSP/Taglibs a fair bit, and within a taglib you have access to
> page, request, session, and application scope contexts. Is there a reason
> Ant should not provide similar "scoping"? Taglibs are all about making
> JSP's *not* scripty - to get rid of <% %> junk.
Exactly so, wrt JSP. Perhaps if ant would be more like JSP in that regard (with
templates, iteration capable, etc.) I wouldn't have to graft this on the front
end with my custom stuff.
> So, for the record, I am +1 on us adding the main target name being executed
> to Ant (probably as "ant.target.name"). I'm CC'ing ant-dev. While Drew's
> rant on ant-user was certainly harsh, he's been brewing this issue over with
> me privately some in the past so he was not posting on this issue for the
> first time, only for the first time on the list.
>
> It may likely get veto'd by ant-dev. And I personally don't have the time
> to make this change, so if it gets accepted, Drew, will you supply the patch
> for it?
I can't promise anything but I'll look into it.
> But, in the mean time, I have these requests/suggestions for Drew:
>
> 1) Why not make this change to a local copy of Ant yourself and save
> yourself the trouble of writing your own build file generator? Then the
> patch is ready, you'll learn the good/bad/ugly of Ant's source code, and you
> can always run your own version of Ant forever! :)
I think that the current line of thinking on ant development is still
declarative, rather than scripting.
> 2) If you do continue on the build file generator path (as others have done,
> so you may be reinventing the wheel on this, check the archives of ant-dev),
> would you submit it back to ant-dev at the very least for archive purposes,
> or perhaps we even commit it to our CVS?
The template parser is, right now, a private thing that I use in my web
framework. Open sourcing it is definitely in my plan, but until that is
resolved I can't promise anything.
> 3) Question: how are you able to determine the target at run time with your
> template pre-processor? You mean you are just able to supply it statically
> into the generated build files, correct?
The pre-processor runs before it starts ant - you basically call my program
which calls ant so it knows the target list before passing it to ant.
> p.s. No offense to any other Java developers out there that I know
> personally, but Drew is by far the sharpest and most innovative Java
> developer/architect I've ever had the pleasure of working with. He is truly
> "ahead of his time" architecturally and the things I've seen him build push
> the envelope of my comprehension.
Thanks, Erik.
- Drew
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>