On 03/09/14 13:31, Claude Warren wrote:
Sounds good to me.
I would like to see Jena 3 added to Jira so we can begin to log requested
features against it (e.g. remove the GraphAdd interface)
Good idea.
Any JIRA can have a label, which is does not have to be preallocated.
Labels appear off the bottom of the "create" dialog which is a nuisance
- but now one exists, they do autocomplete. If it turns out to be
pain, we can create a "component" - like labels but for a fixed set and
do appear higher up in the create JIRA dialog for me at least.
There is JENA-189 - I just added a label of "Jena3".
Andy
On Wed, Sep 3, 2014 at 11:47 AM, Andy Seaborne <[email protected]> wrote:
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
