Jim Moore
Jim Moore
Grabbit is currently -- by design -- quite fragile. If there's any bad data, incomplete transmission of data, etc. it is blatantly obvious that something went wrong with no possibility...
Even though a Node name may not meet the JCR specification, it is still possible (especially for content migrated from old CQ instances) for bad data to come over. Grabbit...
In addition to removing yet-another potential library dependency conflict (per #105), Grabbit would benefit from the additional performance and type-safety, per some of the changes made in [grabbit-cli](../../grabbit-cli). A proposed...
To increase the flexibility of deploying Grabbit, the bundles that it depends on should be extracted into their own deployable package. Though [Felix/AEM has some reasonably smarts when it comes...
For GH-69
- https://github.com/TWCable/gradle-plugin-scr - https://github.com/TWCable/gradle-plugin-cq-bundle - https://github.com/TWCable/gradle-plugin-cq-package
Per GH-128 and dependent on GH-127. Remove OSGi and library dependencies on Groovy and related. Update the build to use only `src/main/java` instead of `src/main/groovy`. The `groovy` plugin will still...
Per GH-125 This may need to be more of an epic, depending on what is found as we get in there. Converting from Groovy-style collections handling to JDK 8 Streams...
Per GH-125 Convert the classes that are a simple mechanical translation. Fortunately IntelliJ IDEA has a "Convert to Java" refactoring that -- while far from perfect -- takes care of...
Per GH-125 - [ ] Convert build to target compiling for JRE 1.8 - [ ] Add Lombok - [ ] Add Checker Framework - [ ] Add PMD -...