To minimize the work, and because 1.6.5 works well for us without known vulnerability, I would either copy/paste the code into gwtproject/gwt or provide it in a JAR in gwtproject/tools and call it a day. We already have a copy of Rhino (with changes for JSNI), and a slimmed down version of jsilver containing only the streamhtmlparser. No need to try to update and risk a breaking change, and no need to make it "more maintainable" as I'm sure it'll be a one-shot anyway (and that decision could be revisited in the future should we need to make changes to those Ant classes).
On Friday, June 12, 2020 at 3:31:04 PM UTC+2, Colin Alworth wrote: > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/7e0c1856-2835-4254-a8ed-b73a03de1ea7o%40googlegroups.com.
