I had a go at refactoring to have both org.apache.jena and
com.hp.hpl.jena APIs (my target was the RDF and ontology APIs). It
looks possible but isn't trivial. Some classes link the API to the SPI
and that then gets a bit messy, which equates to it's not a perfect drop
in replacement.
But I also got to ask myself about whether this really is an advantage
to users and the project.
A/ If there is a legacy, when will it go away?
B/ If there are multiple classes called "Model", it can be quite
confusing for people. Autocomplete is already polluted enough.
C/ There isn't one system to use because using Jena involves choosing
different setups via jars included, which in itself may cause a steady
stream of questions.
And with changes like RDF 1.1 persistent data, there are changes anyway
that a major version change reflects.
So just making the package rename once and for all seems to me to be
just as helpful. It's a bump at the point of jena2 -> jena3 but the
bump is going to happen if the legacy adapter ever goes away.
A quick migration route for user code is to convert all the imports:
s/import \s+com.hp.hpl.jena/import org.apache.jena/g
in your favorite editor (including Eclipse).
Obviously, some corner cases, like full names for classes, do not work
but I think they will be few and far between.
Whatever we do, we end up with parallel codebases to apply bug fixes to.
The only practical way round that that I can see is to delay making the
package rename as late as possible. That does not seem very attractive.
Data namespaces are untouched. We can consider them separately, on a
case-by-case basis.
So ...
1/ Move the code to git
2/ Repackage com.hp.hpl.jena -> org.apache.jena
3/ Declare jena-3.0-alpha-1 (not a release - just POM version set.).
4/ Starting making changes
(like RDF 1.1 details - invalidates persistent data).
...
X/ Release jena-3.0.0 (when we feel it is ready).
Andy
