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.
[ BUILD # : 200509251800 ] [ JDK VERSION : 1.6 ] Bryan E. Boone wrote: > On Monday 26 September 2005 12:58 pm, Jan Chalupa wrote: > >>Bryan E. Boone wrote: >> >>>On Monday 26 September 2005 09:56 am, Bryan E. Boone wrote: >>> >>>>Has anyone else installed NetBeans somewhere other than the default >>>>location? I did, and ant doesn't seem to reflect the installed location. >>>>That is, it still points to nebeans-5.0dev/ide6/ant/lib. >>> >>>That being said, It's easy enough to change in the options. Just >>>unexpected. Is this value set at install time or in the >>>[user]/.netbeans/dev settings? >> >>Did you reuse the same userdir by any chance? The value definitely is >>not set at install time, but it may be persisted in the userdir the >>first time you run the IDE, or access the Ant settings (not sure at the >>moment). >> >>-Honza > > Yes, I reused the same userdir, but isn't that expected? > I can set the location for the install, but not the userdir (ok, really I can, > but not in the installer) Yes, I think you're right. No settings should be persisted unless explicitly set. It might be a settings bug. Feel free to file it. We'll look at that. -Honza
ant?
There *used* to be a bug that changes to unrelated Ant settings (e.g. Verbosity) would store a hardcoded Ant location referring to the NB installation, but that was fixed a while back (issue #43522). If this is rebroken, it is probably due to recent changes in the Options dialog. But first we would like to have explicit steps to reproduce from scratch. Hanz do you want to take a look, since this is probably your code? If not, just pass back to me.
I think the problem is that the new Options infrastructure persists most (all?) of the settings as soon as the Options dialog is opened for the first time. I've just verified that on the Beta candidate build. Steps to reproduce: 1. Start with a fresh userdir. 2. Open Tools | Options. Do nothing else. Close the Options dialog. 3. Shutdown the IDE. Now, ${userdir}/config is populated with a lot of stuff that hasn't been touched by the user at all. For example: Services/IndentEngine Services/formsettings.settings Services/org-apache-tools-ant-module-AntSettings.settings Services/org-netbeans-core-IDESettings.settings ... Obviuously, if there is an absolute path pointing to the IDE installation stored as part of the settings (as is the case for Ant), and the userdir is being reused from multiple IDE installations, there's a problem. The build system gets completely broken and typical user has no chance to figure out what's wrong. Raising prio to P2.
... and removing the INCOMPLETE keyword.
I know about it.
Please also test the following case: 1. Start w/ fresh userdir. 2. Open Options, change Verbosity to Verbose, press OK to close. 3. Open Options again, change Verbosity back to Normal. 4. Move (do not copy) NB installation to a different dir. 5. Start new installation on same userdir as before. 6. Run Ant e.g. on some project - ought to work. Options should show Ant location beneath new NB installation (ide6/ant/ subdir).
More info: the fix of issue #43522 was made in AntSettingsBeanInfo.AntHomeEd.[gs]etAsText. Probably an analogous fix now needs to be made in AntCustomizer; or just put it right into AntSettings.setAntHome, if that does not screw up deserialization. (SystemOption makes this subtle.)
this looks like a related problem. I copied a Netbeans application from one machine to another (didn't install using the installer) and got this error when I tried to build : ERROR - Ant is misconfigured and cannot be run. java.io.IOException: No such Ant library dir: /Volumes/josh/Desktop/NetBeansIDE5.0Beta.app/ Contents/Resources/NetBeans/ide6/ant/lib at org.apache.tools.ant.module.bridge.AntBridge.createMainClassPath(AntBridge.java:344) at org.apache.tools.ant.module.bridge.AntBridge.createStuff(AntBridge.java:251) at org.apache.tools.ant.module.bridge.AntBridge.getStuff(AntBridge.java:241) at org.apache.tools.ant.module.bridge.AntBridge.getInterface(AntBridge.java:230) at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:287) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125) I looks like that path is persisted, since the volume name is the name of the volume on the first machine I installed it from. On OSX it is expected that an application can be installed by simply copying it from one machine to another, and should continue to work if it's moved to another place in the file system (for instance a user might initially download and run an app from their desktop, and then if they like the app they move it to their "Applications" folder). Relying on the application never moving in the file system will cause it to break for a lot of OSX users.
i've done some checking, and it looks like what caused the problem i was having above is that the first time i ran netbeans on the new machine the volume of the old machine may have been mounted. i may even have actually run netbeans from the network volume itself, rather than the copy on the new machine. This seems to have set up a lot of paths in my settings folder that pointed to the network volume. When the volume was unmounted netbeans was referencing a volume which didn't exist any more. However, exactly the same problem occurs if you simply move netbeans to another place in the file system - I know that moving applications in other operating systems is unusual, but it's a very, very common thing to do in OSX.
*** Issue 65519 has been marked as a duplicate of this issue. ***
fixed in trunk: IDE:------------------------------------------------- IDE: [7.10.05 17:16] Committing AntCustomizer.java started Checking in AntCustomizer.java; /cvs/ant/src/org/apache/tools/ant/module/AntCustomizer.java,v <-- AntCustomizer.java new revision: 1.12; previous revision: 1.11 done IDE: [7.10.05 17:16] Committing AntCustomizer.java finished
Patch looks OK, though it is probably too much work - there was no problem for other AntSettings attrs, only for antHome. Would probably have sufficed to add at start of method AntSettings.setAntHome: if (f.equals(getDefaultAntHome()) { f = null; } (Haven't tried it though.)
I am having the same problem. It happened after I renamed the netbeans installation folder. I installed by ZIP extraction. The exact error appears when I tried to delete a web project (with deleting sources). The trace: ERROR - Ant is misconfigured and cannot be run. java.io.IOException: No such Ant library dir: C:\Program Files\netbeans-5.0dev\ide6\ant\lib at org.apache.tools.ant.module.bridge.AntBridge.createMainClassPath(AntBridge.java:344) at org.apache.tools.ant.module.bridge.AntBridge.createStuff(AntBridge.java:251) at org.apache.tools.ant.module.bridge.AntBridge.getStuff(AntBridge.java:241) at org.apache.tools.ant.module.bridge.AntBridge.getInterface(AntBridge.java:230) at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:287) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125) My build is 200510251800
fixed in trunk: IDE:------------------------------------------------- IDE: [10.11.05 17:04] Committing Files started Checking in AntCustomizer.java; /cvs/ant/src/org/apache/tools/ant/module/AntCustomizer.java,v <-- AntCustomizer.java new revision: 1.18; previous revision: 1.17 done Checking in AntSettings.java; /cvs/ant/src/org/apache/tools/ant/module/AntSettings.java,v <-- AntSettings.java new revision: 1.34; previous revision: 1.33 done IDE: [10.11.05 17:04] Committing Files finished
This seems to have happened after installing a new version of NB.. How has the behavior changed? Does it look at startup?... if there is no value, does it auto-set the value? Or, does it check at startup for a valid location, changing to the default location if there is a problem? I deleted an old build (10/25 I believe), and my 20051121 version is having this problem. It was pointing to the 10/25 build folder.
clever, I'm not able to reproduce any problem when changing installation while keeping the same userdir. Please could you describe your steps to reproduce. Don't forget to mention any change done in Tools | Options. Thanks.
There was a bug that could be reproduced, and it was fixed. If a new problem arises, please file a fresh bug (with as many details to reproduce as are practical) and refer to this one as needed.
And clever - you will not see changes made to a bug report unless you are on CC.
Thanks for that tip! (This isn't the first time I've neglected to CC myself) I'm grabbing a daily build today. I'll leave closed unless I can confirm what I experienced a couple weeks ago. Cheers! -s-
*** Issue 75084 has been marked as a duplicate of this issue. ***
*** Issue 76396 has been marked as a duplicate of this issue. ***
*** Issue 76397 has been marked as a duplicate of this issue. ***