hibernate-search HSEARCH-3319 WIP: Type-safe field references v2

https://hibernate.atlassian.net/browse/HSEARCH-3319

May 09 '24 16:05 marko-bekhta

Quality Gate failed

Failed conditions
78.2% Coverage on New Code (required ≥ 80%)

May 22 '24 03:05 sonarqubecloud[bot]

So, in the new commit, I've tried adding a Maven plugin that would generate things. The approach I've taken here is to have model+ search config classes in their own jar that is passed as a dependency to the Maven plugin. The plugin then starts the Search. I've used some of our test helpers to start things since, well, it's just to test how it'll work.

It generates something like:

package org.hibernate.search.metamodel.generator.model;

class MyEntity__ {

	public String text;	
}

package org.hibernate.search.metamodel.generator.model;

class MyProgrammaticEntity__ {

	public String number;
	public String text;	
}

And since it happens on the generate sources phase, these are getting compiled automatically by Maven itself.

As for the plugin configuration:

<configuration>
    <annotatedTypes>
        <type>org.hibernate.search.metamodel.generator.model.MyEntity</type>
        <type>org.hibernate.search.metamodel.generator.model.MyProgrammaticEntity</type>
    </annotatedTypes>
    <properties>
        <hibernate.search.mapping.configurer>org.hibernate.search.metamodel.generator.model.MyConfigurer</hibernate.search.mapping.configurer>
    </properties>
</configuration>

There's a way to pass any properties that should be "forwarded" to the Search through properties. In this case, I've tried passing a configurer to apply some programmatic mapping 🙈.

now.... next thing I'd want to try is to run the plugin in the same module that the model is. From what I've seen so far, it is easy to get the source root, and the dependencies (things that were missing in the AP approach).

May 23 '24 14:05 marko-bekhta

Thanks for your pull request!

This pull request appears to follow the contribution rules.

› This message was automatically generated.

Dec 12 '24 21:12 hibernate-github-bot[bot]

Quality Gate failed

Failed conditions
72.8% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

Feb 12 '25 16:02 sonarqubecloud[bot]

Hey. I'm finally having a look, but first some answers

take care of "various backends". I think that we'd just add all backends (lucene,elasticsearch) and have a config property for the annotation processor to let the user specify the backend to use (or even both).

Backends should be in the user classpath already, no? If you rely on that, you can make the annotation processor work without any configuration for the most common case (only one backend type in the classpath).

the next steps, as I see it, are: [...]

Makes sense.

Except...

deal with the ORM mapper. I don't think that it would be feasible to make ORM somehow generate the model from javax.lang.model.element types

As stated, I agree. But:

We don't need the whole ORM metamodel. Most of the things we do around the Hibernate ORM metamodel in Search are related to dependency resolution, which is pointless when generating Search's static metamodel. We would only need to infer access type, somehow, and that could reasonably be done by getting rid of our current way of doing it and directly applying the JPA spec ourselves instead.
We don't need ORM to do it, we can do it ourselves. It's annoying, but possible.
Perhaps Hibernate Models could help someday.

Critically, this task can even be extracted to a separate issue, and we can ask someone who knows this AccessType stuff to help with a first solution that just implements this stuff directly in Hibernate Search :)