On 09/09/14 17:48, Stian Soiland-Reyes wrote:
+1 from me, sounds like a good plan. You would not want to do the dual
branches in svn!
Given the extensive repackaging that will happen, using tools to manage
changes to the two code lines would be really quite impressive.
(svn branch merges may be slow and clunky but when I've used them, via
Eclipse, they have worked - but that was not across renamed package trees.)
For me, the big win is having one less tool chain to keep on top of.
Cloning Jena on github etc etc works at the moment.
Andy
On 9 Sep 2014 12:50, "Andy Seaborne" <[email protected]> wrote:
Claude +1'ed and I'm OK with this plan.
Is everyone else OK with it? (please "+1/0/-1")
If so, I'll call a VOTE for moving trunk.
It'll look like:
https://github.com/apache/jena
The website remains in subversion because the CMS/svnpubsub does not as
far as I know, work with git.
As for the misc items we have (Experimental/, Imports/, Scratch/ etc), I
suggest we leave them for now to keep the main migration clean, then
migrate them separately if there is a requirement.
Andy
On 03/09/14 11:47, Andy Seaborne 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 ...
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).
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
