Summary: | Standalone JDT core package with ASTParser and Compiler outside the SDK | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | ashwin.jayaprakash |
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | arend, ashwin.jayaprakash, daniel_megert, Konstantin.Scheglov, pascal |
Version: | 3.7.1 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
ashwin.jayaprakash
2011-10-19 18:13:20 EDT
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. |