New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain how to add dagger to Eclipse project #126

Closed
macsux opened this Issue Dec 20, 2012 · 62 comments

Comments

@macsux

macsux commented Dec 20, 2012

I tried adding dagger to an android eclipse project. dagger-0.9.jar library was added to java build path. Under java compiler annotation processor was enabled, and dagger-compiler-0.9.jar was added as factory path. Consistently get
Internal compiler error: java.lang.NoClassDefFoundError: Could not initialize class dagger.internal.codegen.ProvidesProcessor at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) BuildConfig.java

How about a simple "how-to" on adding dagger support to eclipse - not everyone is using Marven. You guys did a good job explaining how to use the framework but installation instructions suck.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Dec 20, 2012

Collaborator

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.

Collaborator

cgruber commented Dec 20, 2012

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.

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Dec 21, 2012

Collaborator

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.

Collaborator

tbroyer commented Dec 21, 2012

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.

@staxgr

This comment has been minimized.

Show comment
Hide comment
@staxgr

staxgr Jan 3, 2013

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

staxgr commented Jan 3, 2013

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

@macsux

This comment has been minimized.

Show comment
Hide comment
@macsux

macsux Jan 3, 2013

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 notifications@github.comwrote:

@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/square/dagger/issues/126#issuecomment-11837049.

macsux commented Jan 3, 2013

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 notifications@github.comwrote:

@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/square/dagger/issues/126#issuecomment-11837049.

@staxgr

This comment has been minimized.

Show comment
Hide comment
@staxgr

staxgr Jan 8, 2013

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!

staxgr commented Jan 8, 2013

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!

@Steven-Mark-Ford

This comment has been minimized.

Show comment
Hide comment
@Steven-Mark-Ford

Steven-Mark-Ford Jan 14, 2013

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.

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.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Jan 14, 2013

Collaborator

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 notifications@github.com wrote:

I can get code generation working but no compiler errors.


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

Collaborator

cgruber commented Jan 14, 2013

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 notifications@github.com wrote:

I can get code generation working but no compiler errors.


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

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Jan 14, 2013

Collaborator

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 cgruber@google.com 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 notifications@github.com wrote:

I can get code generation working but no compiler errors.


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

Collaborator

cgruber commented Jan 14, 2013

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 cgruber@google.com 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 notifications@github.com wrote:

I can get code generation working but no compiler errors.


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

@Steven-Mark-Ford

This comment has been minimized.

Show comment
Hide comment
@Steven-Mark-Ford

Steven-Mark-Ford Jan 14, 2013

@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?

@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?

@staxgr

This comment has been minimized.

Show comment
Hide comment
@staxgr

staxgr Jan 14, 2013

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
notifications@github.comwrote:

@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/square/dagger/issues/126#issuecomment-12219258.

staxgr commented Jan 14, 2013

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
notifications@github.comwrote:

@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/square/dagger/issues/126#issuecomment-12219258.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Jan 14, 2013

Collaborator

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 notifications@github.com 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/square/dagger/issues/126#issuecomment-12219258.

Collaborator

cgruber commented Jan 14, 2013

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 notifications@github.com 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/square/dagger/issues/126#issuecomment-12219258.

@Steven-Mark-Ford

This comment has been minimized.

Show comment
Hide comment
@Steven-Mark-Ford

Steven-Mark-Ford Jan 15, 2013

@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?

@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?

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Jan 15, 2013

Collaborator

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

Collaborator

cgruber commented Jan 15, 2013

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

@Steven-Mark-Ford

This comment has been minimized.

Show comment
Hide comment
@Steven-Mark-Ford

Steven-Mark-Ford Jan 16, 2013

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

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

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Jan 21, 2013

Collaborator

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 notifications@github.com 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/square/dagger/issues/126#issuecomment-12313982.

Collaborator

cgruber commented Jan 21, 2013

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 notifications@github.com 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/square/dagger/issues/126#issuecomment-12313982.

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Jan 21, 2013

Collaborator

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

Collaborator

tbroyer commented Jan 21, 2013

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

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Jan 22, 2013

Collaborator

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.

Collaborator

cgruber commented Jan 22, 2013

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.

@Steven-Mark-Ford

This comment has been minimized.

