Use case: user DnD DB table onto GUI form in order to display DB data in this
When there isn't a persistence unit corresponding to the DB connection of the
dragged DB table then we have to create a new persistence unit for this
connection. Please, provide us an API to achieve that.
So far, we were using ProviderUtil.buildPersistenceUnit() and
ProviderUtil.addPersistenceUnit() for that purpose. If these APIs are going to
survive in NB 6.0 then it is sufficient to add us
(org.netbeans.modules.form.j2ee) as friends to j2ee\persistence module.
Note that based on what I see in ProviderUtil.addPersistenceUnit() the
persistence.xml file is created if it doesn't exist. So do you need to explicity
request persistence.xml to be created if you just use this method?
The current implementation (e.g. the one that was in NB 5.5) of
addPersistenceUnit() works for us. It is fine for us if it remains as it is.
I see that ProviderUtil.buildPersistenceUnit() and
ProviderUtil.addPersistenceUnit() still exist in the trunk, and Matisse is a
friend of the persistence module. So if there are no plans to change this, we
are done, right? Are there plans to do changes in this area in 6.0?
I don't plan to remove those methods, but I'd like to make some clean up of the
ProviderUtil as now it is a bit messy combination of various utility methods of
which many shouldn't be exposed through the friend API. So I'd leave this one
open still and close once that is done. I don't want to make any major changes
though, just some minor refactorings.
If you have the time, consider removing the assumption that there is a single
persistence.xml file per project (see ProviderUtil.getPUDataObject(Project) and
similar). I'm not comfortable with exposing this bug to clients outside the
enterprise cluster (even if they don't plan to use it right now). And I'm afraid
that VWP will want to do something with JPA soon and this will get even messier
and harder to fix. It is also needed for the JPA support in freeform projects.
In the ideal case the method should be
where the FileObject is a persistence client (e.g., a servlet in a web project).
Note you already have a method with this signature, where the FileObject has a
This could also require modifying PersistenceLocation to allow for a FileObject
parameter with similar semantics. That could be postponed if necessary, since it
affects mainly implementors, not clients.
The methods required here are still present and the ProviderUtil class has been
cleaned up, so I'm closing this. I filed a new defect for the case Andrei
mentioned (issue 98085).