Skip to content
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

Move codegen logic to own modules #106

Closed
timowest opened this issue Feb 29, 2012 · 12 comments
Closed

Move codegen logic to own modules #106

timowest opened this issue Feb 29, 2012 · 12 comments

Comments

@timowest
Copy link
Member

@timowest timowest commented Feb 29, 2012

  • codegen code in querydsl-core -> querydsl-codegen
  • codegen code in querydsl-sql -> querydsl-sql-codegen
  • codegen code in querydsl-jpa -> querydsl-jpa-codegen

The MorphiaAnnotationProcessor could be moved to querydsl-apt.

@matthewadams
Copy link
Contributor

@matthewadams matthewadams commented Mar 19, 2012

Is this issue to essentially separate the runtime components from the compile-time ones?

@timowest
Copy link
Member Author

@timowest timowest commented Mar 19, 2012

Yes

timowest added a commit that referenced this issue Apr 5, 2012
@timowest
Copy link
Member Author

@timowest timowest commented Apr 6, 2012

TODO

  • update querydsl-sql docs
timowest added a commit that referenced this issue Apr 6, 2012
timowest added a commit that referenced this issue Apr 11, 2012
@timowest
Copy link
Member Author

@timowest timowest commented Apr 20, 2012

Released in 2.5.0

@timowest timowest closed this Apr 20, 2012
@matthewadams
Copy link
Contributor

@matthewadams matthewadams commented Apr 20, 2012

Thanks, Timo! Can you please summarize in this issue what you've done? What dependencies are required to be available at runtime now?

@timowest
Copy link
Member Author

@timowest timowest commented Apr 20, 2012

For JPA it would be the following

com.mysema.commons.lang.*;version="${mysema.lang.version}", -> mysema-commons-lang
com.mysema.query.*;version="${project.version}", -> querydsl-core / querydsl-jpa
com.mysema.util.*;version="${project.version}", -> querydsl-core
javax.annotation.*;version="0", -> net.sourceforge.findbugs:jsr305
javax.inject.*;version="0", -> javax.inject
javax.persistence.*;version="[2.0.0,2.1.0)", -> JPA 2.0
javax.xml.stream.*;version="0", -> 
org.hibernate.*;version="${hibernate.version}", -> if Hibernate is used
org.slf4j.*;version="${slf4j.version}" -> slf4j

and in Querydsl Core

com.mysema.commons.lang.*;version="${mysema.lang.version}",
javax.annotation.*;version="0",
javax.inject.*;version="0", 
net.sf.cglib.proxy.*;version="${cglib.version}", -> CGlib (only needed if alias functionality is used)
com.google.common.*;version="${guava.version}" -> Guava

I think the relevant change for you is that codegen was dropped as a runtime dependency

@matthewadams
Copy link
Contributor

@matthewadams matthewadams commented Apr 20, 2012

Ok. I sure wish findbugs wasn't part of the runtime requirements. Package "javax.annotation" is problematic in OSGi. Any way that could be made optional so that those annotations are not part of the generated code so that the user can decide if he wants them at runtime?

@timowest
Copy link
Member Author

@timowest timowest commented Apr 20, 2012

We use this dependency for static analysis. What is problematic with this package? Split-package risks or something like that?

And it's not findbugs that is packaged but a set of standard annotations that are provided via a findbugs module.

@matthewadams
Copy link
Contributor

@matthewadams matthewadams commented Apr 20, 2012

Yes, split package. Package javax.annotation is in some system bundle as
well as findbugs/jsr305. Sucks...

On Fri, Apr 20, 2012 at 11:00 AM, Timo Westkämper <
reply@reply.github.com

wrote:

We use this dependency for static analysis. What is problematic with this
package? Split-package risks or something like that?


Reply to this email directly or view it on GitHub:
#106 (comment)

@matthewadams12
mailto:matthew@matthewadams.me
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12@gmail.com
msn:matthew@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

@matthewadams
Copy link
Contributor

@matthewadams matthewadams commented Apr 20, 2012

...and by "some", I mean rt.jar. I should have said "THE". :)

@timowest
Copy link
Member Author

@timowest timowest commented Apr 21, 2012

Could you open a ticket for the javax.annotation.* annotation removal? I don't see any other option.

Doing post-processing of bytecode to remove the annotations is not worth the effort.

@timowest
Copy link
Member Author

@timowest timowest commented Apr 23, 2012

The jsr305 dependency comes also through Guava, so it is difficult to remove it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants