Refrain from requiring/using @ComponentScan to define a base package for Spring Data repositories

[odrotbohm]

Currently the defaulting of e.g. Spring Data JPA fails if no base package is defined and prints a log message to use @ComponentScan to do so. I'd argue using this annotation to do so is bad style for the following reasons:

• it effectively reuses an annotation with defined semantics and also triggers additional behavior which might not be intended
• If you only want to lookup repositories using the basic @Enable…Repositories annotation as is has the same, but more precise effect
• You might want to configure the component scanning for application components different from the one used for repository discovery. Do the filters potentially registered with @ComponentScan actually get forwarded to the repositories correctly?

Speaking to @jhoeller about this here a few thoughts to optimize the situation:

• couldn't @EnableAutoConfiguration simply take the role of an empty @ComponentScan, meaning the base package is defined by the annotated class.
• couldn't @EnableAutoConfiguration take a base package or a base package class to customize the general base package used by Boot by default.
• additional @ComponentScan annotation would then purely work as expected - picking up annotation based application components
• a manually defined @Enable…Repositories would take over repository configuration, ignoring the auto configuration activated around it

[philwebb]

I originally took the decision to reuse the @ComponentScan annotation since it seemed fairly logical for Spring Boot application. We actually use the annotation not just for Spring Data repositories but also for @Entity scanning. Perhaps we need an alternative annotation that users can add if they want fine grain control.

it effectively reuses an annotation with defined semantics and also triggers additional behavior which might not be intended

This is true, it makes the assumption that if you have a @ComponentScan that might also be a sensible place to look for Spring Data repositories and @Entity classes.

If you only want to lookup repositories using the basic @Enable…Repositories annotation as is has the same, but more precise effect

I am not sure what the existing logic is, but I think if the user adds @Enable…Repositories we should not apply our auto-configuration.

You might want to configure the component scanning for application components different from the one used for repository discovery. Do the filters potentially registered with @ComponentScan actually get forwarded to the repositories correctly?

This is true, but using @ComponentScan still seems like a sensible first option. Filters don't get applied to the repository or entity scanning code. We basically only use the base package.

Speaking to @jhoeller about this here a few thoughts to optimize the situation: couldn't @EnableAutoConfiguration simply take the role of an empty @ComponentScan, meaning the base package is defined by the annotated class.

I don't like this idea. Auto-configuration can work without component scanning and I feel like scanning is something that the user should opt-into. It also wouldn't work that well if the @Configuration class was in a sub-package.

couldn't @EnableAutoConfiguration take a base package or a base package class to customize the general base package used by Boot by default.

I think I would prefer a new annotation for this, rather than extending @EnableAutoConfiguration.

additional @ComponentScan annotation would then purely work as expected - picking up annotation based application components

You now need to duplicate base package information in two places and we are making the default configuration more difficult.

a manually defined @Enable…Repositories would take over repository configuration, ignoring the auto configuration activated around it

Yes, this should definitely happen to allow the user to take ultimate control.

[dsyer]

I just added a test (commit aebaa58). A user can add @EnableJpaRepositories and it overrides the Boot auto-config setting. He still has to provide a @ComponentScan for the @Entities to be located, or else define his own EntityManagerFactory. I think that's a pretty good balance of doing something sensible with the minimum of information and allowing the user to override it if necessary.

I might be open to a new annotation to optionally signal the @Entity base package, (@EntityScan maybe, might even be useful in Spring ORM?), but I agree with Phil that we shouldn't add more behaviour to @EnableAutoConfiguration.

[odrotbohm]

What's your concerns about stating base packages in @EnableAutoConfiguration? It's not like it's overloaded with configuration already and it would clearly communicate: for all auto configuration applied, this is the base package we use. In contrast to that, everything specified outside the annotation would not interfere with the auto config mechanisms. The component scanning reuse clearly blurs (read: violates) that clear guideline. I add explicit configuration and it also affects (but doesn't rule out) the auto config stuff.

What I find particularly weird is that the current state effectively forces me to enable component scanning to activate features that don't require it in the first place: repositories have their custom scanning setup, @Entity classes are not found by @ComponentScan either. So we're not really defaulting stuff here but changing the semantics of established concepts, don't we?

[gregturn]

Just my $0.02. If I didn't know anything about Spring Boot, where would I get the impression that @EnableAutoConfiguration comes component scanning? Doesn't seem intuitive in the name. Kind of reminds me about that JPA annotation you tweeted about a week or two ago.

On Thu, Jan 9, 2014 at 5:24 AM, Oliver Gierke notifications@github.comwrote:

What's your concerns about stating base packages in @EnableAutoConfiguration? It's not like it's overloaded with configuration already and it would clearly communicate: for all auto configuration applied, this is the base package we use. In contrast to that, everything specified outside the annotation would not interfere with the auto config mechanisms. The component scanning reuse clearly blurs (read: violates) that clear guideline. I add explicit configuration and it also affects (but doesn't rule out) the auto config stuff.

What I find particularly weird is that the current state effectively forces me to enable component scanning to activate features that don't require it in the first place: repositories have their custom scanning setup, @Entity classes are not found by @ComponentScan either. So we're not really defaulting stuff here but changing the semantics of established concepts, don't we?

— Reply to this email directly or view it on GitHubhttps://github.com/spring-projects/spring-boot/issues/200#issuecomment-31922048 .

Greg Turnquist | Senior Software Engineer | Pivotal Mobile: +1 321-759-1143 | Skype: gregturn | gturnquist@gopivotal.com

goPivotal.com http://www.gopivotal.com/

[odrotbohm]

Maybe I've been to imprecise about my expectations. I am explicitly not expecting a potential @EnableAutoConfiguration("my.base.package") to activate any component scanning in terms of application component discovery. I can imagine it as a provider of a base package to be used in defaulting scenarios such as the repositories and the configuration of the LocalContainerEntityManagerFactoryBean. It could just still pick up the package of the annotated class by default - so that it effectively works the same way as @ComponenScan does from a customization point of view but simplified to the base package definition.

To be precise, the current behavior actually forces me to activate application component scanning, just to declare a base package for defaulting purposes. I suggest to clearly separate between means to control the auto-configuration - which I think @EnableAutoConfiguration is a reasonable place for - and user provided configuration such as enabling of application component scanning for a certain package through @ComponentScan.

[philwebb]

I think I understand the issue, but to me the @EnableAutoConfiguration annotation is the wrong place for this. I think it could cause confusion, especially when used in combination with @ComponentScan:

@Configuration
@EnableAutoConfiguration("my.base.package") 
@ComponentScan
public class MyApp {
    // confusing because scanning actually occurs from this package
    // if I don't use entities or repositories 'my.base.package' is not even needed
}

I think instead we should look at specific annotations that allow you to override the actual packages for the specific need. This would also let us deal with situations where entities and repositories might be in different locations:

@Configuration
@EnableAutoConfiguration
@ComponentScan("my.base.package")
public class MyApp {
    // enable scanning and also assume that entities and repositories are in 'my.base.package'
}

@Configuration
@EnableAutoConfiguration
@ComponentScan("my.base.package.components")
@EntityPackage("my.base.package.entities")
public class MyApp {
    // enable scanning in 'my.base.package.components' but look for entities somewhere else
    // assume repositories are in the 'components' package
}

@Configuration
@EnableAutoConfiguration
@ComponentScan("my.base.package.components")
@EntityPackage("my.base.package.entities")
@RepositoryPackage("my.base.package.data")
public class MyApp {
    // enable scanning in 'my.base.package.components' but look for entities somewhere else
    // and repositories in a different location again
}

@Configuration
@EnableAutoConfiguration
@EntityPackage("my.base.package.entities")
@RepositoryPackage("my.base.package.data")
public class MyApp {
    // no component scanning but a specific location for entities and repositories
}

I think that this would allow us to keep the current defaults (which I still think are sensible for lots of people) then gradually opt-in to changes. It would also allow the use of repositories without needing full scanning. We could also update the error message to indicate that you can use @ComponentScan or @RepositoryPackage.

Thoughts?

[dsyer]

To be clear: even as things stand we don't force Ollie to use @ComponentScan (he can always add an EntityManagerFactory instead), but I do think it would be more convenient to simply declare the package in one way or another.

I don't think we need @RepositoryPackage since @EnableJpaRepositories does a pretty good job of the same thing, doesn't it? @EntityPackage or (@EntityScan) as a way to default the packages to scan in a Boot-provided LocalEntityManagerFactoryBean makes sense to me, but I agree with Phil that it shouldn't preclude using @ComponentScan as a hint.

[dsyer]

@philwebb I would assume in your second example that repositories were in the entity package (best practice to colocate domain model with its repository interfaces).

[philwebb]

@dsyer I just took a guess :), if that is best practice then we should do that.

I thought about @EntityScan as a name but then changed my mind since it doesn't actually do the scanning.

[dsyer]

@EntityScan converts to a packagesToScan (ugly property name) in LocalEntityFactoryBean I think, so I thought "scan" was a reasonable description. Also it isn't just the package you specify but also subpackages that can contain @Entities, so "scan" seems to describe what will happen better than "package".

[odrotbohm]

I don't think that individual annotations really work out. As Dave already discovered with the one for repositories. If you want to customize things it's usually sufficient to use the actually activating annotation anyway. Needing to configure different annotations for individual auto-config features or even a declaration of an EntityManagerFactoryBean to just to configure the base package feels like a huge step backwards actually.

I am not sure how common the scenario of specifying separate packages actually is. Personally, I dislike using Strings quite a bit, so just using the package of the class annotated with @EnableAutoConfiguration is just fine. I also still don't get how this is creating any confusion: @ComponentScan does application scanning on that package, @EnableAutoConfiguration would enable all auto configuration that relates to some package to get the package of the annotated class applied.

So I'd end up with:

@EnableAutoConfiguration
class MyApp {  }

for the simplest possible case enabling all auto configuration repos, EMF configuration but no application component scanning.

@EnableAutoConfiguration
@ComponentScan
class MyApp {  }

would then enable auto config with the current package plus application component scanning. That's clean, precise and totally aligned with the current semantics of @ComponentScan in a non-Boot scenario.

To get into Phil's example:

@Configuration
@EnableAutoConfiguration("my.base.package") 
@ComponentScan
public class MyApp {
    // confusing because scanning actually occurs from this package
    // if I don't use entities or repositories 'my.base.package' is not even needed
}

What do you mean with "scanning" in this scenario. According to my definition above the config would configure the EMF to use my.base.package and activate repositories for the very same package as well. Other application components would be picked up from the package MyApp resides in. Do you think that's surprising behavior? As already stated, I find the configuration scenario rather constructed (although I don't doubt there will be people coming up with stuff like this) as I cannot come up with a good reason why to put entities and repositories into a separate package and services into some totally separate one. As far as I can see, people seem to avoid layer packages these days and just cut by slice (e.g. com.acme.order, com.acme.payment etc.)

[philwebb]

You don't get many clues that "my.base.package" on @EnableAutoConfiguration is used for entities and repositories. I might assume that it is something related to auto-configuration or that since the package has been specified it is also used for component scanning.

[philwebb]

I do like the idea of defaulting the entity package based on @EnableAutoConfiguration annotation. Rather than throwing an error about adding @ComponentScan we could assume that the the package of the class with @EnableAutoConfiguration is a good default.

I also agree with @dsyer that @RepositoryPackage doesn't add anything over @EnableJpaRepositories.

That would just leave us with @EntityScan to indicate the packagesToScan attribute for EMF.

So: I'm lazy...

@EnableAutoConfiguration
class MyApp {  
// no component scanning
// entities scanned from the `MyApp` package
// repositories scanned from `MyApp` package.
}

I want a specific repository package...

@EnableAutoConfiguration
@EnableJpaRepositories("my.base.repo")
class MyApp {  
// no component scanning
// entities scanned from the `MyApp` package
// repositories scanned from "my.base.repo"
}

I want a specific repository package and a different EMF scan...

@EnableAutoConfiguration
@EnableJpaRepositories("my.base.repo")
@EntityScan("my.base.entity")
class MyApp {  
// no component scanning
// entities scanned from "my.base.entity"
// repositories scanned from "my.base.repo"
}

I just want a different EMF scan...

@EnableAutoConfiguration
@EntityScan("my.base.entity")
class MyApp {  
// no component scanning
// entities scanned from "my.base.entity"
// repositories also scanned from "my.base.entity" since likely to be co-located with entites
}

@ComponentScan is no longer overloaded, we get sensible defaults if you follow conventions and @EntityScan("...") is clearer than @EnableAutoConfiguration("...").

Thoughts?

[dsyer]

