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.
Tried today to install a module globally in our branded application built on top of NetBeans 6 RC2 platform with no success. Looks like there is no longer a way for the user to specify if a certain module is to be installed globally or locally. (there used to be a checkbox next to each module in the list of available modules in NetBeans 4 and 5, old Update Center Window). There is a checkbox in the Settings tab of the Plugins window (Tools -> Plugins) called "Force install into shared directories", but when that is checked it does not seem to do the job for the installable modules (i checked that box to on and then selected some modules to install, and then i saw that their jars were in the user directory, not the installation directory). Also, about that "Force install into shared directories" checkbox: what is that supposed to apply to? The checked Update Centers in the above list? Or to whatever modules you download at that particular time? Not extremely clear in terms of usability it seems, or at least, not the same functionality as before. We need to be able to install certain modules globally, is there any work around? In the past, we used to mark modules with: nbm.is.global=true in their project.properties files Does that still work?
Curious. It should really work. The switch 'Force install into shared dirs' forces all plugins will installed into install dir since it has been switched on. Besides that switch the option 'nbm.is.global' should work as well as before. Of course, users must have write permission on install dir. I have verified it on RC2 http://bits.netbeans.org/download/6.0/nightly/latest/zip/netbeans-trunk-nightly-200711050000.zip and it worked for me. To monitor target directory on being installed plugin you can run your IDE more verbose with options -J-Dnetbeans.logger.console=true -J-Dorg.netbeans.modules.autoupdate.services.InstallManager.level=-1 and then attach your messages log.
Maybe we are doing something different: going to specify all steps to reproduce. I am also attaching the final suite/modules used, in case you do not feel necessary to follow the steps below. 1. With NB IDE 6 RC2 (or your nightly build), create a new Module Suite "myplatform", brand it "myplatform", remove all clusters except platform7 from it, compile, create platform, and add it to your list of platforms with Tools -> NetBeans Platform (it will have a name like "myplatform 200711050000"). 2. create a second Module Suite "myapp", brand it as "myapp", make it point to myplatform (right-click on myapp->Properties->Libraries->NB Platf set to "myplatform"), compile, do create-platform. 3. go to directory myapp\dist\myapp\bin and double click on myapp.exe to launch it. 4. go back to NB IDE 6 RC2 and add a new module "globalmodule" to your "myapp" suite. 5. in globalmodule's project.properties file, add line: nbm.is.global=true to force global installation. 6. create an nbm out of module globalmodule. 7. go back to myapp that you opened at step 3, go to Tools -> Plugins -> Downloaded -> Add Plugins..., add org-yourorghere-globalmodule.nbm and install it. Now, at this point in time, the first bug i notice is that if you click on the Installed tab, this module does not show: you have to restart myapp to be able to show it. Closing the Plugins Window will not be enough for refreshing the list of installed modules. The user at this point does not know if the module was installed or not. 8. Go check where the globalmodule was installed in your filesystem: you will find it in .myapp\dev\modules in your user dir, and not in dist\myapp\myapp\modules where it should be. 7'. Now take a different route, back to step 7: try forcing global installation from the UI this time. First close myapp, delete user dir .myapp\dev, restart myapp as in step 3 (not from NB IDE). Go to Tools -> Plugins -> Settings -> select checkbox "Force install into shared directories" and redo step 7: you will see the same problem as described above. As a last comment, the "Force install into shared directories" checkbox, even if it worked, has now less functioanlity than before. If i understand the use case of that checkbox correctly (please confirm), it applies to everything, not selectively. So, if someone forgets that checkbox on, all modules installed in future updates will all be installed globally. Again, not totally sure if that is a usability enhancement.
Created attachment 53574 [details] zip containing myapp, myplatform and globalmodule
> ------- Additional comments from massimo@netbeans.org Tue Nov 27 22:24:49 +0000 2007 ------- > Maybe we are doing something different: going to specify all steps to reproduce. > I am also attaching the final suite/modules used, in case you do not feel necessary to follow the steps below. > > 1. With NB IDE 6 RC2 (or your nightly build), create a new Module Suite "myplatform", brand it "myplatform", remove all > clusters except platform7 from it, compile, create platform, and add it to your list of platforms with Tools -> NetBeans That's the crucial factor. The Autoupdate uses SPI for creating newone clusters. This functionality providers the module Update Centers in nb6.x cluster. See http://bits.netbeans.org/6.0/javadoc/org-netbeans-modules-autoupdate-services/org/netbeans/spi/autoupdate/AutoupdateClusterCreator.html In this case Autoupdate cannot create new one cluster and has to install into userdir. You should add that module Update Centers into your application or provide own cluster creator. ... > As a last comment, the "Force install into shared directories" checkbox, even if it worked, has now less functioanlity > than before. > If i understand the use case of that checkbox correctly (please confirm), it applies to everything, not selectively. So, > if someone forgets that checkbox on, all modules installed in future updates will all be installed globally. Again, not > totally sure if that is a usability enhancement. By usability study on NB5.5 Autoupdate user didn't understand meaning of Global check in Install wizard which makes them confusing. UI spec for current Autoupdate UI aka Plugin Manager tries to hide this option for most users.
Thanks for your response, but i am afraid i did not understand. Do you mean that we need to include module Autoupdate in our first suite? Sorry, but i cannot verify your response without understanding what to do.
ok, i am sorry, but this issue is blocking our release... If this is not working right now, it is fine, but we would just need to know about it. If it is working, is there any way we can have a more descriptive answer to this? Maybe some documentation somewhere with an example on how to have a module install globally. Looked into page: http://platform.netbeans.org/articles/update-descriptor-specification.html#what-is-target-cluster but after setting nbm.target.cluster correctly, it did not do it. Also taken a look at page: http://bits.netbeans.org/6.0/javadoc/org-netbeans-modules-autoupdate-services/org/netbeans/spi/autoupdate/AutoupdateClusterCreator.html but that does not tell us what to do. What do you specifically mean by "newone cluster"? the sentence "Autoupdate cannot create new one cluster" refers to what exactly? AutoUpdate now creates new clusters? I guess the bottom line question is: how can we manage to have it work as it was working before?
I assert the functionality is working. This switch is working in NB6. QE guys, please verify. Moreover, the global installation was not found as key feature in Autoupdate => decreasing the priority. My good suggestion is don't remove Update Centers module because that module is provider SPI for creating new clusters in NetBeans IDE. I can simple use it or copy&paste this functionality into your code if you want not use that module. Ad target cluster: there a reviewed API change in target.cluster handling tracked as issue 111701 where is specified how Autoupdate should behave. Fell free to contact me directly or mail on openide-dev@netbeans.org I'll help you with SPI what was said before.
P5 was set by mistake.
Created attachment 55539 [details] Complete testcase (source, .zip and updated .nbm)
I created a testcase that fails. Unzip the testcase-122815.zip, you will find: * source.zip: a suite with 3 modules: - clustercreator 1.0: the module containing a AutoupdateClusterCreator (like NB updatecenters module) as Jiri suggested. - localmodule 1.0: is a regular module - globalmodule 1.0: is a regular module with nbm.is.global=true and nbm.target.cluster=suite_testglobal * distribution.zip: the result zip from build-zip target in the suite * org-yourorghere-globalmodule-1.1.nbm: an updated version of globalmodule (spec version = 1.1) Now follow these steps: 1) unzip the distribution.zip 2) run the suite_testglobal application 3) install the org-yourorghere-globalmodule-1.1.nbm using Plugin Manager The 1.1 version of globalmodule is installed locally, not globally as we expected to be...
Weird thing: the previous test has been done in a Linux machine. I'm testing right now in a Windows machine and it installs globally the globalmodule...
Confirmed, works on my end as well when trying suite_testglobal on Windows XP. However, it still does not work on Linux, nor in our branded application, where is the difference?
I don't understand why this issue was decreased to P3. Some modules needs to do installation and update do installation dir. We preferes update to new version by using autoupdate. We did branding of splashscreen in our product. The branding must be installed globally. Property nbm.is.global=true doesn't work. Force to install to shared directory checkbox also doesn't. This feature was working in NetBeans trunk in September 2007. I don't understand why it was disabled.
Fixed a problem with normalization of java.io.File http://hg.netbeans.org/main/rev/220df670b1cd
Jirko, thanks a lot. The fix works also fine in release60 branch. I am also interested in writing regression test for our critical issue. I am not sure if it make sense if test results are not published outside SWAN. Jardo and Mariane what do you think?
Zajo, it would be glad to see your contribution to regression test suite. I think it would be useful even if it's running inside SWAN.
Yes, you can run the test inside Sun and publish them outside. Test results are helpful for someone, who is not Sun employee, to integrate, develop his own app based on platform or fix bug in NetBeans because from the test history you know which test are passing and failing...