Just starting, running into issues, seriously confused

[bdleitner80]

Querydsl looked like a good substitute for Criteria queries, which weren't supporting (nicely) everything I needed.  In addition, I'm stuck with hibernate 3.3 / entitymanager 3.4 due to compatibility issues, and I was running into the alias-in-where clause issue.

In any case, after some effort, I was able to generate the model classes.

I'm using GWT for my application, and had to keep them separate from classes I'd use on the server side, so, since I had some embeddable classes, I moved the corresponding Q* classes elsewhere.

But then, when I tried to rebuild I got a bunch of errors of the form:

Error: : Attempt to recreate a file for type com.jnd.jnddb.model.QContact

But I noticed that the error messages were still the same even after I'd moved the classes to a different package.

I got one of these for every class involved, both embeddable and not.  So then I decided to see what was causing this (I'm using IntelliJ, and the internal build did not give me a stacktrace for the error)

So, I removed all of the Q* classes form the project and I removed the library dependency from my module dependencies in IntelliJ.  I was then able to build.

I then added back in the library, which has the following

classes:

/home/.../querydsl-jpa-2.3.3/lib/all

/home/.../querydsl-jpa-2.3.3/lib/apt

sources

/home/.../querydsl-jpa-2.3.3/src/querydsl-core-2.3.3-sources.jar

/home/.../querydsl-jpa-2.3.3/src/querydsl-jpl-2.3.3-sources.jar

I did NOT re-add the Q* classes.  But the rebuild gives me the same error.

It seems that merely adding this dependency to my IJ project is causing it to try and recreate files, which means I'm completely blocked.

Please advise.

-Ben

[Timo Westkämper]

Hi.

On Fri, Mar 30, 2012 at 12:32 AM, bdleitner80 <bdlei...@gmail.com> wrote:

Querydsl looked like a good substitute for Criteria queries, which weren't supporting (nicely) everything I needed.  In addition, I'm stuck with hibernate 3.3 / entitymanager 3.4 due to compatibility issues, and I was running into the alias-in-where clause issue.

Which Querydsl version are you using now? This should be fixed in the latest Querydsl version and was caused by a bug in Hibernate.
 

In any case, after some effort, I was able to generate the model classes.

I'm using GWT for my application, and had to keep them separate from classes I'd use on the server side, so, since I had some embeddable classes, I moved the corresponding Q* classes elsewhere.

But then, when I tried to rebuild I got a bunch of errors of the form:

Error: : Attempt to recreate a file for type com.jnd.jnddb.model.QContact

How does your build look like in more detail? This sounds like the Q files are already available and you try to recreate them.
 

But I noticed that the error messages were still the same even after I'd moved the classes to a different package.

I got one of these for every class involved, both embeddable and not.  So then I decided to see what was causing this (I'm using IntelliJ, and the internal build did not give me a stacktrace for the error)

So, I removed all of the Q* classes form the project and I removed the library dependency from my module dependencies in IntelliJ.  I was then able to build.

I then added back in the library, which has the following

classes:

/home/.../querydsl-jpa-2.3.3/lib/all

/home/.../querydsl-jpa-2.3.3/lib/apt

sources

/home/.../querydsl-jpa-2.3.3/src/querydsl-core-2.3.3-sources.jar

/home/.../querydsl-jpa-2.3.3/src/querydsl-jpl-2.3.3-sources.jar

I did NOT re-add the Q* classes.  But the rebuild gives me the same error.

It seems that merely adding this dependency to my IJ project is causing it to try and recreate files, which means I'm completely blocked.

The /home/.../querydsl-jpa-2.3.3/lib/apt dependencies are used for code generation, so simply adding them will create the files. Yes.

I will see if this is not properly documented in the reference docs.

Timo
 

Please advise.

-Ben

--
Timo Westkämper
Mysema Oy
+358 (0)40 591 2172
www.mysema.com

[bdleitner80]

I'm using version 2.3.3

Yes, I had APT included and that was the issue.

My project uses GWT and some of the classes that generate the model classes are used on the client side, so I ended up moving all of the generated code to a different package after using an ant target to generate the Q* classes in advance.

Without the APT dependency, I no longer get that error message.  Now I get an entirely new one (which shows up both with the Q* classes moved and if I leave them in their original generated locations)

The full build from within IntelliJ didn't tell me much, but when I tried to compile a single class, I got the error included below.  I've included the source of the underlying class and its generated Q class.  I see the same error for all the ones I've tried:

... various errors on classes package that can't be found (which is odd because they are all easily verified to be available and without the Q* classes everything compiles fine)

methods when(com.mysema.query.types.Expression<? extends T>) from com.mysema.query.types.expr.SimpleExpression<BasicContactInfo> and when(T) from com.mysema.query.types.path.BeanPath<BasicContactInfo> are inherited with the same signature

... some more cannot find symbols.

[Timo Westkämper]

Hi.

Could you post the exact error messages?

Timo

[Benjamin Leitner]

Ok, I am now very very confused.  I had removed the classes from my project, so in order to regenerate the error messages I had to re-add them.  Here is an account of what i just did:

I used an ant build target to regenerate the classes.

I noticed that an additional file was generated: com/jnd/jnddb/model/package-info.class, but this com directory was NOT put under src, whereas all of the rest of the classes were in their proper locations.  I'm not very experienced with Ant (I usually just use IntelliJ's internal build tools).  I'm attaching my ant xml file, which I created by using IJ's feature to generate an ant build and removing all of the existing targets and replacing them with a build target containing the javac command as shown in the getting starting documentation.

I then tried, as before, to compile the single file QBasicContactInfo.java.  It again failed, but did not complain about methods being inherited with the same signature.  Instead, it only reported that it couldn't find the symbols:

QMessage, QAddress.  QAddress is in the same package as QBasicContactInfo.  QMessage is in another package with Message, which is a superclass of BasicContactInfo.

I then tried to build just QMessage, and it worked.

I then went back to build QAddress, and that worked, and then QBasicContactInfo worked.

I then tried to rebuild the whole project, but I got "cannot find symbol" errors for just about all the classes for which Q* is generated.  I'm sorry I don't have the exact list, IJ doesn't let me copy from the message window except one line at a time.

I then deleted all of the generated classes and rebuilt.  Everything built just fine.

I then re-generated the classes and tried to rebuild just QBasicContactInfo.java again, and this time it worked!

I tried several other of the Q* classes and they all worked.

So then I tried one more time to rebuild the entire project.  The whole build failed with the error:

Compiler internal error. Process terminated with exit code 1

and then there were error messages for specific classes, all under my testing directory:

package com.jnd.jnddb.client.service does not exist

package com.jnd.jnddb.shared does not exist (several times)

cannot find symbol (every in these packages)

I tried deleted the testing directory (temporarily, just for diagnostics) and tried again.  This time I just got the message:

Compiler internal error. Process terminated with exit code 1

So I went back and tried to compile just the QBasicContactInfo class, which had worked before, and now I got:

cannot find symbol class BasicContactInfo

package com.bdl.message.base does not exist

cannot find symbol class QAddress
cannot find symbol class BasicContactInfo

methods when(com.mysema.query.types.Expression<? extends T>) from com.mysema.query.types.expr.SimpleExpression<BasicContactInfo> and when(T) from com.mysema.query.types.path.BeanPath<BasicContactInfo> are inherited with the same signature

package com.bdl.message.base does not exist

cannot find symbol class BasicContactInfo

cannot find symbol class BasicContactInfo

cannot find symbol class QAddress

So... for a hypothesis:

When trying to build the Q* classes the compiler is looking for the compiled versions of the classes on which it depends.  this seems mostly consistent.  After a fresh rebuild and the generation of the new classes, I can compile them individually, since the compiled classes for everything else exists, and compiling one class does not clean up the output directory.  But as soon as I try to rebuild the entire project, the output directory is cleaned and then the compiled output is not there when the Q* classes are reached for compilation.

I don't know why it would behave like this, or even if that hypothesis is correct.  All I really know for certain is that these generated classes are not behaving like normal classes with respect to the compiler, and thus they are basically unusable.  So far, it's simpler just to hand-type the sql for the queries.

[Timo Westkämper]

Hi.

On Tue, Apr 3, 2012 at 9:12 PM, Benjamin Leitner <bdlei...@gmail.com> wrote:

Ok, I am now very very confused.  I had removed the classes from my project, so in order to regenerate the error messages I had to re-add them.  Here is an account of what i just did:

I used an ant build target to regenerate the classes.

Do you generate the Q-classes directly into the source directory? From the Ant config it looks like that.

Keep the static and generated sources always separate.

 

I noticed that an additional file was generated: com/jnd/jnddb/model/package-info.class, but this com directory was NOT put under src, whereas all of the rest of the classes were in their proper locations.  I'm not very experienced with Ant (I usually just use IntelliJ's internal build tools).

