Explain how to add dagger to Eclipse project about dagger HOT 62 CLOSED

I think you meant dagger-0.9.jar, Thomas.

Yes - dagger-compiler-${version}.jar requires dagger-${version}.jar and
if you're not using Maven or some other dependency management system,
then you have to add all the relevant jars manually wherever you need to
use the compiler/code-generator.

from dagger.

Ah, I deleted my comment as soon as I posted it but the notifications were apparently already sent ;-)

I backed it up 'cause obviously you already have dagger-0.9.jar (yes, I mean 0.9) in your project's build path, so you shouldn't have to add it again in the factory path I guess. Just a guess though; I thought I'd better try it before making such claims.

from dagger.

@macsux Did you find a solution to your problem, I'm having sort sort the same?

from dagger.

No, decided to use Guice instead. Felt like a more mature project, and had
features which I liked that dagger didn't. I don't care that much about
startup time anyways for what I'm doing.

On Thu, Jan 3, 2013 at 3:04 AM, Anton Gravestam [email protected]:

@macsux https://github.com/macsux Did you find a solution to your
problem, I'm having sort sort the same?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/126#issuecomment-11837049.

from dagger.

For anyone interested...

This is how you get dagger to run without maven with a (simple) eclipse setup

1. Create a directory compile-libs next to your libs directory.
2. Put dagger-compiler-.jar in this directory.
3. Put dagger-.jar and javax.inject.jar (get it from here: http://code.google.com/p/atinject/downloads/list ) in your libs directory.
4. Put dagger-.jar and javax.inject.jar on your buildpath.
5. Goto Project->Properties->Java Compiler-> and check "Enable project specific settings". AND Goto Project->->Properties->Java Compiler->Factory path and check "Enable project specific settings"
6. Under Factory path Click add JARs and add dagger-compiler-.jar, dagger-.jar and javax.inject.jar

Update!
Make sure you have ".apt_generated" as a source folder on your build path.

Clean and rebuild project and you should be good to go!

from dagger.

I can get code generation working but no compiler errors. Despite the fact that I have a provider with a parameter which has not been provided.

from dagger.

So you won't get errors in wiring if you simply have some inject
annotations. You need to have at least one complete module that is the
starting definition of your graph or dagger can't perform it's full graph
analysis. Do you have a module defined?

Regards,
Christian
Sent from my iPhone.

On Jan 14, 2013, at 3:06, Steven-Mark-Ford [email protected] wrote:

I can get code generation working but no compiler errors.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/126#issuecomment-12209445.

from dagger.

Also, if you haven't set up annotation processing in eclipse you have to
build from maven then add the generated classes source dir as a source
folder in eclipse.

Regards,
Christian
Sent from my iPhone.

On Jan 14, 2013, at 8:44, Christian Gruber [email protected] wrote:

So you won't get errors in wiring if you simply have some inject
annotations. You need to have at least one complete module that is the
starting definition of your graph or dagger can't perform it's full graph
analysis. Do you have a module defined?

Regards,
Christian
Sent from my iPhone.

On Jan 14, 2013, at 3:06, Steven-Mark-Ford [email protected] wrote:

I can get code generation working but no compiler errors.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/126#issuecomment-12209445.

from dagger.

@cgruber I followed staxgr example on setting up annotation processing in eclipse and I have defined a module but I still don't see any compile errors. Where would they appear within eclipse? In the "Problems" window?

from dagger.

Hmm, I'm not sure if I could see compile errors (guess you mean if you have
unresolved dependencies and such) either. I was happy once I got it to
work... (don't have my environment here so I can test unfortunately)

On Mon, Jan 14, 2013 at 9:59 PM, Steven-Mark-Ford
[email protected]:

@cgruber https://github.com/cgruber I followed staxgr example on
setting up annotation processing in eclipse and I have defined a module but
I still don't see any compile errors. Where would they appear within
eclipse? In the "Problems" window?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/126#issuecomment-12219258.

from dagger.

They should, but I am not using eclipse's annotation processing config. I
just build with maven inside eclipse using m2e and add the
target/generated-sources/annotations folder. I'd maven generation fails I
get the error there and then the compilation errors are showing as broken
in eclipse too.

Regards,
Christian
Sent from my iPhone.

On Jan 14, 2013, at 8:59, Steven-Mark-Ford [email protected] wrote:

@cgruber https://github.com/cgruber I followed staxgr example on setting
up annotation processing in eclipse and I have defined a module but I still
don't see any compile errors. Where would they appear within eclipse? In
the "Problems" window?

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/126#issuecomment-12219258.

from dagger.

@cgruber Would you be able to give me an example of a Dagger compile-time error and how to induce it so I can see if I can replicate this within my eclipse project?

from dagger.

In order to structure my response, are you using M2E?

from dagger.

Nope, just vanilla Eclipse+ADT (All-in-one package). Thanks in advance.

from dagger.

Ok, so my examples would have all been maven and m2e based. I've not done
enough with the standard eclipse config.

I will say that I added the key jars to the factory path and I got code and
.dot generation but did NOT get errors from the full graph processor.
Strange because I do get such errors from maven and javac, and I know it's
generating code because I clear out the folder and "clean" the project and
I get adapters and .dot files.

Very weird. I'll investigate further but I know this is an uncommon
configuration for dagger devs who either use IntelliJ or eclipse with m2e.

Regards,
Christian
Sent from my iPhone.

On Jan 16, 2013, at 6:13, Steven-Mark-Ford [email protected] wrote:

Nope, just vanilla Eclipse+ADT (All-in-one package). Thanks in advance.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/126#issuecomment-12313982.

from dagger.

This is because errors are reported without being attached to an “element”, so they only appear in the “Error Log” view (which is hidden by default); see issue #110

from dagger.

On 21 Jan 2013, at 9:51, Thomas Broyer wrote:

This is because errors are reported without being attached to an
“element”, so they only appear in the “Error Log” view (which
is hidden by default); see issue #110

Makes sense. I was going to look into #110 soon, so maybe I can fix all
of this at once. Thanks for the pointer.

from dagger.

@cgruber @tbroyer Thanks! I look forward to using full integration but for now I will use the "Error Log" view for compilation errors.

from dagger.

Hi, I am trying to configure Dagger in my Android project...I am running into some issue. I just want to be sure that my m2e configuration is ok. I checked the dagger projects from SCM but imported in my pom.xml version 0.9.1.
I created a debug configuration to launch mvn. Do I need to tick Resolve Workspace Artifacts?
It looks that it compiles using maven but the error checking in Eclipse doesn't work (there is an error on a black private final field with @Inject annotation). Do I need additional steps?
EDIT: I have a "The POM for com.squareup:dagger-compiler:jar: is missing, no dependency information available" in the ErrorLog...I might have set up wrong my pom.xml.

from dagger.

We're not quite there with eclipse error integration… that is, you
need to add the dagger, dagger-compiler, and javax.inject jars manually
to your annotation processing class path for your project, in the
preferences, in the java compiler section.

I'm digging into whether it'll be possible to have maven auto-configure
eclipse to use these, but for now, you need to add those. I'll work up
some instructions with screen shots hopefully this week.

Christian.

On 11 Feb 2013, at 22:23, Andrea Richiardi wrote:

Hi, I am trying to configure Dagger in my Android project...I am
running into some issue. I just want to be sure that my m2e
configuration is ok. I checked the dagger projects from SCM but
imported in my pom.xml version 0.9.1.
I created a debug configuration to launch mvn. Do I need to tick
Resolve Workspace Artifacts?
It looks that it compiles using maven but the error checking in
Eclipse doesn't work (there is an error on a black static field with
@Inject annotation). Do I need additional steps?