Show comment
Hide comment
@Steven-Mark-Ford

Steven-Mark-Ford Jan 23, 2013

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

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

@arichiardi

This comment has been minimized.

Show comment
Hide comment
@arichiardi

arichiardi Feb 12, 2013

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.

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.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Feb 12, 2013

Collaborator

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)

Collaborator

cgruber commented Feb 12, 2013

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)

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Feb 12, 2013

Collaborator

@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…)

Collaborator

tbroyer commented Feb 12, 2013

@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…)

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Feb 12, 2013

Collaborator

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.

Collaborator

cgruber commented Feb 12, 2013

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.

@arichiardi

This comment has been minimized.

Show comment
Hide comment
@arichiardi

arichiardi Feb 12, 2013

@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...

@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...

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Feb 12, 2013

Collaborator

Add the generated sources jar as a source folder manually.

Collaborator

cgruber commented Feb 12, 2013

Add the generated sources jar as a source folder manually.

@pforhan pforhan closed this Feb 12, 2013

@pforhan pforhan reopened this Feb 12, 2013

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Feb 12, 2013

Collaborator

@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.

Collaborator

tbroyer commented Feb 12, 2013

@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.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Feb 12, 2013

Collaborator

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

Collaborator

cgruber commented Feb 12, 2013

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

@arichiardi

This comment has been minimized.

Show comment
Hide comment
@arichiardi

arichiardi Feb 13, 2013

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!

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!

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Feb 13, 2013

Collaborator

@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).

Collaborator

tbroyer commented Feb 13, 2013

@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).

@arichiardi

This comment has been minimized.

Show comment
Hide comment
@arichiardi

arichiardi Feb 13, 2013

@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.

@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.

@arichiardi

This comment has been minimized.

Show comment
Hide comment
@arichiardi

arichiardi Feb 13, 2013

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.

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.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Feb 13, 2013

Collaborator

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

Collaborator

cgruber commented Feb 13, 2013

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

@arichiardi

This comment has been minimized.

Show comment
Hide comment
@arichiardi

arichiardi Feb 13, 2013

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.

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.

@Steven-Mark-Ford

This comment has been minimized.

Show comment
Hide comment
@Steven-Mark-Ford

Steven-Mark-Ford Feb 14, 2013

@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.

@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.

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Feb 14, 2013

Collaborator

@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)

Collaborator

tbroyer commented Feb 14, 2013

@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)

@Steven-Mark-Ford

This comment has been minimized.

Show comment
Hide comment
@Steven-Mark-Ford

Steven-Mark-Ford Feb 14, 2013

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

On Thu, Feb 14, 2013 at 4:02 PM, Thomas Broyer notifications@github.comwrote:

@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/square/dagger/issues/126#issuecomment-13550413.

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

On Thu, Feb 14, 2013 at 4:02 PM, Thomas Broyer notifications@github.comwrote:

@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/square/dagger/issues/126#issuecomment-13550413.

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Feb 14, 2013

Collaborator

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

Collaborator

tbroyer commented Feb 14, 2013

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

@Steven-Mark-Ford

This comment has been minimized.

Show comment
Hide comment
@Steven-Mark-Ford

Steven-Mark-Ford Feb 14, 2013

@tbroyer Thanks. That would be the issue then.

On Thu, Feb 14, 2013 at 4:11 PM, Thomas Broyer notifications@github.comwrote:

@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/square/dagger/issues/126#issuecomment-13550788.

@tbroyer Thanks. That would be the issue then.

On Thu, Feb 14, 2013 at 4:11 PM, Thomas Broyer notifications@github.comwrote:

@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/square/dagger/issues/126#issuecomment-13550788.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Feb 14, 2013

Collaborator

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.

Collaborator

cgruber commented Feb 14, 2013

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.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Feb 14, 2013

Collaborator

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.

Collaborator

cgruber commented Feb 14, 2013

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.

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Feb 14, 2013

Collaborator

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.

Collaborator

tbroyer commented Feb 14, 2013

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.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Feb 14, 2013

Collaborator

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

Collaborator

cgruber commented Feb 14, 2013

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

@adennie

This comment has been minimized.

Show comment
Hide comment
@adennie

adennie Feb 20, 2013

Contributor

@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>
Contributor

