Community
Participate
Working Groups
We need the ability to add features to the base generators without having to modify the base generator's code. An example feature is the IBMi work. We have created a few plugins allow Java gen to support the calling of IBMi programs and services on the IBMi host.
Generators are now controlled by one or more configurators. These configurators define 5 important pieces of information, that define the characteristics of the extension. These 5 pieces of information are: 1) any additional command line options that this extension defines 2) any additional template properties files that contain a list of additional generator classes 3) any additional native type property files that contain additional native types 4) any additional primitive type property files that contain additional primitive types 5) any additional message property files that contain additional messages These configurators provide needed information for either a generator or a user extension to a generator. The exist as a class that implements Configurator and generally reside (although they do not have to) with the generator or extension templates. During generation of an EGL part, the appropriate list of configurators is passed to the command line processor for the generator, as a list of fully qualified class names, in the required order, as arguments to the -c command line operand. This passing of the configurator class names is done in either of 2 ways: 1) if using batch, then a user entered value as part of the command line. For example: EGL2Java -p myPart -r myRootLocation -c org.eclipse.edt.gen.myExetnsion.MyExtensionGenConfig org.eclipse.edt.gen.java.JavaGenConfig 2) if using the user interface of Eclipse, then this list of configurators is dynamically determined and passed during the behind-the-scenes processing when the generator is invoked, once the EGL source has been saved. This dynamic determination is based on defined configurator extension points within the environment. Each configurator, if used in this way, needs to be defined in their plugin's xml file as an extension. The extension is called "org.eclipse.edt.gen.configurators" and you would provide this information: a) the id of this configurator, typically something like MyExtensionConfigurator or JavaConfigurator b) the fully qualified configurator class name c) the generator id that will use this configurator extension. This must be the id of the Eclipse UI for the generator provider. If it is not defined correctly, then the extension's configurator will not be used. Typically, most configurators are simply extending either JavaGen or JavaScriptGen, but could also extend their own generator. If you are: i) extending JavaGen, then specify org.eclipse.edt.ide.gen.JavaGenProvider ii) extending JavaScriptGen, then specify org.eclipse.edt.ide.gen.JavaScriptGenProvider iii) extending another generator, then you need to find the Eclipse UI provider for that generator and use that name d) the requires id, which may be left blank. If you are not providing your own generator, but simply extending JavaGen or JavaScriptGen, then you do not need to specify any value, as this configurator will be loaded along with the others for that specific generator. If you are providing your own generator that extends another, then you need to specify the id of the other generator's configurator. For example, if you wrote a new generator that extends JavaGenerator, you would want to include all of JavaGenerator's configurators. By defining a requires id of "JavaConfigurator" (the configurator id associated with JavaGenerator) you would cause all of its configurators to get loaded as well as your own.
In order to obtain a list of the configurators associated with a specific Eclipse UI generator, you can use the following information: 1) org.eclipse.edt.ide.core.AbstractGenerator contains a static variable that is initialized as Eclipse UI startup time. This variable contains the list of all configurators in the environment. You may reference it by using this: AbstractGenerator.configurators 2) if you wish to obtain a list of configurators for a given Eclipse UI generator provider, then you may issue these instructions: List<ConfiguratorEntry> configuratorsUsed = new ArrayList<ConfiguratorEntry>(); AbstractGenerator.determineConfigurators(id, configuratorsUsed); where id is a string containing the Eclipse generator provider's id. This must match the generator id of the Eclipse UI for the generator provider. On exit from this call, you will have a List of ConfiguratorEntry.
fixed
We decided to alter the term "configurator" to something more meaningfull. We are now using "GenerationContribution", "CompilationContribution" and "ValidationContribution" instead. I have updated the software for the "GenerationContribution" part and also updated the above documentation to reflect this. The following 2 comments are the replacement docs.
Generators are now controlled by one or more contributions. These contributions define 5 important pieces of information, that define the characteristics of the extension. These 5 pieces of information are: 1) any additional command line options that this extension defines 2) any additional template properties files that contain a list of additional generator classes 3) any additional native type property files that contain additional native types 4) any additional primitive type property files that contain additional primitive types 5) any additional message property files that contain additional messages These contributions provide needed information for either a generator or a user extension to a generator. They exist as a class that implements GenerationContribution and generally reside (although they do not have to) with the generator or extension templates. During generation of an EGL part, the appropriate list of contributions is passed to the command line processor for the generator, as a list of fully qualified class names, in the required order, as arguments to the -c command line operand. This passing of the GenerationContribution class names is done in either of 2 ways: 1) if using batch, then a user entered value as part of the command line. For example: EGL2Java -p myPart -r myRootLocation -c org.eclipse.edt.gen.myExtension.MyExtensionGenerationContribution org.eclipse.edt.gen.java.JavaGenerationContribution 2) if using the user interface of Eclipse, then this list of contributions is dynamically determined and passed during the behind-the-scenes processing when the generator is invoked, once the EGL source has been saved. This dynamic determination is based on defined GenerationContribution extension points within the environment. Each GenerationContribution, if used in this way, needs to be defined in their plugin's xml file as an extension. The extension is called "org.eclipse.edt.gen.GenerationContributions" and you would provide this information: a) the id of this GenerationContribution, typically something like MyExtensionGenerationContribution or JavaGenerationContribution b) the fully qualified GenerationContribution class name c) the provider that will use this GenerationContribution extension. This must be the id of the Eclipse UI for the generator provider. If it is not defined correctly, then the extension's GenerationContribution will not be used. Typically, most contributions are simply extending either JavaGen or JavaScriptGen, but could also extend their own generator. If you are: i) extending JavaGen, then specify org.eclipse.edt.ide.gen.JavaGenProvider ii) extending JavaScriptGen, then specify org.eclipse.edt.ide.gen.JavaScriptGenProvider iii) extending another generator, then you need to find the Eclipse UI provider for that generator and use that name d) the requires field, which may be left blank. If you are not providing your own generator, but simply extending JavaGen or JavaScriptGen, then you do not need to specify any value, as this GenerationContribution will be loaded along with the others for that specific generator. If you are providing your own generator that extends another, then you need to specify the id of the other generator's GenerationContribution. For example, if you wrote a new generator that extends JavaGenerator, you would want to include all of JavaGenerator's contributions. By defining a requires id of "JavaGenerationContribution" (the GenerationContribution id associated with JavaGenerator) you would cause all of its contributions to get loaded as well as your own.
In order to obtain a list of the contributions associated with a specific Eclipse UI generator, you can use the following information: 1) org.eclipse.edt.ide.core.AbstractGenerator contains a static variable that is initialized as Eclipse UI startup time. This variable contains the list of all contributions in the environment. You may reference it by using this: AbstractGenerator.contributions 2) if you wish to obtain a list of contributions for a given Eclipse UI generator provider, then you may issue these instructions: List<GenerationContributionEntry> contributionsUsed = new ArrayList<GenerationContributionEntry>(); AbstractGenerator.determineContributions(id, contributionsUsed); where id is a string containing the Eclipse generator provider's id. This must match the generator id of the Eclipse UI for the generator provider. On exit from this call, you will have a List of GenerationContributionEntry.
And once again, we changed the terminology ... the 2 following comments reflect the updates
Generators are now controlled by one or more contributors. These contributors define 5 important pieces of information, that define the characteristics of the extension. These 5 pieces of information are: 1) any additional command line options that this extension defines 2) any additional template properties files that contain a list of additional generator classes 3) any additional native type property files that contain additional native types 4) any additional primitive type property files that contain additional primitive types 5) any additional message property files that contain additional messages These contributors provide needed information for either a generator or a user extension to a generator. They exist as a class that implements GenerationContributor and generally reside (although they do not have to) with the generator or extension templates. During generation of an EGL part, the appropriate list of contributors is passed to the command line processor for the generator, as a list of fully qualified class names, in the required order, as arguments to the -c command line operand. This passing of the GenerationContributor class names is done in either of 2 ways: 1) if using batch, then a user entered value as part of the command line. For example: EGL2Java -p myPart -r myRootLocation -c org.eclipse.edt.gen.myExtension.MyExtensionGenerationContributor org.eclipse.edt.gen.java.JavaGenerationContributor 2) if using the user interface of Eclipse, then this list of contributors is dynamically determined and passed during the behind-the-scenes processing when the generator is invoked, once the EGL source has been saved. This dynamic determination is based on defined GenerationContributor extension points within the environment. Each GenerationContributor, if used in this way, needs to be defined in their plugin's xml file as an extension. The extension is called "org.eclipse.edt.gen.GenerationContributors" and you would provide this information: a) the id of this GenerationContributor, typically something like MyExtensionGenerationContributor or JavaGenerationContributor b) the fully qualified GenerationContributor class name c) the provider that will use this GenerationContributor extension. This must be the id of the Eclipse UI for the generator provider. If it is not defined correctly, then the extension's GenerationContributor will not be used. Typically, most contributors are simply extending either JavaGen or JavaScriptGen, but could also extend their own generator. If you are: i) extending JavaGen, then specify org.eclipse.edt.ide.gen.JavaGenProvider ii) extending JavaScriptGen, then specify org.eclipse.edt.ide.gen.JavaScriptGenProvider iii) extending another generator, then you need to find the Eclipse UI provider for that generator and use that name d) the requires field, which may be left blank. If you are not providing your own generator, but simply extending JavaGen or JavaScriptGen, then you do not need to specify any value, as this GenerationContributor will be loaded along with the others for that specific generator. If you are providing your own generator that extends another, then you need to specify the id of the other generator's GenerationContributor. For example, if you wrote a new generator that extends JavaGenerator, you would want to include all of JavaGenerator's contributors. By defining a requires id of "JavaGenerationContributor" (the GenerationContributor id associated with JavaGenerator) you would cause all of its contributors to get loaded as well as your own.
In order to obtain a list of the contributions associated with a specific Eclipse UI generator, you can use the following information: 1) org.eclipse.edt.ide.core.AbstractGenerator contains a static variable that is initialized as Eclipse UI startup time. This variable contains the list of all contributions in the environment. You may reference it by using this: AbstractGenerator.contributions 2) if you wish to obtain a list of contributions for a given Eclipse UI generator provider, then you may issue these instructions: List<GenerationContributorEntry> contributionsUsed = new ArrayList<GenerationContributorEntry>(); AbstractGenerator.determineContributions(id, contributionsUsed); where id is a string containing the Eclipse generator provider's id. This must match the generator id of the Eclipse UI for the generator provider. On exit from this call, you will have a List of GenerationContributorEntry.
EGL Web Developer Tools 0.8.0.v201202220747