That works for me (except of course that I'd only use basePackageClasses not package names).

[odrotbohm]

I like the way @EnableAutoConfiguration defines the base package currently but @EntityScan feels weird for a variety of reasons:

• it's not configuring any active scanning but effectively the setter invoked on LocalContainerEntityManagerFactoryBean
• doesn't its mere presence imply it's needed to enable entity scanning on the LCEMFB at all?
• does it work without a package defined (either as string or by configuring a class)?
• isn't it weird to customize a default (implied through @EnableAutoConfiguration) using a different annotation?

Summing up the just mentioned points, it works way different than @ComponentScan does. Introducing a dedicated annotation to customize parts of the auto-config also might create the expectation that other Boot features can be configured in an annotation driven way, which is probably not what we want.

What about the following compromise:

• @EnableAutoConfiguration implicitly determines the base package used for auto configuration (as already suggested by Phil)
• if you want to customize repository setup you need to fallback to @Enable…Repositories (also already on the table)
• we add the ability to customize the entity package through a application property (e.g. spring.jpa.packagesToScan) as it effectively is just a slight tweak in the LCEMFB setup but fall back to the package determined through @EnableAutoConfiguration

That way we don't expose any real hints that Boot might do some custom scanning at all but rely on people using reasonable defaults or understanding the setup anyway.

[dsyer]

Looks like we are converging. Responding to your peeves about @EntityScan:

it's not configuring any active scanning but effectively the setter invoked on LocalContainerEntityManagerFactoryBean

What's not active about that? Someone (I assume Hibernate in this case) is going to scan that package. You need a way to declare it somewhere, and by far the most convenient way to do that for a user is to declare a class that lives in that package.

doesn't its mere presence imply it's needed to enable entity scanning on the LCEMFB at all?

Not sure what you mean by that (probably I'm not up to speed with LCEMFB features). Do you mean that it's possible (even common) to use the LCEMFB without enitity scanning?

does it work without a package defined (either as string or by configuring a class)?

Wouldn't it be natural to use the same semantics as @ComponentScan (i.e. the package default to that of the class it annotates)?

isn't it weird to customize a default (implied through @EnableAutoConfiguration) using a different annotation?

It's not something we've done so far, but why is that a problem? The "real" owner of the configuration value is the @EntityScan (if there is one). If there isn't one we make an educated guess. If we had to declare the package in weakly-typed external configuration file I think we would have missed an opportunity to be expressive in the Java config.

I think it makes sense for @EntityScan to be in Spring ORM. Would that make it more palatable?

[philwebb]

I am starting to come around to using the @EnableAutoConfiguration annotation, especially as we are now using it as an implicit marker. Perhaps we can try some different ideas to solve my concerns.

Naming: I still think @EnableAutoConfiguration("my.base.package") is confusing but perhaps a different attribute name would solve that:

@EnableAutoConfiguration(basePackages="my.base.package")

I can't think of completely suitable name here.

ComponentScan: The combination of @EnableAutoConfiguration(basePacakges=) and @ComponentScan is a bit odd. I can see the case where @Configuration is in a sub-package and I want both component scanning and entity scanning from one level-up. What if we also offer a componentScan attribute on @EnableAutoConfiguration to save duplicating base packages?

@EnableAutoConfiguration(basePackages="my.base.package", componentScan=true)

I have thought about adding this before but previously decided it wasn't worth it.

Entity Scan: We still don't offer an easy way configure the packagesToScan attribute if it should be different from the component scan and repository scan packages. Perhaps this is something we can raise as a different bug.

[philwebb]

Examples again:

I'm lazy...

@EnableAutoConfiguration
class MyApp {  
// no component scanning
// entities scanned from the `MyApp` package
// repositories scanned from `MyApp` package.
}

I'm lazy and I want scanning...

@EnableAutoConfiguration(componentScan=true)
class MyApp {  
// components scanned from the `MyApp` package
// entities scanned from the `MyApp` package
// repositories scanned from `MyApp` package.
}

I want a specific repository package...

@EnableAutoConfiguration
@EnableJpaRepositories("my.base.repo")
class MyApp {  
// no component scanning
// entities scanned from the `MyApp` package
// repositories scanned from "my.base.repo"
}

I want a specific repository package and a different EMF scan...

@EnableAutoConfiguration(basePackages="my.base.entity")
@EnableJpaRepositories("my.base.repo")
class MyApp {  
// no component scanning
// entities scanned from "my.base.entity"
// repositories scanned from "my.base.repo"
}

I just want a different EMF scan...

@EnableAutoConfiguration(basePackages="my.base.entity")
class MyApp {  
// no component scanning
// entities scanned from "my.base.entity"
// repositories also scanned from "my.base.entity"
}

I want my configuration in a com.corp.app.config package but scanning for entities, repositories and components happens from the root:

@EnableAutoConfiguration(basePackages="com.corp.app", componentScan=true)
class MyApp {  
// components scanned from "com.corp.app"
// entities scanned from "com.corp.app"
// repositories scanned from "com.corp.app"
}

[philwebb]

BTW: Thanks for all the back and forth on this one. I know it's a PITA but I think these core decisions are important for a nice user experience.

[dsyer]

I don't see what's wrong with @ComponentScan so I don't think I like componentScan=true in @EnableAutoConfiguration. Your previous proposal is still the best so far (with the caveat that base packages need to be specifiable as classes), if we can persuade Ollie on @EntityScan. Anyway I think we should implement something and try it out now, instead of talking about it more.

[odrotbohm]

What's not active about that? Someone (I assume Hibernate in this case) is going to scan that package. You need a way to declare it somewhere, and by far the most convenient way to do that for a user is to declare a class that lives in that package.

The notion of scanning in a Spring application was usually defined as "detecting application components managed by Spring", which means, the candidate components become Spring beans. This is both true for application components detected by @ComponentScan as well as repositories. This is certainly not true for the entity classes found. While one might argue that this is an implementation detail, I don't agree with that as it conceptually separates injectables from newables and these two types of types have completely different traits and semantics applied.

Not sure what you mean by that (probably I'm not up to speed with LCEMFB features). Do you mean that it's possible (even common) to use the LCEMFB without entity scanning?

Yes it is. Let me elaborate on that real quick. By definition, the persistence provider will scan for entity classes in the persistence unit anyway. The sole purpose of the packagesToScan property introduced in Spring 3.2 was to be able to work with JPA and eliminating the need for a persistence.xml (which is actually required by JPA). So we're effectively defaulting the persistence unit definition and let the persistence provider do the heavy lifting.

My original point was, that the existance of @EntityScan seems to imply that you need to declare it (customized base package or not) to activate the scanning (assuming you derive that from the way @ComponentScan works). That cognitive stretch is the consequence of getting the default from one annotation and the customization from another) which I don't think that this was the intention, right? So again, I think with that additional annotation we're elevating a tiny feature of a local class to a first class configuration citizen and then (assuming that would be a good idea in the first place) miss to make it behave like other means on the upper configuration level. We're certainly not going to create annotations to define values for other automatically registered bean definition properties, do we?

packagesToScan is a bean property on LCEMFB. We already have dedicated means to change the bean definition for it: a few important ones being exposed through config properties and the ability to completely customize the LCEMFB through a manually declared bean definition. So I'd vote for making packagesToScan part of the former - as there's no reason it's more important than, let's say generate-ddl - and allow to tweak it if need, falling back to the default package expressed through the class that takes @EnableAutoConfiguration.

Effectively, that would take us to the default be derived from @EnableAutoConfiguration instead of @ComponentScan and allowing to tweak the package through a property. That's not even too much of a change plus actually less code to write for the default case.

@philwebb - I like the fact that we can avoid the need for @EntityScan but I agree with Dave that pulling component scanning into the annotation doesn't provide too much benefit from using @ComponentScan directly. The current approach (assuming we get rid of the need for @ComponentScan to let the JPA setup defaulting work) cleanly separates between boot applying defaults (through @EAS) and user config (everything else). Drawing that strict line probably helps people imagining what's going on and where to look for documentation in case things go wrong.

Don't worry about the back and forth. It's great to be able to actually have these discussions on that level. :)

[dsyer]

OK, I still like the @EntityScan idea (just because JPA config spec sucks doesn't mean we can't make it nice to use), but I'm sure that as long as we have a default from @EnableAutoConfiguration and a way to override it somewhere I guess that's enough.

So we don't need any new attributes in @EnableAutoConfiguration is my understanding. We have:

I'm lazy...

@EnableAutoConfiguration
class MyApp {  
// no component scanning
// entities scanned from the `MyApp` package
// repositories scanned from `MyApp` package.
}

I want a specific repository package...

@EnableAutoConfiguration
@EnableJpaRepositories("my.base.repo")
class MyApp {  
// no component scanning
// entities scanned from the `MyApp` package
// repositories scanned from "my.base.repo"
}

I want a specific repository package and a different EMF scan (as above for specific repositories but)...

# application.properties
spring.jpa.entity.basePackages: my.base.entity

I just want a different EMF scan (as in the lazy case but)...

# application.properties
spring.jpa.entity.basePackages: my.base.entity

Maybe we should also externalize the persistence.xml location (or a flag to signal its existence), so the user doesn't have to create a new LEMFB just to read a custom native JPA configuration? (Or can you already do that?)

[odrotbohm]

I like that a lot. Do we already have the entity sub-path so that adding packagesToScan makes sense or shall we just go with spring.jpa.packagesToScan (which would be closer to the implementation class - similar to all other currently supported properties). On the other hand spring.jpa.entity.basePackages provides a nice template that could be reused for MongoDB (spring.mongodb.entity.basePackages).

Every defaulting related to persistence.xml is kind of tricky as the spec requires it to be located in the persistence unit root under META-INF. So in case a developer uses the file already it has to be in this place and the selection of the PU used is done through the persistenceUnitName property on LCEMFB. So if you're using persistence.xml you're very likely to declare your LCEMFB manually.

[philwebb]

I still quite like the idea of an annotation that allows you to specify the entity package. Mainly so that you can declare it in a type safe way. I also don't think it is great to put "code" specifics in the application.properties.

What if we extracted LocalContainerEntityManagerFactoryBean from JpaBaseConfiguration and made it an Enable.... With JpaBaseConfiguration just doing the same import:

@EnableEntityManager("my.package.to.scan")

@EnableEntityManager(basePackageClasses=Something.class)

That might also give a nice way to configure the persistenceUnitName

@EnableEntityManager(persistenceUnitName="whatever")

Just an idea, I am also happy with Dave's solution two comments up.

[odrotbohm]

Would this be required to generally enable the feature? Just asking because that's how all of the @Enable… annotations currently work.

[philwebb]

You mean would it be part of Spring Framework or Spring Boot? or just could you use it without @EnableAutoConfigure ?

[dsyer]

I like the implied semantics of @EnableEntityManager (or @EnableLocalEntityManager?). In answer to Ollie's question: I think it should be required to activate the feature, but Spring Boot can provide an instance that "just works" with sensible defaults, if it detects all the right pieces on the classpath (a bit like the way we provide @EnableWebMvc). It could be used without @EnableAutoConfiguration in other words. And it would be a candidate for inclusion in Spring ORM as soon as is expedient.

One problem would be that the autoconfig class that we provide would not be in a package with user @Entities in it, so defaulting the packages to scan would have to be finessed. We would need a mechanism internally to the @EnableEntityManager process so that we can trap the @EnableAutoConfiguration and default the packages to scan from there. That's a bit like the way @EnableJpaRepositories works already, so there is some hope it can be done (even if it ends up being a bit ugly internally to Boot).

[dsyer]

Another problem is that @ConditionalOnMissingBean(annotations=...) really doesn't work yet, even after some last minute changes to Spring 4.0 to try and support it. I guess we can probably work around that in the same way we have for SecurityAutoConfiguration, but it does point to a weakness in the condition processing for this kind of scenario.

[odrotbohm]

Any chance we move the discussion about @EnableEntityManager into a separate ticket? It seems to open up a new can of worms. IMO, the means we have concluded on (application property and manual bean declaration) are quite sufficient for the time being.

[dsyer]

Another ticket is a good idea, but wouldn't it be a mistake to introduce a new application.properties path that might be obsoleted by @EnableEntityManager? I guess we can always make it additive, i.e. if @EnableEntityManager is added later it can add more packages to scan if the project already contains spring.jpa.entity.basePackages and/or spring.jpa.entity.persistenceUnit.

[odrotbohm]

I still stay with my argument that @EnableEntityManager is misleading as it's not really enabling the JPA setup, in contrast to all other @Enable… annotations. To be honest, I don't see any need for the annotation, as I think it's fine to either go with a property or a bean definition.

You can't really use the basePackages and persistenceUnit properties in combination as the preparation of the persistence unit information is mutual between the persistence provider (in case of a persistence unit name provided) or Spring (with the base packages approach).

[dsyer]

I thought that @EnableEntityManager creates a LocalEntityManagerFactoryBean the way that @EnableWebMvc creates a RequestMappingHandlerMapping. What's the difference? Or did you infer something that wasn't as obvious to me?

You can't really use the basePackages and persistenceUnit properties in combination

Obviously. But we can warn or fail if we find the user trying to do both. That's also not an uncommon pattern.

[philwebb]

I thought the same as Dave, but lets move @EnableEntityManager out of this issue to discuss that.

I am not going to add the property for the entity packages to scan, I think application.properties is the wrong place for that. We can discuss this more in the other bug.

For now, if you want a custom package scan package you will need to declare your own LEMFB.

[odrotbohm]

Fine with me. :)

[philwebb]

Reopening because documentation was missed. Document the new defaults and the @EntityScan annotation added in #239