Reopen of 623696 (NPE)

[Brian Topping]

Okee, got hit with this again, time to make a project that emulates the problem. Was able to get it duplicated after tracing the APT plugin and seeing which classes were getting loaded first.

I wish the attached was a patch, but as I noted in https://bugs.launchpad.net/querydsl/+bug/623696, I am really stuck on how to resolve this. I hope the sample project is enough to get things rolling again though.

If there is anything I can do, please do not hesitate to ask! I'm looking forward to reviewing the patch so I can see what was done... If possible, please note it here! Thanks!!

[Timo Westkämper (timo-westkamper)]

Thanks for the bug report. I was already able to reproduce the problem, now I am gonna fix it.

[Brian Topping (topping)]

Thanks Timo. Apologies for the task insertion...

[Timo Westkämper (timo-westkamper)]

Fixed in SVN trunk. I added initial pre-process loops for basic EntityType creation without supertype handling.

Eventually the APT code might need some more refactorings. Could you verify that your problems went away with this fix?

[Brian Topping (topping)]

Thanks Timo, that indeed fixed the problem I was seeing.

[Brian Topping (topping)]

It turns out this fixed the parsing problem, but is now generating incomplete source. It seems that the class parameterization is not passed down deeper than one or two levels.

I've added another file to the test project here and attached it.

[Timo Westkämper (timo-westkamper)]

I got this issue fixed as well. The class parameters are handled correctly, but the generic contract for createSet, createList and createCollection is not satisfied.

[Brian Topping (topping)]

This is FYI, you may already know this is a problem. Sorry for the extra noise if so...

On r13037, I get the following when trying to instantiate a query type:

java.lang.NoSuchMethodError: com.mysema.query.types.PathMetadata.<init>(Lcom/mysema/query/types/Path;Lcom/mysema/query/types/Expression;Lcom/mysema/query/types/PathType;)V
 at com.mysema.query.types.PathMetadataFactory.forVariable(PathMetadataFactory.java:53)
 at net.mauswerks.pubsite.domain.party.QPerson.<init>(QPerson.java:53)
 at net.mauswerks.pubsite.domain.party.QPerson.<clinit>(QPerson.java:18)

QPerson.java:18 in my build is the "public static final QPerson person = new QPerson("person");" field.

[Timo Westkämper (timo-westkamper)]

The dependencies in your last sample project were problematic. querydsl-jpa and querydsl-apt need to have the same version.

[Brian Topping (topping)]

Indeed, apologies there. I was also missing the source plugin:

            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
            </plugin>

I generally develop in IntelliJ IDEA and was checking classpaths from there so I didn't catch that.

The other problem is really weird. At runtime in my environment, the class name of the second parameter shows up as "c.m.q.t.Expr" (instead of "Expression"). Somehow the name of the class is being mangled. I don't believe it has anything to do with Querydsl, sorry for the noise.

[Timo Westkämper (timo-westkamper)]

Released in 2.0.6