Empire 0.7
Mike Grove
I've made Empire 0.7 'official' -- 0.7 has been the head revision for
quite some time now, we've been using it in production for over a year
now I just had not gotten around to closing the last ticket and
calling it a day. The full set of changes that went into 0.7 are
listed in CHANGES.txt. The recent significant change that I was
holding the final release for was better support for polymorphic
behavior in your beans and avoiding 'lossy' conversions to/from RDF.
Now Empire will do the right thing if you have an individual with
multiple rdf:type assertions, you'll be able to view it as any of
those types and if you persist it as one type, it won't affect the
statements pertaining to its other types.
We had several people contribute patches that went into this release,
so I'd just like to thank them again for contributing, I am very happy
to get some support from the growing Empire community.
Also, for the Empire maven users out there, head now contains the
contents of Nicolas's pull request which adds some maven stuff, so
hopefully that will now work for all of you maven folks. I'll do my
best to maintain these as I go along. If i fat finger something and
break the maven bits, just shout; I won't notice since we don't use
maven.
Lastly, I don't think I announced it on here, but a few months back we
released [1] some support for using Empire w/ the Play! web framework,
which if you have not tried it, is a really great web framework in
Java & Scala.
Cheers,
Mike
Nicolas Delsaux
> All,
>
> I've made Empire 0.7 'official' --
Great !
>
> We had several people contribute patches that went into this release,
> so I'd just like to thank them again for contributing, I am very happy
> to get some support from the growing Empire community.
>
> Also, for the Empire maven users out there, head now contains the
> contents of Nicolas's pull request which adds some maven stuff, so
> hopefully that will now work for all of you maven folks. I'll do my
> best to maintain these as I go along. If i fat finger something and
> break the maven bits, just shout; I won't notice since we don't use
> maven.
Wow, that was fast ! I guess i'm the user which patch was integrated
the faster :-)
Anyway, as modification is not complete, let me explain what i did and
what would be the next steps.
But before, a warning :
if pom.xml tend to make you go crazy,
if for you, maven is the surest way to download teh interwebz,
then stop your reading here, as there be dragons.
For each sub-module of Empire I created a pom listing its specific
dependencies and specifying how to build this module.
I alos defined a "parent pom" containing common configuration. Before
to go into details of sub-modules, let me explain a little the
vocabulary.
Maven defines each element as "an artifact". As a consequence, a
project like empire contains some artifacts :
- empire-core
- empire-jena
- empire-sesame
- empire-fourstore
As most of these project shares common configuration and dependencies,
it's of good use to merge them into a "multi-module" pom. And that's
what I did.
this parent pom (here :
https://github.com/mhgrove/Empire/blob/master/pom.xml) defines as a
consequence the module list, the dependency management (allowing
submodules to use defined dependencies without specifying their
versions), the compiler version (java 1.5 in our case), the project
organization (sources are in "src", resources in "resources"), and a
specific packaging : "output jar for non maven use" which produces a
jar with classifier "onejar" containing all classes from project and
its non system dependencies.
Now, for the submodules.
Each of them (as a good example empire-sql -
https://github.com/mhgrove/Empire/blob/master/sql/pom.xml) defines its
dependencies, and nothing else, as its layout follows the standard
defined in parent pom.
Unfortunatly, there are in Empire some modules which use non-maven
dependencies : empire-core and empire-fourstore. For these modules, I
had to store locally (read in a so-called file repository) the
"offending" dependencies in order to build project. That's why the
various clarkparsia dependencies moved in
lib/com/clarparsia/artifactId/version/artifactId.jar. I guess (from
this magnificent release) that that file move didn't alter the ant
build, which is cool. Later, I realized that, as these dependencies
are non maven ones, they are available in no maven repository. As a
consequence, I decided to re-use the maven-shade-plugin to include the
code from these dependencies in the generated jars. That's why the
empire-fourstore pom is a little longer :
https://github.com/mhgrove/Empire/blob/master/fourstore/pom.xml
Finally, empire-core includes a special system dependency to
tools.jar, as EmpireAnnotationProcessorFactory is a com.sun.... class.
This dependency is a system one, which means it's not incorporated in jars.
What's coming next ?
For now, I only can package empire using maven, but there is no way to
easily get it.
So, walking on the steps of cemerik
(http://cemerick.com/2010/08/24/hosting-maven-repos-on-github/), the
next step is to create a github- hosted repository, containing various
versions of empire modules. I don't yet know how to do that without
eating space, but it's the simplest solution before ... sending Empire
releases to Sonatype OSS repository
(https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide)
which is the best possible maven repository solution, as it makes
empire available throught THE maven central repository.
So, if one has any question, feel free to ask.
And Mike, sorry to abuse your announce mail for such "noise" :-)
Now .. head up to datasource closing (I'll talk about that next week).
>
> Lastly, I don't think I announced it on here, but a few months back we
> released [1] some support for using Empire w/ the Play! web framework,
> which if you have not tried it, is a really great web framework in
> Java & Scala.
Great !
--
Nicolas Delsaux