I agree with you, merging persistence.xml is ugly.
But more than a specific IDE issue, I think this is more a general
"dynamically discover Entites in != classloaders" related issue.
I have made some prototypes and my conclusion is that JPA is not build
for my use case, even if it is a real need as soon as you start to
build modular application.
I finally succeeded using Spring scanning approach. The idea is to
build a custom PersistenceUnitManager, where I specify entities
packages to scan in various classloaders (like you can specify
packages to scan in order to discover Spring or J2EE6 beans), scan
them and then use pui.addManagedClassName() in order to add them to
You can see my implementation with Spring 3.0 here :
In my case, the packagePatternToScan property is set to
What do you think of this approach ?
On Fri, Feb 5, 2010 at 5:52 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
The approach consisting of merging persistence.xml files is super broken. Period.
It's a hack that happens to work for some version(s) of Hibernate but surely fails on
other providers and is totally against the spirit and the word of the spec.
The only decent approach I can think of is for the IDE to:
- implement PersistentUnitInfo and use the initialization process a container uses.
After all an IDE is a container. For some reason, you don't like this one.
- the IDE does the scanning and use the Hibernate specific configuration APIs in
Ejb3Configuration (like addClass)
- write your own scanning approach, it's all abstracted behind
org.hibernate.ejb.packaging.Scanning. There is no way to pass a custom Scanning
implementation but I am open to suggestions on the way to do it.
On 5 févr. 2010, at 14:38, Max Rydahl Andersen wrote:
> This discussion is super relevant for multi module project development in IDE's
> I've followed up - I hope emmanuel do too since this one actually is one of my
> biggest issues I have when it comes to "autoscanning".
> ----- "Bouiaw" <bouiaw(a)gmail.com> wrote:
>> Thanks for your answer.
>> I made some tests but I think there is no way to acheive this my
>> (common) need without tweaking with merging in one PU.
>> I don't want to SPAM the dev list so I created a thread on the
>> Hibernate forum with my feedback :
>> On Thu, Feb 4, 2010 at 9:06 AM, Emmanuel Bernard
>> <emmanuel(a)hibernate.org> wrote:
>>> Splitting entities amongst several JARs is definitely supported by
>> JPA 2, you need to use the <jar-file> element in persistence.xml (or
>> to a lesser extend <class>).
>>> Merging several persistence.xml and considering them one is not a
>> concept that makes sense in the JPA 2 spec. Conceptually that means a
>> lot of metadata duplication that can and will conflict.
>>> The exception you see comes from the fact that your "merging" does
>> not "unduplicate" jar file urls and it's associated root url.
>>> On 3 févr. 2010, at 17:43, Bouiaw wrote:
>>>> I would like to warn you about a blocking (from my point of view)
>>>> issue in Hibernate 3.5 (JIRA issue :
>>>> Dispatching entities is not supported out of the box by
>>>> but with a small tweak commonly used
>>>> it is possible to acheive this.
>>>> This worked with previous version of Hibernate, but not anymore in
>>>> Hibernate 3.5 betas.
>>>> Even if this is not specified in JPA, this is mandatory for a lot
>>>> developer to do modular applications (each module (JAR) provide
>>>> own DAO, business and model layer).
>>>> I hope you will be able to fix HHH-4864, because this is a
>>>> point for a lot of developers.
>>>> Thanks in advance for your feedback,
>>>> hibernate-dev mailing list
>> hibernate-dev mailing list