You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2012/03/01 14:33:33 UTC

IRI library repackage

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

Re: IRI library repackage

Posted by Andy Seaborne <an...@apache.org>.
On 01/03/12 16:25, Marco Neumann wrote:
> it may be a good idea to rename the project (software release) once
> you rename all the packages to avoid confusion.
>
> e.g Jena4,

Slightly jumping the gun ... we haven't got to Jena3 yet!

> ApacheJena etc

Point taken.

We have talked about compatibility code still in com.hp.hpl.jena so the 
degree of change isn't clear yet.

There are clutch of discussion JIRA around here:

JENA-189 :: Jena 3 / technical
https://issues.apache.org/jira/browse/JENA-189

JENA-190 :: Jena delivery
https://issues.apache.org/jira/browse/JENA-190

JENA-191 :: Jena module structure and build
https://issues.apache.org/jira/browse/JENA-191

JENA-192 :: Jena java package renaming
https://issues.apache.org/jira/browse/JENA-192

JENA-193 :: Changes needed, or desirable, for RDF 1.1
https://issues.apache.org/jira/browse/JENA-193

	Andy

Re: IRI library repackage

Posted by Marco Neumann <ma...@gmail.com>.
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 <an...@apache.org> 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

Re: IRI library repackage

Posted by Andy Seaborne <an...@apache.org>.
On 01/03/12 13:33, Andy Seaborne wrote:
> Does anyone mind if I go in and convert the IRI library to
> org.apache.jena.iri?

Done, I hope.  Jenkins says Jena and ARQ are working.

I have completely rebuilt the IRI from the jflex files, not just from 
the auto-generated java we base the release on.

As ever, svn and deleted folders was not a one-shot commit.

	Andy