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).
