At a first glance I liked the idea, but the more I think about it the less it sounds reasonable to me. Encoding persistence unit name as a sub-package provides more confusion than benefits. First of all because it limits you in naming your persistence units. As per JPA spec a unit's name is a string. So, you are free to use names like "foo-bar" or "1unit" which we would need to encode into valid Java package names. This will be confusing. Another objection is that renaming unit name you would need to rename your packages.
I think I'll do it as follows: 1) Single persistence unit: 1.1) The most of the users will be having only a single persistence unit. For such users we need to provide a solution which is compatible with the JPA spec. So,we allow autoscanning of the classpath and don't auto-include entities from root-package.entities. 1.2) For those of us, who loves to place the entities into root-package.entities, we could provide a symbol like "jpa-compatibility-mode" which is true by default. Having jpa-compatibility-mode=true results in behavior described in 1.1. If the mode is set to false, auto-scanning is switched off and the entities from root-package.entities are added automatically. 2) Multiple persistence units In this case we don't include any of the entities automaticall. The user is responsible to add the entities to the entity managers manually as only he/she knows which entity belongs to which manager. I think this solution provides the lowest confusion rate as the most frequent use case just works out of the box. On Wed, Jul 13, 2011 at 6:34 PM, Lenny Primak <[email protected]>wrote: > After sleeping on this I have an even simpler suggestion. Just auto-scan > the .../entities.${persistenceUnit} > pah fo it's own entities by default and update package contributor to > return a map of PUs to paths so it's easy to customize. > > I.e default search path com.xxx.app.entities.PU > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Best regards, Igor Drobiazko http://tapestry5.de
