Does anyone mind if I go in and convert the IRI library to
org.apache.jena.iri?
I would do it on a branch, or just locally, but what I want to test out
is the overall process for propagating repacking to other code. An
off-trunk change doesn't help test that. It'll affect Jena core and ARQ
internally. And Fuseki's IRI validation service.
It is possible there is application code that uses IRI e.g. RIOT has
support code for IRI resolution that is public althouhg it really there
to support other parts of RIOT.
If complete compatibility is required, a class at the old name that
wraps the new one can be done (scala implicits would be nice ...) but,
on balance, I'd like to see it's needed first. App code can't create
IRI objects (it's an abstract class), only get them from libraries.
In theory, it's an invisible change ... do the changes, install jars in
the local repo, update imports in other code, green lines, commit.
Anyone else should see a single change (not quite perfectly atomic but
close - the snapshot repository build and the svn update of core and ARQ
need to sync up). In theory ... which is why the experiment is needed
This is not moving the code tree to the new layout.
(Also, with the new JENA-191 we don't have to separately release the
parent POM for dropping ICU4J. A good reason for the re-org.)
Andy
