Community
Participate
Working Groups
Lars Vogel posted the following on the JDT core mailing list: A fellow Java champion pointed out to me that the annotation processing setup in Eclipse is very complex compared to other IDEs. Here is what we wrote me (slightly reworked for readability): QUOTE_BEGIN ------------ - NetBeans automatically finds APT JARs in the classpath. You can't turn it off. You can't tweak any settings. - IntelliJ allows to activate APT processing (per project) with a checkbox; this will find all available APT JARs in the classpath by default. You can also configure which JARs may be used. - Eclipse forces you to locate and define every APT JAR by hand, per project. This means NB is on one side of the spectrum (fully automatic) where Eclipse is at the opposite side (fully manual), while Intellij sits somewhere in between. Example instructions for all IDEs can be found at http://griffon-framework.org/tutorials/1_getting_started.html#_tutorial_1_4 ------------ QUOTE_END --- End original post to JDT core mailing list My own preference would be to have something across from NetBeans and IntelliJ. We could have some fairly fine-grained settings to control what annotation processor is used for each package, but the default value of the setting would be to use everything that appears on the classpath... so if you don't change any defaults, things will work pretty much like NetBeans... but you could still have fine-grained control if you want to use - say - two different IoC injectors in the same project at the same time. However, I think that making this "just work" by default would require fixing bug 472175 first since Eclipse would otherwise end up loading unreliable APT code into its own VM.
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.
May still be relevant, but considering this needs bug 472175 to be fixed first, that's a lot of work. May not happen any time soon.