adennie commented Feb 20, 2013

@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>
@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Feb 20, 2013

Collaborator

@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)

Collaborator

tbroyer commented Feb 20, 2013

@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)

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Feb 20, 2013

Collaborator

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.

Collaborator

cgruber commented Feb 20, 2013

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.

@adennie

This comment has been minimized.

Show comment
Hide comment
@adennie

adennie Feb 20, 2013

Contributor

@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?

Contributor

adennie commented Feb 20, 2013

@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?

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Feb 20, 2013

Collaborator

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.

Collaborator

cgruber commented Feb 20, 2013

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.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Aug 7, 2013

Collaborator

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.

Collaborator

cgruber commented Aug 7, 2013

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.

@adriancole

This comment has been minimized.

Show comment
Hide comment
@adriancole

adriancole Aug 7, 2013

Contributor

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

On Wed, Aug 7, 2013 at 12:12 PM, Christian Edward Gruber <
notifications@github.com> 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/square/dagger/issues/126#issuecomment-22262930
.

Contributor

adriancole commented Aug 7, 2013

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

On Wed, Aug 7, 2013 at 12:12 PM, Christian Edward Gruber <
notifications@github.com> 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/square/dagger/issues/126#issuecomment-22262930
.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Aug 9, 2013

Collaborator

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.

Collaborator

cgruber commented Aug 9, 2013

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.

@JakeWharton

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Aug 9, 2013

Collaborator

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

Collaborator

JakeWharton commented Aug 9, 2013

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

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Aug 9, 2013

Collaborator

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

Collaborator

cgruber commented Aug 9, 2013

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

@JakeWharton

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Aug 9, 2013

Collaborator

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" notifications@github.com
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/square/dagger/issues/126#issuecomment-22371488
.

Collaborator

JakeWharton commented Aug 9, 2013

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" notifications@github.com
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/square/dagger/issues/126#issuecomment-22371488
.

@adriancole

This comment has been minimized.

Show comment
Hide comment
@adriancole

adriancole Aug 9, 2013

Contributor

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/square/dagger/issues/126#issuecomment-22370880
.

Contributor

adriancole commented Aug 9, 2013

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/square/dagger/issues/126#issuecomment-22370880
.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Aug 9, 2013

Collaborator

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.

Collaborator

cgruber commented Aug 9, 2013

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.

@adriancole

This comment has been minimized.

Show comment
Hide comment
@adriancole

adriancole Aug 9, 2013

Contributor

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/square/dagger/issues/126#issuecomment-22393851
.

Contributor

adriancole commented Aug 9, 2013

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/square/dagger/issues/126#issuecomment-22393851
.

@adriancole

This comment has been minimized.

Show comment
Hide comment
@adriancole

adriancole Aug 9, 2013

Contributor

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/square/dagger/issues/126#issuecomment-22393851
.

Contributor

adriancole commented Aug 9, 2013

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/square/dagger/issues/126#issuecomment-22393851
.

@adriancole

This comment has been minimized.

Show comment
Hide comment
@adriancole

adriancole Aug 19, 2013

Contributor

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 adrian.f.cole@gmail.comwrote:

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/square/dagger/issues/126#issuecomment-22393851
.

Contributor

adriancole commented Aug 19, 2013

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 adrian.f.cole@gmail.comwrote:

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/square/dagger/issues/126#issuecomment-22393851
.

@stephenh

This comment has been minimized.

Show comment
Hide comment
@stephenh

stephenh Oct 1, 2014

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.

stephenh commented Oct 1, 2014

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.

@gk5885

This comment has been minimized.

Show comment
Hide comment
@gk5885

gk5885 Oct 2, 2014

Contributor

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…

Contributor

gk5885 commented Oct 2, 2014

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…

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Oct 2, 2014

Collaborator

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 notifications@github.com 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).

Collaborator

cgruber commented Oct 2, 2014

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 notifications@github.com 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).

@stephenh

This comment has been minimized.

Show comment
Hide comment
@stephenh

stephenh Oct 2, 2014

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.

stephenh commented Oct 2, 2014

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.

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Oct 2, 2014

Collaborator

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 notifications@github.com
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).

Collaborator

cgruber commented Oct 2, 2014

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 notifications@github.com
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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment