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.
The value of %IDE_HOME% and %IDE_USER% are the same. The problem seems to be in the code autoupdate.services/libsrc/org/netbeans/updater/ModuleUpdater.java: private String replaceVars(String original) { original = replaceAll(original, VAR_IDE_HOME, UpdateTracking.getPlatformDir () == null ? "" : UpdateTracking.getPlatformDir ().getPath()); // <----------- getPlatfromDir() original = replaceAll(original, VAR_IDE_USER, UpdateTracking.getPlatformDir () == null ? "" : UpdateTracking.getPlatformDir ().getPath()); // <----------- getPlatfromDir() also original = replaceAll(original,VAR_FILE_SEPARATOR, UpdateTracking.FILE_SEPARATOR); original = replaceAll(original,VAR_JAVA_HOME, System.getProperty ("java.home")); return original; } This bug needs to be fixed in NB 6.1. Cannot wait for 6.5 release. Thanks, __Nasser
The new release of NetBeans DTrace gui plugin does not work without the fix to updater module. The next NB 6.1 patch must include the fix to updater module. Thanks, __Nasser
patch2 candidate - requested by sustaining
Already fixed in NB6.5 - changeset 39c00ad59e33 Because NetBeans 6.1 is out there is no way to fix it in NB6.1. We could ask sustaining team to backport it to NetBeans 6.1 IDE but you cannot suppose all IDE users apply that patch. I guess patching might be more useful for delivering bugfixes of most intrusive end-users bugs rather than platform bugs like this. Anyway, please write down you use-case why you need post-install hook for DTrace GUI. I decreased the priority until get a justification the problem behind. We really need to know known use-cases to tune post-install feature for real usage. I'm wonder no-one needed %IDE_USER% since NetBeans 4.0 where the bug was appeared. Thanks
The new DTrace GUI plugin has dependencies on an external jar file that cannot be bundled with the nbm file. The external jar file needs to copied into the user.dir/modules/ext directory before the class loader loads the Java classes. Passing the incorrect value for %IDE_UDER% makes the post-install a useless feature in NB. Currently, there is no other alternative to get around the external jar file in NB 6.1. This bug needs to be fixed in the next NB 6.1 patch. Otherwise I have to delay the release of the new DTrace gui for another 6 months!!!
YOU are NOT allowed to set Target Milestone field. It is up to the developer to decide where it will be fixed! OTOH: 1, this issue has been fixed in trunk. It CANNOT be fixed in NB 6.1. The release was published a month ago. Nor priority zero will help you to get it into published release. I'm changing it back to the right priority P3 2, this issue is marked as candidate for patch2 for NB 6.1 3, I still don't see how you can depend on a fix in a patch. Please, make it clear for users of dTrace plugin that the plugin will work only and only when they have patch2 in NB6.1 please, verify that the fix works for you. This is more important than changing TM and priority.
Nasser, I see what you say but we can find another solution for this. You stated you need to copy /usr/share/lib/java/dtrace.jar into the user.dir/modules/ext directory. I guess you can copy that file into as same cluster as dtrace plugin is being installed and it will work for you as well. (Because your plugin doesn't declare any target cluster it causes the dtrace plugin will be installed into userdir, anyway). I've just updated a sample on http://wiki.netbeans.org/DevFaqNbmPostInstall to show how to get cluster directory in post-install hook. Since you will know the cluster directory you can copy /usr/share/lib/java/dtrace.jar to <cluster_directory>/modules/ext. With using the proposed solution this bug could not be blocker for you in NetBeans 6.1. Do you agree? Thanks By the way: I should declare dtrace plugin to be Solaris only specific. Just declare OpenIDE-Module-Requires: org.openide.modules.os.Solaris in dtrace plugin's manifest.mf and rebuild your NBM (more info in http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#how-os-specific)
Jirka, your fixed to the updater module works fine. Additionally, the workaround solution that you have shown in your example, works properly with DTrace module. If the Dtrace module is installed in "extra" clauser, does the update directory reside under the "extra" directory? extra / \ update modules If yes, then we have a workaround solution for NB 6.1 and I can release the DTrace plugin without waiting for NB 6.1 patch 2. Thanks, __Nasser
> If the Dtrace module is installed in "extra" clauser, does the update directory reside under the "extra" > directory? Yes. update directory will be created by declared target cluster (course, depends on write permission of that cluster. If the extra cluster was read-only then the plugin would be installed in to userdir which must be writable always.) Under the update directory will be unpack post-install classes too. > If yes, then we have a workaround solution for NB 6.1 and I can release the DTrace plugin without waiting > for NB 6.1 patch 2. It's good. A dependency on a patched code could be risky in such cases. Sounds good your confirmation the workaround works for you. Thanks
nassern confirmed it is working now. I also have checked the diff -> I am marking this issue as verified.
The fix has been ported into the release61_fixes branch: http://hg.netbeans.org/release61_fixes/147d22f750b2
Removed fixes2 related status whiteboard - final decision is that this fix cannot be delivered to the patch2 (see issue #138450).