Difference between revisions of "Equinox/p2/Getting Started"

Revision as of 22:29, 23 July 2007

Getting the code

1. Create a CVS repository connection to ":pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse". Hint: Select the quoted text, open the CVS Repositories view, and select "Paste Connection" or hit Ctrl+V to add the connection
2. Expand HEAD -> equinox-incubator > provisioning
3. Checkout org.eclipse.equinox.prov.releng
4. File > Import > Team Project Set. Select "projectSet.psf" in the releng project checked out above. If you are a committer, and able to make an extssh connection, you can use projectSet-extssh.psf

My first run, running the tests

The easiest way to get a feel for what is going on with the new code base is to run the tests.

1. Generate metadata/artifacts Until the new provisioning story is fully integrated into Eclipse, you create artifact and metadata repositories with stuff to install. After having checked out the code as described above, run the Metadata Generator SDK launch configuration in the OSGi Framework launch category.
   Note: You may need to alter some of the properties in the launch configuration's Arguments. In particular,
   * "-Declipse.prov.metadataGenerator.eclipseBase=" should point to the location of the Eclipse install you want to add to the repository. The metadata generator will scan this location and generate metadata for all discovered features and plugins. For your first run you can point at the Eclipse 3.3 install that you are running.
   Run the launch configuration. Progress should be reported in the console. When generation is complete you can terminate the launch by typing "exit" in the console or killing the launch.
2. Install profile' Having generated the metadata and artifact repos, you can create and install a new "profile" by running the Test Director SDK launch configuration in the JUnit Plug-in Test launch configuration category.
   Note: Again, you may need to tweak some of the arguments based on how you generated the metadata (e.g., where the repositories got generated). In particular,
   * "-Declipse.prov.installFolder=" is the location for the new profile. This is where you can find eclipse executable etc. after the install.
   * "-Declipse.prov.autoInstall=" is the IU to install. For the simple case this is the same as the "eclipse.prov.rootIUId" specified during generation.
   Note: You can also run the metadata JUnit tests by running org.eclipse.equinox.prov.metadata.test.AllTests as a JUnit Plug-in Test.
3. Run profile Once the test has run you can go to the installFolder and find the eclipse executable and run it. You should get a complete running Eclipse. Notice that the installFolder does not contain the plugins or features. Just a mess of configuration files. In the new provisioning story the plugins etc. are stored in managed pool and shared between profiles.

Using the console

To use the provisioning commands on the OSGi console, you can run the "Provisioning Console" launch configuration. Type "help" on the console to get a list of available commands.

Setting up selfhosting

This setup allows you to get a feel for how we want the new selfhosting story to work, but requires a complex setup.

Self-hosting is the ability to develop Eclipse bundles using Eclipse and then run them from Eclipse. This just works for free in normal cases but when doing provisioning work, there are some challenges. Under the covers PDE uses Update Manager to discover and manage the set of bundles to be run. Of course, with the new provisioning work, we don't have Update Manager. So, until the provisioning support solidifies and PDE support is added, you have to do a few tricks to be really effective. For those who care, this process is somewhat similar to the traditional "Feature-based selfhosting" you had to do when developing Update Manager code. Here's what you do...

1. Launch Eclipse and create a workspace that targets your current Eclipse SDK and has all of the projects from the provisioning .psf file checked out (see above). Let's call this workspace "LEFT".
2. Create an Eclipse launch configuration that includes all of the Eclipse SDK and the provisioning projects you just checked out. For fun, call that launch config "MIDDLE".
3. Run the launch configuration and create another workspace (say "WORK"). It is easiest to just set this workspace location in the launch configuration. This workspace is where you will be doing the bulk of your work.
4. In the console of LEFT, start the selfhosting bundle: type start org.eclipse.equinox.prov.selfhosting
5. In the MIDDLE workspace, once again, check out all of the provisioning projects you need.
6. Now to setup self-hosting you have to create an OSGi launch configuration (say "RIGHT") that includes the things you want to run and, for simplicity, all of the provisioning related projects. In practice you only need the provisioning projects required to run the agent but that list will change over time and is/will be detailed elsewhere.
7. With the RIGHT launch config setup, you can now run you code. When you run RIGHT, the provisioning selfhosting code that is loaded in LEFT and running in the MIDDLE Eclipse will kick in and generate some metadata and modify the launch to hook everything together. The net result is RIGHT will be running a Profile that has all the proper IUs installed and there will be a metadata repository containing all the IUs in your workspace and associated target platform. These IUs can, for example, then be installed into RIGHT using the provisioning console (whatever).

Hint: You can leave LEFT running for a long time and simply minimize it. It is also useful change the look of LEFT's workspace so you don't confuse its content with that of WORK. Perhaps just set the editor font large. It is also useful to run MIDDLE with -consolelog and -console.