https://protegewiki.stanford.edu/api.php?action=feedcontributions&user=Tredmond&feedformat=atomProtege Wiki - User contributions [en]2024-03-29T14:36:39ZUser contributionsMediaWiki 1.27.7https://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12294CompileProtege5InEclipseWithMaven2013-09-20T22:31:06Z<p>Tredmond: /* Configuring Eclipse so that the Protege sources are available */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources which may be done as follows:<br />
<pre><br />
git clone https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
'''''If you have a lot of dependencies, the steps below are more than a bit tedious. Is there a maven-eclipse plugin that can help here?'''''<br />
<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre><br />
To satisfy this dependency I need to link the appropriate version of the sesame-repository-sail jar file in my repository to the org.protege.owl.rdf project directory and add it to my class path. To do this I perform the following steps:<br />
# I select the top directory of the project. <br />
# I click ''File->New->File'' and I get a dialog. <br />
# I make sure that the parent folder is the top level directory of the org.protege.owl.rdf project.<br />
# I click on "Advanced" because I want to make a file link and that is advanced. <br />
# There is then a checkbox near the bottom of the dialog that says link to the file system and I click on that.<br />
# I click on variables which causes a sub-dialog to come up.<br />
# In that subdialog I select the M2_REPO variable.<br />
# I click extend and I get a file browser dialog where the top of the file tree is given by the location pointed to by my M2_REPO variable. The path that I select in this browser is governed by the fields in the dependency record for sesame-repository-sail that I am trying to incorporate into eclipse. I explore my way to org/openrdf/sesame (which is derived from the group id in the pom.xml dependency). From that subdirectory I open sesame-repository-sail (which comes from the artifactId. From that subdirectory I open the directory 2.7.0 which comes from the version. Finally in that directory I select the jar file and I click ok for the file browser dialog.<br />
# I make one more check of the parameters in the "New File" dialog. The parent directory should be the top level directory of the org.protege.owl.rdf project, the filename should be sesame-repository-sail-2.7.0.jar and the text in the text box under "link to the file system" should be M2_REPO/org/openrdf/sesame/sesame-repository-sail/2.7.0/sesame-repository-sail-2.7.0.jar.<br />
# I click ok to the new file dialog and I have a link.<br />
After all this work I can look in the "Package Explorer" and see that the sesame-repository-sail-2.7.0.jar file has indeed been linked into the workspace. To add this file to the class path, I right click on the file in the "Package Explorer", move the mouse to "Build Path" and then click on "Add to Build Path".<br />
<br />
I then repeat these steps for each of the dependencies in the pom, excluding the core protege plugins and libraries that are imported by the manifest. On the mac I keep getting this error dialog that says it cannot launch all these jars but I think that this can be ignored. I don't know what it is trying to launch and everything appears to be working fine. If all this pointing and clicking is getting you down then it may be possible to avoid some of this by editing the .project file directly and then refreshing the project in eclipse. The specifications of linked resources in the .project file looks like this:<br />
<pre><br />
<linkedResources><br />
<link><br />
<name>logback-classic-1.0.12.jar</name><br />
<type>1</type><br />
<locationURI>M2_REPO/ch/qos/logback/logback-classic/1.0.12/logback-classic-1.0.12.jar</locationURI><br />
</link><br />
...<br />
</pre><br />
The corresponding entry in the .classpath looks like this:<br />
<pre><br />
<classpathentry kind="lib" path="logback-classic-1.0.12.jar"/><br />
</pre><br />
<br />
<br />
After doing all this work there were a few dependencies of dependencies that were missing:<br />
<pre><br />
sesame-rio-api-2.7.0.jar<br />
sesame-query-2.7.0.jar<br />
sesame-repository-api-2.7.0.jar<br />
sesame-sail-api-2.7.0-jar<br />
</pre><br />
I found these by applying advanced unix search tools to the maven repository. One such command was:<br />
<pre><br />
for i in `find . -name "*protege*" -prune -o -name *.jar -print`<br />
do <br />
echo $i ; jar -tf $i |grep Sail <br />
done<br />
</pre><br />
I don't know of a generally accessible way of finding the missing dependencies but I suspect that this problem is rare.<br />
<br />
Then eclipse has some problems with the manifest. I suspect that these errors are due to a difference of opinion between eclipse and bnd (the MANIFEST was made by maven which uses bnd). The best solution would be to convince eclipse to ignore these errors. Alternatively I opened the manifest in eclipse and applied all the fixes.<br />
<br />
'''''I couldn't try the osgi runnable because I am on a mac. But I will try the project that I made later on a unix machine.'''''</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12293CompileProtege5InEclipseWithMaven2013-09-20T22:28:28Z<p>Tredmond: /* Configuring Eclipse so that the Protege sources are available */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
'''''If you have a lot of dependencies, the steps below are more than a bit tedious. Is there a maven-eclipse plugin that can help here?'''''<br />
<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre><br />
To satisfy this dependency I need to link the appropriate version of the sesame-repository-sail jar file in my repository to the org.protege.owl.rdf project directory and add it to my class path. To do this I perform the following steps:<br />
# I select the top directory of the project. <br />
# I click ''File->New->File'' and I get a dialog. <br />
# I make sure that the parent folder is the top level directory of the org.protege.owl.rdf project.<br />
# I click on "Advanced" because I want to make a file link and that is advanced. <br />
# There is then a checkbox near the bottom of the dialog that says link to the file system and I click on that.<br />
# I click on variables which causes a sub-dialog to come up.<br />
# In that subdialog I select the M2_REPO variable.<br />
# I click extend and I get a file browser dialog where the top of the file tree is given by the location pointed to by my M2_REPO variable. The path that I select in this browser is governed by the fields in the dependency record for sesame-repository-sail that I am trying to incorporate into eclipse. I explore my way to org/openrdf/sesame (which is derived from the group id in the pom.xml dependency). From that subdirectory I open sesame-repository-sail (which comes from the artifactId. From that subdirectory I open the directory 2.7.0 which comes from the version. Finally in that directory I select the jar file and I click ok for the file browser dialog.<br />
# I make one more check of the parameters in the "New File" dialog. The parent directory should be the top level directory of the org.protege.owl.rdf project, the filename should be sesame-repository-sail-2.7.0.jar and the text in the text box under "link to the file system" should be M2_REPO/org/openrdf/sesame/sesame-repository-sail/2.7.0/sesame-repository-sail-2.7.0.jar.<br />
# I click ok to the new file dialog and I have a link.<br />
After all this work I can look in the "Package Explorer" and see that the sesame-repository-sail-2.7.0.jar file has indeed been linked into the workspace. To add this file to the class path, I right click on the file in the "Package Explorer", move the mouse to "Build Path" and then click on "Add to Build Path".<br />
<br />
I then repeat these steps for each of the dependencies in the pom, excluding the core protege plugins and libraries that are imported by the manifest. On the mac I keep getting this error dialog that says it cannot launch all these jars but I think that this can be ignored. I don't know what it is trying to launch and everything appears to be working fine. If all this pointing and clicking is getting you down then it may be possible to avoid some of this by editing the .project file directly and then refreshing the project in eclipse. The specifications of linked resources in the .project file looks like this:<br />
<pre><br />
<linkedResources><br />
<link><br />
<name>logback-classic-1.0.12.jar</name><br />
<type>1</type><br />
<locationURI>M2_REPO/ch/qos/logback/logback-classic/1.0.12/logback-classic-1.0.12.jar</locationURI><br />
</link><br />
...<br />
</pre><br />
The corresponding entry in the .classpath looks like this:<br />
<pre><br />
<classpathentry kind="lib" path="logback-classic-1.0.12.jar"/><br />
</pre><br />
<br />
<br />
After doing all this work there were a few dependencies of dependencies that were missing:<br />
<pre><br />
sesame-rio-api-2.7.0.jar<br />
sesame-query-2.7.0.jar<br />
sesame-repository-api-2.7.0.jar<br />
sesame-sail-api-2.7.0-jar<br />
</pre><br />
I found these by applying advanced unix search tools to the maven repository. One such command was:<br />
<pre><br />
for i in `find . -name "*protege*" -prune -o -name *.jar -print`<br />
do <br />
echo $i ; jar -tf $i |grep Sail <br />
done<br />
</pre><br />
I don't know of a generally accessible way of finding the missing dependencies but I suspect that this problem is rare.<br />
<br />
Then eclipse has some problems with the manifest. I suspect that these errors are due to a difference of opinion between eclipse and bnd (the MANIFEST was made by maven which uses bnd). The best solution would be to convince eclipse to ignore these errors. Alternatively I opened the manifest in eclipse and applied all the fixes.<br />
<br />
'''''I couldn't try the osgi runnable because I am on a mac. But I will try the project that I made later on a unix machine.'''''</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12288Protege Server design2013-09-13T21:42:04Z<p>Tredmond: /* Plugin Model */</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports]. This class is intentionally a very lean interface; it currently contains only seven interface methods.<br />
The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions <br />
<pre><br />
ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;<br />
</pre><br />
and some interfaces to commit changes to the server:<br />
<pre><br />
void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;<br />
</pre><br />
In addition to these simple interfaces supporting the main functionality of the server, that is maintaining the change sets between different versions of ontologies, the server has support for orthogonal requirements such as authentication and the enforcement of policies for reading and/or writing ontologies.<br />
<br />
==Plugin Model==<br />
<br />
While a server may be configured in a programatic fashion, one of the primary methods of running the server uses a plugin architecture. In this plugin architecture, jar files for server plugins are placed in a directory where they are automatically loaded and then configured to work together by following the instructions in a server configuration file. This plugin mechanism is based on the OSGi declarative services. There are four main types of extensions that a plugin may make to the Protege OWL Server:<br />
* A core server. The server is the core component that implements all the [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/Server.java server interface] which includes both [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java public interfaces] that are accessible to the client as well as [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerInternals.java server private interfaces] that are only accessible by plugins on the server. This means that somebody who thinks they have a better implementation of the server interface can simply write a plugin and configure a Protege OWL Server to use their implementation. <br />
* A server filter extension. This type of extension intercepts all calls to the server and may perform arbitrary processing, including throwing an exception, either before or after calling the server. Examples of server filters that are used by the standard Protege OWL server distribution include <br />
** extensions that check that a given call is consistent with policy,<br />
** extensions that check that the caller is properly authenticated,<br />
** extensions that detect conflicts,<br />
** extensions that prevent race conditions by making sure that certain operations, in this case commit operations, occur in a sequential manner, and<br />
** extensions that make sure that the server is properly shutdown on completion.<br />
* A server transport extension. This extension controls the protocol that the client and the server use to communicate. Thus for example the current Protege OWL distribution uses the RMI protocol for client server communications. While a restful implementation of the client server communications would probably not be very efficient, it might make sense for a for an instance of the Protege OWL Server that<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Serialization of ontology changes===<br />
<br />
<br />
==Client side revision management==<br />
<br />
==Tricky points==<br />
<br />
<br />
===Update after a commit===<br />
<br />
<br />
===Out of band interfaces===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12287Protege Server design2013-09-13T21:14:35Z<p>Tredmond: /* Plugin Model */</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports]. This class is intentionally a very lean interface; it currently contains only seven interface methods.<br />
The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions <br />
<pre><br />
ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;<br />
</pre><br />
and some interfaces to commit changes to the server:<br />
<pre><br />
void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;<br />
</pre><br />
In addition to these simple interfaces supporting the main functionality of the server, that is maintaining the change sets between different versions of ontologies, the server has support for orthogonal requirements such as authentication and the enforcement of policies for reading and/or writing ontologies.<br />
<br />
==Plugin Model==<br />
<br />
While a server may be configured in a programatic fashion, one of the primary methods of running the server uses a plugin architecture. In this plugin architecture, jar files for server plugins are placed in a directory where they are automatically loaded and then configured to work together by following the instructions in a server configuration file. This plugin mechanism is based on the OSGi declarative services. There are four main types of extensions that a plugin may make to the Protege OWL Server:<br />
* A core server. The server is the core component that implements all the [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/Server.java server interface] which includes both [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java public interfaces] that are accessible to the client as well as [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerInternals.java server private interfaces] that are only accessible by plugins on the server.<br />
* A server filter extension. This type of extension intercepts all calls to the server and may perform arbitrary processing either before or after calling the server. Examples of server filters include <br />
** extensions that check that a given call is consistent with policy,<br />
** extensions that check that the caller is properly<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Serialization of ontology changes===<br />
<br />
<br />
==Client side revision management==<br />
<br />
==Tricky points==<br />
<br />
<br />
===Update after a commit===<br />
<br />
<br />
===Out of band interfaces===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12286Protege Server design2013-09-13T21:10:22Z<p>Tredmond: </p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports]. This class is intentionally a very lean interface; it currently contains only seven interface methods.<br />
The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions <br />
<pre><br />
ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;<br />
</pre><br />
and some interfaces to commit changes to the server:<br />
<pre><br />
void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;<br />
</pre><br />
In addition to these simple interfaces supporting the main functionality of the server, that is maintaining the change sets between different versions of ontologies, the server has support for orthogonal requirements such as authentication and the enforcement of policies for reading and/or writing ontologies.<br />
<br />
==Plugin Model==<br />
<br />
While a server may be configured in a programatic fashion, one of the primary methods of running the server uses a plugin architecture. In this plugin architecture, jar files for server plugins are placed in a directory where they are automatically loaded and then configured to work together by following the instructions in a server configuration file. This plugin mechanism is based on the OSGi declarative services. There are four main types of extensions that a plugin may make to the Protege OWL Server:<br />
* A core server. The server is the core component that implements all the [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/Server.java server interface] which includes both [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java functionality] that is accessible to the client as well as [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerInternals.java server functionality] that is only accessible by plugins on the server.<br />
* A server filter extension. This type of extension intercepts all <br />
<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Serialization of ontology changes===<br />
<br />
<br />
==Client side revision management==<br />
<br />
==Tricky points==<br />
<br />
<br />
===Update after a commit===<br />
<br />
<br />
===Out of band interfaces===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12285Protege Server design2013-09-13T21:01:59Z<p>Tredmond: /* Plugin Model */ (checkpoint save)</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports]. This class is intentionally a very lean interface; it currently contains only seven interface methods.<br />
The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions <br />
<pre><br />
ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;<br />
</pre><br />
and some interfaces to commit changes to the server:<br />
<pre><br />
void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;<br />
</pre><br />
In addition to these simple interfaces supporting the main functionality of the server, that is maintaining the change sets between different versions of ontologies, the server has support for orthogonal requirements such as authentication and the enforcement of policies for reading and/or writing ontologies.<br />
<br />
==Plugin Model==<br />
<br />
While a server may be configured in a programatic fashion, one of the primary methods of running the server uses a plugin architecture. In this plugin architecture, jar files for server plugins are placed in a directory where they are automatically loaded and then configured to work together by following the instructions in a server configuration file. This plugin mechanism is based on the OSGi declarative services. Each plugin<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Serialization of ontology changes===<br />
<br />
<br />
==Client side revision management==<br />
<br />
==Tricky points==<br />
<br />
<br />
===Update after a commit===<br />
<br />
<br />
===Out of band interfaces===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12284Protege Server design2013-09-13T19:15:13Z<p>Tredmond: /* Plugin Model */</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports]. This class is intentionally a very lean interface; it currently contains only seven interface methods.<br />
The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions <br />
<pre><br />
ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;<br />
</pre><br />
and some interfaces to commit changes to the server:<br />
<pre><br />
void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;<br />
</pre><br />
In addition to these simple interfaces supporting the main functionality of the server, that is maintaining the change sets between different versions of ontologies, the server has support for orthogonal requirements such as authentication and the enforcement of policies for reading and/or writing ontologies.<br />
<br />
==Plugin Model==<br />
<br />
While a server may be configured in a programatic fashion, one of the primary methods of running the server uses a plugin architecture. In this plugin architecture, jar files for server plugins are placed in a directory where they are automatically loaded and then configured to work together by following the instructions in a server configuration file.<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Serialization of ontology changes===<br />
<br />
<br />
==Client side revision management==<br />
<br />
==Tricky points==<br />
<br />
<br />
===Update after a commit===<br />
<br />
<br />
===Out of band interfaces===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12283Protege Server design2013-09-13T19:04:39Z<p>Tredmond: /* Main concepts */</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports]. This class is intentionally a very lean interface; it currently contains only seven interface methods.<br />
The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions <br />
<pre><br />
ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;<br />
</pre><br />
and some interfaces to commit changes to the server:<br />
<pre><br />
void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;<br />
</pre><br />
In addition to these simple interfaces supporting the main functionality of the server, that is maintaining the change sets between different versions of ontologies, the server has support for orthogonal requirements such as authentication and the enforcement of policies for reading and/or writing ontologies.<br />
<br />
==Plugin Model==<br />
<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Serialization of ontology changes===<br />
<br />
<br />
==Client side revision management==<br />
<br />
==Tricky points==<br />
<br />
<br />
===Update after a commit===<br />
<br />
<br />
===Out of band interfaces===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12282Protege Server design2013-09-13T19:01:53Z<p>Tredmond: /* Tricky points */</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports]. This class is intentionally a very lean interface; it currently contains only seven interface methods.<br />
The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions <br />
<pre><br />
ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;<br />
</pre><br />
and some interfaces to commit changes to the server:<br />
<pre><br />
void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;<br />
</pre><br />
<br />
==Plugin Model==<br />
<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Serialization of ontology changes===<br />
<br />
<br />
==Client side revision management==<br />
<br />
==Tricky points==<br />
<br />
<br />
===Update after a commit===<br />
<br />
<br />
===Out of band interfaces===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12281Protege Server design2013-09-13T19:01:04Z<p>Tredmond: /* Protege Server Modules */</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports]. This class is intentionally a very lean interface; it currently contains only seven interface methods.<br />
The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions <br />
<pre><br />
ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;<br />
</pre><br />
and some interfaces to commit changes to the server:<br />
<pre><br />
void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;<br />
</pre><br />
<br />
==Plugin Model==<br />
<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Serialization of ontology changes===<br />
<br />
<br />
==Client side revision management==<br />
<br />
==Tricky points==<br />
<br />
<br />
===Update after a commit===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12280Protege Server design2013-09-13T19:00:32Z<p>Tredmond: /* Ontology Serialization */</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports]. This class is intentionally a very lean interface; it currently contains only seven interface methods.<br />
The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions <br />
<pre><br />
ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;<br />
</pre><br />
and some interfaces to commit changes to the server:<br />
<pre><br />
void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;<br />
</pre><br />
<br />
==Plugin Model==<br />
<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Serialization of ontology changes===<br />
<br />
==Tricky points==<br />
<br />
<br />
===Update after a commit===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12279Protege Server design2013-09-13T18:59:51Z<p>Tredmond: /* Ontology Serialization */</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports]. This class is intentionally a very lean interface; it currently contains only seven interface methods.<br />
The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions <br />
<pre><br />
ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;<br />
</pre><br />
and some interfaces to commit changes to the server:<br />
<pre><br />
void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;<br />
</pre><br />
<br />
==Plugin Model==<br />
<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Ontology Serialization===<br />
<br />
<br />
==Tricky points==<br />
<br />
<br />
===Update after a commit===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12278Protege Server design2013-09-13T18:45:27Z<p>Tredmond: /* Main concepts */</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports]. This class is intentionally a very lean interface; it currently contains only seven interface methods.<br />
The ServerExports class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents. The ServerExports class will have some interfaces to get the changes between any two revisions <br />
<pre><br />
ChangeHistory getChanges(AuthToken u, ServerOntologyDocument doc, OntologyDocumentRevision start, OntologyDocumentRevision end) throws OWLServerException;<br />
</pre><br />
and some interfaces to commit changes to the server:<br />
<pre><br />
void commit(AuthToken u, ServerOntologyDocument doc, SingletonChangeHistory changes) throws OWLServerException;<br />
</pre><br />
<br />
==Plugin Model==<br />
<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Ontology Serialization===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12277Protege Server design2013-09-13T18:40:00Z<p>Tredmond: /* Main concepts */</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class [https://github.com/protegeproject/org.protege.owl.server/blob/master/src/main/java/org/protege/owl/server/api/server/ServerExports.java org.protege.owl.server.api.server.ServerExports].<br />
This class will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents.<br />
<br />
<br />
The core idea is that the server provides the abstraction of an evolving ontology through calls that provide the changes made to an ontology between any two revisions. Thus, for any ontology, the first revision of the ontology will be empty - it will not even have a name. Then in many cases the delta between the first and second contains all the changes needed to take the empty ontology to what the end user views as his initial version of the ontology.<br />
<br />
==Plugin Model==<br />
<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Ontology Serialization===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12276Protege Server design2013-09-13T18:36:40Z<p>Tredmond: /* Main concepts */</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the ontology document will have two revisions, the initial empty revision and the next revision.<br />
The server interface as seen by a client is contained in the class <br />
<pre><br />
org.protege.owl.server.api.server.ServerExports<br />
</pre><br />
It will have some interfaces to provide the hierarchical directory structure that contains the ontology documents. For example, one of the interfaces in ServerExports is the following:<br />
<pre><br />
Collection<ServerDocument> list(AuthToken u, ServerDirectory dir) throws OWLServerException;<br />
</pre><br />
This call lists the contents of a Protege OWL Server directory. The AuthToken parameter is a representation of the authenticated user that wants to list the contents of the directory. The ServerDirectory parameter is the Protege OWL Server document that represents a directory. The call returns a list of the entities in the directories which are represented by ServerDocuments. A ServerDocument is an interface which may represent either a ServerDirectory object or a ServerOntologyDocument. That is to say, a server directory contains a collection of zero or more server directories and server ontology documents.<br />
<br />
<br />
The core idea is that the server provides the abstraction of an evolving ontology through calls that provide the changes made to an ontology between any two revisions. Thus, for any ontology, the first revision of the ontology will be empty - it will not even have a name. Then in many cases the delta between the first and second contains all the changes needed to take the empty ontology to what the end user views as his initial version of the ontology.<br />
<br />
==Plugin Model==<br />
<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Ontology Serialization===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_Server_design&diff=12275Protege Server design2013-09-13T18:24:04Z<p>Tredmond: Created page with " =Protege Server Design= ==Main concepts== The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008..."</p>
<hr />
<div><br />
<br />
=Protege Server Design=<br />
<br />
==Main concepts==<br />
<br />
The Protege OWL Server is loosely based on the ideas expressed in a [http://bmir.stanford.edu/file_asset/index.php/1435/BMIR-2008-1366.pdf paper] that was a collaborative effort between Stanford University and the University of Manchester. The Protege OWL server presents a hierarchical arrangement of directories and evolving ontologies. Each evolving ontology in this hierarchical arrangement is represented as a sequence of revisions together with a collection of ontology changes that represent the change needed to take one revision to the next. Thus, for example, if a user wants to take an existing ontology and place it on the server, a client may perform the following steps<br />
* The client utilizes Protege OWL Server calls to navigate to the directory where she wants to place the original version of her ontology.<br />
* The client creates an ontology document in that directory. This ontology document will initially have only one revision and if the ontology at that revision is retrieved it will be empty; it will not even have a name.<br />
* The client commits all those changes to the ontology document to bring it from its empty document status to the ontology that the client wishes to put on the server. At this point the server will contain those <br />
<br />
<br />
<br />
The core idea is that the server provides the abstraction of an evolving ontology through calls that provide the changes made to an ontology between any two revisions. Thus, for any ontology, the first revision of the ontology will be empty - it will not even have a name. Then in many cases the delta between the first and second contains all the changes needed to take the empty ontology to what the end user views as his initial version of the ontology.<br />
<br />
<br />
==Plugin Model==<br />
<br />
<br />
==Interfaces==<br />
<br />
<br />
==Protege Server Modules==<br />
<br />
===Ontology Serialization===</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=Protege_5_Development_Environment&diff=12274Protege 5 Development Environment2013-09-13T17:37:01Z<p>Tredmond: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
<br />
The Protege 4 client server allows multiple Protege 4 clients (such as the desktop application) to browse and edit concurrently an ontology stored on a Protege 4 server.<br />
<br />
The Protege 4 client server works in a way similar to SVN (update, commit, resolve conflicts). The conflict resolution mechanism is pluggable. You can read more about the client-server implementation (as a generic OWL-API server) in [http://bmir.stanford.edu/publications/view.php/managing_change_an_ontology_version_control_system this paper]. Here is the first of several videos that I am going to make to demonstrate server features:<br />
<ul><br />
<li>[http://www.youtube.com/watch?v=x9L2CUQiRBo Protege OWL Client-Server Basics]</li><br />
</ul><br />
I have also created a new page [[Protege Server design]] to explain how the Protege Server works for the Protege developers.<br />
<br />
= Status =<br />
<br />
We are working on an alpha release. Most of the things that would block an alpha release are relatively easy to do. Here are some things that need doing:<br />
<ul><br />
<li> Figure out how to setup the Protege server as windows service. The startup scripts are now working on linux and on os x.</li><br />
<li> Develop a security policy for server access. We have a policy mechanism but it is not quite ready yet.</li><br />
<li> Don't expose passwords as plaintext. We can live with this for a bit and eventually use the fix in Protege 3.</li><br />
<li> Branching. This shouldn't be too difficult and we plan to permit branches to go across server boundaries (e.g. git-like).</li><br />
<li> Update backwards to a previous revision. The underlying server implementation now supports this but it has not yet been exposed. </li><br />
</ul><br />
Many things already work including<br />
<ul><br />
<li> Basic Client-Server interaction</li><br />
<li> Conflict management</li><br />
<li> Authentication (password is sent as plaintext)</li><br />
<li> Firewall compatibility</li><br />
<li> Extended sessions where a user logs out with uncommitted changes and commits them in a later session</li><br />
</ul><br />
<br />
= Setting Up the Protege 4 Server Development Environment =<br />
<br />
The Protege server is going to be released with a version of Protege 4.2 very soon. At that time this page will be divided into instructions for users wanting to try it out and a developer page for developers. Until that time, we will only include the developer page.<br />
<br />
== Prerequisites ==<br />
<br />
* Java 6 or above. We test this with Oracles java more but openjdk should work.<br />
* Maven 2.<br />
* ant is nice as is some useful development environment such as Eclipse or IntelliJ.<br />
<br />
== Install and Run From Svn ==<br />
<br />
First checkout the development tree<br />
<pre><br />
svn checkout https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk org.protege.owl.server<br />
cd org.protege.owl.server<br />
</pre><br />
To build the server and run the unit and integration tests type:<br />
<pre><br />
mvn verify<br />
</pre><br />
If you want to do this without running the tests type:<br />
<pre><br />
mvn verify -DskipTests<br />
</pre><br />
Note ''mvn package'' will build the main artifact ''target/org.protege.owl.server-*.jar''. In addition, ''mvn verify'' will build a working server in the <br />
''target/server/server-distribution'' directory. This working server is needed for the integration tests but is made even if the tests are not run.<br />
<br />
In addition to the maven lifecycle, this project has an ant build file to add some scripts that are not naturally part of the maven build lifecycle. The ant targets are<br />
* ''usage'' which will give a complete listing of the ant targets with some additional documentation.<br />
* ''run'' which will run the server, assuming that ''mvn verify'' has already been run. This server will listen for client requests on port 5100.<br />
* ''debug'' which will run the server as above but will allow debugging by waiting for a debugger to connect on port 8100. I believe that most reasonable ide's will have a facility for debugging in this manner and the eclipse capability can be configured with the menu ''Debug&rarr;Debug Configurations&rarr;Remote Java Application''. <br />
* ''install'' which will install the Protege server library into the copy of a Protege distribution pointed to by the PROTEGE_HOME environment variable. This target assumes that maven has been previously run with a lifecycle goal of ''package'' or better (e.g., ''verify'' works). In order for this to be useful, you will also need to install the protege client. The client installation is described below. Information about the PROTEGE_HOME environment variable and the Protege build scripts can be found [[ConfiguringAntBuildFiles|here]].<br />
The server that is started in this way is preconfigured with the following usernames and passwords:<br />
{| class="wikitable"<br />
| fergerson || ncbo<br />
|- <br />
| redmond || bicycle<br />
|-<br />
| vendetti || protege<br />
|- <br />
| guest || guest<br />
|}<br />
<br />
<br />
After installing a copy of the server library into PROTEGE_HOME, you may want to install the Protege client so that you can use Protege to connect to the server. To do this first checkout the client code:<br />
<pre><br />
svn checkout https://smi-protege.stanford.edu/repos/protege/protege4/plugins/org.protege.editor.owl.client/trunk org.protege.editor.owl.client<br />
</pre><br />
Then you can compile and install it as follows:<br />
<pre><br />
cd org.protege.editor.owl.client<br />
ant install<br />
</pre><br />
<br />
== Setting up Eclipse ==<br />
<br />
To configure the org.protege.owl.server project follow the following steps:<br />
# first check the project out from svn (e.g., ''svn checkout https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk org.protege.owl.server''). This can be done using the eclipse tools but don't worry about how the project gets configured. Then, after making sure that the META-INF/MANIFEST.MF file has not been modified when eclipse checked out the org.protege.owl.server.<br />
# make the maven call ''mvn eclipse:clean eclipse:eclipse''.<br />
# in eclipse either refresh the org.protege.owl.server project, if it is already visible there, or import the project using the ''File&rarr;Import&rarr;Existing Projects Into Workspace'' menu.<br />
<br />
<br />
'''''This has changed and will be updated shortly.'''''<br />
<br />
<br />
To set up eclipse, <br />
<ol><br />
<li> run "ant install". This step ensures that the built sources will be included in the<br />
org.protege.owl.server project.</li><br />
<li> unzip the ide-eclipse.zip file.</li><br />
<li> start eclipse using protege.server as the workspace.</li><br />
<li>import the projects (File -> Import -> General -> Existing Projects Into Workspace).</li><br />
</ol><br />
<b>The next part doesn't work yet but should be coming soon.</b><br />
This eclipse workspace will come with a couple of runnables:<br />
<ul><br />
<li><b>Client</b> starts the Protege OWL Client.</li><br />
<li><b>Server</b> starts the Protege OWL Sever</li><br />
<li><b>ConnectToAntServer</b> connects to the "ant debug.server" script for debugging.</li><br />
</ul><br />
<br />
== Programatic access to the server ==<br />
<br />
Some of the key classes used to access the OWL server are:<br />
* the [https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/main/java/org/protege/owl/server/api/Client.java Client] which provides a low level api for server access. A Client object can also be used by classes such as the [https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/main/java/org/protege/owl/server/util/ClientUtilities.java ClientUtilities] to provide easy higher level operations such as uploading, downloading and updating ontologies.<br />
* the [https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/main/java/org/protege/owl/server/api/VersionedOntologyDocument.java VersionedOntologyDocument] is an object representing an open ontology corresponding to a server document at a particular document revision. An instantiation of the Client and VersionedOntologyDocument are sufficient to do many operations on a checked out ontology including update, commit and save.<br />
<br />
=== Connecting to the server programatically ===<br />
<br />
Connecting to the Protege server involves two steps, authentication and connection. Both the authentication protocol and the connection protocol are fully pluggable on the server, so the exact method of connecting to the server depends on how the server is configured. However currently we only support one authentication mechanism, a very simple username/password mechanism, and two connection protocols, the rmi protocol for accessing the server remotely and the local protocol for accessing a server running on the same jvm.<br />
<br />
==== Accessing the server through rmi ====<br />
<br />
Accessing the server with standard authentication and rmi can be done with the following steps:<br />
<pre><br />
String host = "171.65.32.14";<br />
int rmiPort = 4875;<br />
AuthToken tim = RMILoginUtility.login(host, rmiPort, "redmond", "troglodyte");<br />
RMIClient client = new RMIClient(tim, host, rmiPort);<br />
</pre><br />
The first step authenticates the user "redmond" on to a server running on the same machine but in a different process. This authentication step results in a AuthToken object (tim) that can then be used to connect to the server. The result of the above steps is an object that implements the [https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/main/java/org/protege/owl/server/api/Client.java Client] interface.<br />
<br />
==== Accessing the server from the same jvm ====<br />
<br />
The best way to access the server when running on the same jvm is to use a local transport. This transport bypasses all network protocols such as rmi and makes a direct connection to the server through java function calls. The manner in which the local transport object is obtained depends on how the server is started. The normal case will be the standard Protege server installation where the code accessing the server is run from a plugin. In this case the LocalTransport object can be obtained from [http://wiki.osgi.org/wiki/Declarative_Services OSGi declarative services]. An example of this approach can be found [https://smi-protege.stanford.edu/repos/protege/protege4/misc/examples/org.protege.owl.server.example/trunk here]. This example can be run by<br />
* checking out the project from the svn [https://smi-protege.stanford.edu/repos/protege/protege4/misc/examples/org.protege.owl.server.example/trunk location].<br />
* copying the local.properties.template to local.properties and changing the server.home to the appropriate location of the Protege server.<br />
* running ant install to install the plugin to the Protege server plugin directory.<br />
* (re)starting the Protege server so that it will pick up the new plugin.<br />
<br />
To obtain the LocalTransport object through declarative services, create a server component declaration like this [https://smi-protege.stanford.edu/repos/protege/protege4/misc/examples/org.protege.owl.server.example/trunk/OSGI-INF/example-component.xml one]:<br />
<pre><br />
<?xml version="1.0"?><br />
<scr:component name="org.protege.owl.server.example.component" <br />
immediate="true"<br />
xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"><br />
<implementation class="org.protege.owl.server.example.EntryImpl"/><br />
<service><br />
<provide interface="org.protege.owl.server.example.Entry"/><br />
</service><br />
<reference name="LOCALTRANSPORT"<br />
interface="org.protege.owl.server.connect.local.LocalTransport"<br />
bind="initialise"<br />
cardinality="1..1"/><br />
</scr:component><br />
</pre><br />
This declaration tells OSGi declarative services that if it sees a new LocalTransport service then it should instantiate an EntryImpl class and send the new LocalTransport to the EntryImpl's initialise method.<br />
<br />
Once the LocalTransport object has been obtained, the client can easily be obtained after authenticating as follows:<br />
<pre><br />
AuthToken token = Authenticator.localLogin(transport, "redmond", "troglodyte");<br />
Client client = transport.getClient(token);<br />
</pre><br />
This client can be used just as any ordinary client. In the example plugin it is used to list the contents of the root directory of the server:<br />
<pre><br />
RemoteServerDirectory serverRoot = (RemoteServerDirectory) client.getServerDocument(localRoot);<br />
boolean isEmpty = true;<br />
for (RemoteServerDocument doc : client.list(serverRoot)) {<br />
logger.info("Found doc : " + doc);<br />
isEmpty = false;<br />
}<br />
if (isEmpty) {<br />
logger.info("Server root is empty");<br />
}<br />
</pre><br />
In a more realistic plugin, [https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server.bioportal/trunk the bioportal import plugin] for instance, it is used to copy and update ontologies from the [http://bioportal.bioontology.org/ NCBO BioPortal] into a directory on the Protege server.<br />
<br />
<br />
Alternatively, if you start the server without OSGi (see [[#Starting the server manually|manual setup]]) then you can arrange to register the LocalTransport somehow so that classes that need it can find it.<br />
<br />
=== Navigating the server file system ===<br />
<br />
Documents on the Protege server are identified by an IRI. Thus for example, the root directory for the server at 171.65.32.14:4875 would look like this:<br />
<pre><br />
rmi-owl2-server://localhost:5100<br />
</pre><br />
This IRI can be construced programatically as follows:<br />
<pre><br />
String host = "171.65.32.14";<br />
int rmiPort = 4875;<br />
IRI serverIRI = IRI.create(RMIClient.SCHEME + "://" + host + ":" + rmiPort);<br />
</pre><br />
If you know the name for a server document (the root directory, for example, should always exist) then you can retrieve it directly:<br />
<pre><br />
client.getServerDocument(serverIRI);<br />
</pre><br />
This server document ([https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/main/java/org/protege/owl/server/api/RemoteOntologyDocument.java RemoteOntologyDocument]) can either be a directory ([https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/main/java/org/protege/owl/server/api/RemoteServerDirectory.java RemoteServerDirectory]) or an ontology document<br />
[https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/main/java/org/protege/owl/server/api/RemoteOntologyDocument.java RemoteOntologyDocument]). <br />
<br />
In particular, in the case of the server root directory, the server document is guaranteed to be a directory so it can be directly cast to that type. So if serverIRI represents the server root as described above then we can use the following code:<br />
<pre><br />
RemoteServerDirectory dir = (RemoteServerDirectory) client.getServerDocument(serverIRI);<br />
</pre><br />
The contents of a directory can then be listed:<br />
<pre><br />
for (RemoteServerDocument doc : client.list(dir)) {<br />
System.out.println("found: " + doc.getServerLocation());<br />
}<br />
</pre><br />
<br />
=== Uploading an ontology document to the server ===<br />
<br />
The pre-requisites for uploading an ontology to a Protege server are a valid client to the server and an open (e.g. instantiation of the OWL api OWLOntology interface) ontology. The [https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/main/java/org/protege/owl/server/util/ClientUtilities.java ClientUtilities] class provides a convenience method for uploading an ontology to the server and a typical invocation looks something like this:<br />
<pre><br />
VersionedOntologyDocument versionedOntology = ClientUtilities.createServerOntology(client, pizzaLocation, new ChangeMetaData("A tasty pizza"), ontology);<br />
</pre><br />
where <br />
* client is the [https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/main/java/org/protege/owl/server/api/Client.java Client]<br />
* pizzaLocation is an IRI for the ontology document on the server,<br />
* ChangeMetaData is a class containing a commit timestamp and a commit comment.<br />
* ontology is the ontology that you wish to save.<br />
<br />
=== Downloading an ontology document from the server ===<br />
<br />
Again the [https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/main/java/org/protege/owl/server/util/ClientUtilities.java ClientUtilities] class is the key. The ClientUtilities class has a loadOntology method that takes three arguments: a Client, an ontology manager and a RemoteOntologyDocument to be downloaded. The following code demonstrates how this works:<br />
<pre><br />
RemoteOntologyDocument doc = (RemoteOntologyDocument) client.getServerDocument(IRI.create(RMIClient.SCHEME + "://" + host + ":" + rmiPort <br />
+ "/Pizza.history"));<br />
VersionedOntologyDocument vont = ClientUtilities.loadOntology(client, OWLManager.createOWLOntologyManager(), doc);<br />
OWLOntology ontology = vont.getOntology();<br />
System.out.println("Axiom count = " + ontology.getAxiomCount());<br />
</pre><br />
The caller knows that there is a server-side ontology document representing the pizza ontology and requests a RemoteOntologyDocument pointing to that location.<br />
<br />
=== Saving a server ontology locally along with server metadata ===<br />
<br />
=== Loading a server ontology and server meta data from a local file ===<br />
<br />
=== Uploading an ontology onto the server ===<br />
<br />
== Extending the server with a plugin ==<br />
<br />
Here I will talk about the metaproject and server components.<br />
<br />
== Starting the server manually ==<br />
<br />
In its standard installation, the Protege server is automatically configured based on a configuration file using a [http://en.wikipedia.org/wiki/Dependency_injection dependency injection strategy]. However it is possible to start the server programmatically and this approach to starting and running the server is demonstrated in a [https://smi-protege.stanford.edu/repos/protege/protege4/libraries/org.protege.owl.server/trunk/src/test/java/org/protege/owl/server/DirectServerSetupTest.java unit test]. The key code in this test is the code that starts the server:<br />
<pre><br />
Server core = new ServerImpl(TestUtilities.ROOT_DIRECTORY, TestUtilities.CONFIGURATION_DIRECTORY);<br />
server = new Authenticator(new ConflictManager(core));<br />
<br />
List<ServerTransport> transports = new ArrayList<ServerTransport>();<br />
ServerTransport rmiTransport = new RMITransport(rmiPort, rmiPort);<br />
rmiTransport.start(server);<br />
transports.add(rmiTransport);<br />
localTransport = new LocalTransportImpl();<br />
localTransport.start(server);<br />
transports.add(localTransport);<br />
<br />
server.setTransports(transports);<br />
</pre><br />
The first two lines:<br />
<pre><br />
Server core = new ServerImpl(TestUtilities.ROOT_DIRECTORY, TestUtilities.CONFIGURATION_DIRECTORY);<br />
server = new Authenticator(new ConflictManager(core));<br />
</pre><br />
initialize a new server and configure two filters for the server which provide a simple authentication mechanism and basic conflict management.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12256CompileProtege5InEclipseWithMaven2013-09-06T22:38:52Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
'''''If you have a lot of dependencies, the steps below are more than a bit tedious. Is there a maven-eclipse plugin that can help here?'''''<br />
<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre><br />
To satisfy this dependency I need to link the appropriate version of the sesame-repository-sail jar file in my repository to the org.protege.owl.rdf project directory and add it to my class path. To do this I perform the following steps:<br />
# I select the top directory of the project. <br />
# I click ''File->New->File'' and I get a dialog. <br />
# I make sure that the parent folder is the top level directory of the org.protege.owl.rdf project.<br />
# I click on "Advanced" because I want to make a file link and that is advanced. <br />
# There is then a checkbox near the bottom of the dialog that says link to the file system and I click on that.<br />
# I click on variables which causes a sub-dialog to come up.<br />
# In that subdialog I select the M2_REPO variable.<br />
# I click extend and I get a file browser dialog where the top of the file tree is given by the location pointed to by my M2_REPO variable. The path that I select in this browser is governed by the fields in the dependency record for sesame-repository-sail that I am trying to incorporate into eclipse. I explore my way to org/openrdf/sesame (which is derived from the group id in the pom.xml dependency). From that subdirectory I open sesame-repository-sail (which comes from the artifactId. From that subdirectory I open the directory 2.7.0 which comes from the version. Finally in that directory I select the jar file and I click ok for the file browser dialog.<br />
# I make one more check of the parameters in the "New File" dialog. The parent directory should be the top level directory of the org.protege.owl.rdf project, the filename should be sesame-repository-sail-2.7.0.jar and the text in the text box under "link to the file system" should be M2_REPO/org/openrdf/sesame/sesame-repository-sail/2.7.0/sesame-repository-sail-2.7.0.jar.<br />
# I click ok to the new file dialog and I have a link.<br />
After all this work I can look in the "Package Explorer" and see that the sesame-repository-sail-2.7.0.jar file has indeed been linked into the workspace. To add this file to the class path, I right click on the file in the "Package Explorer", move the mouse to "Build Path" and then click on "Add to Build Path".<br />
<br />
I then repeat these steps for each of the dependencies in the pom, excluding the core protege plugins and libraries that are imported by the manifest. On the mac I keep getting this error dialog that says it cannot launch all these jars but I think that this can be ignored. I don't know what it is trying to launch and everything appears to be working fine. If all this pointing and clicking is getting you down then it may be possible to avoid some of this by editing the .project file directly and then refreshing the project in eclipse. The specifications of linked resources in the .project file looks like this:<br />
<pre><br />
<linkedResources><br />
<link><br />
<name>logback-classic-1.0.12.jar</name><br />
<type>1</type><br />
<locationURI>M2_REPO/ch/qos/logback/logback-classic/1.0.12/logback-classic-1.0.12.jar</locationURI><br />
</link><br />
...<br />
</pre><br />
The corresponding entry in the .classpath looks like this:<br />
<pre><br />
<classpathentry kind="lib" path="logback-classic-1.0.12.jar"/><br />
</pre><br />
<br />
<br />
After doing all this work there were a few dependencies of dependencies that were missing:<br />
<pre><br />
sesame-rio-api-2.7.0.jar<br />
sesame-query-2.7.0.jar<br />
sesame-repository-api-2.7.0.jar<br />
sesame-sail-api-2.7.0-jar<br />
</pre><br />
I found these by applying advanced unix search tools to the maven repository. One such command was:<br />
<pre><br />
for i in `find . -name "*protege*" -prune -o -name *.jar -print`<br />
do <br />
echo $i ; jar -tf $i |grep Sail <br />
done<br />
</pre><br />
I don't know of a generally accessible way of finding the missing dependencies but I suspect that this problem is rare.<br />
<br />
Then eclipse has some problems with the manifest. I suspect that these errors are due to a difference of opinion between eclipse and bnd (the MANIFEST was made by maven which uses bnd). The best solution would be to convince eclipse to ignore these errors. Alternatively I opened the manifest in eclipse and applied all the fixes.<br />
<br />
'''''I couldn't try the osgi runnable because I am on a mac. But I will try the project that I made later on a unix machine.'''''</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12255CompileProtege5InEclipseWithMaven2013-09-06T22:37:01Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
'''''If you have a lot of dependencies, the steps below are more than a bit tedious. Is there a maven-eclipse plugin that can help here?'''''<br />
<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre><br />
To satisfy this dependency I need to link the appropriate version of the sesame-repository-sail jar file in my repository to the org.protege.owl.rdf project directory and add it to my class path. To do this I perform the following steps:<br />
# I select the top directory of the project. <br />
# I click ''File->New->File'' and I get a dialog. <br />
# I make sure that the parent folder is the top level directory of the org.protege.owl.rdf project.<br />
# I click on "Advanced" because I want to make a file link and that is advanced. <br />
# There is then a checkbox near the bottom of the dialog that says link to the file system and I click on that.<br />
# I click on variables which causes a sub-dialog to come up.<br />
# In that subdialog I select the M2_REPO variable.<br />
# I click extend and I get a file browser dialog where the top of the file tree is given by the location pointed to by my M2_REPO variable. The path that I select in this browser is governed by the fields in the dependency record for sesame-repository-sail that I am trying to incorporate into eclipse. I explore my way to org/openrdf/sesame (which is derived from the group id in the pom.xml dependency). From that subdirectory I open sesame-repository-sail (which comes from the artifactId. From that subdirectory I open the directory 2.7.0 which comes from the version. Finally in that directory I select the jar file and I click ok for the file browser dialog.<br />
# I make one more check of the parameters in the "New File" dialog. The parent directory should be the top level directory of the org.protege.owl.rdf project, the filename should be sesame-repository-sail-2.7.0.jar and the text in the text box under "link to the file system" should be M2_REPO/org/openrdf/sesame/sesame-repository-sail/2.7.0/sesame-repository-sail-2.7.0.jar.<br />
# I click ok to the new file dialog and I have a link.<br />
After all this work I can look in the "Package Explorer" and see that the sesame-repository-sail-2.7.0.jar file has indeed been linked into the workspace. To add this file to the class path, I right click on the file in the "Package Explorer", move the mouse to "Build Path" and then click on "Add to Build Path".<br />
<br />
I then repeat these steps for each of the dependencies in the pom, excluding the core protege plugins and libraries that are imported by the manifest. On the mac I keep getting this error dialog that says it cannot launch all these jars but I think that this can be ignored. I don't know what it is trying to launch and everything appears to be working fine. If all this pointing and clicking is getting you down then it may be possible to avoid some of this by editing the .project file directly and then refreshing the project in eclipse. The specifications of linked resources in the .project file looks like this:<br />
<pre><br />
<linkedResources><br />
<link><br />
<name>logback-classic-1.0.12.jar</name><br />
<type>1</type><br />
<locationURI>M2_REPO/ch/qos/logback/logback-classic/1.0.12/logback-classic-1.0.12.jar</locationURI><br />
</link><br />
...<br />
</pre><br />
The corresponding entry in the .classpath looks like this:<br />
<pre><br />
<classpathentry kind="lib" path="logback-classic-1.0.12.jar"/><br />
</pre><br />
<br />
<br />
After doing all this work there were a few dependencies of dependencies that were missing:<br />
<pre><br />
sesame-rio-api-2.7.0.jar<br />
sesame-query-2.7.0.jar<br />
sesame-repository-api-2.7.0.jar<br />
sesame-sail-api-2.7.0-jar<br />
</pre><br />
I found these by applying advanced linux search tools to the maven repository. One such command was:<br />
<pre><br />
for i in `find . -name "*protege*" -prune -o -name *.jar -print`<br />
do <br />
echo $i ; jar -tf $i |grep Sail <br />
done<br />
</pre><br />
I don't know of a generally accessible way of finding the missing dependencies but I suspect that this problem is rare.<br />
<br />
Then eclipse has some problems with the manifest. I suspect that these errors are due to a difference of opinion between eclipse and bnd (the MANIFEST was made by maven which uses bnd). The best solution would be to convince eclipse to ignore these errors. Alternatively I opened the manifest in eclipse and applied all the fixes.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12254CompileProtege5InEclipseWithMaven2013-09-06T22:30:35Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
'''''If you have a lot of dependencies, the steps below are more than a bit tedious. Is there a maven-eclipse plugin that can help here?'''''<br />
<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre><br />
To satisfy this dependency I need to link the appropriate version of the sesame-repository-sail jar file in my repository to the org.protege.owl.rdf project directory and add it to my class path. To do this I perform the following steps:<br />
# I select the top directory of the project. <br />
# I click ''File->New->File'' and I get a dialog. <br />
# I make sure that the parent folder is the top level directory of the org.protege.owl.rdf project.<br />
# I click on "Advanced" because I want to make a file link and that is advanced. <br />
# There is then a checkbox near the bottom of the dialog that says link to the file system and I click on that.<br />
# I click on variables which causes a sub-dialog to come up.<br />
# In that subdialog I select the M2_REPO variable.<br />
# I click extend and I get a file browser dialog where the top of the file tree is given by the location pointed to by my M2_REPO variable. The path that I select in this browser is governed by the fields in the dependency record for sesame-repository-sail that I am trying to incorporate into eclipse. I explore my way to org/openrdf/sesame (which is derived from the group id in the pom.xml dependency). From that subdirectory I open sesame-repository-sail (which comes from the artifactId. From that subdirectory I open the directory 2.7.0 which comes from the version. Finally in that directory I select the jar file and I click ok for the file browser dialog.<br />
# I make one more check of the parameters in the "New File" dialog. The parent directory should be the top level directory of the org.protege.owl.rdf project, the filename should be sesame-repository-sail-2.7.0.jar and the text in the text box under "link to the file system" should be M2_REPO/org/openrdf/sesame/sesame-repository-sail/2.7.0/sesame-repository-sail-2.7.0.jar.<br />
# I click ok to the new file dialog and I have a link.<br />
After all this work I can look in the "Package Explorer" and see that the sesame-repository-sail-2.7.0.jar file has indeed been linked into the workspace. To add this file to the class path, I right click on the file in the "Package Explorer", move the mouse to "Build Path" and then click on "Add to Build Path".<br />
<br />
I then repeat these steps for each of the dependencies in the pom, excluding the core protege plugins and libraries that are imported by the manifest. On the mac I keep getting this error dialog that says it cannot launch all these jars but I think that this can be ignored. I don't know what it is trying to launch and everything appears to be working fine.<br />
<br />
After doing all this work there were a few dependencies of dependencies that were missing:<br />
<pre><br />
sesame-rio-api-2.7.0.jar<br />
sesame-query-2.7.0.jar<br />
sesame-repository-api-2.7.0.jar<br />
sesame-sail-api-2.7.0-jar<br />
</pre><br />
I found these by applying advanced linux search tools to the maven repository. One such command was:<br />
<pre><br />
for i in `find . -name "*protege*" -prune -o -name *.jar -print`<br />
do <br />
echo $i ; jar -tf $i |grep Sail <br />
done<br />
</pre><br />
I don't know of a generally accessible way of finding the missing dependencies but I suspect that this problem is rare.<br />
<br />
Then eclipse has some problems with the manifest. I suspect that these errors are due to a difference of opinion between eclipse and bnd (the MANIFEST was made by maven which uses bnd). The best solution would be to convince eclipse to ignore these errors. Alternatively I opened the manifest in eclipse and applied all the fixes.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12253CompileProtege5InEclipseWithMaven2013-09-06T22:09:26Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre><br />
To satisfy this dependency I need to link the appropriate version of the sesame-repository-sail jar file in my repository to the org.protege.owl.rdf project directory and add it to my class path. To do this I perform the following steps:<br />
# I select the top directory of the project. <br />
# I click ''File->New->File'' and I get a dialog. <br />
# I make sure that the parent folder is the top level directory of the org.protege.owl.rdf project.<br />
# I click on "Advanced" because I want to make a file link and that is advanced. <br />
# There is then a checkbox near the bottom of the dialog that says link to the file system and I click on that.<br />
# I click on variables which causes a sub-dialog to come up.<br />
# In that subdialog I select the M2_REPO variable.<br />
# I click extend and I get a file browser dialog where the top of the file tree is given by the location pointed to by my M2_REPO variable. The path that I select in this browser is governed by the fields in the dependency record for sesame-repository-sail that I am trying to incorporate into eclipse. I explore my way to org/openrdf/sesame (which is derived from the group id in the pom.xml dependency). From that subdirectory I open sesame-repository-sail (which comes from the artifactId. From that subdirectory I open the directory 2.7.0 which comes from the version. Finally in that directory I select the jar file and I click ok for the file browser dialog.<br />
# I make one more check of the parameters in the "New File" dialog. The parent directory should be the top level directory of the org.protege.owl.rdf project, the filename should be sesame-repository-sail-2.7.0.jar and the text in the text box under "link to the file system" should be M2_REPO/org/openrdf/sesame/sesame-repository-sail/2.7.0/sesame-repository-sail-2.7.0.jar.<br />
# I click ok to the new file dialog and I have a link.<br />
After all this work I can look in the "Package Explorer" and see that the sesame-repository-sail-2.7.0.jar file has indeed been linked into the workspace. To add this file to the class path, I right click on the file in the "Package Explorer", move the mouse to "Build Path" and then click on "Add to Build Path".<br />
<br />
I then repeat these steps for each of the dependencies in the pom, excluding the core protege plugins and libraries that are imported by the manifest. On the mac I keep getting this error dialog that says it cannot launch all these jars but I think that this can be ignored. I don't know what it is trying to launch and everything appears to be working fine.<br />
<br />
After doing all this there was one more missing dependency. I will investigate this further but what I think happened is that when maven built the project and found the dependency of the project<br />
<br />
<br />
sesame-rio-api-2.7.0.jar<br />
sesame-query-2.7.0.jar<br />
sesame-repository-api-2.7.0.jar<br />
sesame-sail-api-2.7.0-jar</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12252CompileProtege5InEclipseWithMaven2013-09-06T21:36:26Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre><br />
To satisfy this dependency I need to link the appropriate version of the sesame-repository-sail jar file in my repository to the org.protege.owl.rdf project directory and add it to my class path. To do this I perform the following steps:<br />
# I select the top directory of the project. <br />
# I click ''File->New->File'' and I get a dialog. <br />
# I make sure that the parent folder is the top level directory of the org.protege.owl.rdf project.<br />
# I click on "Advanced" because I want to make a file link and that is advanced. <br />
# There is then a checkbox near the bottom of the dialog that says link to the file system and I click on that.<br />
# I click on variables which causes a sub-dialog to come up.<br />
# In that subdialog I select the M2_REPO variable.<br />
# I click extend and I get a file browser dialog where the top of the file tree is given by the location pointed to by my M2_REPO variable. The path that I select in this browser is governed by the fields in the dependency record for sesame-repository-sail that I am trying to incorporate into eclipse. I explore my way to org/openrdf/sesame (which is derived from the group id in the pom.xml dependency). From that subdirectory I open sesame-repository-sail (which comes from the artifactId. From that subdirectory I open the directory 2.7.0 which comes from the version. Finally in that directory I select the jar file and I click ok for the file browser dialog.<br />
# I make one more check of the parameters in the "New File" dialog. The parent directory should be the top level directory of the org.protege.owl.rdf project, the filename should be sesame-repository-sail-2.7.0.jar and the text in the text box under "link to the file system" should be M2_REPO/org/openrdf/sesame/sesame-repository-sail/2.7.0/sesame-repository-sail-2.7.0.jar.<br />
# I click ok to the new file dialog and I have a link.<br />
After all this work I can look in the "Package Explorer" and see that the sesame-repository-sail-2.7.0.jar file has indeed been linked into the workspace. To add this file to the class path, I right click on the file in the "Package Explorer", move the mouse to "Build Path" and then click on "Add to Build Path".<br />
<br />
I then repeat these steps for each of the dependencies in the pom, excluding the core protege plugins and libraries that are imported by the manifest. On the mac I keep getting this error dialog that says it cannot launch all these jars but I think that this can be ignored. I don't know what it is trying to launch and everything appears to be working fine.<br />
<br />
After doing all this there was one more missing dependency. I will investigate this further but what I think happened is that when maven built the project and found the dependency of the project<br />
<br />
<br />
sesame-rio-api-2.7.0<br />
sesame-repository-api-2.7.0.jar</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12251CompileProtege5InEclipseWithMaven2013-09-06T21:29:32Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre><br />
To satisfy this dependency I need to link the appropriate version of the sesame-repository-sail jar file in my repository to the org.protege.owl.rdf project directory and add it to my class path. To do this I perform the following steps:<br />
# I select the top directory of the project. <br />
# I click ''File->New->File'' and I get a dialog. <br />
# I make sure that the parent folder is the top level directory of the org.protege.owl.rdf project.<br />
# I click on "Advanced" because I want to make a file link and that is advanced. <br />
# There is then a checkbox near the bottom of the dialog that says link to the file system and I click on that.<br />
# I click on variables which causes a sub-dialog to come up.<br />
# In that subdialog I select the M2_REPO variable.<br />
# I click extend and I get a file browser dialog where the top of the file tree is given by the location pointed to by my M2_REPO variable. The path that I select in this browser is governed by the fields in the dependency record for sesame-repository-sail that I am trying to incorporate into eclipse. I explore my way to org/openrdf/sesame (which is derived from the group id in the pom.xml dependency). From that subdirectory I open sesame-repository-sail (which comes from the artifactId. From that subdirectory I open the directory 2.7.0 which comes from the version. Finally in that directory I select the jar file and I click ok for the file browser dialog.<br />
# I make one more check of the parameters in the "New File" dialog. The parent directory should be the top level directory of the org.protege.owl.rdf project, the filename should be sesame-repository-sail-2.7.0.jar and the text in the text box under "link to the file system" should be M2_REPO/org/openrdf/sesame/sesame-repository-sail/2.7.0/sesame-repository-sail-2.7.0.jar.<br />
# I click ok to the new file dialog and I have a link.<br />
After all this work I can look in the "Package Explorer" and see that the sesame-repository-sail-2.7.0.jar file has indeed been linked into the workspace. To add this file to the class path, I right click on the file in the "Package Explorer", move the mouse to "Build Path" and then click on "Add to Build Path".<br />
<br />
I then repeat these steps for each of the dependencies in the pom, excluding the core protege plugins and libraries that are imported by the manifest. On the mac I keep getting this error dialog that says it cannot launch all these jars but I think that this can be ignored. I don't know what it is trying to launch and everything appears to be working fine.<br />
<br />
After doing all this there was one more missing dependency. I will investigate this further but what I think happened is that when maven built the project and found the dependency of the project</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12250CompileProtege5InEclipseWithMaven2013-09-06T21:13:11Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre><br />
To satisfy this dependency I need to link the appropriate version of the sesame-repository-sail jar file in my repository to the org.protege.owl.rdf project directory and add it to my class path. To do this I perform the following steps:<br />
# I select the top directory of the project. <br />
# I click ''File->New->File'' and I get a dialog. <br />
# I make sure that the parent folder is the top level directory of the org.protege.owl.rdf project.<br />
# I click on "Advanced" because I want to make a file link and that is advanced. <br />
# There is then a checkbox near the bottom of the dialog that says link to the file system and I click on that.<br />
# I click on variables which causes a sub-dialog to come up.<br />
# In that subdialog I select the M2_REPO variable.<br />
# I click extend and I get a file browser dialog where the top of the file tree is given by the location pointed to by my M2_REPO variable. The path that I select in this browser is governed by the fields in the dependency record for sesame-repository-sail that I am trying to incorporate into eclipse. I explore my way to org/openrdf/sesame (which is derived from the group id in the pom.xml dependency). From that subdirectory I open sesame-repository-sail (which comes from the artifactId. From that subdirectory I open the directory 2.7.0 which comes from the version. Finally in that directory I select the jar file and I click ok for the file browser dialog.<br />
# I make one more check of the parameters in the "New File" dialog. The parent directory should be the top level directory of the org.protege.owl.rdf project, the filename should be sesame-repository-sail-2.7.0.jar and the text in the text box under "link to the file system" should be M2_REPO/org/openrdf/sesame/sesame-repository-sail/2.7.0/sesame-repository-sail-2.7.0.jar.<br />
# I click ok to the new file dialog and I have a link.<br />
After all this work I can look in the "Package Explorer" and see that the sesame-repository-sail-2.7.0.jar file has indeed been linked into the workspace. To add this file to the class path, I right click on the file in the "Package Explorer", move the mouse to "Build Path" and then click on "Add to Build Path".<br />
<br />
I then repeat these steps for each of the dependencies in the pom, excluding the core protege plugins and libraries that are imported by the manifest. On the mac I keep getting this error dialog that says it cannot launch all these jars but I think that this can be ignored. I don't know what it is trying to launch and everything appears to be working fine.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12249CompileProtege5InEclipseWithMaven2013-09-06T20:54:10Z<p>Tredmond: /* A manual method */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre><br />
To satisfy this dependency I need to link the appropriate version of the sesame-repository-sail jar file in my repository to the org.protege.owl.rdf project directory and add it to my class path. To do this I perform the following steps:<br />
# I select the top directory of the project. <br />
# I click ''File->New->File'' and I get a dialog. <br />
# I make sure that the parent folder is the top level directory of the org.protege.owl.rdf project.<br />
# I click on "Advanced" because I want to make a file link and that is advanced. <br />
# There is then a checkbox near the bottom of the dialog that says link to the file system and I click on that.<br />
# I click on variables which causes a sub-dialog to come up.<br />
# In that subdialog I select the M2_REPO variable.<br />
# I click extend and I get a file browser dialog where the top of the file tree is given by the location pointed to by my M2_REPO variable. The path that I select in this browser is governed by the fields in the dependency record for sesame-repository-sail that I am trying to incorporate into eclipse. I explore my way to org/openrdf/sesame (which is derived from the group id in the pom.xml dependency). From that subdirectory I open sesame-repository-sail (which comes from the artifactId. From that subdirectory I open the directory 2.7.0 which comes from the version. Finally in that directory I select the jar file and I click ok for the file browser dialog.<br />
# I make one more check of the parameters in the "New File" dialog. The parent directory should be the top level directory of the org.protege.owl.rdf project, the filename should be sesame-repository-sail-2.7.0.jar and the text in the text box under "link to the file system" should be M2_REPO/org/openrdf/sesame/sesame-repository-sail/2.7.0/sesame-repository-sail-2.7.0.jar.<br />
# I click ok to the new file dialog and I have a link.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12248CompileProtege5InEclipseWithMaven2013-09-06T20:23:50Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre><br />
To satisfy this dependency I need to link the appropriate version of the sesame-repository-sail jar file in my repository to the org.protege.owl.rdf project directory and add it to my class path. So first I click ''File->New->File'' and I get a dialog. I then click on "Advanced" because I want to make a file link and that is advanced.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12247CompileProtege5InEclipseWithMaven2013-09-06T20:10:55Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse. The first dependency looks like this:<br />
<pre><br />
<dependency><br />
<groupId>org.openrdf.sesame</groupId><br />
<artifactId>sesame-repository-sail</artifactId><br />
<version>2.7.0</version><br />
</dependency><br />
</pre></div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12246CompileProtege5InEclipseWithMaven2013-09-06T20:02:44Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my class path. The first step to doing this is to add a linked resource variable that makes it easy to link items in my repository to the eclipse workspace. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than once for each project.<br />
<br />
Now I work through the list of dependencies so that I can add them all to eclipse:</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12245CompileProtege5InEclipseWithMaven2013-09-06T19:58:21Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
At this point the org.protege.owl.rdf project still has a bunch of errors (342). These errors are caused because eclipse does not know about the dependency of the org.protege.owl.rdf project on some libraries that it uses, the most obvious of which is the openrdf sesame project. One of the typical errors looks like this:<br />
<pre><br />
BNode cannot be resolved to a type<br />
</pre><br />
and if I go to the file where this error occurs and then go to the top of the file to see the imports, I see that eclipse is unable to see the package org.openrdf.<br />
<br />
Now, since the project builds properly with the command 'mvn clean install' I know that I have all the needed libraries on my machine. The libraries are in my repository. What I need to do is to make eclipse think that the libraries are in the place that it expects them to be and to add them to my <br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12244CompileProtege5InEclipseWithMaven2013-09-06T19:30:58Z<p>Tredmond: /* Dealing with libraries */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12243CompileProtege5InEclipseWithMaven2013-09-06T19:29:33Z<p>Tredmond: /* Configuring Eclipse */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
Here we describe two ways of loading the core Protege plugins into eclipse. In the first method, eclipse sees the full source code for these projects allowing a plugin developer to understand what the Protege code is doing. This is my personal preference - I even prefer to have my IDE's configured so that I can look at the Java library sources if I want to (which is rare but happens occasionally). The second method is easier but it only tells eclipse about the binary core Protege plugins. The second method is sufficient for a plugin developer to test and run his or her plugin but does not display the sources.<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12242CompileProtege5InEclipseWithMaven2013-09-06T17:13:14Z<p>Tredmond: /* Configuring Eclipse */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
=== Configuring Eclipse so that the Protege sources are available ===<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
=== Quick method for configuring eclipse without the sources ===<br />
<br />
Download Protege 4 or 5 distribution.<br />
<br />
File->Import and then Plug-in Development->Plug-ins and Fragments.<br />
<br />
Then get org.protege.common.jar and org.protege.editor.core.application.jar bundles from the bundles directory of the Protege distribution. Repeat and get org.semanticweb.owl.owlapi.jar and org.protege.editor.owl from the plugins directory of the distribution.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12241CompileProtege5InEclipseWithMaven2013-09-06T17:05:12Z<p>Tredmond: /* Configuring Eclipse */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other than the protege5 directory that we have been using above perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12240CompileProtege5InEclipseWithMaven2013-09-06T17:04:26Z<p>Tredmond: /* Configuring Eclipse */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Start of temporary workaround'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''End of Temporary workaround'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12239CompileProtege5InEclipseWithMaven2013-09-06T17:03:09Z<p>Tredmond: /* A manual method */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For the org.protege.owl.rdf project there is one more hurdle (which is why I chose it) because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12238CompileProtege5InEclipseWithMaven2013-09-06T16:58:03Z<p>Tredmond: /* A manual method */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. <br />
<br />
'''''Temporary workaround'''''<br />
<br />
The org.protege.owl.rdf project still has some remnants from the ant build days and these will probably be removed shortly. In the mean time, I manually removed the lib, META-INF directories and the build.xml file.<br />
<br />
'''''End of temporary workaround'''''<br />
<br />
The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For this project there is one more hurdle because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12237CompileProtege5InEclipseWithMaven2013-09-05T17:41:43Z<p>Tredmond: /* A manual method */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
'''''Ultimately the META-INF, build.xml and lib files and directories will not exist in the git repository. In the meantime to make this example work convincingly you should delete these files before starting.'''''<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a project-specific manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For this project there is one more hurdle because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12236CompileProtege5InEclipseWithMaven2013-09-05T17:41:08Z<p>Tredmond: /* A manual method */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
'''''Ultimately the META-INF, build.xml and lib files and directories will not exist in the git repository. In the meantime to make this example work convincingly you should delete these files before starting.'''''<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.<br />
<br />
In many cases you will be done at this point. For this project there is one more hurdle because it uses libraries that are included in the jar bundle.<br />
<br />
====Dealing with libraries====</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12235CompileProtege5InEclipseWithMaven2013-09-05T15:37:40Z<p>Tredmond: /* A manual method */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
'''''Ultimately the META-INF, build.xml and lib files and directories will not exist in the git repository. In the meantime to make this example work convincingly you should delete these files before starting.'''''<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
In many cases you will be done at this point. For this project there is one more hurdle because it uses libraries that are included in the jar bundle.<br />
<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12234CompileProtege5InEclipseWithMaven2013-09-05T15:35:35Z<p>Tredmond: /* A manual method */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
'''''Ultimately the META-INF, build.xml and lib files and directories will not exist in the git repository. In the meantime to make this example work convincingly you should delete these files before starting.'''''<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works. In addition try to remember to set the source path to <br />
<pre><br />
src/main/java<br />
</pre><br />
or you will have to fix this later.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
You might want to run <br />
<pre><br />
git status<br />
</pre><br />
at this point to make sure that there are no other files that eclipse has created or modified. Another common file to get changed or modified is the activator.<br />
After doing this I refresh eclipse so that it sees the new manifest.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12233CompileProtege5InEclipseWithMaven2013-09-05T15:30:55Z<p>Tredmond: /* A manual method */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
'''''Ultimately the META-INF, build.xml and lib files and directories will not exist in the git repository. In the meantime to make this example work convincingly you should delete these files before starting.'''''<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
After doing this I refresh eclipse so that it sees the new manifest.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12232CompileProtege5InEclipseWithMaven2013-09-05T15:28:29Z<p>Tredmond: /* A manual method */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
'''Ultimately the META-INF, build.xml and lib files and directories will not exist in the git repository.'''<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
After doing this I refresh eclipse so that it sees the new manifest.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12231CompileProtege5InEclipseWithMaven2013-09-05T15:27:02Z<p>Tredmond: /* A manual method */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
I will describe how I made this approach work with a particular plugin project. I chose the [https://github.com/protegeproject/org.protege.owl.rdf org.protege.owl.rdf] project as this is project that includes some libraries. The first step is to setup the .gitignore file so that git will ignore files that are only meaningful to an eclipse developer and are not of general interest. I suggest the following configuration:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
<br />
Now I am ready to start eclipse. In eclipse I create a new plugin project called org.protege.owl.rdf making sure that it is based on the files in the gir project org.protege.owl.rdf that I just checked out. If I checked out the org.protege.owl.rdf file into the protege workspace then this usually simply works.<br />
<br />
Now I need to replace the MANIFEST.MF that eclipse created with a manifest.mf that can be used by eclipse.<br />
I first need to build the project with maven<br />
<pre><br />
mvn clean install<br />
</pre><br />
and then I extract the MANIFST.MF file from the built artifact:<br />
<pre><br />
jar -xf target/org.protege.owl.rdf-1.0.3-SNAPSHOT.jar META-INF/MANIFEST.MF<br />
</pre><br />
After doing this I refresh eclipse so that it sees the new manifest.</div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12230CompileProtege5InEclipseWithMaven2013-09-05T09:11:50Z<p>Tredmond: /* Add your own plugin */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse. We have determined that this can be done in a reasonable manner without requiring that we commit either the META-INF directory or the libraries used by the plugin to our git repository. Since these files are visible to eclipse, it makes sense that we add an entry for them in the .gitignore file. In fact I would suggest that the .gitignore file contain at least the following entries:<br />
<pre><br />
.classpath<br />
.project<br />
.settings/<br />
META-INF/<br />
build.properties<br />
target/<br />
</pre><br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
I will describe how I made this approach work with the <br />
<br />
<pre><br />
jar -xf target/....jar<br />
</pre></div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12219CompileProtege5InEclipseWithMaven2013-09-02T04:33:29Z<p>Tredmond: /* A manual method */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse.<br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
I will describe how I made this approach work with the <br />
<br />
<pre><br />
jar -xf target/....jar<br />
</pre></div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12218CompileProtege5InEclipseWithMaven2013-09-02T04:31:20Z<p>Tredmond: /* Add your own plugin */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
Now we assume that a developer wants to introduce a plugin into eclipse.<br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described below.<br />
<br />
===A manual method===<br />
<br />
<pre><br />
jar -xf target/....jar<br />
</pre></div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12217CompileProtege5InEclipseWithMaven2013-09-02T04:25:29Z<p>Tredmond: /* The easy way */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
In this note<br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described bel.ow<br />
<br />
===A manual method===<br />
<br />
<pre><br />
jar -xf target/....jar<br />
</pre></div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12216CompileProtege5InEclipseWithMaven2013-09-02T04:15:36Z<p>Tredmond: /* Add your own plugin */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
=== The easy way ===<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach described bel.ow<br />
<br />
<br />
<pre><br />
jar -xf target/....jar<br />
</pre></div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12215CompileProtege5InEclipseWithMaven2013-09-02T04:07:40Z<p>Tredmond: /* Add your own plugin */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this would to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
But if this doesn't work you can try the approach <br />
<br />
<br />
<pre><br />
jar -xf target/....jar<br />
</pre></div>Tredmondhttps://protegewiki.stanford.edu/index.php?title=CompileProtege5InEclipseWithMaven&diff=12214CompileProtege5InEclipseWithMaven2013-09-02T04:06:22Z<p>Tredmond: /* Add your own plugin */</p>
<hr />
<div><br />
= Instructions for setting up Eclipse for working with Protege using maven =<br />
<br />
'''Under construction'''<br />
<br />
This would be better if we could do this using ''mvn eclipse:eclipse''. But when I tried this the resulting plugin projects were all messed up. So after a lot of experimentation I came up with another more manual approach.<br />
<br />
On the other hand, ''mvn eclipse:eclipse'' works very well with the owl api and I think that this is a fun and easy way of including the owlapi sources.<br />
<br />
== Prerequisites ==<br />
<br />
To follow these directions you will need the following tools:<br />
* Eclipse (of course) with <br />
** the Plugin Development tools included. As indicated [http://www.eclipse.org/downloads/packages/compare-packages here], the plugin development environment comes with the Java EE or the RCP/Plugin versions of eclipse.<br />
* A tool for checking out a git repository. This is useful for getting the owlapi sources and setting up owlapi projects.<br />
* Optionally the bnd tool. This is useful for creating owlapi bundles from the owlapi sources. If you use a version of the owlapi that has an osgi bundle version in maven central then you won't need this.<br />
* The maven build tool.<br />
These directions are based on a preconfigured workspace which you can use for the build.<br />
<br />
== Configuring Eclipse ==<br />
<br />
This is just one method of setting up eclipse and so feel free to adjust the approach to suit your preferences. When I first set up eclipse this way, I decided to have the Protege source tree be in a separate but parallel directory to the eclipse workspace. I decided that I like this arrangement because, as you will see, it ensures that the eclipse workspace files don't show up as modifications to the Protege source tree sources.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
When the explanation, client and server projects are checked into maven this step will not be necessary. For now, in some directory other perform the following operations:<br />
<pre><br />
git clone https://github.com/protegeproject/org.protege.explanation<br />
cd org.protege.explanation<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.owl.server<br />
cd org.protege.owl.server<br />
mvn clean install<br />
cd ..<br />
<br />
git clone https://github.com/protegeproject/org.protege.editor.owl.client<br />
cd org.protege.editor.owl.client<br />
mvn clean install<br />
cd ..<br />
</pre><br />
I generally do this in the protege5-workspace directory that I use later.<br />
<br />
'''''Temporary workaround here'''''<br />
<br />
<br />
The first step in this process is to check-out the Protege sources. The method for doing this is going to change in the very near future. For now you need to checkout the nosubmodules branch of the git repository [https://github.com/protegeproject/protege/tree/nosubmodules]. You can use any client that you like to perform the ckeck-out but for my command line client the command is as follows:<br />
<pre><br />
git clone --branch nosubmodules https://github.com/protegeproject/protege protege5<br />
</pre><br />
Now we build Protege using the maven command:<br />
<pre><br />
cd protege5<br />
mvn clean install<br />
</pre><br />
This takes a little while to run (about a minute on my computer) so now would be a good time to go get a cup of coffee. By running this, we have built a fully functional copy of Protege (in a directory with a name like protege-distribution/target/protege-distribution-5.0.0-beta-04-bin/Protege) and we have arranged that any generated source directories needed by the build are present. <br />
<br />
Now we can set up the projects for eclipse. To do this first download a zip file that contains the eclipse information. This zip file can be found [http://protege.stanford.edu/fileshare/tredmond/maven-eclipse-projects.zip here].<br />
Unzip this file into the protege5 directory. Note that in addition to including the usual .project and .classpath files, this zip file also contains the META-INF/MANIFEST.MF files. These manifest files are duplicates of the manifest files that are included in the bundles that are created by the mvn build scripts. On windows machines you might see messages that various directories already exist (e.g. org.protege.common) and asking if you want to merge the contents. This is far from an error in this case and actually may mean that you are putting the files in the right places.<br />
<br />
Now we start eclipse to create a workspace. This step can actually be done while the maven install step abbove is running. In my example, I created the workspace in a separate directory, protege5-workspace that is at the same level as the protege5 directory that I just created. In this first run of eclipse, all that I plan to do is to setup a parameter that points to the local maven repository. To do this, click on ''Window->Preferences'' (''Eclipse->Preferences'' on a mac), select ''General->Workspace->Linked Resources'' and click on the button that defines a new path variable.<br />
<br />
[[File:MavenEclipseSetREPO.png]]<br />
<br />
In this window configure the M2_REPO variable so that it points to the local maven repository which is usually (always?) located at '.m2/repository' in your home directory. This allows me to set up the eclipse projects so that they do not require pointers to system specific locations. The system specific location of the repository is set once in the eclipse workspace rather than several times in each project.<br />
<br />
First you need to import the owl api as an eclipse plugin project. Click on File->Import... and select Plug-in Development->Plug-ins and Fragments.<br />
<br />
[[File:MavenEclipseImportOWLapi1.png]]<br />
<br />
In the next screen you can set the directory to import from to be <br />
<pre><br />
protege5/protege-distribution/target/protege-distribution-5.0.0.beta-04-bin/Protege/plugins.<br />
</pre><br />
<br />
[[File:MavenEclipseImportOWLapi2.png]] <br />
<br />
<br />
Finally on the next screen, you can select the OWL api for import.<br />
<br />
[[File:MavenEclipseImportOWLapi3.png]]<br />
<br />
<br />
Now we can import the eclipse projects from the protege5 directory. From the file menu click Import, select General/Existing Projects into Workspace, and click next:<br />
<br />
[[File:MavenEclipseImportExisting1.png]]<br />
<br />
In the next screen, make sure that "Select root directory" is selected, browse to the protege5 directory that we were working on before, select the plugins that you want to include and click finish:<br />
<br />
[[File:MavenEclipseImportExisting2.png]]<br />
<br />
The important projects to select are org.protege.common, org.protege.editor.core.application, org.protege.editor.owl and protege-distribution.<br />
You may need to wait a moment before looking at the errors because it takes a moment to build. The build progress is displayed in the lower right hand corner.<br />
At this point in the "Problems" view there will be a single compilation error:<br />
<pre><br />
Access restriction: The method render() from the type RDFRendererBase is not accessible due to restriction on required library org.semanticweb.owl.owlapi/owlapi-distribution.jar<br />
</pre><br />
I don't know what this error means yet but it appears to be harmless.<br />
<br />
== Running Protege ==<br />
<br />
===Running Protege using the eclipse OSGi support===<br />
<br />
This is the easiest type of runnable to create, run and debug. But there are two issues with this approach. First, if you are running mac os x, it won't work. The Mac has some long standing problems with java and eclipse and there appear to be troubles. But it works just fine on linux and windows. Second, this type of runnable may hide or change issues that would occur when the plugin is run in a true Protege deployment. I don't know exactly what eclipse does to make this type of runnable work but suffice it to say that eclipse is being a bit tricky. It is a good idea to at least occasionally the runnable in a more Protege-like environment such as is created by runnable that I describe in the next section.<br />
<br />
<br />
[[File:EclipsePluginDevelopmentOpenRunDialog.png]]<br />
* Create a new OSGi runnable<br />
* Select all the Workspace plugins that you want.<br />
* Deselect all the Target Platform plugins<br />
* Click "Add Required Bundles"<br />
<br />
Then add some jvm options to specify a logger and memory such as, for example:<br />
<pre><br />
-Declipse.ignoreApp=true -Dosgi.noShutdown=true<br />
-Xmx512M<br />
-Dlog4j.configuration=file:${workspace_loc:org.protege.editor.owl/log4j.xml}<br />
</pre><br />
This setup is generating an exception for me<br />
<pre><br />
org.osgi.framework.BundleException: Could not find bundle: org.eclipse.equinox.console<br />
at org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)<br />
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br />
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)<br />
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)<br />
at java.lang.reflect.Method.invoke(Method.java:606)<br />
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)<br />
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)<br />
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)<br />
at org.eclipse.equinox.launcher.Main.main(Main.java:1414) <br />
</pre><br />
When I tried to fix this I got into some problems but it doesn't seem too important.<br />
<br />
On a linux machine this works perfectly but on the mac it failed with the exception<br />
<pre><br />
java.lang.UnsupportedClassVersionError: org/protege/editor/owl/ProtegeOWL : Unsupported major.minor version 51.0<br />
</pre><br />
This is a serious problem but if it only happens on the mac it may be irrelevant because historically the macs have been unable to run swing programs in eclipse-OSGi mode even after the bug about the problem was closed.<br />
<br />
<br />
===Running Protege in native mode===<br />
<br />
In this mode we run protege with the same configuration as is used by the end users of eclipse. In some ways, problems with this runnable are easier to debug than problems with the eclipse method given above because there is no hidden magic. But on the other hand, this approach requires more manual steps between debug steps.<br />
<br />
== Adding OWL api projects ==<br />
<br />
<pre><br />
git clone git://owlapi.git.sourceforge.net/gitroot/owlapi/owlapi<br />
cd owlapi<br />
mvn -Declipse.workspace=../protege5-workspace eclipse:add-maven-repo<br />
mvn eclipse:clean eclipse:eclipse<br />
</pre><br />
<br />
Import the ''Existing projects into workspace''.<br />
<br />
== Add your own plugin ==<br />
<br />
In this note, I assume that the plugin is maven project. The simplest way to do this is to use the maven eclipse support that is described [http://maven.apache.org/guides/mini/guide-ide-eclipse.html here]. Unfortuately we have had bad experience with this technique but it is sweet when it works and is worth a try. Essentially the two core commands are<br />
<pre><br />
mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo<br />
mvn eclipse:eclipse<br />
</pre><br />
After these commands the project will be ready to import. Also you can arrange that the project that is created is a plugin project by including the following configuration in the pom.xml file:<br />
<pre><br />
<plugin><br />
<artifactId>maven-eclipse-plugin</artifactId><br />
<version>2.9</version><br />
<configuration><br />
<pde>true</pde><br />
</configuration><br />
</plugin><br />
</pre><br />
<br />
<pre><br />
jar -xf target/....jar<br />
</pre></div>Tredmond