So, given either "make a git repo on gwtproject/ and add a jar to gwtproject/tools" with the minimal history, or a single commit adding all already-modified classes to gwt in one go? I should be able to turn out either change fairly quickly, once we decide.
Adding to GWT directly would be somewhat lower friction (no need to ship a jar to central, easier to further tweak if something is screwy), but as I said, loses that tiny bit of history/context. Like you said, a forked jar is not at all new for the project to have, and is a nice way to say "this is external, even if we tweaked it a bit". For the zip distribution I imagine we'd shade it in to the overall zip, but for the m2 release it would probably be an external jar (since it will hopefully never change). -- Colin Alworth [email protected] On Fri, Jun 12, 2020, at 1:36 PM, Thomas Broyer wrote: > 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 > > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/7e0c1856-2835-4254-a8ed-b73a03de1ea7o%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/fd913f25-f6a0-4820-ad96-ff95a064cdb0%40www.fastmail.com.
