Compiling Empire using maven after a git clone
Christophe Gravier
I was looking if a RDF+JPA approach exists, and here I found Empire
today :-) It is an awesome project, and I am sure it will gain further
interest in the future.
Here is a quick feedback on trying to build Empire using maven (you
should have read http://groups.google.com/group/empire-rdf/browse_thread/thread/7ecc747440a4876e
before).
Some pom.xml files seem misplaced to me (*)):
- Empire-parent pom.xml is provided as file://${project.basedir}/pom.xml
while it is searched by the maven install routine in
file://${project.basedir}/lib/com/clarkparsia/Empire-parent/0.7
- Empire-core pom.xml is provided as file://${project.basedir}/core/pom.xml
while it is searched by the maven install routine in
file://${project.basedir}/core/lib/pom.xml
Fortunately, this can be resolved using sysmlink or copying/moving the
pom files.
For those who are trying to build Empire 0.7 using, maven, here is a
recipe (quick and dirty and works) :
git clone https://github.com/mhgrove/Empire.git
cd Empire/
mkdir -p /lib/com/clarkparsia/Empire-parent/0.7/
cp pom.xml /lib/com/clarkparsia/Empire-parent/0.7/Empire-
parent-0.7.pom
cp ./core/pom.xml ./core/lib/
I also build Empire using sesame-runtime 2.6.2 (the comment was
tempting) :
- Edit Empire-parent and Empire-core pom.xml files accordingly :
sesame.version becomes : "<sesame.version>2.6.2</sesame.version>"
This dependency has to be commented in Empire-core pom.xml since I'm
on MacOS (http://programmerjohnny.wordpress.com/2011/02/23/maven-
missing-com-suntoolsjar1-6-0/) :
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>${java.version}</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
and I also commented, because of conflict with another version of
slf4j already on my machine, the following:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${slf4j.version}</version>
</dependency>
and then :
mvn install
=> BUILD SUCCESSFUL
It is then possible to create a client to a remote Sesame instance
2.6.2, and provide persistence on my own RDF class with Empire 0.7 as
an artifact in your local maven repository.
As I didn't find any documentation on how to build a Map for creating
the EntityManagerFactory, here is what I found successful after
various tries in case it helps someone, someday (SWDF is the owlim
repository I created through Sesame WorkbenchUI):
Map<Object, Object> map = new HashMap<Object,Object>();
map.put(ConfigKeys.FACTORY, "sesame");
map.put(RepositoryFactoryKeys.URL, "http://localhost:8080/openrdf-
sesame/");
map.put(RepositoryFactoryKeys.REPO, "SWDF");
HTH
@chgravier
(*) I am only a "maven user", therefore I am sorry it this could have
been addressed in a proper way from the start. I was able to handle it
quickly otherwise.
Mike Grove
> Dear all,
>
> I was looking if a RDF+JPA approach exists, and here I found Empire
> today :-) It is an awesome project, and I am sure it will gain further
> interest in the future.
>
Thanks. I hope you find it useful in your project.
> Here is a quick feedback on trying to build Empire using maven (you
> should have read http://groups.google.com/group/empire-rdf/browse_thread/thread/7ecc747440a4876e
> before).
I appreciate you sending this along, I'm sure its helpful. As I said
on the list before, I don't use maven, so I'm not a good judge of
whether or not these tweaks ought to be made, or if they're normal
per-user setup to get things going. So I'll yield to someone who will
actually use the maven stuff for that determination, and if the
consensus is these changes should be in the Empire maven bits, I'll
attempt to make them, or better yet, happily accept a patch from one
of our maven folks.
Cheers,
Mike
Christophe Gravier
> I appreciate you sending this along, I'm sure its helpful. As I said
> on the list before, I don't use maven, so I'm not a good judge of
> whether or not these tweaks ought to be made, or if they're normal
> per-user setup to get things going. So I'll yield to someone who will
> actually use the maven stuff for that determination, and if the
> consensus is these changes should be in the Empire maven bits, I'll
> attempt to make them, or better yet, happily accept a patch from one
> of our maven folks.
>
Yes, and neither am I a maven expert ;-) I just hope this could serve
someone who would be stuck with Empire+maven (hence the public post).
As Nicolas said, I suspect having Empire on a public maven repo would
ease its adoption, but it requires some "maven-magic" as you pointed
out. I suspect moving the two pom files does the trick though.
Peter Ansell
https://maven.apache.org/general.html#tools-jar-dependency
I just incorporated the profile based strategy that is recommended in
the maven FAQ, along with the sesame-2.6.2 dependency into the
"develop" branch of my fork [1], and my mavenised forks of the
cp-openrdf-utils [2] , cp-common-utils [3] , and cp-common-fourstore
(aka, 4Store-API) [4] dependencies. I tested it on my OS X Snow
Leopard (java version 1.6.0_29) and it compiles and installs with
maven-3.0.3.
To build the cp-common-fourstore with maven you will need to
temporarily disable the tests as there is an issue with finding the
test resources that I haven't fixed yet. You can disable them using:
mvn -DskipTests=true clean install
If you want to change the SLF4J version it might be best to do it in
the projects that you are using empire from, as opposed to in the
empire pom.xml files. If you need to remove jcl-over-slf4j you will
need to check that you have java commons logging as a depedency
somewhere to fill in for it as that is its purpose.
Cheers,
Peter
[1] https://github.com/ansell/Empire
[2] https://github.com/ansell/cp-openrdf-utils
[3] https://github.com/ansell/cp-common-utils
[4] https://github.com/ansell/4Store-API
Nicolas Delsaux
I all, sorry for the very very late answer, but things were a little
crazy over the last month, so .. well, i've just found the time to
answer this question the way it desevers it.
>
> I was looking if a RDF+JPA approach exists, and here I found Empire
> today :-) It is an awesome project, and I am sure it will gain further
> interest in the future.
>
> Here is a quick feedback on trying to build Empire using maven (you
> should have read http://groups.google.com/group/empire-rdf/browse_thread/thread/7ecc747440a4876e
> before).
>
> Some pom.xml files seem misplaced to me (*)):
> - Empire-parent pom.xml is provided as file://${project.basedir}/pom.xml
> while it is searched by the maven install routine in
> file://${project.basedir}/lib/com/clarkparsia/Empire-parent/0.7
> - Empire-core pom.xml is provided as file://${project.basedir}/core/pom.xml
> while it is searched by the maven install routine in
> file://${project.basedir}/core/lib/pom.xml
That is really strange. Let me explain a little how project is organized.
As Empire contains differents jars, I translated in traditionnal maven
view as multiple maven modules
(http://www.sonatype.com/books/mvnex-book/reference/multimodule.html).
In that kind of project, we usually have one parent pom stored in
parent folder of modules. That is why there is a pom.xml in empire
folder, then in various code folders (sesame, jena, fourstore,
reflections, core, test), one pom.xml describing the very module.
So, to build Empire using maven, one has to get the full empire folder
and to perform a "mvn install" (as an example) in this folder.
Getting only one of the subfolders (as an example only the sesame2
one) could result in amven bugs looking like the one you mentionned
upper.
>
> Fortunately, this can be resolved using sysmlink or copying/moving the
> pom files.
> For those who are trying to build Empire 0.7 using, maven, here is a
> recipe (quick and dirty and works) :
I strongly suggest not using this one, but getting the whole Empire
folder and performing a build in that folder.
>
> I also build Empire using sesame-runtime 2.6.2 (the comment was
> tempting) :
> - Edit Empire-parent and Empire-core pom.xml files accordingly :
> sesame.version becomes : "<sesame.version>2.6.2</sesame.version>"
Indeed, that's the way to do.
>
> This dependency has to be commented in Empire-core pom.xml since I'm
> on MacOS (http://programmerjohnny.wordpress.com/2011/02/23/maven-
> missing-com-suntoolsjar1-6-0/) :
>
> <dependency>
> <groupId>com.sun</groupId>
> <artifactId>tools</artifactId>
> <version>${java.version}</version>
> <scope>system</scope>
> <systemPath>${java.home}/../lib/tools.jar</systemPath>
> </dependency>
I just fix that path for mac, it will be pushed soon
>
> and I also commented, because of conflict with another version of
> slf4j already on my machine, the following:
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>jcl-over-slf4j</artifactId>
> <version>${slf4j.version}</version>
> </dependency>
I don't understand how a version of slf4j installed on your machine
can conflict with one of our dependencies, unless your client project
uses it.
In that case, you should consider the use of the maven exclude tag
(http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management)
which allows you to not use our dependencies, without modifying our
pom.
>
> and then :
> mvn install
> => BUILD SUCCESSFUL
>
--
Nicolas Delsaux