On BugZilla we discussed that with the prepending "-" of the targetnames. So that use case can be realized.
A more complex would be something like <target access="public|expert|private"/> where "public"s are listed with -projecthelp while "expert" are not. Both can be invoked from outside (CLI and IDEs). And "private" is not displayed with -projecthelp and can not be invoked (neither CLI nor IDEs). But I donīt miss that feature ... Jan > -----Original Message----- > From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 25, 2003 6:10 PM > To: Ant Developers List > Subject: RE: AW: DO NOT REPLY [Bug 23397] - Need attribute for target > tag to indicate hidden/internal target > > > This attribute would be rather handy for tools such as IntelliJ IDEA > which allows the graphical display of available targets for invocation > (within its Ant integration). It would be great if IDEA could > know which > targets are "entry points" to the build file and only display > those for > execution. For it to do this, the "public/private" attribute would be > needed. > > Phil Weighill-Smith > > On Thu, 2003-09-25 at 17:02, [EMAIL PROTECTED] wrote: > > I donīt see the need for such an attribute. And if > introduced it should work > > not only from commandline. It should work too, if invoked > by other java > > applications. > > > > > > Jan > > > > > > > -----Original Message----- > > > From: Gus Heck [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, September 25, 2003 5:58 PM > > > To: Ant Developers List > > > Subject: Re: AW: DO NOT REPLY [Bug 23397] - Need > attribute for target > > > tag to indicate hidden/internal target > > > > > > > > > In fact I would be even more interested to hear the > opinons of both > > > commiters and non-commiters :). > > > > > > -Gus > > > > > > Gus Heck wrote: > > > > > > > Antoine Levy-Lambert wrote: > > > > > > > >> What you would like would be useful to prevent the "wrong" > > > targets from > > > >> being called. But I wonder whether this change would > not make ant > > > >> unnecessary complex. > > > >> > > > >> > > > > The default (atribute omitted) state should behave as > > > always. This is > > > > necessary for back compatability, and to keep the learning > > > curve from > > > > getting too steep. The import task gives me the same > sort of worry > > > > about complexity, but I keep reiminding myself... You > don't have to > > > > use it if you don't want it ;). So at least from the user > > > side, there > > > > is no obligatory complexity increase. The addition of > > > another atribute > > > > in the documentation for target would be the only brain > drain :)... > > > > > > > > As for the development side, it may lead to increased > > > complexity if we > > > > add access modifiers with more complex meanings. As it is > > > now, however > > > > the only meaning of public/private is "do we reject it > when invoked > > > > from the command line" and the only time we need to > check that is > > > > already included in the patch. > > > > > > > > I too would be interested to hear what other commiters think. > > > > > > > > - Gus > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > Phil Weighill-Smith > > Tech Lead > Volantis Systems Limited > 1 Chancellor Court, Occam Road > Surrey Research Park > Guildford, Surrey > GU2 7YT > > mailto:[EMAIL PROTECTED] > http://www.volantis.com > tel: +44 1483 739 778 > mob: +44 7803 498 603 > > This message may contain confidential information and will be > protected by > copyright. If you receive it in error notify us, delete it > and do not make > use of, nor copy it. Any reply may be read by the recipient > to whom you send > it and others within Volantis Systems Ltd. Although we aim > to use efficient > virus checking procedures we accept no liability for viruses > and recipients > should use their own virus checking procedures. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
