This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 54471 - Get ready for removal of implementation dependencies
Summary: Get ready for removal of implementation dependencies
Status: VERIFIED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Code (show other bugs)
Version: 4.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Pavel Buzek
URL:
Keywords: API_REVIEW_FAST
Depends on:
Blocks: 52155
  Show dependency tree
 
Reported: 2005-02-03 13:53 UTC by Jaroslav Tulach
Modified: 2006-09-01 12:32 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
updated ejb api javdoc (126.16 KB, application/x-compressed)
2005-08-22 07:45 UTC, Pavel Buzek
Details
j2ee/utilities updated javadoc (133.05 KB, application/x-compressed)
2005-08-22 07:50 UTC, Pavel Buzek
Details
new javadoc for ejbcore (164.72 KB, application/x-compressed)
2005-08-22 07:51 UTC, Pavel Buzek
Details
ejbjarproject updater javadoc (52.55 KB, application/x-compressed)
2005-08-22 07:52 UTC, Pavel Buzek
Details
commit log for ejb split and removal of impl. deps (142.48 KB, text/plain)
2005-08-24 05:20 UTC, Pavel Buzek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2005-02-03 13:53:35 UTC
In order to eliminate implementation dependencies
completely one day, please separate the API that
you right now access thru the impl deps between
your modules into separate packages.
Comment 1 Petr Jiricka 2005-02-08 09:48:08 UTC
Pavle, what are the concrete changes we need to do?
Comment 2 Pavel Buzek 2005-02-15 10:11:53 UTC
The suggestion was to put all classes from every module that we call
from other modules (via impl dep) into one package. Currently the deps
are scattered across the modules.
Comment 3 Petr Jiricka 2005-02-21 17:52:47 UTC
I am not sure how this will help to eliminate implementation
dependencies. When we collect potential API classes in one package,
will we want to use exactly these classes as API in the future? For
example, we currently use

org.netbeans.modules.xml.tools.actions.CheckAction in several modules.
Will we want to eventually expose this class as an API? Or will we
want to have a factory method that returns a singleton instance of
this action as a javax.swing.Action, without exposing the internal
implementation of CheckAction? How does moving CheckAction to a
separate package take us closer to that goal?

