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.
Every so often when I attempt to do a Clean and Build, I get the following error building: init: Deleting: C:\Fastlane\java\ParseBuilder\build\built-clean.properties deps-clean: Updating property file: C:\Fastlane\java\ParseBuilder\build\built-clean.properties C:\Fastlane\java\ParseBuilder\nbproject\build-impl.xml:1024: The following error occurred while executing this line: C:\Fastlane\java\ParseBuilder\nbproject\build-impl.xml:1071: The following error occurred while executing this line: C:\Fastlane\java\designer\nbproject\build-impl.xml:86: The J2SE Platform is not correctly set up. Your active platform is: default_platform, but the corresponding property "platforms.default_platform.home" is not found in the project's properties files. Either open the project in the IDE and setup the Platform with the same name or add it manually. For example like this: ant -Duser.properties.file=<path_to_property_file> jar (where you put the property "platforms.default_platform.home" in a .properties file) or ant -Dplatforms.default_platform.home=<path_to_JDK_home> jar (where no properties file is used) BUILD FAILED (total time: 0 seconds) I did not change any of the properties files or project files created. If I delete the project and start over everything is fine. Which project files do you need to see when this happens? Product Version: NetBeans IDE 7.0 Beta 2 (Build 201102140001) Java: 1.7.0-ea; Java HotSpot(TM) Client VM 21.0-b05 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and Settings\dm185016\.netbeans\7.0beta2
Seems like you specified a nondefault Java platform in the Libraries panel, yet 'default_platform' is supposed to refer only to the (you guessed it!) default platform. Attaching the whole project or at least build.xml plus the nbproject dir, as well as build.properties and config/Services/Platforms/org-netbeans-api-java-Platform from the user directory, might shed some light on the problem. But these files would probably just confirm that you have platform.active=default_platform in project.properties and <explicit-platform...> in project.xml, which should not happen. The question is how you got the IDE to write this incorrect metadata; to diagnose that we would need steps to reproduce the problem from scratch.
Created attachment 107492 [details] Image of New Java Project dialog Picture of New Java Project dialog showing Build script name as nbbuild.xml not build.xml. I never set this field to anything. This is the default value that always comes up.
Currently I cannot recreate. Two theories about cause: 1. Running multiple versions of NB on the same projects. I had 6.7.1, 6.9.1 and 7.0 Beta 2 (now RC1). I ran 6.7.1 for UML features, then I accidently ran 6.9.1. I killed 6.9.1 and then ran 7.0 beta2. 2. Two different build scripts in directory. The older versions created build.xml. These versions were committed to SVN. The 7.0 beta 2 (and RC1) versions by default create nbbuild.xml not build.xml. So there were 2 build scripts in the directory. When I "fixed" my problem, I deleted by hand all build scripts and directories and created new projects with existing source. The attached image shows what comes up by default when I select that option. As you can see, it builds nbbuild.xml not build.xml. Would having both cause this kind of problem?
The nbbuild.xml is preferred name of build script in case when build.xml already exists to prevent collisions with existing build file. I think it's there from 6.8 before it the Wizard rejected to create a project. Anyway I don't understand how you created 2 projects in single folder (this is unsupported) and the wizard reject it as the "nbproject" folder exists. Please attach the whole nbproject folder, the build.xml, the nbbuild.xml and describe how you has created the second project. Thanks
Several of my projects were originally created years ago using NB 6.5. These project files were named build.xml. They are committed to SVN. I recently recreated some of the project files using NB 7.0 when I installed it. These project files were named nbbuild.xml. When I did an SVN update, it restored the build.xml files to the project directories. Now I have both build.xml and nbbuild.xml in the same directory. I thought this might be the problem since in order to get rid of the original problem I reported, i had to regenerate all my projects. However, as a test, I backed up the new stuff and updated from SVN. Now I have both in the project files. I did a Clean and Build. No problemS! This is different symptom than before. Of course since I originally reported the problem, I switched from Beta2 to RC1. If it happens again, I will try to isolate the problem again and reopen this problem.
>project files were named build.xml. They are committed to SVN. I recently >recreated some of the project files using NB 7.0 when I installed it. These >project files were named nbbuild.xml. Yes but you have to delete the nbproject folder before you was able to recreate them as the IDE prevents this. You should just update the projects. The IDE used the nbbuild.xml as the build.xml already existed. You probably restored the nbproject folder from VCS and this caused the problems.
Fine. I want to be able to store project files in SVN. Which files are required to share projects with other users? nbbuild.xml manifest.mf nbproject/build-impl.xml nbproject/genfiles.properties nbproject/project.properties nbproject/project.xml How about nbproject/private/config.properties nbproject/private/private.properties nbproject/private/private.xml Which of these can safely be shared with multiple users thru SVN? What does each do? Which is specific to each user (those I don't want to check in) Is there an explanation of the files anywhere? Which manual do I need to RTFM :-) I can't ever find any useful info in the help system so I don't use it.
In general everything except of private/** should be in the VCS. Here comes some short description: nbbuild.xml == build.xml - It's an top level build script where you can override the default behavior. It should be shared manifest.mf - manifest file added into META-INF by build. Should be shared nbproject/build-impl.xml - automatically generated build script. When you open a project in newer IDE it's regenerated. CRCs stored in genfiles.properties are used to regenerate it. In fact it's regenerated when it's missing or when it has an older version when you open the project. But it should be shared as well to be able to do headless build outside of the IDE. When the build-impl.xml is updated you see some strange changes in VCS diff which may be strange. nbproject/genfiles.properties - the CRC file used to regenerate the build-imp.xml. The same sharing policy as in case of build-impl.xml nbproject/project.properties - the public project metadata. Contains project set up. Should be shared. nbproject/project.xml - Also the public project metadata. Should be shared. nbproject/private/config.properties - Per user config files should not be shared. nbproject/private/private.properties - Per user config files should not be shared. nbproject/private/private.xml - Per user config files should not be shared. I agree that it should be described somewhere in doc. Adding doc to cc list.
Thanks for the information. That is very helpful. That's about what I thought but I have been hesitant to put project files in SVN. Someone else put those files in but they also put in the private files and messed a lot of people up. I removed most of the files to fix problems. If (can) I modify the manifest file, will my mods be trashed by regeneration?
>If (can) I modify the manifest file, will my mods be trashed by regeneration? No the manifest is generated just once (when you create the project). It's not affected by regeneration. Also the build of the project automatically may add some additional elements into the META-INF/MANIFEST.MF which are not in your manifest.mf (Class-Path, Main-Class). They are added if the project has set the main class.