Latest revision as of 10:36, April 24, 2013

Instructions for Compiling and Running Protege 4.1+ in Eclipse using the sources from SVN

These instructions will help you set up the Eclipse environment for Protege 4.1. In the first part, we will check out from SVN a Eclipse workspace already configured for Protege 4.1 and its plugins, then in the second part, we will show how to add your own plugin in Eclipse.

Prerequisites

To follow these directions you will need the following tools:

• Eclipse (of course) with
  • the Plugin Development tools included. As indicated here, the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.
  • the Eclipse Subversive plugin, though this is only required if you want to do svn updates using eclipse. Note that there is another similar but different plugin (from Tigris I believe). I don't know if these plugins interfere with one another if they are both loaded.
• A tool for extracting a zip file into a directory.
• A tool for checking out a repository from subversion (e.g. tortoise or the svn command line client).

These directions are based on a preconfigured workspace which you can use for the build.

Configuring Eclipse

Step 1: Checking out the workspace Use subversion to checkout the following workspace:

    https://smi-protege.stanford.edu/repos/protege/protege4/ide/eclipse/protege4.1/trunk

If you are using command line tools you can do this with the svn command

    svn checkout https://smi-protege.stanford.edu/repos/protege/protege4/ide/eclipse/protege4.1/trunk protege4.1

This creates an eclipse workspace but some of the metadata is still missing.

Tortoise svn Users: Note that when using Tortoise svn, you need to do a full recursive checkout. It may appear that there is only one file in the repository but the svn checkout needs to also checkout the external references.

Using Eclipse svn: It is possible to checkout this directory using eclipse but eclipse developers need to understand that they are checking out a workspace and not a project. If the developer has an alternative method of checking out the directory that method would probably be less confusing.

Step 2: Install the Eclipse metadata Inside the directory that you just checked out is a file called metadata.zip. Extract this file into the created directory. Now the eclipse workspace is ready for eclipse. Note that on the mac, double-clicking the metadata.zip file does not do the right thing; it does not simple extract the files into the current directory. So on the mac the command line unzip is probably recommended:

      unzip metadata.zip

Step 3: Load the Workspace Start eclipse and choose the newly created directory as the workspace. Since this is a new workspace, eclipse comes up with a welcome screen which you can dismiss. We now import the projects. Go to the file menu and click "File->Import". You should get a window as shown below and can open the "General" tree to see and select the "Existing Projects into Workspace".

Once "Existing Projects into Workspace" has been selected click Next. This should give you the window shown below.

Click the Browse button to select the workspace directory.

Once you have selected the workspace you should see the window below that includes the projects that you want to import.

Click Finish and the files should be imported.

Now all the projects have been loaded into eclipse.

Step 4a: Run Protege (The easy and better way) This step can be a bit problematic on the mac but works for linux and windows machines. Just recently this method seems to have started working with Snow Leopard and the latest eclipse (Helios).

Click on the down arrow just to the right of the little bug (near the top of the eclipse window perhaps just under the Refactor menu). Select Protege (not Protege.From.Build). This should start Protege.

Note that when starting Protege in this way, the mechanism by which the plugins are found is different than the mechanism that Protege uses when it is distributed. When Protege is distributed, it scans the plugin directory and find the plugins there. When Protege is started in this manner, eclipse is loading the plugins for Protege. In fact, Protege will report "No Plugins Found" because it does not find a plugin directory and thus did not find any plugins to load. But if you enter "status" in the console you will see a detailed description of the state of the run including a description of what plugins have been found.

Step 4b: Run Protege the Harder Way (use only if the easy way 4a did not work) The second icon to the right of the little bug is a run icon with a suitcase. Click the little down arrow beside this icon and run the following scripts in this order:

1. Build.Protege.Infrastructure
2. Build.Common
3. Build.Core
4. Build.Jaxb.Lib
5. Build.Owlapi.Lib
6. Build.Owl.Editor
7. Build.OwlViz

If the projects are marked with red in the left project tree view, refresh them all.

Now we have built a Protege distribution. This distribution is in the Protege directory in the eclipse workspace. Having created this distribution, we can run the other runnable in the bug menu. Click the down arrow beside the little bug and select run Protege from build.

Add your own plugin

Just make your plugin into a plugin development project.

Easy way. If you are able to run protege the easy way (4a) then your plugin will be included. Hotspot replace works (some of the time as always).

Harder way. If you run protege the harder way (4b) then you will need to install your plugin into the protege distribution that we have created. To do this you will need an ant build file. We have provided a template build file that can easily be filled in. We will now describe how this script is added as an eclipse build script. We will turn the fact that I forgot to install the dlquery build script in eclipse into an advantage by showing how this is added here.

To create this new eclipse build script, click on the down arrow to the right of the suitcase runnable and click on "External Tool Configurations". Select "Ant Build" and click the "New Launch Configuration" just above the selected "Ant Build" option. In the resulting window, set the name to "Build.DlQuery" and browse the workspace for the DLQuery build.xml file. The result should look like this:

Now go to the targets tab and make sure that the install target is chosen.

Finally go to the Environment tab and make sure that PROTEGE_HOME is set to ${workspace_loc}/Protege.

Now the new build script can be saved (Apply) and run. Running this script will install your plugin (DLQuery in this case) into the Protege distribution that we have been making.