That's an Ant curiosity, but I don't remember anymore why they do it. I use exclusively Maven.

 

I understand your frustration, but where did you pick up this kind of APT configuration for Ant? The Querydsl reference docs have sections on Ant configuration.


 

[Timo Westkämper]

Hi.

Concerning the following part

<target name="build querydsl files">
<javac classpathref="jnddb.module.classpath">
  <src>
    <path refid="jnddb.module.sourcepath"/>
  </src>
  <compilerarg value="-proc:only"/>
  <compilerarg value="-processor"/>
  <compilerarg value="com.mysema.query.apt.jpa.JPAAnnotationProcessor"/>
  <compilerarg value="-s"/>
  <compilerarg value="${module.jnddb.basedir}/src"/>
</javac>
</target>

Replace this part

  <compilerarg value="-s"/>
  <compilerarg value="${module.jnddb.basedir}/src"/>

with

  <compilerarg value="-s"/>
  <compilerarg value="${module.jnddb.basedir}/generated"/>

or something similar

In Maven for example you have

src/main/java - for main Java sources
src/test/java - for test Java soruces
target/generated-sources/java - for generated main sources
target/generated-test-sources/java - for generated test soruces

[Benjamin Leitner]

Responses inline

On Tue, Apr 3, 2012 at 11:24 AM, Timo Westkämper <timo.we...@mysema.com> wrote:

