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.
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.
Pavle, what are the concrete changes we need to do?
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.
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?
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.
Thanks, that explains it!
asking for waiver, 54123 is planned for promoF so this can be fixed then as well
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)
Created attachment 24111 [details] updated ejb api javdoc
Created attachment 24112 [details] j2ee/utilities updated javadoc
Created attachment 24113 [details] new javadoc for ejbcore
Created attachment 24114 [details] ejbjarproject updater javadoc
See updated apichanges and arch for ejbmodule, j2ee-common and ejbjarproject. Ejbcore has only javadoc at this moment (arch.xml pending).
Looks good to me. Puts more logic into codebase.
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.
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.
Created attachment 24162 [details] commit log for ejb split and removal of impl. deps
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.
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.
v.