EntityScanPackages has package-private constructor

[riba2101]

Hello,

is there a reason why EntityScanPackages has a package-private constructor?
The whole thing about entity scanning is extensible, but the class is "hindering" this?

BR

[snicoll]

What are you trying to achieve and why do you think you should be creating your own instance of EntityScanPackages?

[riba2101]

Hi,

well, a lib that has entities and with this the consumer of a lib would not need to always use @EntityScan("{their package}", "{lib package}")

[riba2101]

Btw after a bit of looking into it, it would be super nice to be able to merge annotations like EnableJpaRepositories?

[wilkinsona]

It sounds like using @AutoConfigurationPackage may do what you want. It's not yet very well documented so please see #27549 for some more details.

[riba2101]

I'm not quite sure if @AutoConfigurationPackageis intended for this. (and the lack of the docs is just baffling)
Let's say you are writing an auditing lib.
Let's say that you want to support and use various already existing integrations from spring as a basis (spring-data-jpa as one provider, spring-data-elastic as another etc)

The lib itself knows where the configurations are so it would make sense to configure the defaults for it because those will be used in 98% of the cases.

what im proposing is to have @Repeatable or some other type of merge on all @Enable... annotations.

what is happening here is that:
there are 3 projects and all have their own custom @Enable annotations:

• rmi lib(the name is misleading - ignore i,t it's not important)
• storage lib
• storage audit lib

The following is the setup(sry, code example would be too big and complex):

• Component scan happens in rmi -> so autoconfiguration helps here, the stack starts, where to scan etc
• Storage lib bootstraps based on selected impl (or multiple) the whole, for example, JPA stack (there are custom things like QueryDSL extensions etc). Among other things it has out of "convenience" @EnableJpaRepositories on its own @EnableJpa
• storage audit lib also has its own @Enable... annotation and now here we have the problem

I would need another @EnableJpaRepositories for example, but this one gets swallowed.

maybe for visual reference:

JpaAuditTestConfiguration

@SpringBootApplication(scanBasePackages = "test.app.jpa")
@EntityScan(basePackages = {"test.app.jpa"})
@EnableStorageJpa(basePackages = {"test.app.jpa"})
@EnableStorageAuditJpa
public class JpaAuditTestConfiguration {
}

EnableStorageJpa

@EnableTransactionManagement
@EnableJpaRepositories
public @interface EnableCloudStorageJpa {
....
    @AliasFor(annotation = EnableJpaRepositories.class, attribute = "basePackages")
    String[] basePackages();
...
}

EnableStorageAuditJpa

@EnableJpaRepositories
@EnableAspectJAutoProxy
public @interface EnableStorageAuditJpa {
...
    @AliasFor(annotation = EnableJpaRepositories.class, attribute = "basePackages")
    String[] basePackages() default {"lib.storage.audit.provider.jpa"};
...
}

now, yes, i could slam the @EnableJpaRepositories onto a config class, hardcode it and import it...but then you couldn't configure DataSource, TX, etc...if for example, someone would like to keep them somewhere else.

In addition to this problem, there's also @EntityScan who behaves the same - that's probably why you proposed the
@AutoConfigurationPackage @wilkinsona rights?

[philwebb]

I'm not really following the above example I'm afraid, but it won't be possible to make @Enable annotations @Repeatable. I also don't think we want to make the constructor of EntityScanPackages public.

If you want to register additional packages for entity scanning you can use the EntityScanPackages.register static methods.

[riba2101]

This is what I'm doing, but there is no such (easy) thing for repositories. What I'm saying is that for example @EnableJpaRepositories will be scanned multiple times if present on multiple config classes, but won't if present on annotations.

This is java related but still would say a bit inconsistent in spring?