---

Reply to this email directly or view it on GitHub:
#126 (comment)

from dagger.

@cgruber I've successfully used m2e-apt in the past; haven't tried it with Dagger yet though. It also requires you to put dagger-compiler as a dependency of the compiler or processor plugin.

@arichiardi you won't have error annotations in your code with 0.9.1 (see issue #110). The error you're seeing is probably due to some network/server error when retrieving the artifact, try forcing resolution (mvn -U or check the appropriate box in Eclipse when you Maven → Update project configuration…)

from dagger.

Hmm. When I put dagger-compiler as a dep of the compiler plugin then
I don't get generated code in the target/generated-sources/annotations
folder, so I've been doing it as an optional dependency of the library
being processed. Hrm.

from dagger.

@tbroyer I can survive without error on annotation in eclise, I can generate the code with mvn -install, that means that the correct jars are there (I can see them in my local .m2 folder). The problem is that it looks like the code is not "visible" to Eclipse, as I have the "blank field might not be initialized" error on private final field with @Inject annotation...

from dagger.

Add the generated sources jar as a source folder manually.

from dagger.

@cgruber I'd swear I saw it work but now that I try it again on a small project, it actually doesn't even run the annotation processors! (tried with an Oracle JDK6 and OpenJDK7, with and without -Dmaven.compiler.fork; the dagger-compiler-0.9.1.jar never appears in the Command line options (when running mvn with -X`)). Auto-config of Eclipse with m2e-apt works fine though.

Actually, m2e-apt seems to work OK even with dagger-compiler as a project dependency ( optional or provided), as it simply enables annotation processing in Eclipse and puts the whole build path as the factory path (and configures the output to target/generated-sources/annotations). Annotation processor discovery from JDT/ADT does the rest to pick and run the annotation processors from Dagger.

from dagger.

That's awesome. I'll do some testing and write up some docs specific to
dagger.

from dagger.

I confirm that it perfectly works with just dependency under pom.xml. I have compiled (no-test) dagger after having synced with the repo and installed the version 1.0-SNAPSHOP in my local repository. There is no error log for annotations but the mvn output is fine.
I discovered that my "blank field not initialized" was caused by the fact that the injected field was final. Thanks!

from dagger.

@arichiardi with a recent 1.0-SNAPSHOT and m2e-apt (or manually configured annotation processing in Eclipse), you should have markers in the editor. It's not clear whether you're using m2e-apt or not (it would confirm, or not, my experience with m2e-apt).

from dagger.

@tbroyer No, I don't have m2e-apt at the moment. I am trying to configure it manually actually, linking the dagger-compiler.jar in the maven local repo to the project specific properties, enabling annotations. Note that it is still not compiling with regular maven.

from dagger.

Ok, now something's better. I get this:
Internal compiler error: java.lang.NoClassDefFoundError: com/squareup/java/JavaWriter at dagger.internal.codegen.InjectProcessor.writeIncjectAdapter(InjectProcessor.java:190)
But at least it seems that it is trying to compile annotations with the custom dagger-compiler-.jar.
Not that I have just pulled from the repository.

from dagger.

The Javawriter was extracted into another project and you need that
jar in your factory class path also.

from dagger.

Sorry for all these updates....but I am now able to see annotation errors under Problems in Eclipse!
So, in order to achieve this, under Factory path click "Add Jar..." and add dagger-compiler-.jar, dagger-.jar, javax.inject.jar AND javawriter.jar.
I don't know/think that it works without this "Project specific property" setting. Again, I am not using m2e-apt.

from dagger.

@arichiardi just so you are aware updating the factory path to include the JARs listed above will induce the compiler of annotations but the errors you are seeing in the Problems window are not the full list of dagger compile errors. They will not yet include errors like "No injectable members on ..." as far as I am aware. Such errors can still only be located in the "Error Log" window. @cgruber please correct me if I am wrong here.

from dagger.

@Steven-Mark-Ford Just tested in dagger-example and “No injectable members on …” are reported on the module class, but only if you somehow make Eclipse recompile the module (rebuild project, or edit/save the module). Similarly, errors don't go even after you fixed them, until Eclipse recompiles the module. But this is because the validation doesn't take place at all, so no error will be reported to the Error Log view either.

(note: to make m2e-apt work in dagger-example, I had to Maven → Disable Workspace Resolution on the project)

from dagger.

@tbroyer I get “No injectable members on …” in the Error Log.

On Thu, Feb 14, 2013 at 4:02 PM, Thomas Broyer [email protected]:

@Steven-Mark-Ford https://github.com/Steven-Mark-Ford Just tested in
dagger-example and “No injectable members on …” are reported on the
module class, but only if you somehow make Eclipse recompile the module
(rebuild project, or edit/save the module). Similarly, errors don't go even
after you fixed them, until Eclipse recompiles the module. But this is
because the validation doesn't take place at all, so no error will be
reported to the Error Log view either.

(note: to make m2e-apt work in dagger-example, I had to Maven → Disable
Workspace Resolution on the project)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/126#issuecomment-13550413.

from dagger.

@Steven-Mark-Ford with a recent self-built 1.0-SNAPSHOT?

from dagger.

@tbroyer Thanks. That would be the issue then.

On Thu, Feb 14, 2013 at 4:11 PM, Thomas Broyer [email protected]:

@Steven-Mark-Ford https://github.com/Steven-Mark-Ford with a recent
self-built 1.0-SNAPSHOT?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/126#issuecomment-13550788.

from dagger.

If I'm not mistaken, #110 fixes this, so errors should show up in the
problem frame. But I haven't tested that. I'll try to confirm that
today.

from dagger.

On 14 Feb 2013, at 9:02, Thomas Broyer wrote:

(note: to make m2e-apt work in dagger-example, I had to Maven →
Disable Workspace Resolution on the project)

Ok… THAT seriously sucks. Thats one of my favorite m2e features.

from dagger.

On Thu, Feb 14, 2013 at 5:39 PM, Christian Edward Gruber wrote:

On 14 Feb 2013, at 9:02, Thomas Broyer wrote:

(note: to make m2e-apt work in dagger-example, I had to Maven →
Disable Workspace Resolution on the project)

Ok… THAT seriously sucks. Thats one of my favorite m2e features.

I suppose it's a limitation of Eclipse: you can only add JARs to the
Factory Path, so there's no way m2e-apt would add dependent projects (at
least without mvn package-ing them, which you don't want it to do
automatically; so in the end, a manual mvn install is clearer, and you
won't break Eclipse with a mvn clean). I haven't tried re-enabling
workspace resolution after m2e-apt has configured the factory path, maybe
it'd work, and thus only annotation processing would suffer from the
situation.

Workspace resolution works OK for most projects though, it's only an issue
when you have dagger-compiler as a project in the same namespace. So
basically, it's mostly an issue for us people hacking on Dagger, not for
developers using Dagger in their projects.

from dagger.

Totally makes sense, Thomas. I'm just annoyed - it means I'll have to
use separate workspaces in some cases, but yeah - it's mostly annoying
for me/us, not our users. :D

from dagger.

@tbroyer I'm trying to get this working (Eclipse, m2e, m2e-apt). Can you show how you configured maven-compiler-plugin in your POM? I haven't used m2e-apt before... I installed it, and then went to to Window->Preferences->Maven->Annotation Processing and choose "Automatically configure...". Now I'm trying to figure what to put here:

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <dependencies>
    <dependency>
      <groupId>com.squareup</groupId>
      <artifactId>dagger-compiler</artifactId>
      <version>${dagger.version}</version>
    </dependency>
  </dependencies>
  <configuration>
    <annotationProcessors>
      <annotationProcessor>WHAT GOES HERE?</annotationProcessor>
    </annotationProcessors>
  </configuration>
</plugin>

from dagger.

@adennie Let everyone (maven-compiler-plugin and Eclipse) discover the annotation processors, i.e. don't specify them explicitly; the dependency should be enough (for m2e-apt at least)

from dagger.

Yeah... I can't even find Annotation Processing in my m2e 1.2 configuration settings. I'm on Juno SR1 - and I get no UI at those preferences locations. Grr.

from dagger.

@tbroyer Hmm, OK, thanks. Still not working for me, so must be something else. Besides installing m2e-apt and choosing "Automatically configure..." is there anything else to the m2e-apt configuration that I might be missing?

from dagger.

And of course 1.3 is announced today. I'ma start from scratch with m2e 1.3, install m2e-apt and see how it goes.

from dagger.

I''m now having consistent success with this using m2e, m2e-apt, and "disable workspace resolution" (if I have dagger open as a project in eclipse). This seems worth closing at this point.

from dagger.

still fiddling with this in gradle even in eclipse...

On Wed, Aug 7, 2013 at 12:12 PM, Christian Edward Gruber <
[email protected]> wrote:

I''m now having consistent success with this using m2e, m2e-apt, and
"disable workspace resolution" (if I have dagger open as a project in
eclipse). This seems worth closing at this point.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/126#issuecomment-22262930
.

from dagger.

Can't help on the gradle front. Never used it, have zero idea how it
could even integrate with an IDE, since it's more script-like than
something declarative like maven. I'm sure one could, but exposing
things like dependency graph / class path would seem to need specific
support for IDEs and I just don't know Gradle well enough.

from dagger.

IntelliJ just delegates to CLI Gradle. Eclipse does do the same?

from dagger.

That would suck, as it wouldn't be able to auto-configure eclipse's annotation processing support to "just work" in eclipse incremental builds. :(

from dagger.

True. But Gradle does incremental builds itself and the IDE keeps the
daemon warm so it's just as quick. Change one file and it only compiles one.
On Aug 8, 2013 7:06 PM, "Christian Edward Gruber" [email protected]
wrote:

That would suck, as it wouldn't be able to auto-configure eclipse's
annotation processing support to "just work" in eclipse incremental builds.
:(

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/126#issuecomment-22371488
.

from dagger.

Depends. If you have a custom wrapper than configuring the eclipse
gradle can be a pain, if possible. The eclipse plugin/task for Gradle
doesn't support writing the apt metadata in .classpath, .factories,
.setttings etc. For my use case, I can't use reflection at all anymore due
to failover loader, and this makes this issue really painful in clunky
integration scenarios.

I've no doubt I or we can improve things to make adt work fine in
eclipse,idea from maven, Gradle, just that it is suprise ancillary
work. at least in the case of Gradle, this probably eludes to a dagger
plugin, as I'm not really looking forward to teaching a bunch of people the
magic settings.

An alternative would be to make it possible to use a combination of compile
and reflection in unit tests. This is basically the feature that is now
gone.

On Thursday, August 8, 2013, Jake Wharton wrote:

IntelliJ just delegates to CLI Gradle. Eclipse does do the same?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/126#issuecomment-22370880
.

from dagger.

You would be surprised how much "ancillary work" I had to do or
instigate and track related to Dagger to get it all going in google.
Build systems seem ancillary but they are HOW our framework's facilities
are manifested.

from dagger.

I've no doubt that even what I could imagine would only be a small part of
the effort you've put through towards getting builds right.

So let's just catalog what he have, as we aren't really tracking build
system debt that needs to be sorted as much as the java code.

Before FailoverLoader, we had getting:

• adding a scope to Gradle which could use annotation processing during
  test runs but not include it as a compile deps. These are still somewhat
  snowflake special instructions.
• similar for the android plugin for Gradle which has slightly different
  classpath stuff.
• ProGuard support

Now that failover loader makes it impossible to mix and match adhoc modules
via reflection, we have a bit more stuff in IDE land.

• probably need to update docs to say reflection is deprecated as it barely
  has a use case that can work now.
• for build system plugins that generate eclipse metadata(eclipse:eclipse
  or Gradle eclipse), instructions or extensions that setup the proper 3 jar
  dependency for adp processing and how to keep that in sync when next
  upgrade happens.
• for IDE plugins, any similar instructions or config to do above,
  including a known list of IDEs that may have worked with reflection but
  don't work properly with ADP.

Choosing battles, I'd still love to be able to have folks productive before
the latter mountain is moved, especially as it is usually an override
module used in a test that now fails and enters an IDE config loop. In
hindsight I think we should have done a flag as there are cases where mixed
reflection and compile is ok, provided we aren't deprecating reflection.

On Friday, August 9, 2013, Christian Edward Gruber wrote:

You would be surprised how much "ancillary work" I had to do or
instigate and track related to Dagger to get it all going in google.
Build systems seem ancillary but they are HOW our framework's facilities
are manifested.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/126#issuecomment-22393851
.

from dagger.

Anyway since I'm the one whining, I'll take on the how-to etc stuff. ;)

On Friday, August 9, 2013, Adrian Cole wrote:

I've no doubt that even what I could imagine would only be a small part of
the effort you've put through towards getting builds right.

So let's just catalog what he have, as we aren't really tracking build
system debt that needs to be sorted as much as the java code.

Before FailoverLoader, we had getting:

• adding a scope to Gradle which could use annotation processing during
  test runs but not include it as a compile deps. These are still somewhat
  snowflake special instructions.
• similar for the android plugin for Gradle which has slightly different
  classpath stuff.
• ProGuard support

Now that failover loader makes it impossible to mix and match adhoc
modules via reflection, we have a bit more stuff in IDE land.

• probably need to update docs to say reflection is deprecated as it
  barely has a use case that can work now.
• for build system plugins that generate eclipse metadata(eclipse:eclipse
  or Gradle eclipse), instructions or extensions that setup the proper 3 jar
  dependency for adp processing and how to keep that in sync when next
  upgrade happens.
• for IDE plugins, any similar instructions or config to do above,
  including a known list of IDEs that may have worked with reflection but
  don't work properly with ADP.

Choosing battles, I'd still love to be able to have folks productive
before the latter mountain is moved, especially as it is usually an
override module used in a test that now fails and enters an IDE config
loop. In hindsight I think we should have done a flag as there are cases
where mixed reflection and compile is ok, provided we aren't deprecating
reflection.

On Friday, August 9, 2013, Christian Edward Gruber wrote:

You would be surprised how much "ancillary work" I had to do or
instigate and track related to Dagger to get it all going in google.
Build systems seem ancillary but they are HOW our framework's facilities
are manifested.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/126#issuecomment-22393851
.

from dagger.

FYI: I'm not happy with this solution, but it works in both idea and
eclipse and can be used as a scrapyard until we can coerce a proper gradle
plugin.

https://github.com/Netflix/denominator/blob/master/dagger.gradle

On Fri, Aug 9, 2013 at 11:01 AM, Adrian Cole [email protected]:

Anyway since I'm the one whining, I'll take on the how-to etc stuff. ;)

On Friday, August 9, 2013, Adrian Cole wrote:

I've no doubt that even what I could imagine would only be a small part
of the effort you've put through towards getting builds right.

So let's just catalog what he have, as we aren't really tracking build
system debt that needs to be sorted as much as the java code.

Before FailoverLoader, we had getting:

• adding a scope to Gradle which could use annotation processing during
  test runs but not include it as a compile deps. These are still somewhat
  snowflake special instructions.
• similar for the android plugin for Gradle which has slightly different
  classpath stuff.
• ProGuard support

Now that failover loader makes it impossible to mix and match adhoc
modules via reflection, we have a bit more stuff in IDE land.

• probably need to update docs to say reflection is deprecated as it
  barely has a use case that can work now.
• for build system plugins that generate eclipse metadata(eclipse:eclipse
  or Gradle eclipse), instructions or extensions that setup the proper 3 jar
  dependency for adp processing and how to keep that in sync when next
  upgrade happens.
• for IDE plugins, any similar instructions or config to do above,
  including a known list of IDEs that may have worked with reflection but
  don't work properly with ADP.

Choosing battles, I'd still love to be able to have folks productive
before the latter mountain is moved, especially as it is usually an
override module used in a test that now fails and enters an IDE config
loop. In hindsight I think we should have done a flag as there are cases
where mixed reflection and compile is ok, provided we aren't deprecating
reflection.

On Friday, August 9, 2013, Christian Edward Gruber wrote:

You would be surprised how much "ancillary work" I had to do or
instigate and track related to Dagger to get it all going in google.
Build systems seem ancillary but they are HOW our framework's facilities
are manifested.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/126#issuecomment-22393851
.

from dagger.

As popular as annotation processors are these days (see dagger, auto value, etc.) perhaps some kind soul (or team of kind souls at Google/Square) could fix what I believe is the core underlying issue:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=280542

AFAIK this would mean that however dagger/autovalue/& friends got on the Eclipse classpath (whether manually, or via a Maven classpath container, or via a Gradle classpath container, etc.) that Eclipse would automatically run them. Just like javac.

from dagger.

I don't have any personal experience with it, but I've heard that getting the eclipse team to accept patches (even for pretty grievous bugs) is quite difficult. For that reason, you're probably not going to see a lot of people volunteering to fix that issue…

from dagger.

Terry says they've had more luck recently. I'll check with him in next
week.

On Wed, Oct 1, 2014, 20:27 Gregory Kick [email protected] wrote:

I don't have any personal experience with it, but I've heard that getting
the eclipse team to accept patches (even for pretty grievous bugs) is quite
difficult. For that reason, you're probably not going to see a lot of
people volunteering to fix that issue…

—
Reply to this email directly or view it on GitHub
#126 (comment).

from dagger.

FWIW back in 2009/2010 I submitted several bugs (NPEs/etc.) in Eclipse's APT support and they were pretty responsive. (As responsive as waiting for the next Eclipse release can be anyway.)

Walter Harley, who wrote the initial Eclipse APT support while working at BEA, was especially helpful, although since BEA defunded their Eclipse work, he was just watching the bug tracker as a hobby.

I have no idea if Walter is interested in Eclipse/APT anymore, but I'd love to see someone fund him (or someone like him) to fix this bug. I would personally chip in to that effort, as that Eclipse APT bug is basically the sole reason I'm loathe to write annotation processors anymore, and almost always pick a different means of code generation.

from dagger.

I just met a few eclipse contributors at JavaONE. I'll hit them up to see
if they can suggest profitable direction - who to talk to, etc., if Walter
is not involved.

On Thu, Oct 2, 2014, 08:41 Stephen Haberman [email protected]
wrote:

FWIW back in 2009/2010 I submitted several bugs (NPEs/etc.) in Eclipse's
APT support and they were pretty responsive. (As responsive as waiting for
the next Eclipse release can be anyway.)

Walter Harley, who wrote the initial Eclipse APT support while working at
BEA, was especially helpful, although since BEA defunded their Eclipse
work, he was just watching the bug tracker as a hobby.

I have no idea if Walter is interested in Eclipse/APT anymore, but I'd
love to see someone fund him (or someone like him) to fix this bug. I would
personally chip in to that effort, as that Eclipse APT bug is basically the
sole reason I'm loathe to write annotation processors anymore, and almost
always pick a different means of code generation.

—
Reply to this email directly or view it on GitHub
#126 (comment).

from dagger.