Bug 198530 - Examine and remove unnecessary dependencies between modules
Examine and remove unnecessary dependencies between modules
Status: NEW
Product: platform
Classification: Unclassified
Component: -- Other --
7.0
All All
: P2 with 1 vote (vote)
: TBD
Assigned To: issues@platform
issues@platform
: UMBRELLA
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-11 20:50 UTC by tomwheeler
Modified: 2013-12-27 12:12 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tomwheeler 2011-05-11 20:50:00 UTC
As I wrote in issue #198529, there are currently dependencies between modules which seem unnecessary and which contradict the granular and modular nature of the platform.

I therefore request that dependencies between modules, especially in the 'ide' cluster, be re-examined to determine whether they really are needed and that any unnecessary dependencies be removed.  The 'platform' cluster is in pretty good shape, but here are some other dependencies I found by checking what errors resulted as I disabled modules in the 'ide' cluster for a platform application.  Additional unnecessary dependencies would surely come to light using a more scientific method and/or by examining other clusters:

- Editor module depends on Search API

- Many modules (e.g. Diff,  Editor Braces Matching, Jump To, Terminal, Versioning, etc.) depend on deprecated Swing Layout Extensions module from 'platform' cluster.  According to the FAQ (http://wiki.netbeans.org/FaqFormSwingLayoutLibrary), this is part of JDK 6, and since NetBeans now requires JDK 6, it seems that these should be removed.

- Directory chooser depends on Project API

- Editor Bookmarks depends on Project API (maybe that makes sense; I don't use bookmarks)

- Spellchecker Core depends on Project API

- Editing Files oddly depends on CSS Visual Editor, which has a lot of other dependencies.

- Hudson depends on Core IDE, which has a lot of other dependencies.
Comment 1 Antonin Nebuzelsky 2011-05-25 13:19:12 UTC
Changing to umbrella enhancement.

Jesse, Jarda, please comment on the individual cases mentioned by Tom.
Comment 2 Antonin Nebuzelsky 2011-05-25 13:24:40 UTC
Changing to umbrella enhancement.

Jesse, Jarda, please comment on the individual cases mentioned by Tom.
Comment 3 cappicard 2011-07-18 22:05:20 UTC
This may be related. I only include the platform modules in my Suite project. Creating NBMs works fine. However, when I do "ZIP Distribution," the other clusters are still included even though I do not check them in the Suite Project Properties.

This is causing my Suite app to attempt to load all the extraneous modules (sometimes causes my app to freeze).

This is happening with 7.0 with latest module updates.
Comment 4 Jesse Glick 2011-07-18 22:50:31 UTC
(In reply to comment #3)
> This may be related.

It is not.
Comment 5 tomwheeler 2011-11-02 17:34:38 UTC
I discovered another one in the 10/25/2011 nightly build:

  Module NetBeans Plugin Development in apisupport depends on 
  module CRUD Application Platform Sample in apisupport but 
  this is excluded.

Support for plugin development ought not depend on having an example module installed.  AFAICT, The apisupport.crudsample module doesn't even define a public API.
Comment 6 Jesse Glick 2011-11-10 20:31:05 UTC
(In reply to comment #5)
>   Module NetBeans Plugin Development in apisupport depends on 
>   module CRUD Application Platform Sample in apisupport
> 
> Support for plugin development ought not depend on having an example module
> installed.

"NetBeans Plugin Development" is apisupport.kit, the higher-level user feature visible in Plugin Manager which among other things pulls in samples. If you do not want all this, do not enable apisupport.kit.
Comment 7 tomwheeler 2011-11-10 20:52:39 UTC
I'd be willing to bet that > 95% of NetBeans Platform developers don't know the specific purpose of apisupport.kit because it has no description in the suite customizer's Libraries tab.  As such, it would be hard for someone to determine whether or not to enable it for a given project, nor what dependencies it should reasonably have.

I guess what I pointed out in comment #5 is therefore a documentation/usability problem rather than an incorrect dependency problem.  There are a number of similiarly undocumented modules (e.g. Maven NetBeans Module Projects); if I get time, I will file a separate issue and list all of them there.
Comment 8 Jesse Glick 2011-11-16 00:20:14 UTC
(In reply to comment #7)
> apisupport.kit [...] has no description in the suite
> customizer's Libraries tab.

True, has no short description. Can be fixed. Probably never noticed since Plugin Manager just shows the long description in all cases I know of.

Maybe more relevant is that the Libraries customizer does not indicate visible modules ("plugins"), which could be relevant when deciding what modules to focus on. http://wiki.netbeans.org/DependencyBasedModuleIncludes may be the right system in the long run.

> There are a number of
> similarly undocumented modules (e.g. Maven NetBeans Module Projects); if I get
> time, I will file a separate issue and list all of them there.

Or just patch the module yourself to include a short description.
Comment 9 Quality Engineering 2011-11-17 07:30:57 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/de4f6b0491e7
User: Jesse Glick <jglick@netbeans.org>
Log: Adding short description as mentioned in #198530.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo