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 <[email protected]> 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 KONA
