Looks like constructor in Editor called from from JavaEditor is calling an overloaded method back in JavaEditor that expects debugger to have been initialized which is not possible since the parent constructor has not returned. This switches to loading debugger on demand (upon calling getDebugger) which allows for the Editor to use overloaded methods that expect debugger to be initialized.
Per https://github.com/processing/processing4/issues/58, pixelDensity should run in settings and currently results in failure if used in static context. This will rewrite pixelDensity into the setting section if found in static or settings context. Adds unit tests for both scenarios.
Refactored ant build chain to allow building / running without execution of tests but ensure tests are run during dist. Note that tests are still runnable under the test target itself. Resolves#8.
Discontinued use of string import statement generation and migrated to pdex's ImportStatement class which can keep track of if the import is static or not. This allows static imports to be handled correctly in PDEX, JavaBuild library resoluation, and actual Java compilation step. Resolves https://github.com/processing/processing/issues/5577 and https://github.com/processing/processing4/issues/16 but only in the Processing4 branch.
Per @benfry goal of reducing class count, rolled RewriteParams into PdeParseTreeListener now that the code rewrite utils are also rolled into PdeParseTreeListener.
An explicit goal of @benfry is to reduce class count and this PR cleans up edits made within preproc to merge supporting classes and utility functions of PdeParseTreeListener into PdeParseTreeListener itself. This includes removal of ImportUtil per https://github.com/processing/processing4/issues/10.
Some difficult to generate code is managed by the RewriterCodeGenerator and some modes may need to modify that logic. This commit makes it easier to extend parts of RewriterCodeGenerator without requiring client code to duplicate too much effort.
In response to https://github.com/processing/processing4/issues/11, allow client code to override preprocessing edit behabior by providing a subclass of PdeParseTreeListener. This does make the construction for PdePreprocessor.java a little bit messier but a builder may help and moving dependent types within enclosing classes can hopefully keep things coherent.
A Pottinger