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

Refactor spring-data-couchbase into modules. #1990

Conversation

mikereiche
Copy link
Collaborator

This allows pulling CouchbaseAnnotationProcessor into its own module so that javax.inject is not needed as a dependency for spring-data-couchbase.

Closes #1989.

@mikereiche
Copy link
Collaborator Author

I've started trying to solve the javax.inject dependency from query dsl by reorganizing the spring-data-couchbase project into modules. My immediate question is - should the documentation stay in the top-level (now spring-data-couchbase-parent), should it have it's own module (say - spring-data-couchbase-doc), or should it stay with the code (now spring-data-couchbase module).

#1948

This allows pulling CouchbaseAnnotationProcessor into its own module so
that javax.inject is not needed as a dependency for spring-data-couchbase.

Closes #1989.
@mikereiche mikereiche force-pushed the sdc_1989_reorg_spring-data-couchbase_to_modules_for_querydsl branch from cdb33f1 to 8c9668c Compare October 16, 2024 00:22
@mp911de
Copy link
Member

mp911de commented Oct 16, 2024

I think this is fundamentally the wrong direction and could be solved the way it is handled in MongoDB that also ships an annotation processor.

The root cause are that querydsl-apt:

        <dependency>
            <groupId>com.querydsl</groupId>
            <artifactId>querydsl-apt</artifactId>
            <version>${querydsl}</version>
            <classifier>jakarta</classifier>
            <exclusions>
                <exclusion>
                    <groupId>javax.inject</groupId>
                    <artifactId>javax.inject</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

is declared as a mandatory dependency and that Couchbase ships a javax.annotation.processing.Processor service definition.

In MongoDB, we have the following:

	<dependency>
		<groupId>com.querydsl</groupId>
		<artifactId>querydsl-apt</artifactId>
		<version>${querydsl}</version>
		<scope>provided</scope>
	</dependency>

MongoDB doesn't declare a javax.annotation.processing.Processor service under META-INF/services, instead we require users to define the annotation processor within the compiler.

Going forward, the JDK is going to require a more explicit annotation processor config so it is reasonable to ask users to configure which annotations they want to be applied via the javac --processor option.

Paging @wilkinsona for visibility.

@wilkinsona
Copy link
Member

MongoDB doesn't declare a javax.annotation.processing.Processor service under META-INF/services, instead we require users to define the annotation processor within the compiler.

+1 for this approach. I think I'd dismissed it as an option because of SDC's CouchbaseAnnotationProcessor and had assumed that it would need to reside in a separate module. If that's not the case then Mark's proposal is way less disruptive.

@mikereiche
Copy link
Collaborator Author

Thanks both. This really, really helps. I made a new pull-request with the suggest solution (that is about 100 times easier)

MongoDB doesn't declare a javax.annotation.processing.Processor service under META-INF/services, instead we require users to define the annotation processor within the compiler.

I didn't realize that this is what was triggering the java compiler to call the annotation processors. I thought the only way to avoid calling it was to move it into another jar (module).

@mikereiche mikereiche closed this Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants