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.
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.
OK, I can help with the Lookups.forPath and ActionBridge stuff.
I set up a branch, and a Hudson job to track progress.
I guess we can start incremental API review. Here is my proposed change in Lookup API: http://hg.netbeans.org/prototypes/rev/0da1c161aa80
The Hudson job is up and running, and artifacts show 1. The outstanding implementation dependencies. 2. The running patch against trunk.
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.
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.
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.
Is there any progress on this?
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.
Created attachment 93395 [details] Running patch
Please review; I will merge to trunk shortly.
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.
(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.
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
Created attachment 93465 [details] Graph of some dependencies of the mimelookup module
Created attachment 93466 [details] DataSystems>MimeLookupAPI>MimeLookup on SystemFS>DataSystems
Created attachment 93467 [details] Detail of other pseudo-circular deps
(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.
Probably final patch, will merge tomorrow: http://deadlock.netbeans.org/hudson/job/platform-impl-deps-179289/lastSuccessfulBuild/artifact/nbbuild/build/platform-impl-deps-179289.diff
core-main #e109df9be1af
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.