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.
It has been realized as a result of "Versioning of modules" discussion between me and Jesse (available at http://openide.netbeans.org/servlets/BrowseList?listName=dev&by=subject&from=147225) that the best distribution of a module API is as autoload module. As such the GUI needs to be separated from the module otherwise it might not get enabled at all. So I suggest to create module projects-api.jar that will contain the APIs + some necessary impl, but no GUI. Also create another module projects-gui.jar that will provide the rest. The projects-api should be autoload, projects-gui should depend on it and be either regular module or it might provide something that projects-api requires. So as soon as somebody needs the projects-api, the gui is also enabled. If there is a need to communicate between projects-api and projects-gui, you can use following trick. In projects-api have a class org.netbeans.modules.projects.Access that is abstract with all methods you need from the GUI part and static getter that uses lookup to get its instance. The projects-gui will then implement the Access class and register it in lookup (META-INF/services/org.netbeans.modules.projects.Access). Please restrict API packages in projects module so nobody can call the Access class if it depends just on specification version (the projects-gui needs to depend on implementation version).
One thing: if p-gui depends on p-api, you cannot have p-api require some token and p-gui provide it, because that would be cyclic. However recommended style is this: 1. p-api has an API and an SPI. SPI describes a (singleton?) implementation, say some abstract class. 2. p-gui depends on p-api, registers to lookup an impl of the SPI, and OpenIDE-Module-Provides the class name of the abstract SPI class too. 3. Other modules depend on p-api and OpenIDE-Module-Requires the same token. If you later decide to supply a non-GUI impl as a third module, usable programmatically but with no UI, then you would have 1. p-api (autoload): defines API and SPI 2. p-impl (autoload): depends on p-api, implements SPI and provides the token 3. p-gui (regular): depends on p-api, requires token 4. other modules: depend on p-api, require token
I'll take this task.
The projects module is split to two modules projects-core and projects-ide. See details on http://projects.netbeans.org/openissues/incompatible_issues.html and http://projects.netbeans.org/openissues/upgrade_27055.html. (related issue #27915)
This separation is good, but it does not exactly solves the problem that this issue wanted to solve. The problem is the preservation of investments and continuability and upgradability of modules. Because the project api depends on old datasystem it is possible for it to become obsolete. Then one needs to introduce emulator module. The thing is complex but believe me that it is much easier to provide the emulator module if it was always just autoload without any user functionality.
OK, I believe you, let's start preserving ...
schedule (4.0/milestone7)
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped.
--> VERIFIED