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

Separate artifacts used at build time from those used at runtime #374

matthewadams opened this issue Mar 26, 2013 · 1 comment

Separate artifacts used at build time from those used at runtime #374

matthewadams opened this issue Mar 26, 2013 · 1 comment


Copy link

@matthewadams matthewadams commented Mar 26, 2013

IMHO, it would be clearer from a user's perspective if all querydsl modules were consistent in their composition. Each persistence technology-specific module (querydsl-jpa, querydsl-mongodb, etc) should have separate build-time versus runtime artifacts, and the runtime artifacts should depend on the build-time ones with a scope of provided.

As of the latest release, querydsl-mongodb includes the MorphiaAnnotationProcessor within the runtime artifact, which is unused at runtime. Further, other technologies' annotation processors are found not in their runtime artifacts (which would also be unnecessary), but in querydsl-apt itself.

I would consider it cleaner and more consistent to remove all concrete annotation processors from the querydsl-apt artifact and place them in their own, technology-specific artifacts used only at build-time. This would serve to decouple the artifact with the abstract annotation processor from its subclasses.

Since the proposed solution above may be overkill, what with some artifacts containing only a single class, another solution that would be understandable is to put all annotation processors in the querydsl-apt artifact, which may consist only of moving querydsl-mongodb's MorphiaAnnotationProcessor into querydsl-apt, but there may be others.

In any case, making it consistent would be beneficial.

Note: This issue is related to #373.

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

Successfully merging a pull request may close this issue.

None yet
2 participants