Hi.

On Tue, Apr 3, 2012 at 9:12 PM, Benjamin Leitner <bdlei...@gmail.com> wrote:

Ok, I am now very very confused.  I had removed the classes from my project, so in order to regenerate the error messages I had to re-add them.  Here is an account of what i just did:

I used an ant build target to regenerate the classes.

Do you generate the Q-classes directly into the source directory? From the Ant config it looks like that.

Keep the static and generated sources always separate.

So it seems like my thoughts are correct.  The entity classes for my DB are only "static" in the sense that I do not foresee them changing much from here on out.  The nature of the project is such that I cannot have code generated on the fly at compile time, at least not in certain packages (this is due to restrictions in GWT).  There doesn't seem to be a way to control where all of the generated classes go when I run an ant target.  I gave it my source root and each Q[Foo] went to the same package as the corresponding [Foo].

So

I really don't know anything about APT, and I suspect that's where I'm being tripped up.  When I tried to use an ant target just copying off the website:

<!-- APT based code generation -->    <javac srcdir="${src}" classpathref="cp">

<compilerarg value="-proc:only"/>           <compilerarg value="-processor"/>      <compilerarg value="com.mysema.query.apt.jpa.JPAAnnotationProcessor"/>      <compilerarg value="-s"/>

<compilerarg value="${generated}"/>    </javac>          <!-- compilation -->    <javac classpathref="cp" destdir="${build}">           <src path="${src}"/>      <src path="${generated}"/>    </javac> I ran into trouble with the classpath, so I used IJ to generate an ant file that would have all fo the classpath information in it.  The compiler arguments I used are precisely these.  I also only used the ant target to generate the classes.  I am not using ant at all when I try to build. So, what I actually need is a way to generate the Q* classes as a one-off operation.  Thereafter, I want to be able to move them around like normal classes. I got your next message as well, I'll give it a try but I'm wary of it, since there are restrictions to what classes I can reference in the com.jnd.jnddb.shared package.

[Benjamin Leitner]

I tried this and then tried rebuilding everything.  I got the same:

Compiler internal error. Process terminated with exit code 1

and then errors in my testing classes.

Trying to compile the single QBasicContactInfo.java class gave me the same error as before.

I even tried commenting out the @Generated annotation on all the classes and got the same error.

This is what I don't understand.  Why after I generate these sources and then try to build my project to these source files behave differently than other ones, even after I remove the annotation?

[Timo Westkämper]

Hi.

On Tue, Apr 3, 2012 at 9:40 PM, Benjamin Leitner <bdlei...@gmail.com> wrote:

Responses inline

On Tue, Apr 3, 2012 at 11:24 AM, Timo Westkämper <timo.we...@mysema.com> wrote:

Hi.

