ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34045] New: - Declaration of task visibility
Date Wed, 16 Mar 2005 23:18:35 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34045>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34045

           Summary: Declaration of task ‘visibility’
           Product: Ant
           Version: unspecified
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Other
        AssignedTo: dev@ant.apache.org
        ReportedBy: sprokitthemonkey@gmail.com


I have been using ANT since day one and have written MANY tools which make use
of ANT and integrate with ant including a flash build server, swing clients,
over 15 new tasks and 10's of thousands of lines of ant script. My only
complaint to this day is that there is still no real intuitive way to declare a
task 'internal/external'. As I personally believe EVERY task should have a
description, I don’t agree with the ant documentation in that:

'Targets without such a description are deemed internal and will not be listed,
unless either the -verbose or -debug option is used.'
[http://ant.apache.org/manual/using.html#targets]

I'm currently working at the largest telecommunications company in Australia
where in my spare time I manage the build process for over 7 very large
projects. One project alone has 23 files (not including around 10 common files
for things like cvs/vss/svn tasks) totalling over 7000 lines. One of those files
alone has 43 targets. It is a very complex build and deployment environment. 

Since I have managed many build environments before I introduced something into
this build environment which has made it much easier to determine which targets
are allowed to be called externally and which are main entry points. I have been
using the standard OO scope methodology such that targets which can be called
from any ant script I have added the scope="public" attribute to the target
element. Targets which can be called from scripts in the same directory have the
scope="protected" attribute. Targets which can only be called by other targets
within the same script are marked with the scope="private" attribute.

I had to make a couple of mods to the ant source so that parsing of the build
scripts is achieved without error, etc. This has worked great, especially with
build scripts which are used in IDE's. In the flash build server and swing ant
clients I've written, only public targets are visible/executable which cuts down
on a lot of confusion. I currently have 120 build scripts loaded into my IDE.
Gets a bit confusing if all the scripts show all their targets, especially when
90 percent of the targets are internal targets.

Please let me know what you feel about this approach. Sorry about all the
history but I wanted to make the point that I didn't write my first script
yesterday.

Thanks,

- Jay


[internal public private scope visibility description]

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message