We have two issues tracking the dependency that GWT has on Ant, 
https://github.com/gwtproject/gwt/issues/9690 and 
https://github.com/gwtproject/gwt/issues/9677. I've taken a little time and 
produced a minimal set of classes copied from ant which appear to provide a 
working ZipScanner. For the moment, this lives in its own git repository at 
https://github.com/vertispan/ant-zipscanner, and is not deployed anywhere.

I spent a while testing with latest ant, 1.10.8, but semantics have changed 
with the zip/directory scanner API such that leading "/" characters no 
longer match - rather than break behavior, I've instead switched to simply 
using the 1.6.5 code, and modified that for our purposes. This has the 
advantage of being substantially smaller than 1.10.8 - 18 types instead of 
46, and of those 18, 11 are required for ant's own implementation of the 
zip format, so the other 7 are needed to scan a zip and match contents. It 
is quite likely that this could be pruned further, but might come at a cost 
when updating to some later ant version (should we decide to do that).

This repository is arranged in three commits:

   - Create a script to copy the classes we need from the ant repo, and a 
   pom to ship these contents. The script is handy when iterating on a new 
   version, but probably won't be needed unless we do attempt to use a new 
   version
   - Copy all required classes from the tag "rel/1.6.5" in the upstream ant 
   repo 
   - Comment out anything which didn't compile due to missing dependencies 
   (we have no use for Project or refs, we only call ZipScanner methods 
   directly), or which modify the filesystem in some way (to limit risks when 
   depending on this codebase

The resulting output is shaded into a new package by the pom so that it 
will not interfere with ant when GWT is compiled (or if GWT is invoked from 
ant). 

When GWT is updated to both include this jar and also to reference these 
new shaded classes instead of the originals within ant, all tests in dev/ 
pass and all samples compile, though I haven't yet run all of the other 
tests.

So, my question is then how to proceed. First of all, is this approach 
acceptable in terms of maintenance, or would we prefer reimplementing the 
API from scratch in order to drop this dependency, or just updating to the 
latest ant version for this one API?

Assuming we like the approach, should we incorporate these copied/modified 
sources into GWT itself, or add an additional jar to gwtproject/tools, with 
instructions on how to update it, and from there include it into the 
project? A somewhat related option could be releasing this jar to maven 
central under something like org.gwtproject.ant:ant-zipscanner, and 
maintaining it in the github.com/gwtproject umbrella.

Finally, is there any objection to staying with 1.6.5, or should I see if 
we can use a later version, or update GWT's internals to use the new 
behavior around leading slashes, etc?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/f3957563-9097-4e1d-9166-77858655aa64o%40googlegroups.com.

Reply via email to