Possibly a dumb question ... but isn't it possible to just manually vendor in the source files to GWT? I can't imagine there is a whole lot of dependencies that would need to be maintained. Just strip out the gunk you don't need.
On Sat, Jun 13, 2020 at 7:05 AM Colin Alworth <[email protected]> wrote: > > 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. > > > -- > 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. -- Cheers, Peter Donald -- 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/CACiKNc5vrgR1wWz1kEn1HSU0O76ks7tr1BddMY6MfvMc47vnEQ%40mail.gmail.com.
