Google-Guice support

[GoogleCodeExporter]

Check for google-guice @Inject in classpath.

If present create a custom Provider implementation, and ad an @ProvidedBy 
annotation to the QueryBuilder.

This will ease instance/provider injection.

Obviously there would need to be a binding for the Objectify object in your 
module (i.e. something that called the ofy() method).  

Original issue reported on code.google.com by james.ta...@jrtechnical.com on 1 Jun 2011 at 9:50

[GoogleCodeExporter]

I've fiddled around with this, and think there's a better way to do it.

All your processor would need to do is add the @Inject to the constructor if 
it's on the class path.  

A separate processor could be used create a custom Provider / Module that would 
auto-wire Queries based on annotations.

I've attached a patch.  It adds no dependency on Guice (all reflection via 
Strings).

Original comment by james.ta...@jrtechnical.com on 1 Jun 2011 at 6:24

Attachments:

• Add_Guice_support_byadding@Inject_annotation_to_constructor.patch

[GoogleCodeExporter]

Original comment by bren...@doherty.net.nz on 18 Aug 2011 at 4:00

• Changed state: Accepted

[GoogleCodeExporter]

I've updated the patch to accomodate @javax.inject.Inject as well.

Original comment by james.ta...@jrtechnical.com on 4 Oct 2011 at 3:07

Attachments:

• Combined_Patch_with_javax_inject1.patch

[GoogleCodeExporter]

Hi James, I tried applying your latest patch, but it wouldn't apply 
automatically. I guess I've made some changes since then. 

I've reimplemented your changes, but was having a problem where using either 
env.getElementUtils().getTypeElement("com.google.inject.Inject") or 
Class.forName("com.google.inject.Inject") detect guice when running the tests, 
but I don't have guice in the test environment.

I get this error.  Any ideas?
[ERROR] 
\...\workspace\objectify-query\target\generated-sources\apt-test\com\example\Car
Query.java:[13
,24] package com.google.inject does not exist

Original comment by bren...@doherty.net.nz on 5 Dec 2011 at 7:28

Attachments:

• Issue_9.patch

[GoogleCodeExporter]

Brendan,
Pretty sure this is because you upgraded to Maven 3.0.  One of the new 
"features" is that guice is used internally for dependency injection.  This 
means guice is going to show up on the classpath.

Not sure how to fix this.

Pretty sure we will need a custom ClassLoader that figures out if we're running 
within Maven, and then get's the actual classpath somehow.  There's got to be a 
way to do this - I'm just not sure how.

Original comment by james.ta...@jrtechnical.com on 13 Dec 2011 at 6:28

[GoogleCodeExporter]

sisu-guice appears as a dependency of the maven-processor-plugin.
I'm sure that's part of the issue.

Original comment by james.ta...@jrtechnical.com on 13 Dec 2011 at 6:40

[GoogleCodeExporter]

Brendan,
I've confirmed it's either the fault of the processor-plugin, or Maven 3.0 in 
general.
The classloader used during compilation is actually a Maven "classrealm" 
classloader (a classrealm is a subset of a classworld).  I've gotten ahold of 
the classrealm, and played around with that API (zero documentation), but as of 
yet haven't figured out how to do this. 

It might be easier to pass in a processor property (It's available via the 
processenvironment I think).  Unfortunately, I'm pretty sure I read somewhere 
that that has some serious limitations as well (the jdk6 apt compiler only 
recognizes the first property passed - if I'm remembering correctly).

Original comment by james.ta...@jrtechnical.com on 14 Dec 2011 at 2:19

[GoogleCodeExporter]

Also -
I suspect this actually is the fault of the plugin doing something wrong.  It's 
obvious the compiler plugin isn't being provided the extraneous dependencies.

Maybe try using the compiler plugin? (That's a buggy solution - I know - but 
just get confirmation on the issue).

There's also the apt-plugin, but that didn't seem to pick up the processor at 
all.

Original comment by james.ta...@jrtechnical.com on 14 Dec 2011 at 2:23