After using JBuilder for a while, I really want to write some of the practical skills that I remember it, which is only the labor fruit for hard half-day, because forgetting and paying the east. There are a lot of JBuilder's usage techniques, and most of me are here to not pay attention, or rarely mentioned the skills that can be mentioned as [marginal skills].
If you have time, I will continue to populate this series of articles.
In the first one, I will introduce some of the "project name. Project type .local" file.
Title: [JP1: "Project Name. Usage of Project Type. Local"]
Version: 7 ~ 9
JBuilder development is based on project concept. The project file contains a list of (belonging to this item) file list and project properties, where project properties include project templates, default paths, class libraries, and connection configurations, JBuilder uses this information loading, save , Compile and run the project. Use the JBuilder development environment to add, remove files, or settings, and change the project files. The project file can be seen as the primary node in the project panel.
The purpose of generating projects is to use the project template tool to set the project name, type, and template, and JDK, working directory, backup path, and compiler. The project type can be selected .jpx or .jpr [Note 1], the same content, the difference is that the former uses the XML format file, so it is suitable for shared items.
After creating a project, you will generate a "project name. Project type .local" file. Since it is .local, of course this file mainly records some of the information in local JBuilder. Here is the content of this file:
Build.Menu.1 [0] = com.borland.jbuilder.build.projectBuilder $ ProjectBuildAction; Make
Build.Menu.2 [0] = com.borland.jbuilder.build.projectBuilder $ ProjectBuildAction; Rebuild
Debug.notracingClasses.1 [0] = 23 com.borland.DataStore. * 1 1 -1
Debug.notracingClasses.10 [0] = 7 javax. * 1 1 -1
Debug.notracingClasses.11 [0] = 5 Sun. * 1 1 -1
Debug.notracingClasses.12 [0] = 23 com.borland.appclient. * 1 1 -1
Debug.notracingClasses.13 [0] = 21 com.borland.console. * 1 1-1
Debug.notracingClasses.14 [0] = 17 com.borland.ejb. * 1 1 -1
Debug.notracingClasses.15 [0] = 24 com.borland.Enterprise. * 1 1 -1
Debug.NotracingClasses.16 [0] = 18 com.borland.jafa. * 1 1 -1
Debug.notracingClasses.17 [0] = 17 com.borland.jss. * 1 1 -1
Debug.notracingClasses.18 [0] = 24 com.borland.management. * 1 1 -1
Debug.notracingClasses.19 [0] = 23 com.borland.primetime. * 1 1 -1
Debug.notracingClasses.2 [0] = 21 com.borland.dbswing. * 1 1 -1
Debug.notracingClasses.20 [0] = 22 com.borland.security. * 1 1 -1debug.notracingClasses.21 [0] = 18 com.borland.util. * 1 1-11
Debug.notracingClasses.22 [0] = 17 com.borland.xml. * 1 1 -1
Debug.notracingClasses.23 [0] = 13 com.inprise. * 1 1-1
Debug.notracingClasses.24 [0] = 15 com.visigenic. * 1 1 -1
Debug.notracingClasses.25 [0] = 9 Org.omg. * 1 1 -1
Debug.notracingClasses.3 [0] = 16 com.borland.dx. * 1 1-1
Debug.notracingClasses.4 [0] = 16 com.borland.jb. * 1 1-1
Debug.NotracingClasses.5 [0] = 18 com.borland.jbcl. * 1 1 -1
Debug.notracingClasses.6 [0] = 30 com.borland.jbuilder.Runtime. * 1 1 -1
Debug.notracingClasses.7 [0] = 17 com.borland.sql. * 1 1-1
Debug.notracingClasses.8 [0] = 9 com.sun. * 1 1 -1
Debug.notracingClasses.9 [0] = 6 java. * 1 1 -1
Sys.author [0] =
sys.defaultpackage [0] = testjpr
The contents of the Build and Debug sections are generally not required to be modified after the file generation is generated because it is automatically generated. Sys.author [0] is indicated by the author's name, the default is empty, ie (Figure -1) value of the @Author field.
figure 1
Sys.DefaultPackage [0] indicates the name of the project's default package, and the name is the name of the project. Of course, you can also add information about the breakpoint in the .local file, such as:
Debug.breakpoints.1 [0] = 1 329 Net.befresh.oa.common.checklogin 10 1 10 1 10 1 0 -1
The line of text sets a breakpoint for the entire project, once you debug project, it will start.
The reason why I want to say .local files, the main purpose is to configure a Team development environment. The .local file contains information in the Team development environment. Such as [Note 2]:
Team.ActiveVCS [0] = Visual SourceSafe
Team.vssautosaveEnabled [0] = 1
Team.vssDatabaseEloc [0] = f: / vss_db_spoa
Team.vssModulenAme [0] = $ / SPOA / CODE / Projects
Team.vsspassword [0] = 123
Team.vssusername [0] = VSS
After putting the project in the Repository of the Configuration Management Tool, each JBuilder gets the entire project file through "Pull Project from *". Figure (Figure -2)
figure 2
When you first pull the project file from the REPSotory, you need to set the information of the configuration management tool, and this information exists .local file. But because .local files are generally CHECK IN, all you need to reconfigure each time you open the project, it is very trouble [Suggest: When you join the project, you don't have to join the .local file. At this time, you can manually modify the .local file, after modifying, do not use the .local file Check IN. This way, you don't need to configure this information each time. In order not to synchronize the .local file to the Repository, you can click the "Team -> Status Browser ..." menu, then select "File Include Lists", such as (Figure -3), do not select the .local file, this will not Synchronize the file. Not only .local files can be done, other files that do not need synchronization can be operated.
image 3
Reference:
[Note 1]: There is only one project type in JBuilder 7.jpx. In jbuilder9, there is a type of .tpr, I have an error when creating this type of project, an error occurs.
[Note 2]: The configuration management tool used in the example is Microsoft Visual SourceSafe 6.0, and the information displayed by other configuration tools may be different.
By befresh
2003-9-8
