Community
Participate
Working Groups
Build Identifier: Tool providers who would like to use JDT Core's ASTParser and Compiler infrastructure have to bundle the entire SDK just to use these "core"/non-GUI features. Example, this article about using Eclipse JDT Core's AST parser and compiler - http://programcreek.com/2011/01/a-complete-standalone-example-of-astparser depends on JAR files that are not in the JDT (org.eclipse.jdt-3.7.1.zip) bundle even though it's a hefty 24MB zip file. In that article above, the author packaged the dependencies and has made it available on his own: org.eclipse.core.contenttype.jar org.eclipse.core.jobs.jar org.eclipse.core.resources.jar org.eclipse.core.runtime.jar org.eclipse.equinox.common.jar org.eclipse.equinox.preferences.jar org.eclipse.jdt.core.jar org.eclipse.osgi.jar It would be very nice if we had a small but self contained bundle of JDT core and its deps. Why? This will encourage language builders and enhancement writers to leverage a single platform instead of writing one off parsers, AST visitors, expression builders and stuff like that. The Batch compiler is used by many projects and it would be nice if the parser were also packaged for such non-GUI users. Reproducible: Always
Original mailing list thread - http://www.eclipse.org/forums/index.php/m/740970/#msg_740970
I agree with the importance of solving this issue, however I don't think that an all-in-one jar is the right approach since if you want to provide the decompiler in a similar way you will have to produce yet another permutations / big bundle. Instead it would be more beneficial to the general community to make the necessary bundles available in Maven Central since ECJ is already there (http://search.maven.org/#search%7Cga%7C1%7Cecj). Out of this list of bundles and for the use case identified in the blog, it is interesting to note that org.eclipse.core.resources is just here because a couple classes depend on it (I believe around IWorkingCopy) but those are not used at runtime but only needed for the bytecode verification. So there may be something to do API wise or implementation wise to reduce this. Another path for reduction would be to just add a subset of the AST manipulator API in front of the standalone compiler but I assume that this would only work for reading ASTs.
(In reply to comment #2) I agree that a big repackaged jar is not the right way, but at least a set of links to the component/dependent JARs on Maven would be nice.
