I implement something of the sort currently It works like this:

  <target name="public">
    <property name="invoked.public.target" value="true"/>
  </target>

  <target name="init">
     <fail unless="invoked.public.target">
     This target is not available to the general public.
     For a list of public targets use: ant targets
     </fail>
   ... rest of initialization ...
  </target>

  <target name="internal1" depends="init"/>
  <target name="internal2" depends="init"/>

  <target name="invokeMe" depends="public, init, internal, internal2"/>

   <target name="targets">
       <echo>
Public Targets for this ant file:
---------------------------------------------------------------------------
 invokeMe           Does incredibly useful stuff
---------------------------------------------------------------------------
       </echo>
   </target>

The key is to make every target depend on init and only available targets, the
major drawback is you have to maintain your own target to handle project help
type stuff. I would like to see this feature added as well, but I havn't taken
the time to come up with a patch because I already have the workaround in place :).

ack bitten by my own editing errors again. 

The above should say:

The key is to make every target depend on init and only available targets depend
on public, the major drawback...

Also, the depends for invokeMe should say internal1, internal2, but you probably
guessed that.

1. give the target a name beginning with a hyphen '-' and it cannot be called on
the command line

2. give public entry points a description attribute and omit it from the others,
and when you do -projecthelp, the others dont get listed (except in -verbose mode)

When was this targets beginning with - thing introduced? Has it been there all
along? if so where is it documented I know I looked at one point for some form
of public/private target distinction and missed it (which isn't a very good test
at all, but there you have it) 

After testing it myself, I found that anything that begins with "-" is parsed as
an option, but what happens when things change? for example what if support for
"--" to prevent further option recognition is added? Sounds like a perfectly
reasonable feature if you don't know that people are using -internal1 to keep
targets hidden.

Also, the public/privateness is hidden in the text of the target name, rather
than out in an atribute of it's own where it can be easily changed or
programatically considered (perhaps in resolving imports? can an imported ant
file's "private" targets be called? What about overriding them?)

Steve's workaround is cool, clever and provides exactly what I want in terms of
hiding targets, but I am reopening because I think it also looks like a
coincidental result of option processing quirk and a more robust system that
doesn't push funtionality into the target names could be subsituted. This is
afterall only an enhancement request. (maybe after I move I'll try to write
this, if Verizon doesn't go on strike and deprive me of a phone line in my new
appartment) Others are of course welcome to beat me to it :)

I also noticed that this issue sort of came up in bug 3807 but the reporter
seems to have ignored the response given. Perhaps 3807 should be marked a dup of
this (since this one has more info on it already)

Gus, you are 100% correct: any -something target is only private because of the
command line parsing process. It is a dirty trick, but it is also one we know
people use :)

Does that prevent us from adding a proper private="true/false" attribute to 
target, which would correctly enforce the target cannot be called using <ant> 
from the outside (not problem with leading - in the case), or cannot be called 
from a build file that imports the private target (in fact this private target 
would never be visible to the importing build file, which could merrily define 
a similarly named target... exactly like private methods work in Java BTW ;-).

Maybe it's time to get away from the leading dash - trick, and do something 
clean and documented??? --DD

no, it doesnt at all...

Ok, I coded this up. I tried to write it in a way that access modifiers could be
used fairly generally by simply ehancing the isAccessibleFrom method that I
added to target. I have only implemented the from the modifiers public and
private, which will mean works on the command line and doesn't work on the
command line.

Those who would like to consider what should be done with import/overide etc can
simply add another access point name to the isAccessibleFrom method and then
check it in whatever code makes decisions about inclusion/invocation/precedence
of targets to find out what the author intended.

My implementation likely needs to have some constants added instead of the magic
words "command line". I wasn't sure where the best place to put such constants
would be, so I just left it. Edit or not as pleases (of course). A patch for
docs will be forthcomming, I want to see if people like my patch before I spend
time documenting. I suspect that there is no good way to write a unit test for
the invocation on the commandline, but if someone can tell me how I am willing
to learn :)

