Bug 179289 - Remove impl deps from platform cluster
Remove impl deps from platform cluster
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: -- Other --
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Jesse Glick
issues@platform
http://deadlock.netbeans.org/hudson/j...
: API_REVIEW_FAST
Depends on: 177945 179828
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-07 09:47 UTC by Jesse Glick
Modified: 2010-01-25 12:52 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
:


Attachments
Running patch (142.48 KB, patch)
2010-01-18 19:38 UTC, Jesse Glick
Details | Diff
Graph of some dependencies of the mimelookup module (32.08 KB, image/png)
2010-01-21 14:58 UTC, vieiro
Details
DataSystems>MimeLookupAPI>MimeLookup on SystemFS>DataSystems (74.30 KB, image/png)
2010-01-21 15:00 UTC, vieiro
Details
Detail of other pseudo-circular deps (28.72 KB, image/png)
2010-01-21 15:02 UTC, vieiro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2010-01-07 09:47:00 UTC
For various reasons but especially to ease OSGi usage, we should remove all implementation dependencies inside the platform cluster. Currently I see:

MODULE org.netbeans.core.execution (platform)
  REQUIRES org.netbeans.api.progress (platform)
MODULE org.netbeans.core.startup (platform)
  REQUIRES org.openide.util (platform)
  REQUIRES org.openide.util.lookup (platform)
MODULE org.netbeans.core.ui (platform)
  REQUIRES org.openide.filesystems (platform)
MODULE org.netbeans.core.windows (platform)
  REQUIRES org.openide.explorer (platform)
  REQUIRES org.netbeans.core.output2 (platform)
MODULE org.netbeans.modules.progress.ui (platform)
  REQUIRES org.netbeans.api.progress (platform)
MODULE org.netbeans.modules.settings (platform)
  REQUIRES org.openide.util.lookup (platform)
MODULE org.openide.actions (platform)
  REQUIRES org.openide.util (platform)
  REQUIRES org.openide.util.lookup (platform)
MODULE org.openide.awt (platform)
  REQUIRES org.openide.util (platform)
MODULE org.openide.filesystems (platform)
  REQUIRES org.openide.util (platform)
  REQUIRES org.openide.util.lookup (platform)
MODULE org.openide.nodes (platform)
  REQUIRES org.openide.util (platform)
MODULE org.openide.util (platform)
  REQUIRES org.openide.util.lookup (platform)

I will try to prepare a branch for this work. Can submit to apireviews soon.
Comment 1 Jaroslav Tulach 2010-01-07 12:09:05 UTC
OK, I can help with the Lookups.forPath and ActionBridge stuff.
Comment 2 Jesse Glick 2010-01-07 16:00:19 UTC
I set up a branch, and a Hudson job to track progress.
Comment 3 Jaroslav Tulach 2010-01-08 03:32:30 UTC
I guess we can start incremental API review. Here is my proposed change in Lookup API:
http://hg.netbeans.org/prototypes/rev/0da1c161aa80
Comment 4 Jesse Glick 2010-01-08 14:30:25 UTC
The Hudson job is up and running, and artifacts show

1. The outstanding implementation dependencies.

2. The running patch against trunk.
Comment 5 Jesse Glick 2010-01-08 16:46:13 UTC
All impl deps have now been removed. Still need to document API changes, and review variously newly exposed interfaces to see if they can be simplified.
Comment 6 Jaroslav Tulach 2010-01-09 01:53:12 UTC
Y01 I am not fine with having org.openide.util.lookup.spi package in Lookup API. It is too disturbing for real users.

Y02 ActiveQueue is not Lookup API part at all. I did not separate lookup from the trash in Utilities to introduce new trash.

Y03 NamedServicesProvider shall be more hidden. http://hg.netbeans.org/prototypes/rev/0da1c161aa80 is where I want to have it.

Y04 MIMEResolver with <p><strong>Not intended for use by modules outside the NetBeans Platform.</strong> are quite poor. I would never let anything like that appear in the API (if I maintained it). If it cannot be called by external clients than let's hide it better.
Comment 7 Jesse Glick 2010-01-11 15:55:42 UTC
Y01 - the SPI subpackage seemed the best way to section off classes that regular users should not need to look at. (Y03 - putting it in the same package as API classes does not seem to make it "more hidden".) If you have a better idea, implement it.


Y02 - OK, but it needs to be somehow accessible to both modules. Same for AbstractServiceProviderProcessor.


Y04 - seems harmless to me but if you have a better idea, implement it. Using reflection seems worse than a straightforward disclaimer.
Comment 8 Jesse Glick 2010-01-16 09:01:35 UTC
Is there any progress on this?
Comment 9 Jaroslav Tulach 2010-01-16 11:36:23 UTC
Y01, Y02, Y03: I kept the 3rd API package, just renamed it and excluded it from javadoc: 6c0830509d46

Y04: Hiding in nested class in 5228e2fe46c6. I am sure people who like clean code will "love" this patch.
Comment 10 Jesse Glick 2010-01-18 19:38:15 UTC
Created attachment 93395 [details]
Running patch
Comment 11 Jesse Glick 2010-01-18 19:39:53 UTC
Please review; I will merge to trunk shortly.
Comment 12 Jaroslav Tulach 2010-01-19 03:12:27 UTC
Y11 The documentation is horribly insufficient, but I guess you know it. If nothing else, the @since is missing on almost all new classes.

Y12 I do not understand the reason for renaming spi.progress to modules.progress.spi. The versioning is tight to api.progress anyway, so the stability category will have to be the same regardless of the package name. For me the spi.progress looked more natural.

Y13 spi.progress.Controller shall be final or have package private contstructor (if it is really subclassed from tests).

Y14 ActionsBridge & its ActionRunnable is horrible, I eliminated the inner class in 03f6fdf8cfe1 and renamed the outer to ActionsInvoker.

Y15 ActionsInvoker and ActionPresenterProvider should rather be placed in org.openide.util.actions. They are clearly related to actions, and half of the ActionsInvoker is API anyway. I suggest to keep locality, so when splitting actions stuff away from openide.util (who knows when, of course) we don't need to split the org.openide.util.spi package.
Comment 13 Jesse Glick 2010-01-20 18:10:24 UTC
(In reply to comment #12)
> Y11 The documentation is horribly insufficient

Will be corrected.

> Y12 I do not understand the reason for renaming spi.progress to
> modules.progress.spi.

To discourage people from looking at it. I will hide it from Javadoc.

> Y13 spi.progress.Controller shall be final or have package private constructor
> (if it is really subclassed from tests).

It is really subclassed from tests, and they are not in the same package.

> Y14 ActionsBridge & its ActionRunnable is horrible, I eliminated the inner
> class in 03f6fdf8cfe1 and renamed the outer to ActionsInvoker.

Looks good. I just renamed it to ActionInvoker (better English).

> Y15 ActionsInvoker and ActionPresenterProvider should rather be placed in
> org.openide.util.actions.

Good suggestion, implemented. In that case it seems silly to keep org.openide.util.spi just for PreferencesProvider, so I am renaming it to NbPreferences.Provider which is natural enough anyway.
Comment 14 vieiro 2010-01-21 14:53:03 UTC
Hi,

I'm currently taking a look at dependencies in the platform cluster (I'm trying to see what the minimum set of modules is for a Swing application). 

I'm creating some dependency graphs in this subset of the platform cluster (not the whole platform cluster) for NetBeans 6.8, and I thought I could post them here just in case these are of any help. It seems there're some circular dependencies in there (because of the TYPE_REQUIRES, I think).

Edges correspond to org.openide.modules.Dependency.TYPE_REQUIRES, Dependency.TYPE_MODULE and Dependency.TYPE_NEEDS.

Please let me know if you want me to take a photo of any other module in the platform cluster.

Cheers,
Antonio
Comment 15 vieiro 2010-01-21 14:58:11 UTC
Created attachment 93465 [details]
Graph of some dependencies of the mimelookup module
Comment 16 vieiro 2010-01-21 15:00:06 UTC
Created attachment 93466 [details]
DataSystems>MimeLookupAPI>MimeLookup on SystemFS>DataSystems
Comment 17 vieiro 2010-01-21 15:02:33 UTC
Created attachment 93467 [details]
Detail of other pseudo-circular deps
Comment 18 Jesse Glick 2010-01-21 15:36:14 UTC
(In reply to comment #14)
> I'm currently taking a look at dependencies in the platform cluster (I'm trying
> to see what the minimum set of modules is for a Swing application). 

Interesting but off topic here. This issue is about removing implementation dependencies from the platform cluster and nothing else. Better to post to nbdev.

> It seems there're some circular
> dependencies in there (because of the TYPE_REQUIRES, I think).

The NB module system forbids cyclic dependencies. OpenIDE-Module-{Requires,Needs,Recommends} dependencies are on tokens matching OpenIDE-Module-Provides, not specific modules, meaning you can substitute alternate implementations if you prefer.
Comment 20 Jesse Glick 2010-01-22 08:15:28 UTC
core-main #e109df9be1af
Comment 21 Quality Engineering 2010-01-24 08:36:28 UTC
Integrated into 'main-golden', will be available in build *201001240200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/45e9678d6a80
User: Jesse Glick <jglick@netbeans.org>
Log: Backed out changeset 4a2cfb7f789e
Being done differently in #179289.


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