I've actually found a flaw in my suggestion: a scan of all user
provided classes might not be desirable.
For one, someone might have some unintended dependencies which happen
to include such an @AnalyzerDef, which could conflict with some
definition name being used elsewhere and this is not always easy to
Ok that might be far fetched, but there is a stronger use case:
some applications use multiple entity sets, mixing them in various
Persistence Units. Those users typically rely on the configuration
capabilities of JPA / Hibernate to disable annotation scanning and
list entities explicitly, jars explicitly, packages, etc..
When relying on @MappedSuperClass or other *known* entities, we
inherently take advantage of these isolation features to nicely build
just what is expected and no more; if we where to scan all user
classpath without these restrictions, the user wouldn't have an option
to specify some kind of filtering when needed.
Assuming we don't want to be too coupled to ORM - Search integrates
with more - then we need an alternative filtering option, and we would
need to reimplement such logic.
Guillaume, could you clarify the use case once more? I am assuming it
was all about a cleaner code organization; in that case wouldn't it be
enough to specify a single class to be scanned for the global analyzer
On 21 June 2013 10:33, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On 21 Jan 2013, at 12:17 AM, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
> Hi Sanne,
> On Thu, Jun 20, 2013 at 6:45 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>> Great, so maybe we should just do that.
> Yep, looks like a good idea and would be far cleaner.
+1 once we use Jandex we can fore sure do that.
On the other hand, you are saying that you are using Hibernate Search which means that
you have at last one @Indexed class. Why not add the definitions there? Would that not be
logical place anyways?
Another thought, I wonder whether you could use the programmatic API to just define the
definition on a non indexed entity?