Bugzilla – Full Text Bug Listing
| Summary: | Compilation silently aborted when apt is not on the classpath | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Sven Efftinge <sven.efftinge> |
| Component: | Core | Assignee: | Jay Arthanareeswaran <jarthana> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | christian.dietrich.opensource, jarthana, jeffrey.a.cummings, manoj.palat, stephan.herrmann |
| Version: | 4.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | stalebug | ||
|
Description
Sven Efftinge
How can you possibly not fix this immediately. The Eclipse javac compiler is unusable from the command line, and the fix has to be trivial. The result of this bug is that users who need to build from the command line can't move beyond Eclipse 4.5 (Mars 2). Bulk move out of 4.8 @Jay - retargetting to 4.9 - please modify the target as appropriate So, the expectation is to not abort compilation but proceed with it when the annotation processor classes are not found? So, the Eclipse compiler found in Maven central doesn't come with those? Perhaps we should include o.e.jdt.compiler.apt also part of the repo? The ECJ.jar that one can download from eclipse downloads page includes this and I think same should be the case for the maven central repo. (In reply to Sven Efftinge from comment #0) > It got revealed only now because of the latest jdt.core 3.12.2 release on > maven central. This looks like s.o. is consuming that last release of which we did not specifically publish ecj to Maven central. As of now, ppl should use this: https://mvnrepository.com/artifact/org.eclipse.jdt/ecj Checking the latest from that list (3.13.102) against http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.3a-201803300640/download.php?dropFile=ecj-4.7.3a.jar I see both having the exact same bytes. @Sven is this still relevant given that a sufficient ecj (recent versions) is available from Maven central? yes and no. since our code is used from maven/gradle and eclipse we added the two other artifactly to our maven path and thus work around this issue => the main problem is that a user (of jdt core) that does not know that will stumble on that (In reply to Christian Dietrich from comment #7) > => the main problem is that a user (of jdt core) that does not know that > will stumble on that Not sure I understand. ECJ can be consumed in many ways. When consumed as ecj<version>.jar the problem should not occur, right? Are you thinking of clients who use org.eclipse.jdt.core<version>.jar as their standalone compiler? Or is this about clients that are tied to that exact version that contains the change mentioned in comment 0, but of which no ecj.jar has been published to Maven? I would think that this affects only version [3.12.0,3.12.2], even an update to 3.12.3 should resolve it, no? yes older versions of jdt.core seemed to have pulled the dependency implicitly when you have have to add them explicitly (additional) => for us it is no longer a problem since we have all 3 deps explicitly now (In reply to Christian Dietrich from comment #9) > yes older versions of jdt.core seemed to have pulled the dependency > implicitly when you have have to add them explicitly (additional) Something is still confused: if s.o. wants an ecj batch compiler, they should *not* use the org.eclipse.jdt.core bundle (which by design does not include annotation processing), but ecj.jar, which is complete in this regard and specifically packaged as a standalone compiler. Why would anyone still use org.eclipse.jdt.core as a batch compiler? Cause jdt.core is there as a dependency since „ever“ Is there somewhere a list how Ecj and the 3 eclipse plugins differ from each other (In reply to Christian Dietrich from comment #13) > Is there somewhere a list how Ecj and the 3 eclipse plugins differ from each > other I'm not aware of a list (other than build scripts ;p), but it should be easily described: - org.eclipse.jdt.core (6.8MB) is the equinox-based core of the Java IDE - has dependencies to some Eclipse platform bundles - ecj (2.8MB) is the standalone batch compiler, which contains less and more: - not contained are codeassist,dom,eval,formatter,model,search - additionally contained are impls of JSR 269 and JSR 199: - org/eclipse/jdt/internal/compiler/apt/* - org/eclipse/jdt/internal/compiler/tool/* the main pointpoint we have is: - we have code that depends on platform and jdt - the code is consumed in eclipse and in maven gradle - if we keep dependencies in eclipse and maven in sync it is easy (we now added the two fragments additionally to maven) - so we are fine. - if we use ecj we would stuble over duplicate platform stuff and would be more out of sync of what we do in eclipse and what we do standalone It seems everybody has a way to get a complete batch compiler by now. So, is this bug (about continuing when the batch compiler is incomplete) still relevant to anybody? This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. Specifically after https://github.com/eclipse-jdt/eclipse.jdt.core/issues/181 it should no longer be possible to pull a recent ecj (in whatever form) lacking org/eclipse/jdt/internal/compiler/apt/* |