Comment 4 Jaroslav Tulach 2005-02-22 06:37:24 UTC
As soon as issue 54123 is implemented you can safely expose public 
packages that you prepare. If you do not do so, fix of issue 54123 
will not help you much. 
Comment 5 Petr Jiricka 2005-02-22 09:16:19 UTC
Thanks, that explains it!
Comment 6 Pavel Buzek 2005-03-04 19:20:03 UTC
asking for waiver, 54123 is planned for promoF so this can be fixed
then as well
Comment 7 Pavel Buzek 2005-08-22 07:43:42 UTC
I would like to get review and integrate changes that removes most of the
implementation dependencies in j2ee/* modules. This will be done in parallelel
with splitting ejbjarproject module into ejbjarproject and ejbcore and moving
project-related code from j2ee/utilities into j2ee/ejbapi.

Dependencies that were removed

1. Dependency of j2ee/earproject on web/project and j2ee/ejbjarproject replaced
with a friend API for project creation.

2. Dependencies of j2ee/freeform on j2ee/ejbjarproject was replaced by a new API
in ejbapi: 

org.netbeans.modules.j2ee.spi.ejbjar.support.J2eeProjectView, 
org.netbeans.modules.j2ee.spi.ejbjar.support.EjbEnterpriseReferenceContainerSupport 

3. Dependencies between ejbjarproject and the new ejbcore:

A new API was needed to allow j2ee/ejbjarproject and j2ee/freeform to create
nodes for EJBs. In other project types this is solved by simply using DataNodes
but the logical view of EJBs shows nodes that do not represent DataObjects (they
represent EJB objects in ejb-jar.xml). The new SPI for a provider of these nodes is:

org.netbeans.modules.j2ee.spi.ejbjar.EjbNodesFactory

and is implemented in j2ee/ejbcore.

Another new API was needed to make it possible to find EJB modules in a project
(until now a lot of code was looking for an SPI class EjbJarImplementation in
project lookup, see 61524). The new API is the new method in
org.netbeans.modules.j2ee.api.ejbjar.EjbJar:

public static EjbJar [] getEjbJars (Project project)

and a corresponding SPI:
 
org.netbeans.modules.j2ee.spi.ejbjar.EjbJarsInProject

A static method was added to ejbjarproject friend API to allow ejbcore to set
one specific project property: disableSunCmpMappingExclusion().

4. Dependency of j2ee/ddloaders on ejbcore (originally ejbjarproject) was
replaced by a friend API in ejbcore. This API allows to reuse UI (customizers
and dialogs for ejb-jar.xml elements and EJB Java code) and manipulating Java
code for EJBs.

Remaining dependencies:

R1: Dependency on xml/* modules (cannot be done in 4.2)
R2: Dependency on modules that have a public API and cannot have an additional
friend API: j2ee/ddloaders depends on j2ee/ddapi, dbschema depends on db. Will
be left a it is.

R3: Dependencies that should still be reviewed for 4.2:

MODULE org.netbeans.modules.j2ee.refactoring/1 (j2ee)
  REQUIRES org.netbeans.modules.web.core/1 (j2ee)
  REQUIRES org.netbeans.modules.websvc.core (j2ee)
MODULE org.netbeans.modules.j2ee.sun.appsrv81/1 (j2ee)
  REQUIRES org.netbeans.modules.j2ee.sun.appsrv/1 (j2ee)
MODULE org.netbeans.modules.websvc.dev/1 (j2ee)
  REQUIRES org.netbeans.modules.websvc.core (j2ee)

Comment 8 Pavel Buzek 2005-08-22 07:45:29 UTC
Created attachment 24111 [details]
updated ejb api javdoc
Comment 9 Pavel Buzek 2005-08-22 07:50:54 UTC
Created attachment 24112 [details]
j2ee/utilities updated javadoc
Comment 10 Pavel Buzek 2005-08-22 07:51:57 UTC
Created attachment 24113 [details]
new javadoc for ejbcore
Comment 11 Pavel Buzek 2005-08-22 07:52:54 UTC
Created attachment 24114 [details]
ejbjarproject updater javadoc
Comment 12 Pavel Buzek 2005-08-22 07:55:52 UTC
See updated apichanges and arch for ejbmodule, j2ee-common and ejbjarproject.
Ejbcore has only javadoc at this moment (arch.xml pending).
Comment 13 Martin Adamek 2005-08-22 16:27:48 UTC
Looks good to me. Puts more logic into codebase.
Comment 14 Jaroslav Tulach 2005-08-23 16:01:57 UTC
Imho you must have broken links in your documentation. We are trying to fix 
that, instructions can be found at 
http://openide.netbeans.org/tutorial/api.html#write 
 
Maybe you could make EarImplementation (and other classes like that) abstract 
with protected methods. That would ensure nobody is going to lookup that 
directly, as that would be useless - one could not call a method on it. 
Everyone would have to use the Ear from API. 
 
Otherwise I do not have much to comment. The only place where I need such API 
is in nbmwebstart suite, which creates one war file and would like to easily 
execute and debug it, but that is a request for another review, I am affraid. 
 
Please make sure you do not add broken links in javadoc, and go on. 
Comment 15 Pavel Buzek 2005-08-23 16:09:13 UTC
Jardo: excellent idea about abstract cls + protected methods! Thanks.
Javadoc links have been broken anyway, I have several P2 filed for that so I
will fix them separately.

I also got review and comments from Andrei offline, I will fix those.
Thanks for review.
Comment 16 Pavel Buzek 2005-08-24 05:20:00 UTC
Created attachment 24162 [details]
commit log for ejb split and removal of impl. deps
Comment 17 Pavel Buzek 2005-08-24 05:26:27 UTC
Almost fixed, but I still want to check if I should/can do anything about the
impl deps in websvc and sun plugin.

I had to change one thing in module depndencies at last minute (to fix one
problem). Ejbjarproject needs to use some code for ejb generation from ejbcode
(to implement web services related SPI - to generate an implementation of a
newly created web service). In my orig proposal ejbcore had dep on ejbjarproject
to call disableSunCmpMappingExclusion. I turned the dependency so that
ejbjarproject now depends on ejbcore and I changed the
disableSunCmpMappingExclusion from a static API method into an SPI interface. At
least this way (in theory) it can be supported by other project types as well,
not just ejbjarproject.

Jarda's suggestion about preventing
project.getLookup().lookup(EjbJarImplementation.class) will be implemented later
if time permits.
Comment 18 Pavel Buzek 2005-09-14 16:00:23 UTC
Summary:

1. I am OK with the one impl dependency that is in sun appserver because no
other modules should ever need to use API of sun plugin. 

2. I does not make much sense to create friend API for the xml/multiview because
all of its packages would be exposed anyway. Another reason for not creating
friend api there is that the xml/multiview needs a review in future if is should
become used more widely.

3. I filed a separate issue 64359 for websvc - I do not consider this critical
for 5.0 and it will require a review to do it properly.

All other problems were resolved earlier so I am closing this issue as fix.
Comment 19 Dan Kolar 2006-09-01 12:32:00 UTC
v.