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.
I would like to see that future NetBeans system for module management is based on some standard like JSR-277 or JSR-291. This will help to me and to all of the programmers to use NetBeans as core for our future local and remote (through RMI, JWS/JNLP) Applications. Having in mind that GlassFish v3 is based on Apache Felix OSGi Framework implementation this will be very good starting point for the next NetBeans version.
Yarda is already experimenting with this. Not sure what the actual status and plans are. See wiki page.
OK. I will, but I would like to give you my opinion having in mind my experience that the Dynamic Module System (JSR-291/OSGi) is much better than static (JSR-277/JSR294).
*** Issue 128611 has been marked as a duplicate of this issue. ***
As of Nov 12, 2008: The code in http://hg.netbeans.org/netigso/rev/92dcd900be05 allows OSGi bundles to be present at places where NetBeans module JARs are expected. E.g. modules/org-myorg-mybundle.jar (with appropriate config/Modules/org-myorg-mybundle.xml). In such case those bundles are started in appropriate container. Other modules and bundles can have dependencies on it, OpenIDE-Module-Module-Dependencies: org.myorg.mybundle > x.y works. This should be enough for everyone who wants to experiment with the alternative container. Still tbd: bundles cannot have dependency on NetBeans modules. E.g. Require-Bundle: org.openide.awt;version[1.0,9.0] does not work yet. I have no near time plans to implement it.
Great, but if we can not use OSGi bundles together in/with NetBeans then all benefits are lost. My idea and desire is to use NetBeans as Java Web Start environment and base for all of my existing and future applications. This means to use all available NetBeans plugins also.
Created attachment 84504 [details] Needed changes in NetBeans Runtime Container
I'd like to integrate these little changes in o.n.bootstrap and core.startup to main product line. Those were the only necessary changes in the core platfrom to create the bridge - the rest is available as separate module (a friend of o.n.bootstrap and core.startup). My plan is to make the bridge module available on a dedicated autoupdate center and claim that this issue is fixed in 6.8. There is a unit test to demonstrate why these changes are needed and prevent future regressions. The change includes one public method and then bunch of fallback code to eliminate NPEs and other exceptions.
[JG01] I would like some kind of explanation for the changes to ProxyClassLoader. This class is quite complex and any regressions would be disastrous. Semantic changes should also be tested directly in ProxyClassLoaderTest, without referring to other module system classes. [JG02] Minor note: @SW is unnecessary - just use Enumerations.<URL>empty().
MK1: Let's assume that a jar will have both Netbeans and OSGI metadata, which will be preferred? Will one be used consistently once chosen? or will they be merged somehow?
In my opinion the feature is in OSGi. That's why it will be very helpful if all new NetBeans modules are written as OSGi bundles. And if is possible to have OSGi Metadata only will be much better. If this happen, then the NetBeans GUI (Wizard, etc.) for NBM should be improved to support OSGi. And this will be the proof that NetBeans support OSGi.
Created attachment 84595 [details] Updated patch with special test for ProxyClassLoader
JG01: The change in ProxyClassLoader shall be safe. Basically I used Introduce Method refactoring - supposedly safe. Then I called this method (and findResource too) in new situations that would previously resulted in an error. Thus existing working code shall not be affected. MK01: This question is not really related to this patch. The core.netigso module shall stay on (some) autoupdate for now. Currently the NetBeans dependency metadata are checked first and only if they are missing the system seeks the OSGi ones. To mnachev: Here is some background on the Netigso project explaining the motivation behind my decisions: http://wiki.apidesign.org/wiki/OSGiAndNetBeans
Created attachment 84599 [details] Demonstration (as add-on patch) that no changes to PCL are needed, rather that the tests were erroneous
Thanks for your help: http://hg.netbeans.org/netigso/rev/47431b23c843 So the plan is to integrate your add-on-patch too - e.g. no changes in ProxyClassLoader
Tomorrow I plan to integrate my last patch and Jesse's add-on-patch.
After integration of core-main#d8fe1b7651e5 the NetBeans system is ready to co-exist with OSGi via the Netigso effort. For further discussion use http://wiki.apidesign.org/wiki/OSGiAndNetBeans its download resources, mailing lists, bug tracking system, etc.
Integrated into 'main-golden', will be available in build *200907160201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/d8fe1b7651e5 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #149013: Necessary changes to allow external support for OSGi via the core.netigso module. See http://wiki.apidesign.org/wiki/OSGiAndNetBeans for motivation behind these changes
Hi all. I'd like to ask for review before integration of my Netigso[1] project into main NetBeans code base. The overall document is available at http://wiki.netbeans.org/OSGiAndNetBeans Please look at it and share with me your high level concerns. Especially concerns related to the runtime support (also explained in [1]). In case you want to see the gory details, please look at following Dec 17, 2009 patch: http://hg.netbeans.org/netigso/rev/bdd047e466b0 It contains the source for core.netigso module itself as well as NetBeans Ant Based Project changes. I plan to integrate these two areas next week. The Maven part shall follow by end of Jan, 2010. The "dual" metadata will follow if time permits. Please express your comments here or in issue [2]. -jst [1] http://wiki.apidesign.org/wiki/Netigso [2] https://netbeans.org/bugzilla/show_bug.cgi?id=149013
Updated diff as of Jan 6, 2010: http://hg.netbeans.org/netigso/rev/2d3edf6cd0bd
TZ01: How solves the bridge from BundleContext to Lookup the ungetService. I haven't found it in the patch, but the patch is very huge. If it is not solved, it can be done by the WeakReference with an activeReferenceQueue doing the unget. (TCA).
Thanks for the review. I reported the TZ01 as bug 179389 and will try to solve it later (not really easy). I'll integrate the rest tomorrow.
Merged as core-main#2f58f43d47fb
Integrated into 'main-golden', will be available in build *201001131418* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/2f58f43d47fb User: Jaroslav Tulach <jtulach@netbeans.org> Log: Merge of #149013: Netigso - the NetBeans Platform support for OSGi