Currently the Java Persistence support has a dependency on modules which provide
Java EE support, e.g. j2eeserver and j2ee/utilities. This dependency should be
eliminated so it is possible to distribute Java Persistence without J2EE
features, e.g. for use by Matisse.
We will probably also want to move the Java Persistence features to the ide cluster.
Please review the following changes in the cluster configurations.
The JSR220 Persistence (code name base org.netbeans.modules.j2ee.persistence),
JPA verification (code name base org.netbeans.modules.j2ee.jpa.verification)
and Database Schema (code name base org.netbeans.modules.dbschema) modules,
currently part of the J2EE cluster, are planned to be moved to the IDE cluster.
The modules don't have dependencies to modules outside of the IDE cluster. The
JSR220 Persistence and Database Schema modules define a friend API, the JPA
Verification module does not define any API. The JSR220 Persistence module has
5 friends, of which 4 will remain in the J2EE cluster and 1 (JPA Verification)
is to be moved to the IDE cluster as well. The Database Schema module has 3
friends, which are all in the J2EE cluster. All current friends of the JSR220
Persistence and Database Schema modules are controlled by the Java EE team.
The motivation for this is that the Netbeans JPA support is needed also in Java
SE applications and the user should not be required to install the enterprise
cluster to be able to develop Java SE applications with JPA.
Created attachment 38186 [details]
Created attachment 38187 [details]
That's quite a long list of friend packages, especially for inter-cluster use.
It looks like you just made nearly everything public. Please carefully review
the Javadoc for both modules to see which classes (and methods) actually need to
be exported, and move them into a slimmer set of o.n.m.*.[as]pi packages. (Take
a look at ant/freeform/nbproject/project.xml for an example of a friend API of
consciously limited size.)
Also please recheck the list of module dependencies. In particular, the runtime
dependency on the junit module from j2ee/persistence looks odd.
MK1: will the use by matisse for example introduce more friend module
dependencies? will these also be controlled by j2ee team?
jglick01: Agreed that the list of friend packages is rather long, I will look
into restricting the amount of exposed packages. The dependency on the junit
module is unnecessary, I'll remove it and check the other depencies as well.
mkleint01: You're correct that the use by Matisse will introduce another friend
module. As far as I know, it will not be controlled by the Java EE team. Please
note the actual API needed by Matisse is not there yet, it will be introduced
Thanks for the comments so far.
Created attachment 38363 [details]
Created attachment 38364 [details]
hidden friend packages
I've removed unnecessary dependencies and hidden three of the previously
exposed friend packages, though I understand that there still are more packages
exposed than should. I hope to further address this when implementing the API
for Matisse, and there will be another API review when that is done (should
happen before M8). If there are no objections, I will proceed with this today
Y01 I hope no external library is going to be added into ide cluster.
Y02 Why cannot I verify that in a diff before integration?
YO1: In fact, one external module needs to be added, namely the Toplink module
(j2ee/toplinklib). It is a wrapper module for the JPA reference implementation.
Is that enough, or would you need more info on that?
Y02: I will prepare a diff.
Re: toplink. Yes, that sounds relatively fine - I hope it is an opensource
project, part of GlassFish - I need URL for sources of the version that you
Re: toplink2. It is part of the module that provides some functionality
(dialogs, actions, integration with j2se)? Shall not that library be useful as
a library of its own? If so, it might be better to have it as standalone
library in libs. That leads me to a question:
Y03 Any public packages exposed to external world? javax.persistance?
Regarding the version of Toplink, we use the version from GlassFish V1 UR1
(Petr J, could you please verify this?). The URL to sources is https://
Re. functionality: The only functionality that the Toplink module provides is
the registration of the library in the library manager. If there is a better
way to do it, please let us know.
YO3: The module does not expose any packages.
Created attachment 38382 [details]
diff of cluster.properties and ide/golden
> (Petr J, could you please verify this?)
Right, we currently use the UR1 version. Of course, this may change before NB 6 FCS.
Thanks for the review. I'm sorry for the hastened process, time was running out
to get this done for M7 - it dawned on me a bit late that this should be done
by latest today. I hope the concerns expressed here have been adequately
addressed, if not, well, nothing irreversible has been done.
Done in trunk.
Checking in ide/golden/friend-packages.txt;
/cvs/ide/golden/friend-packages.txt,v <-- friend-packages.txt
new revision: 1.106; previous revision: 1.105
Checking in ide/golden/cluster-deps.txt;
/cvs/ide/golden/cluster-deps.txt,v <-- cluster-deps.txt
new revision: 1.77; previous revision: 1.76
Checking in ide/golden/files-layout.txt;
/cvs/ide/golden/files-layout.txt,v <-- files-layout.txt
new revision: 1.208; previous revision: 1.207
Checking in ide/golden/cluster-impl-deps.txt;
/cvs/ide/golden/cluster-impl-deps.txt,v <-- cluster-impl-deps.txt
new revision: 1.16; previous revision: 1.15
Checking in ide/golden/group-friend-packages.txt;
/cvs/ide/golden/group-friend-packages.txt,v <-- group-friend-packages.txt
new revision: 1.39; previous revision: 1.38
Checking in ide/golden/impl-deps.txt;
/cvs/ide/golden/impl-deps.txt,v <-- impl-deps.txt
new revision: 1.73; previous revision: 1.72
Checking in ide/golden/modules.txt;
/cvs/ide/golden/modules.txt,v <-- modules.txt
new revision: 1.112; previous revision: 1.111
Checking in ide/golden/deps.txt;
/cvs/ide/golden/deps.txt,v <-- deps.txt
new revision: 1.454; previous revision: 1.453
Checking in nbbuild/cluster.properties;
/cvs/nbbuild/cluster.properties,v <-- cluster.properties
new revision: 1.187; previous revision: 1.186
Thanks for dealing with the JNLP build, too! Beat me to it. :-)