-TypeGraph Visitor for incremental builds #12
Conversation
Declare dependencies for the transpiler Build transpiler into one jar, attach dependencies to aid in conflict resolution instead of using uberjars prefer unshaded closure compiler build so we can replace/exclude deps as needed Update pom to reflect changes upstream Second draft of poms, a bit more comprehensive (and incomplete) more maven artifacts Fix a version typo, and include details on deploying to our repo Remove the old pom correct the bootstrap output's classifier
…ding it as an artifact of this project
…e have actual code in the bytecode
…build or in bazel itself
…flicts, added a note about an actually-used dependency
…ource dir, not the classes dir
…ew dependency issues
…j2cl test annotation
Extracted out defaults changed upstream URL to ssh and added job dependency Update closure-library cache handling/keys. update bazel version based upon the .bazelversion value added configuration to limit bazel jobs Remove circleci config that jumps off the current branch Further limit how much resources bazel takes, and run 4 times (3 is enough in my testing) Restore auto-rebase so we track changes from upstream CircleCI changes - Reduce bazel host memory usage - Change docker image and removed installation of bazel - Added artifactory deployment
Increment version number since this includes breaking api changes
…oving from bootstrap.
…ort_only instead of prune
…local conventions)
… jar in j2cl, just adding enough for the junit processor to compile
Also increment version, since this is a breaking change.
|
I'm not expecting this to be merged yet, but it's a good time to circulate for feedback. I'm not sure we need this included in J2CL, but it might be nice to have a hook so a custom use provided visitor can be run. I was unable to use the LibraryInfo as its information is not complete and anything visible to JS is not exported as it's more aimed at pruning - but it works in a similar way. I also created my on simple, CVS style, format to read/write the information - because it's compact and fast - much smaller than the json. For incremental refreshes, we want to cut every bit of time we can. For this approach to work it expects the IDE to ensure all compilation errors have been resolved, before being passed to j2cl. Although it gracefully handles when that is not the case. While a subset of .java files are passed for transpiration, it uses .class output from the other classes to ensure everything resolves correctly. We have found this to work fine, with our j2cl Quake port. The code works in two phases. The first phase takes the incoming changeset (as defined by timestamp changes since last iteration) and uses the graph information, if any, to build the expanded list of files that need to be retranspiled. This first phase is done before calling j2cl, such we do in our maven plugin already. The second phase is after the j2cl produces it's compilation units, and it outputs the new graph information. Note, as it has all the graph information from the previous call, so even if a subset of java files are passed, it is able to ensure a full graph write out on each iteration. The visitor builds up a list of all the members, and builds a callee/caller graph. "Impact" tracking is added for a member that calls another member who has as different JS name specified in the annotation - as it's possible to change the js name, and the IDE will not trigger refactor in the caller and thus no timestamp change. This way it is ensured the caller is still added to the transpiration changeset. As other issue are identified, they can be added to impact tracking too. I have added a unit test, to check the main types of issues. We have used this with the j2cl quake port in our maven toolchain and iterations went from 7s to 1.5s for each iteration. |
niloc132
force-pushed
the
rebased_master
branch
from
e8e6ecd
to
64444e1
Compare
niloc132
force-pushed
the
rebased_master
branch
from
8972b62
to
aa5f8c2
Compare
No description provided.