On Tue, Apr 3, 2012 at 9:12 PM, Benjamin Leitner <bdlei...@gmail.com> wrote:

Ok, I am now very very confused.  I had removed the classes from my project, so in order to regenerate the error messages I had to re-add them.  Here is an account of what i just did:

I used an ant build target to regenerate the classes.

Do you generate the Q-classes directly into the source directory? From the Ant config it looks like that.

Keep the static and generated sources always separate.

So it seems like my thoughts are correct.  The entity classes for my DB are only "static" in the sense that I do not foresee them changing much from here on out.  The nature of the project is such that I cannot have code generated on the fly at compile time, at least not in certain packages (this is due to restrictions in GWT).

But still you have a code generation task in your build? Is it part of the normal build or do you trigger it manually? Maybe the manual triggering might be a solution for you?
 

 There doesn't seem to be a way to control where all of the generated classes go when I run an ant target.  I gave it my source root and each Q[Foo] went to the same package as the corresponding [Foo].

Well, I just think this is an invitation for trouble. And I don't thing GWT has such a restriction.
 

Just use a detached ant target. But I'd still use a different folder than the main sources.
 

I got your next message as well, I'll give it a try but I'm wary of it, since there are restrictions to what classes I can reference in the com.jnd.jnddb.shared package.

Also if you are using GWT you probably don't want your Q-classes be handled by GWT. At least it doesn't make much sense.

You have some control over the target package of the Q-classes via the APT options mentioned here :

http://www.querydsl.com/static/querydsl/2.3.3/reference/html/ch03s02.html#d0e1402


I agree that APT can be a bit confusing in the beginning since it does code generation in the build phase. Normally this happens before.
 

[Benjamin Leitner]

On Tue, Apr 3, 2012 at 11:56 AM, Timo Westkämper <timo.we...@mysema.com> wrote:

Hi.

On Tue, Apr 3, 2012 at 9:40 PM, Benjamin Leitner <bdlei...@gmail.com> wrote:

Responses inline

On Tue, Apr 3, 2012 at 11:24 AM, Timo Westkämper <timo.we...@mysema.com> wrote:

Hi.

On Tue, Apr 3, 2012 at 9:12 PM, Benjamin Leitner <bdlei...@gmail.com> wrote:

Ok, I am now very very confused.  I had removed the classes from my project, so in order to regenerate the error messages I had to re-add them.  Here is an account of what i just did:

I used an ant build target to regenerate the classes.

Do you generate the Q-classes directly into the source directory? From the Ant config it looks like that.

Keep the static and generated sources always separate.

So it seems like my thoughts are correct.  The entity classes for my DB are only "static" in the sense that I do not foresee them changing much from here on out.  The nature of the project is such that I cannot have code generated on the fly at compile time, at least not in certain packages (this is due to restrictions in GWT).

But still you have a code generation task in your build? Is it part of the normal build or do you trigger it manually? Maybe the manual triggering might be a solution for you?

I'm not invoking the ant target directly; I'm just going to Build -> Rebuild Project in the Intellij menu.  But code generation is being invoked anyway.

I tried an experiment.  I have a module dependency on Querydsl in the project.  It includes as classes everything in \...\querydsl-jpa-2.3.3\lib\all 

when I removed it and compiled the output was what I expected.  When I added that dependency back in and did nothing else (not even invoking the ant target) the compilation worked, and I also had

Q* classes in the output.  So, somehow, just including the classes under lib is enough to cause code generation.

 

 

 There doesn't seem to be a way to control where all of the generated classes go when I run an ant target.  I gave it my source root and each Q[Foo] went to the same package as the corresponding [Foo].

Well, I just think this is an invitation for trouble. And I don't thing GWT has such a restriction.

Well, I tried putting the classes under generated instead of src, and I had the same problem.

GWT only allows classes on the client side that depend only on classes present in the JRE emulation library.  I don't know what all the dependencies of Querydsl are.  it may be that they are all compatible.

[Timo Westkämper]

Hi.

You should separate the lib content needed for compilation from the lib content needed for APT. Otherwise you will have unwanted code generation.

APT can be triggered via explicit javac invocation with a certain configuration but also with APT service descriptors which are included in the jars.

Maybe you have both now activated.

Br,
Timo

[Benjamin Leitner]

Filtering out some of the dependencies seems to have stopped the errors.  I'll restart this thread if I run into further trouble, but for now things seem stable.

thanks for all your help!