incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Neumann <>
Subject Re: IRI library repackage
Date Thu, 01 Mar 2012 16:25:13 GMT
it may be a good idea to rename the project (software release) once
you rename all the packages to avoid confusion.

e.g Jena4, ApacheJena etc

On Thu, Mar 1, 2012 at 8:33 AM, Andy Seaborne <> wrote:
> 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


Marco Neumann

View raw message