Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Message-ID: <3F73162E.7070400@cognition.olin.edu>
Date: Thu, 25 Sep 2003 12:22:06 -0400
From: Gus Heck <gus-antdev@cognition.olin.edu>
Reply-To: gus@cognition.olin.edu
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030917
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: AW: DO NOT REPLY [Bug 23397]  -     Need attribute for target
  tag to indicate hidden/internal target
References: <879A5AD5DD0ED511891F0003473A9B5608FF7051@Z011004>
In-Reply-To: <879A5AD5DD0ED511891F0003473A9B5608FF7051@Z011004>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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?

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 */ } 

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.

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.

-Gus

Jan.Materne@rzf.fin-nrw.de 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:gus-antdev@cognition.olin.edu]
>>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: dev-unsubscribe@ant.apache.org
>>>For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>>      
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>For additional commands, e-mail: dev-help@ant.apache.org
>>    
>>
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org