Changes between Version 65 and Version 66 of BuildSystem


Ignore:
Timestamp:
12/15/12 17:34:51 (7 years ago)
Author:
welberge
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BuildSystem

    v65 v66  
    245245 
    246246Then there are basically two options to proceed: the first is to create a 
    247 !NetBeans "free form" project. In that case, !Netbeans will simply pick up your 
     247!NetBeans "free form" project. In that case, !NetBeans will simply pick up your 
    248248existing build.xml file, and use that for it own builds. Disadvantage: it's ok 
    249 for basic editing, compiling, etcetera, but you cannot prot from all !Netbeans 
     249for basic editing, compiling, etcetera, but you cannot prot from all !NetBeans 
    250250features. The second option is to create a new !NetBeans "Java project from 
    251251existing sources". In that case, !NetBeans has its own build file, now called 
    252252nbbuild.xml. Advantage: you can profit from all !NetBeans features, and it 
    253253will not disturb the shared build files. Disadvantage: you must setup the 
    254 NetBeans project carefully and manually update it for library changes, as we will describe now. 
     254!NetBeans project carefully and manually update it for library changes, as we will describe now. 
    255255 
    2562561. We assume that you are using !NetBeans 7.2 (or higher) 
     
    2592591. Ensure that the your project has no build directory: for instance use ant clean. 
    2602601. Now create a new project within !NetBeans. Choose "New Java Project with Existing Sources". 
    261 1. Choose the correct project name (by default we pick the project directory name), and select the correct project folder. Enable the "Use dedicated Folder for Storing Libraries" option, but choose a different name than ".\lib". For instance, choose "nbproject\lib". NetBeans stores some of its "own" info in its "lib" folder. Unfortunately, our version manager Ivy will discard such info from .\lib when you do an "ant resolve" operation, so we must give the !NetBeans lib a special place. 
     2611. Choose the correct project name (by default we pick the project directory name), and select the correct project folder. Enable the "Use dedicated Folder for Storing Libraries" option, but choose a different name than ".\lib". For instance, choose "nbproject\lib". !NetBeans stores some of its "own" info in its "lib" folder. Unfortunately, our version manager Ivy will discard such info from .\lib when you do an "ant resolve" operation, so we must give the !NetBeans lib a special place. 
    2622621. "Next", add the src folder to the list of "Source Package Folders", and add the test\src folder to "Test Package Folders". 
    2632631. "Now you can \Finish", and you have a !NetBeans project. Except that it won't compile, because you must correct the library settings: 
    2642641. The !NetBeans "Projects" panel on the left show two sets of libraries: "Libraries" and \Test Libraries" Right click on "Libraries" and choose "Add JAR/Folder". Navigate to the project's lib folder and add all jars that you find there. Also add the project's resource directory here. (This will 
    265 ensure that this directory is on Java's classpath, so the "getResourceAsStream" method for loading resource data will work) Leave the "Reference as Relative Path" option enabled: this prevents NetBeans from copying into its own nbproject\lib directory. Do the same with "Test Libraries", this time using the jars from test\lib, and the test\resource directory. As you can see we now have a junit-4.8.2.jar, that is present in our lib directory, 
     265ensure that this directory is on Java's classpath, so the "getResourceAsStream" method for loading resource data will work) Leave the "Reference as Relative Path" option enabled: this prevents !NetBeans from copying into its own nbproject\lib directory. Do the same with "Test Libraries", this time using the jars from test\lib, and the test\resource directory. As you can see we now have a junit-4.8.2.jar, that is present in our lib directory, 
    266266but also two more !NetBeans "libraries", one for JUnit3.8.2 and one for JUnit4.8.2. The latter two should be removed.  
    2672671. By now, the project should be in shape: no unresolved libraries, it compiles and runs, and JUnits test work. 
    2682681. Note that whenever you change the contents of the lib directories, you will have to go back to the project properties page (from the File menu), 
    269 and reestablish the correct libraries settings. For example, say you had some file "guava-r06.jar" inside your lib directory, but after the resolve operation it has been replaced by "guava-r07.jar" !NetBeans now automatically removes guava-r06.jar from its libraries, but does not auto-understand that it needs guava-r07.jar instead. Right-click on the !Netbeans project name, and choose "Resolve Reference Problems...". Select guava-r06.jar and click "Resolve". Now you can navigate to the project's lib directory, and select the new guava-r07.jar. For the time being, !NetBeans is now satisfied. In reality, it has not really removed the reference to guava-r06.jar, but it has added a redirection inside your own "private" !NetBeans settings. So next time that you resolve, it cannot find guava-r06.jar again. You can correct this by first removing the guava jar from the !NetBeans library, then adding the correct version. Problem: you cannot remove it while the reference problem is not solved. In the end, the easy solution is to first remove all jar files from lib (and also from test\lib if you expect changes over there) before the resolve, then add them back after the resolve. 
     269and reestablish the correct libraries settings. For example, say you had some file "guava-r06.jar" inside your lib directory, but after the resolve operation it has been replaced by "guava-r07.jar" !NetBeans now automatically removes guava-r06.jar from its libraries, but does not auto-understand that it needs guava-r07.jar instead. Right-click on the !NetBeans project name, and choose "Resolve Reference Problems...". Select guava-r06.jar and click "Resolve". Now you can navigate to the project's lib directory, and select the new guava-r07.jar. For the time being, !NetBeans is now satisfied. In reality, it has not really removed the reference to guava-r06.jar, but it has added a redirection inside your own "private" !NetBeans settings. So next time that you resolve, it cannot find guava-r06.jar again. You can correct this by first removing the guava jar from the !NetBeans library, then adding the correct version. Problem: you cannot remove it while the reference problem is not solved. In the end, the easy solution is to first remove all jar files from lib (and also from test\lib if you expect changes over there) before the resolve, then add them back after the resolve. 
    270270 
    271271