Community
Participate
Working Groups
In 3.0, Eclipse compiler that could be called from an Ant task had no dependencies on other Eclipse plugins. It was enough to have only org.eclipse.jdt.core plugin in a classpath. I've tried to run the following snippet on the latest 3.1 build ASTParser parser = ASTParser.newParser( AST.JLS3); parser.setKind(ASTParser.K_COMPILATION_UNIT); parser.setSource( source.toCharArray()); CompilationUnit node = (CompilationUnit) parser.createAST(null); and it require at least following plugins and still does not work. org.eclipse.core.resources_3.1.0.jar org.eclipse.core.runtime_3.1.0.jar org.eclipse.osgi_3.1.0.jar Note that Eclipse compiler is being used for Tomkat and all those dependency may became a big issue. I believe that compiler should be better isolated from an Eclipse core.
This isn't the compiler, but rather the DOM AST API which isn't meant to be separated from Eclipse platform. The batch compiler is and will remain extractible for other to use outside of Eclipse.
Hmm, is there are way to use Eclipse AST outside platform? There are number of projects that may benefit from this. For example dynamic scripting, batch code analysis and transformation, etc.
No, the DOM AST is currently Eclipse-based. Note that you can use Eclipse in a batch mode (headless), so there shouldn't be any problem in using the DOM AST as you want to.
Philippe, the big problem with headless Eclipse is that it will require the entire platform runtime, which is huge, comparing to just jdt.core plugin.
Well, we are talking only about 12-13 extra plugins, and most of them are pretty small. Definitely not for 3.1
Philippe, is it possible to resolve this in 3.2?
I also need a resolution for this issue. In particular, I need to use AST independent from a running Eclipse platform. As it looks to me, the whole AST is independent from a running Eclipse platform - except for the call to JavaCore.getOptions() in ASTParser; this introduces the dependency. What about the following idea: in class org.eclipse.jdt.core.dom.ASTParser instead: this.compilerOptions = JavaCore.getOptions(); just use if (InternalPlatform.isRunning()) { this.compilerOptions = JavaCore.getOptions(); } else { this.compilerOptions = new HashMap(); } This is needed in two places (initializeDefaults() and setCompilerOptions()). This fix does not change the current behaviour for Eclipse, but enables also non-Eclipse environments to work with the powerful AST parser (again). As this fix is really easy and low risk, a fix also in 3.1 would be great.
this.compilerOptions = new HashMap(); should better be a good default. If an empty map is provided, I doubt that you will get the expected result. So I would better work on some default map that would match the existing default. But I agree that changing this should not affect a running Eclipse instance and we should target 3.2.
(In reply to comment #8) > this.compilerOptions = new HashMap(); should better be a good default. > If an empty map is provided, I doubt that you will get the expected result. So > I would better work on some default map that would match the existing default. Ideally it would be handy to have some pluggable options provider, so platform would hook up existing JavaCore.getOptions() and external tool could use their own mechanisms. But defaults will do for a short term...
> Ideally it would be handy to have some pluggable options provider, so platform > would hook up existing JavaCore.getOptions() and external tool could use their > own mechanisms. But defaults will do for a short term... I'm not sure if we make it too pluggable here. Any platform or exploiter may set its options by ASTParser.setCompilerOptions() to whatever it like; this should be enough configurability. Therefore, I could also accept the empty HashMap as default (for my code, this patch worked), but a specific default map is also good for me.
(In reply to comment #10) > I'm not sure if we make it too pluggable here. Any platform or exploiter may > set its options by ASTParser.setCompilerOptions() to whatever it like; this > should be enough configurability. Therefore, I could also accept the empty > HashMap as default (for my code, this patch worked), but a specific default map > is also good for me. I am not very familiar with the code, so I am wondering why platform/jdt can't initialize ASTParser.setCompilerOptions() externally then?
Changing existing behavior may break some clients; so I would rather only consider supporting cases the platform is not running, and then rely on client to specify its options using #setCompilerOptions(...). One other piece of missing information when no project is available is: no classpath. Shouldn't we also have a #setClasspath(...) likewise ? This would allow to resolve bindings, and we could restrain classpath to simple explicit folders or libraries. But maybe this is more than what is needed currently, and could be addressed beyond 3.2, as we froze our API already (M5). Tagging for 3.2M6, as there seems to be some consensus ahead.
*** This bug has been marked as a duplicate of 87852 ***
This will allow the AST to be created, but no binding will be available. Is this ok?
If bindings are required, then another bug should be filled. This bug is about providing equivalent functionality as in 3.0, which is AST no binding.
(In reply to comment #15) > If bindings are required, then another bug should be filled. This bug is about > providing equivalent functionality as in 3.0, which is AST no binding. > That's also my opinion.
(In reply to comment #7) > As it looks to me, the whole AST is independent from a running Eclipse platform > - except for the call to JavaCore.getOptions() in ASTParser; this introduces > the dependency. I prefer to put the patch inside JavaCore.getOptions(). > if (InternalPlatform.isRunning()) { > this.compilerOptions = JavaCore.getOptions(); > } else { > this.compilerOptions = new HashMap(); > } InternalPlatform cannot be used since it is internal. I would say we either check getPlugin() == null or: Platform.isRunning() Would you test it if I release that change for tomorrow's integration build?
(In reply to comment #17) > InternalPlatform cannot be used since it is internal. > I would say we either check getPlugin() == null or: > Platform.isRunning() > > Would you test it if I release that change for tomorrow's integration build? > Yes, I'll test it. Thanks.
