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

Comments

Projects
None yet
2 participants
@timowest
Member

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

This comment has been minimized.

Show comment
Hide comment
@matthewadams

matthewadams Mar 19, 2012

Contributor

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

Contributor

matthewadams commented Mar 19, 2012

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

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Mar 19, 2012

Member

Yes

Member

timowest commented Mar 19, 2012

Yes

timowest added a commit that referenced this issue Apr 5, 2012

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Apr 6, 2012

Member

TODO

  • update querydsl-sql docs
Member

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

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Apr 20, 2012

Member

Released in 2.5.0

Member

timowest commented Apr 20, 2012

Released in 2.5.0

@timowest timowest closed this Apr 20, 2012

@matthewadams

This comment has been minimized.

Show comment
Hide comment
@matthewadams

matthewadams Apr 20, 2012

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Apr 20, 2012

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@matthewadams

matthewadams Apr 20, 2012

Contributor

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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Apr 20, 2012

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@matthewadams

matthewadams Apr 20, 2012

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@matthewadams

matthewadams Apr 20, 2012

Contributor

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

Contributor

matthewadams commented Apr 20, 2012

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

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Apr 21, 2012

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Apr 23, 2012

Member

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

Member

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