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=32142>. 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=32142 [PROPOSAL, PATCH] External public entity and new system entity IDs. Summary: [PROPOSAL, PATCH] External public entity and new system entity IDs. Product: Ant Version: 1.7Alpha (nightly) Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Add support for external public IDs and provide a new protocol such that external system IDs may resolve to resources found in Ant's classpath. Public External IDs: -------------------- The project helper has been modified to accept a Jar service that provides Ant's entity resolver. Anyone wishing to provide a set of shared resources may extend the Ant entity resolver implementation to map their custom public IDs to their resourses. The details of how the mapping is implemented is entirely deferred to the user. One possible implementation puts all of the shared resources and the entity resolver service within the same jar file. Deployment of these resources is then simply a matter of copying the jar file into Ant's class path. Pro: Public IDs can be mapped to any input stream. Consequently, the referenced resources may be deployed locally, to a common server, or any combination thereof. Con: The entity resolver is deployed into the Ant installation so the resolver must be shared by all projects built by that Ant installation. System External IDs: -------------------- The Java URL framework provides for extensions based upon new protocol names (i.e. ftp, http, file). The introduction of the 'resource' protocol provides for a URL similar to the jar protocol. The difference is that the 'resource' protocol does not require naming the actual jar file. Therefore, the URL resource:foo/bar.ext is functionally equivalent to calling LoaderUtils.getContextClassLoader().getResourceAsStream("foo/bar.ext"). Pro: Any number of jar files can be deployed to the ant classloader so long as each uniquely scopes it own resource names. Con: All of the resources must be deployed into the Ant class path. Justification ------------- The rationale for these changes basically reflects on the fact that I use Ant to manage a growing number of independent projects. When I first started using Ant, my build scripts were quite simple. With each new project, new features were added until I had a parameter-driven script that could easily be customized to most of my projects. The only problem was that I also had numerous older versions of the script associated with various legacy projects. What was obviously needed was a way to re-use large parts of a build script across multiple projects. So I moved most of my latest script into a shared file that I then included into each projects script. An example being: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE project [ <!ENTITY standard_rules SYSTEM "file:../../rules.xml"> ]> <project basedir="." default="all" name="Build this project"> &standard_rules; </project> This worked very well except that the relative path in the external entity declaration was a problem when I tried to clone an existing project to a new location. I then switched to using absolute paths in the URLs but that was a problem for co-workers who used the same project but didn't share my directory structures. What was needed was an abstraction layer to hide the physical location of the shared resource from all of the scripts using it. The two solutions where then identified, developed, and deployed to our local copy of Ant 1.5. They have since been re-implemented for Ant 1.7. The attached zip file contains: All source to implement both solutions. A new JDK1.3 service loader utility. New unit tests to validate the new features. Updates for the manual to document the new features. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
