Integrating with TEA

This code will look up a launch configuration named mylaunch in the runtime workspace and launch it. This code is not even TEA specific. You can do this from any code that has a dependency to the com.wamas.ide.launching and com.wamas.ide.launching.ui bundles (provided by LcDsl) as well as the org.eclipse.debug.ui.launchview bundle (provided by the Launch Configuration View feature), which is still pending review⁴ at the time of writing.

To run the sample, you will have to create a new LcDsl launch configuration named mylaunch in the runtime workspace of the TEA-Book-Samples launch configuration. Launch it and create a new Java project, com.example.launching. Add a simple class named Test with a main method to the project—use the package com.example.launching. See Figure 14-2 for an example.

Now add a launch.lc file to the project. Eclipse will want to add the Xtext nature to the containing project to allow “compilation” of the .lc file once you add the file to the project. See Listing 14-3 for the content of the launch.lc file.

Once you have added the content to launch.lc, try running a TEA ➤ Samples ➤ CH14-S02: Run LcDsl: mylaunch. You can also try running the mylaunch launch configuration from the Launch Configurations View.

The whole setup should look like the one shown in Figure 14-3.

This can be very handy, especially in combination with the TeaBuildChain extensions demonstrated in Chapter 12. Imagine having a code generator that needs to read a model from disc, but the code to read the model is part of your application framework. Thus, the generator is consequently an application in your runtime workspace. The LcDsl API facilitates launching such generator applications during builds. This is also what the integration part is about. TEA provides TeaBuildChain extensions that make sure that LcDsl-based launch configurations are available when you need them during builds.

The improved Task will create a new launch configuration (mylaunch-new), which inherits all the properties of mylaunch and adds an additional VM argument (-Dmy.prop=World) to it. This mechanism is not restricted to system properties; you can modify basically every property of the launch configuration (except its type).

Running the improved Task, of course, is more fun if you adapt the sample program. Figure 14-4 shows the whole setup once more. To try it with the prepared sample, run TEA ➤ Samples ➤ CH14-S03: Run LcDsl: mylaunch with property.

You may notice that the mylaunch-new launch configuration is still kept around after execution. This allows manually re-executing generated launch configurations. If this is not desired, replace launch with launchWaitAndRemove⁵ and the configuration is removed after execution.

Generating feature.xml Using LcDsl

Feature projects in the context of PDE are usually set up once and need to be maintained—mostly to keep the list of included bundles up-to-date with what is run from the workspace. This can be an error prone manual task, especially since missing bundles may go unnoticed for a long time, until QA misses functionality, or something of that nature. To avoid this, TEA is capable of generating a feature.xml from an LcDsl launch configuration—actually, even from more than one launch configuration.

To get started, create a feature project as usual. Instead of manually manipulating the feature.xml, simply delete it. Don’t forget to ignore feature.xml in your SCM—in .gitignore, for example. You don’t want to/need to commit this file.

Instead of feature.xml, create a content.properties file in the root of the project. It must contain a single property: dependencies. This property must contain a comma-separated list of (existing) LcDsl launch configurations of type Eclipse or RAP (See Listing 14-6.) TEA will query all the required plug-ins (LcDsl calculates this from dependencies automatically) and generate a feature.xml from there.

Follow these steps to try it out:

1. 1.

   Create a plug-in project, com.example.bundle1

    
2. 2.

   In this project, create an Eclipse IApplication. (See Figure 14-5 for an example.) Remember to register the application using the org.eclipse.core.runtime.applications extension point.

    
3. 3.

   Create a launch.lc file in the example bundle and paste the content of Listing 14-5. You can try the launch configuration from the Launch Configurations View now.

   Note

    Make sure the application ID matches the one in the extension point you created. Use content assist (default: CTRL + Space) if unsure. It will propose all available applications. See Figure 14-5 and Listing 14-5 for a working sample setup.

    
4. 4.

   Create a feature project, delete feature.xml (only build.properties remains for now)

    
5. 5.

   Create a content.properties file in the feature project. It should look like the one in Listing 14-6. What is important is the reference to the MyApp launch configuration created a second ago in step 3.

    
6. 6.

   Now execute TEA ➤ TEA Build Library ➤ Create Update Site from Feature… (the same as described in Chapter 12). Select the feature project you just created and click OK. This should make a brand new feature.xml appear in the feature project. Additionally, a P2 update site for the feature is created, which already contains all referenced (dynamically resolved) bundles as well (See Figure 14-6.) Again, this is the same mechanism and result as described in Chapter 12, except that the feature.xml is now generated on the fly as well.

    

eclipse configuration MyApp {

      plugin com.example.bundle1;

      application com.example.bundle1.id1;

}

Listing 14-5

LcDsl Launch Configuration for the IApplication

dependencies=MyApp

Listing 14-6

content.properties for Example Launch Configuration