Claude,
I'm trying to do all the disruptive changes that I know about / want to
do.
One of those is removing long-term deprecations in Graph, including
TripleMatch and BulkUpdateHandler. JENA-920.
That's going to hit jena-permissions I'm afraid. I had a look as to
whether the fixes were "very obvious" and some weren't to me at least so
ATM rather than make some and not others, I'm not attempting to fixup
jena-permissions.
If you prefer, I can try to fix that code base. Your choice.
I really want to get through the chaos phase - sorting out RIOT/core is
not trivial and will have to wait. A deprecation remove hunt howver,
should (!!) be on a lesser scale.
Do shout if you think some/all of this is a bad way to proceed.
Andy
On 24/04/15 14:02, Claude Warren wrote:
Andy,
Perfect. That was exactly what I had in mind.
So my plan for the weekend is to change the package names and to update the
documentation.
I would like to add the contract test for the graph API (which I think we
should begin to refer to as an SPI) and add documentation for how to
implement contract test for specific implementations.
Is there any objection to this?
Claude
On Fri, Apr 24, 2015 at 1:26 PM, Andy Seaborne <[email protected]> wrote:
On 24/04/15 09:37, Claude Warren wrote:
This would be a good time to change "jena-security" to "jena-permissions".
If there is no objection I will do that this weekend.
Claude,
No problem. I have the main build sorted out now (see other email).
To avoid clashes at that level, I have already renamed the module as
"jena-permissions" in POMs and build for you (I hope that was what you
wanted - if not change again); I have not touched the java code. If the
module naming works for you, this should give you much freedom for changes
on the jena3 branch when it's convenient for you.
Hopefully soon, we can switch to jena3 on master.
Andy
On Fri, Apr 24, 2015 at 9:02 AM, Andy Seaborne <[email protected]> wrote:
On 24/04/15 05:54, Bruno P. Kinoshita wrote:
Looking good so far Andy! I had a look at the imports and Eclipse is
doing a great job!
By the way, do you have a custom coding style for Eclipse? I noticed
that
the Fix imports kept the space between the last character and the ";"
character. If you could share your Eclipse coding style I'd start using
too
to ease merging of patches.
Eclipse is erratic about that particular space - some times it keeps them
(my minor personal preference but I don't care that much; imports are
hidden most of the time) and some times it doesn't.
Different parts of Jena have different styles from different people,
especially in the older jena-core.
I'll dig out my current style setup.
The branch isn't building yet as there are other references to the old
package [1]. But after fixing some locally-only in assembler files, some
tests like TestTDBAssembler start passing again, so looks like the rest
of
the process won't give much trouble (hopefully :)
I know!
The only thing working is running tests for core and arq in Eclipse.
Nothing else works. Must be in Eclipse to pick up the right code.
And if you try to build with maven, then because the versions are not yet
rewritten, do be careful about your maven repo not getting contaminated.
Versions are next on my list.
We can't change "com.hp.hpl.jena" in data because it's "out there".
We do need to change assemblers and/or intercept the ja:loadClass path.
Andy
CheersBruno
[1] https://gist.github.com/kinow/fa054b93df33bc12fb0d
From: Andy Seaborne <[email protected]>
To: [email protected]
Sent: Friday, April 24, 2015 8:42 AM
Subject: Jena3 bootstrap process notes
Brief progress reports for the bulk conversion steps:
* Tag the split point.
* Branches jena2 and jena3 setup
* Package renaming done
* jena-core and jena-arq tests run inside Eclipse, not outside (new
version numbering not redone yet)
POM changes and build next.
Method:
All code modules, open in Eclispe. Not intermediate POMs (parent,
jena-jdbc etc etc), not jena-shaded-guava (if open, it confused Eclipse
for building ARQ).
rename src/main/java and then src/test/java for jena-core, jena-arq,
jena-tdb, jena-sdb.
Track down a few other com.hp.hpl.jena uses in strings, comments and
jena-test-log4j.properties.
Odd things:
It is better to do the bulk conversion before a git-synchronization in
egit. Without egit setup, the renames were faster and more reliable
With egit sync'ed, the rename was much slower and I had one Eclipse lock
up as egit got sorted out.
It seems to be the same thing as using the command line tools only,
which in the end I used to commit and push.
A few (<5) confusions when classes of the same name were in scope:
Statement (java.sql. and org.apache.jena.rdf.model) in SDB and
jena-jdbc.
A few cases of unused imports introduced.
An old ResultSetRewindable was around (deleted).
