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.
During implementation of issue 22922 I discovered old known problem, that NetBeans don't support update of OpenIDE and Core using .nbm files. See http://www.netbeans.org/servlets/ReadMsg?msgId=323108&listName=nbdev http://www.netbeans.org/servlets/ReadMsg?msgId=323874&listName=nbdev or see discussion in thread http://www.netbeans.org/servlets/BrowseList?listName=nbdev&by=thread&from=11993
IMHO the basic issue here is a lack of feature support in the autoupdate module.
Why don't make a hack: create an empty module thecore.nbm, which will include: - lib/core.jar, - lib/core-*.jar's, - lib/openide.jar and - modules/thecore.jar - small and absolutely empty, non- functional module with only one bundle inside and with a module manifest
That will mostly work. It will not work to update thecore.nbm when a module declares that it needs a newer OpenIDE version. However you could maybe hack around that by changing <makenbm> to replace OpenIDE-Module-IDE-Dependencies: IDE/1 > 2.34 with OpenIDE-Module-Module-Dependencies: thecore/1 > 2.34
Ok, so I can try to do following: I'll add the build of fake module to the core/build.xml nbm target. It will create the nbm with the structure Maxym suggested. There will be no openide/build.xml nbm target. Questions: Is the name "thecore" the right one we should use? There is a plan to separate openide to pieces and to slowly remove some of them - the current suggestion is that we will introduce thecore2, thecore3 modules. Is this the right way to proceed? Should not I call the module thecore-minus5 ;-?
> -- from Jesse -- > However you > could maybe hack around that by changing <makenbm> to replace > OpenIDE-Module-IDE-Dependencies: IDE/1 > 2.34 > with > OpenIDE-Module-Module-Dependencies: thecore/1 > 2.34 not replace, but add along, I suppose, because modules must be dependent on the version of the core
To Maxym: no, really replace. But *only* in the Info/info.xml file in the NBM, *not* in the actual module manifest. E.g. you are currently running OpenIDE v. 1.23, and thecore (or whatever) 1.23. You see a new module that says it requires thecore 1.24. AU will then update thecore if you request the new module. You cannot leave the OpenIDE dependency in the info.xml file or AU will just say the new module cannot be run on your current installation at all. But if it thinks that thecore is a regular module, it should happily download both, unpack, and restart NB, at which point the NB module system will verify that the dependencies really work (it does not trust AU to do this). To Yarda: I guess I would actually use "org.openide" as the module name. If we do later split up openide into pieces, the new pieces will presumably be real modules, so we don't have to worry about them. "org.openide" will continue to mean the remaining monolithic Open APIs. We can do something in AU similar to what the module system does: if you e.g. split off the Execution API, you can change <makenbm> (or AU client??) to make old modules (with low IDE/1 dependencies) automatically depend on the new autoload, whereas newer modules (with high IDE/1 dependencies) can choose whether or not to depend on it. The physical API would be removed from the startup classpath of course. Does that work?
Created attachment 6033 [details] I seem to have it. Jesse, I am composing the org-openide.nbm in temporary directory openide/fake and copying there a openide/netbeans core/netbeans and core/*/netbeans content, is this a possible solution or do you want to change something? If this is ge
That sounds basically right to me. 1. <license> will need to include licenses for all extra binaries included in the core. Perhaps Ruda can help here by patching the build script after it is basically working. 2. Petr Hr. - it is ugly that all the core submodules are *still* in lib/. They do not need to be here AFAIK. They should be in modules/eager/ (later modules/autoload/ for some like compiler and execution that may not always be needed). And they should have their own NBMs just like any module. Note that core/javahelp is already treated as a regular module. 3. Consider the fact that unpacking org-openide.nbm might clobber file permissions of e.g. runide.sh on Unix. Ales, do you know if this is a problem, and does AU support extracting with permissions? 4. You probably cannot put the localizing bundle for the module in the org.openide package. It might not be found (since org.openide is available in app classpath). I would recommend having a separate mini source tree containing just e.g. fakesrc/org/openide/fake/Bundle.properties. If you would like help with 1 & 4 especially and maybe 2 & 3, feel free to assign to me; I can work on it and commit a revised version of the patch. Your choice. BTW avoid such long comments in attachment descriptions, they are not line-wrapped in IZ's display...
nbm target is in CVS. I've implemented just the #4 - not using org/openide/Bundle.properties for description of the module bundles. Jesse reassigning to you to take care of anything else you think should be done. /cvs/openide/build.xml,v <-- build.xml new revision: 1.93; previous revision: 1.92 RCS file: /cvs/openide/org-openide.mf,v done Checking in org-openide.mf; /cvs/openide/org-openide.mf,v <-- org-openide.mf initial revision: 1.1 done RCS file: /cvs/openide/org-openide.properties,v done Checking in org-openide.properties; /cvs/openide/org-openide.properties,v <-- org-openide.properties initial revision: 1.1 done
I guess org-openide.properties should be in a package, not top-level... also perhaps org-openide.jar should be "eager" to make sure users cannot turn it off. I will check on it. Thanks for initial impl.
I see one problem: in order to let the user actually update this NBM from a real build, the fake module needs to be included in a regular build, so there is something to update from. I.e. if the fake module is not in the regular build, any user going to the update center will see it as a potential download, and any module depending on it will cause the whole NBM to be retrieved - even if the user in fact already has the correct version of core! So can this this fake module be included in the standard module list as generated by openide/build.xml:netbeans, and in the standard update_tracking.xml?
Created attachment 6055 [details] Possible patch from current CVS sources
The attached patch makes openide.jar into a real module with name org.openide/1. openide-core.nbm contains all core and openide files. Auto Update is modified to treat API dependencies as actually being a dependency on org.openide/1, so that openide-core.nbm can be downloaded if needed. I am going to explore whether it is in fact possible to make separate openide.nbm and core.nbm and core-*.nbm files, divided in the natural way, and have AU actually understand it. That would be cleaner than this patch, I think. It depends on what our policy is for updating core & openide separately. I hope it is OK to update only openide, but not OK to update only core.
*** Issue 16069 has been marked as a duplicate of this issue. ***
Above patch also needs to comment out <genlist> task in netbeans targets of core/*/build.xml.
Created attachment 6057 [details] Different patch making separate core.nbm, openide.nbm, and core-*.nbm
Fixed with the second patch. It really seems to work on Linux at least. On Windows I would assume issue #24361 would be a problem. I tried creating fake updates to core.nbm, openide.nbm, and text.nbm, where the new core and text both depended on the new openide. The AU wizard with the patch correctly forced you to get openide.nbm if you chose either core.nbm or text.nbm or both. Notes: (1) This impl requires that openide be kept compatible even for "inner APIs", i.e. things which can only be implemented by core. Example: adding a new method to org.openide.windows.Workspace is incompatible even though only core can be affected. If the user updates the new openide.nbm, he/she will have to update core.nbm too (AU will not force it), or errors may result. (2) OpenIDE-Module: org.openide/1 is in fact used in openide.jar and it works for AU. You cannot manually add a new lib/*.jar module using the ModuleNode GUI; you need to use AU, or shut down and manually copy over the existing JAR. Hence Ruda's problem reported on nbdev (DuplicateException) - this is correct behavior. committed * Up-To-Date 1.6 autoupdate/src/org/netbeans/modules/autoupdate/DummyModuleInfo.java committed * Up-To-Date 1.7 core/.cvsignore added * Up-To-Date 1.1 core/apache-license.txt committed * Up-To-Date 1.52 core/build.xml committed * Up-To-Date 1.3 core/manifest.mf committed * Up-To-Date 1.340 core/src/org/netbeans/core/Bundle.properties committed * Up-To-Date 1.41 core/src/org/netbeans/core/modules/NbInstaller.java committed * Up-To-Date 1.209 nbbuild/build.xml committed * Up-To-Date 1.17 openide/.cvsignore committed * Up-To-Date 1.95 openide/build.xml committed * Up-To-Date 1.28 openide/manifest.mf removed * Up-To-Date 1.1 openide/org-openide-nbm-license.txt removed * Up-To-Date 1.1 openide/org-openide.mf removed * Up-To-Date 1.1 openide/org-openide.properties committed * Up-To-Date 1.34 openide/src/org/openide/Bundle.properties committed * Up-To-Date 1.15 openide/www/versioning-policy.html