The following build file seems to work as expected... (which I used for testing)

<?xml version="1.0"?>
<project name="access-test" basedir="." default="pubtar">

<target name="pubtar" access="public">
  <echo message="default target called"/>
  <antcall target="privtar"/>
</target>

<target name="pubtar2" access="public" depends="privtar">
  <echo message="default target called"/>
  <antcall target="privtar"/>
</target>

<target name="privtar" access="private">
  <echo message="internal target called"/>
</target>

</project>

Created attachment 7756 [details]
Adds public/private access modifiers to <target>

Any1 have any thoughts on my patch here?

*** Bug 3807 has been marked as a duplicate of this bug. ***

*** Bug 23397 has been marked as a duplicate of this bug. ***

The comment in the middle of the post linked below also points to a user desire
for access control on targets, or in this case ways to work around needing it...
even if it isn't going to make it into the 1.6 can it go into 1.7? That way we
can start finding out why what I wrote is wrong (or not)?

http://marc.theaimsgroup.com/?l=ant-dev&m=106623431723810&w=2

Also to keep info available in one place, I would like to note that some other
relavant discussion of this RFE occured on the dev list here under the heading
of one of the duplicates:

http://marc.theaimsgroup.com/?l=ant-dev&w=2&r=1&s=Bug+23397&q=t

This seems to keep coming up and, like DD et al, I cannot think of a good 
reason to keep it out as long as we preserve BC regarding "-*" targets...

*** Bug 28447 has been marked as a duplicate of this bug. ***

Well, now that the big complexity in the access modifiers exists -<import>, what
are we going to do with access. 

Which of these three do we want:
1. the access modifiers control access from the command line
2. private targets cannot be called from <ant> calls from other build files than
(self)
3. private targets cannot be called from imported files.

(3) scares me. Big time. add that and people will want protected, maybe even
package private. And it complicates importing no end. Would it be an error to
redefine a target that was private in an import? It is in C++ after all. Would
it be allowable to depend on a private target you import? 

I am personally biased towards (1) -we just need to make explicit that
public/private only applies to command line access, not to anything else. 

Nb, assuming we say "-*" defaults to private, what is the semantics of 
<target name="-secret" access="public"> ? 

I would agree that (1) is the simplest.  For clarification here and now, access 
defaults to "public".  I would treat the -* targets as a different issue; i.e. 
if a user can find a way to call a public (explicitly defined as such or 
otherwise) target named -* from the command line, they are welcome to do so.

As a long-overdue response to Gus's question(s) about the attached patch... I 
think an EnumeratedAttribute should be used for the access values... also, I 
don't know if the whole "access point" thing is warranted, especially if we 
choose that access is only relevant with respect to the command line.

$0.02

As an additional note, bug 24231 has historically been associated with this one 
and might be reexamined in terms of providing a way to implicitly allow -* 
tasks to be called from the command-line...

Well, 1.5 years later, I am again in need of something along these lines, so I
figured I might as well ping this bug...

The current scenario is I am trying to set up a simple text based interactive
build that uses input to collect various parameters (rather than having 15
different -D arguments). This will be distributed as part of a zip file and used
by the customer to create a warfile with the tweaks needed for their environment.

Since the customer gets the source code ayway, the quickest way to do this zip
up the source and write an small build file that imports the development build,
but hides dangerous targets from the user. It would be a disaster if they
accidentally ran recreate-db against their production DB since the first thing
it does is wipe the entire database.

This need is slightly different than the intent of my patch, but closely
related. I have created duplicate targets in the build file to match the one
imported which helps (forcing the targets to be refered to as
buildname.sometarget instead of just sometarget), but imported targets show up
under project help.

Has any further thought been given to controling access to targets? Have I
missed something in the past year? (I'm re-subscribing to the dev list so feel
free to answer me there)