---

Move JPA Support into IDE Cluster

Tracked by issue 92285.

Problem Statement and Motivation

Java Persistence API (JPA) can be used in Java SE applications. JPA is even planned to be included into JDK7. NetBeans JPA support works in Java SE project: the user can create and edit JPA classes, setup persistence unit, generate entities from database and support for visual development of DB application with Mattise is planned for NetBeans 6.0.

Users should not need to install enterprise cluster to be able to develop Java SE applications with JPA. We should move module j2ee/persistence (or its parts that are relevant for Java SE development) into IDE cluster.

Tasks and Issues

j2ee/persistence dependencies

The j2ee/persistence module currently depends on 4 modules in enterprise cluster:

• dbschema - used by entity generator
• j2eeserver - used to determine j2ee module
• j2ee/ejbapi - used to find location of metadata files
• j2ee/utilities - code generation and other utils

dbschema: The dbschema module needs to be moved into IDE cluster with j2ee/persistence module. There are two other dependencies on the friend API of dbschema module: j2ee/ejbcore and serverplugins/sun/sunddui. Besides this dbschema is used by GlassFish. In order to move dbschema into IDE cluster we first need to pass a review to legalize the dependency on friend API from another cluster.

j2ee/ejbapi: The j2ee/ejbapi is used to find the location of metadata files (persistence.xml) in the RelatedCMPWizard. Possibly the PersistenceLocationProvider could be extended to handle this case as well to get rid of this dependency. Update: is there a case when EjbJar#getMetaInf() would return a different folder than the one returned by EjbJarPersistenceProvider#getLocation()? As far as I can tell, there isn't but maybe I'm wrong. If not, the depency on this part can just be removed.

AB: another option is adding a getConfigFilesFolder() method to PersistenceGenerator. The advantage is that it doesn't force a client to know about PersistenceLocationProvider when it actually only supports EJB.

Another thing is that currently the RelatedCMPWizard and EntityClassesPanel are used both for generating CMP beans and entity classes and there is some checking whether were dealing with CMPs. In the long run it would be nice to have all of the CMP functionality in ejbcore, especially if/when the UI for these functionalities evolves (currently the EntityClassesPanel handles both cases just be renaming the check boxes in the panel).

AB: in the long run, perhaps we should. But for now more code is common than not, so I'd leave it the way it is for 6.0.

j2eeserver: The dependency on j2eeserver should be moved into EJB provider of persistence generator. This will require additions to the friend API of j2ee/persistence. An additional problem is the EntityManagerGenerator, which needs to know with what kind of module it is dealing with. This could be solved by creating a SPI for resolving the generation strategy and putting implementations of it into the project lookup. Likewise, the DatasourceUIHelper and PersistenceProviderComboBoxHelper could be dealt with similarly.

AB: I think this also requires an SPI for retrieving the datasources from a project's target server. j2ee/persistence could define its own definition of data sources (e.g., a JPADatasource class) and a project could delegate implementations of these classes to instances of Datasource obtained from the project's J2eeModuleProvider. Or is this all covered by the DatasourceUIHelper SPI?

j2ee/utilities: The GenerationUtils, SourceUtils and AbstractTask in j2ee/utilities should be moved into the Java source infrastructure. The InjectionTargetQuery should be moved to the IDE cluster as well, the exact location TBD. Most of the dependencies on the j2ee.common.Util, in particular the helper methods for searching classes from libraries, can be merged to j2ee/persistence as they are not used elsewhere. The check for the source code level can be implemented in j2ee/persistence, although ideally this functionality should perhaps be somewhere in the project related apis. Similarly, the j2ee.common.DelegatingWizardDescriptorPanel should be either moved to some module in the ide cluster, or alternatively it needs to implemented within j2ee/persistence. As these are rather simple helper classes/methods, in the first phase they can be implemented in j2ee/persistence and then try to push them to more appropriate modules. What to do with Util.isValidServerInstance is TBD.

dependencies on j2ee/persistence

Several modules in enterprise cluster depend on j2ee/persistence module's friend API:

• j2ee/ejbcore: this module implements generation of EJB 2.1 entity classes.
• ejbjarproject: provides persistence scope in ejb module, uses persistence node in project UI
• j2ee/refactoring: special refactoring for JPA should be moved into IDE cluster
• j2ee/verification: includes verification and hints for JPA, these should be moved to IDE cluster
• j2ee/jsf - CRUD generator, should remain in enterprise clouster and use a friend API of j2ee/persistence

Some parts of the friend API of j2ee/persistence will have to be legalized through a review so that they can be used by modules in enterprise cluster.

functionality to be moved from j2ee/persistence

The Session Facades for Entity Classes Wizard should be considered to be moved to ejbcore. This requires that the EntitManagerGenerator is made accessible through the friend API.

Steps

In no particular order:

• create an SPI for resolving the generation strategy needed by the EntityManagerGenerator done.
• create an SPI for the DatasourceUIHelper done.
• create an SPI for the PersistenceProviderComboBoxHelper done.
• create a friend API for the EntityManagerGenerator
• enchance the current friend API for generating entities as needed
• move the Session Facades for Entity Classes wizard to ejbcore
• enchance the persistence location provider SPI for resolving configuration files folder for the CMPs from DB wizard (update: maybe works as it is now) done.
• remove the dependencies on those parts of j2ee/utilities which are not going to be moved to java/source (i.e. j2ee.common.Util) done.

Also, before or simultaneously with the actual moving of the j2ee/persistence, the following needs to be done:

• move the GenerationUtils and SourceUtils to java/source. these classes will be partially merged to java/source so that it will provide equivalent functionality.
• move dbschema to the ide cluster

The following can be done after the module has been moved to the ide cluster:

• create a submodule (of j2ee/persistence) for JPA refactoring in the ide cluster
• create a submodule (of j2ee/persistence) for JPA verification in the ide cluster done by tslota.
• expose some of the APIs through a public API, needs that another module is created for that.

In addition to these the APIs need to be reviewed.