Functional components can be identified at the running period component Eclipse to allow identification of the active product, and you can also select each of the functional components in the runtime configuration. Functional components must not be identified, you don't identify all your features, but you should identify one. Identification Definition - The key issue of adding identifiers for plug-ins is to understand where to define the identity. You define the identified functionality, but the identified content is from the plugin. The plugin is identical to the ID of the function (default), or the plugin is clearly identified in the definition of the functional component (this is the new function of Eclipse 2.1.1). In Eclipse 2.1, a functional component definition can define other plugins by specifying attribute plugin = ... in the feature.xml file, and the plugin contains files for defining and providing identification content. Identification Content Summary The About.ini control file defines the identity of the product level and feature level. The product identification must correctly include the following two aspects: • Functional components must be defined as a possible primary feature, that is, in the feature.xml definition file, you want to include Primary = "True". • The functional component must be identified as the active functional component, which is typically set in the product in the / eclipse directory in the install.ini file in the / eclipse directory. The main functional components can also be defined by using the -Feature FeatureID startup parameters at the runtime. Understanding the easiest way to mark the identity of the component is to view which elements are defined in the About.ini control file, and how they work in an identified product or feature.
Figure 2. Identification content available in the Eclipse perspective
Severalings are only used for product logos: • WINDOWIMAGE · AppName · Aboutimage is used during product and feature identity. The value starting with a percent (%) is parsed in the About.properties file. When a functional component is the primary function component, the text defined with the Aboutext keyword is displayed in the About Product dialog. When the user clicks on the Feature Details button, these contents are also displayed in the About Features dialog box. When the feature is added to the running period, the WelcomePage entry is opened, and then you can also open this welcome page by selecting the Eclipse menu option Help> Welcome ... Open this welcome page. The fastest way to build a feasible functional component is to clone an existing feature that can be found in the Eclipse itself. Features and plugins with org.eclipse.platform IDs provide feature identification and plug-in identity. There is a step of detailed guidance instructions in Chapter 34 of the Java Developer's Guide To Eclipse. In the development resource of the Eclipse.org's Update Management Sub-project, you can find another detailed description of the identity. The process of building a feature is introduced in the "The Java Developer's Guide to Eclipse" of the "The Java Developer's Guide to Eclipse" section of the feature of the feature, "PDE Generation Plugins", is introduced, but also There are still some other ways. When you understand how to build features and associated plugins, you can complete them automatically. The ANT target implemented by the PDE allows us to start from the functional summary of PDE. PDE will generate a build.xml file for a plugin.xml or feature.xml file. Build.xml is an ANT script that can complete the different tasks required for the functional components of the running schedule and plugins. The PDE build process allows you to generate one or more of the following build destination. Important Function Component Build Objectives: • Build.jars calls the build.jars task in the build.xml file for each referenced plugin. · Build.Uldate.jar calls the build.update.jars task in the build.xml file for each referenced plugin. At the same time, you will create an Update JAR for the functional components. This is the default target of the ANT script. · Build.Sources calls the build.source task in the build.xml file for each referenced plugin. · Zip.Distribution Creates a compressed file that contains all files required for the plugin that features and references. · Refresh makes the Eclipse project and any referenced plugin for any referenced. Important plug-in build goals: • Build.jars calls many of the goals in the build.xml file for each running period JAR defined by the plugin. The name called the target is the same as the name of the running JAR file. These targets compile JAVA code and create a JAR file that contains any resources in the source file directory. · Build.Update.jar Pack all the required files under all runtime plugins into a file for Plugin.ID_Version.jar, where Plugin.ID and Version are from the Plugin.xml file. This is the default target of the ANT script. · Build.Sources Create the compressed package of the Java source file based on the source file directory defined by a given period JAR file. · Zip.plugin Creates a compression package that contains all the contents you need to plugin. · Refresh makes the Eclipse refreshes the plugin project.
Note: During the ANT processing of the functional components and plugins, update the JAR or the file packaged during the processing of the compression package is those required by the running period environment. These contents are described in the runtime JAR file of the functional component or plugin's build.properties file and each plugin defined in PLUGIN.XML, by bin.includes or bin.excludes entry. In order to build a plugin, you may specify Clean, Build.Sources, Build.jars, Zip.plugin, Refresh. In order to build a functional component, you may specify Clean, Build.Sources, Build.jars, Zip.Distribution, refresh. You may want to use clean when you start using Clean to enforce all results, often there will be this situation. Although the Ant processing process will re-execute the desired steps based on the input change, some changes do not trigger all required processing procedures. Test results show that if you change a Java source file, the corresponding source file compression package will be updated, but the class will not be recompiled, and the running period JAR will not be updated. Therefore, it is recommended that you will clear the output results first to ensure that you are using the running period corresponding to the current source file after rebuilding. The discussion scheme is for discussion, we first describe the content required in the runtime configuration when only one functional component and plug-in are. As you can see the file name, although most of these files belong to the runtime environment, there are still some files that you want to share with others (for example, your design documentation). Contains policies - indicate that the required parts are at least until the beginning, the easiest way is to list the part you want to package during the construction process as part of the feature or plugin in the runtime configuration. The corresponding build.properties files are shown below: Reverse Policy - Specify unwanted or private part of the other method is to list some of the parts you don't want to package as a functional component or plugin in the construction process. This not only includes files you don't want to share, but also include files and directories created during the build process (there are some temporary). The build.properties file used in this method is as follows: If the ID value of the given component or plugin is com.your.feature.id or com.your.plugin.id, then you need to use the rejection policy. The following entries are included in the file: com.your.feature.id_1.0.0.bin.dist.zip, /
com.your.feature.id_1.0.0.jar, /
com.Your.plugin.id_1.0.0.jar, /
