> From: Gus Heck [mailto:[EMAIL PROTECTED]
>
> How does a java application (other than ant) invoke an ant
> target.... (I
> can see using a task easily, but not a target) Can you give me an
> example where a target gets invoked by java code?
>
Well there is the callTarget() method, but nevermind that. I think, we
should concentrate on the proper entry points to a project execution.
> If you are talking about invocation from within ant, then I have
> difficulty imagining what parts of ant would hide targets from other
> parts of ant... Imported Files is about the only case that comes to
> mind, and to me that seems like an entirely different issue,
> but I have
> provided for that possiblity, by adding an isAccessibleFrom(String)
> method, which is used like this:
>
> if (aTarget.isAccessibleFrom("command line")) { /* do stuff */ }
>
There are more entripoints than that in ANT. E.g., <ant/>, <subant/> and
<antcall/>.
I think it is completely in the spirit of public and private, that
<ant/> should only execute "public" targets, after all you use it to
launch the execution of a "different" buildfile. <antcall/> on the other
hand,
is used to launch the execution of other targets inside the same
buildfile,
auxiliary target which are most probably the ones that you want to
declare
private in the first place.
The issue here is that today's implementation of <antcall/> is just a
wrapper
over a call to <ant/>, that would have somehow to change. Most probably
by having
a new implementation for <ant/> that accounts for the different
behavior.
You can extrapolate the story for <subant/> from my line of reasoning.
Let's not forget that given the fact that we never allowed a "foreach"
construct
into the core, there are now a bunch of "foreach"-like tasks out there
based on calling <ant/> that need to be supported backward-compatibly.
> Modification of this method to understand strings other than "command
> line" (such as "importing build") and a check at the time of import
> would be something that could be added in the future I think.
> For now,
> this would eliminate the need to rely on command line
> behavior to hide
> targets from users, and pave the way towards smoother IDE integration.
>
This multiword kind of constants, make little sense to me. It does not
seem to be a well defined set, which means we do not have a clear
meaning
for it. I think this needs to ba addressed.
> I am perfectly happy to change the name of my access atribute to
> something like commandLine/noCommandLine or hidden/visible or
> entry/noEntry if that helps. I can see a good argument for reserving
> public/private for an alternate, deeper meaning than I have
> implemented,
> but it is a word pair that comes to mind easily and so that is what I
> have used for now.
>
Please, do not change it. If we are going to have it it should stand
on its own and not being some decorative thing for IDEs. We should
add features based on well defined principles, every time we don't
do that, we finish with bad behavior that we cannot get rid off due
to backward compatibility.
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
