Q-Type for @Embeddable in foreigen package is not created

[Michael Glauche]

Hi,
   i'm having a problem with APT and entites in different packages. We use a "base" entity which has an @Embedded Field for statistical data. That class is also annotated with @Embeddable and working fine in plain JPA.

Now, when i run maven-apt-plugin on the current project the "base" entity is found and has a matching Q-Class, but it gives an compile error because the Q-Class for the @Embeddable class is missing.

If i copy the source of that @Embeddable class into my current project everything is fine.

Do i need to put the apt-plugin also in the referenced package with the "base" entity ? Or is it possible that the querydsl processor will create all neccessary metatdata ? (Which would be prefered, because sometimes the entity you are refering to is out of your scope)

[Timo Westkämper (timo-westkamper)]

It is difficult to support both modes. I will see if it is possible to enable this easily via an APT option.

[Timo Westkämper (timo-westkamper)]

Are you still having the issue? I was not able to reproduce it with 2.2.0.beta5

[Timo Westkämper (timo-westkamper)]

Ok, it worked with the Querydsl annotations, but not with the JPA annotations.

I made a fix which only requires that you annotate usage of external embeddables with @Embedded on the property.

Could you verify the fix with SVN trunk?

[Timo Westkämper (timo-westkamper)]

Released in 2.2.0

[Werner Willms (w-willms)]

Hi,

on our project we're currently seeing the same issue, QueryDSL version 3.3.2, apt-maven-plugin version 1.1.1, spring 4.0.3.RELEASE, spring data version 1.5.2.RELEASE. The maven project build is just fine and works like a charm until the Q-Types have to be created during generate sources phase:

[...]
symbol: class QProductInfoId
  location: package com....common.uuid
.../trunk/backend/app/target/generated-sources/com/.../backend/app/entities/partners/QPartner.java:32: error: cannot find symbol
    public final com...backend.common.uuid.QPartnerId partnerId;
[...]

We've checked against version 2.2.0 which apparently has fixed the issue. Then, we've tried various versions of QueryDSL and found that version 2.2.4 is the one that does not cause the issue. So, maybe the bug was re-introduced in version 2.2.5?