You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <Fe...@day.com> on 2008/01/18 14:40:59 UTC

Re: svn commit: r613154 - /incubator/sling/trunk/jcr/jackrabbit-server/pom.xml

Hi Betrand,

Do we really need "spi" packages here ? This sounds like intrusive in
the API and Commons bundle....

Regards
Felix

Am Freitag, den 18.01.2008, 13:15 +0000 schrieb bdelacretaz@apache.org:
> Author: bdelacretaz
> Date: Fri Jan 18 05:15:17 2008
> New Revision: 613154
> 
> URL: http://svn.apache.org/viewvc?rev=613154&view=rev
> Log:
> SLING-169 - adapt some Jackrabbit package names due to move to 1.4
> 
> Modified:
>     incubator/sling/trunk/jcr/jackrabbit-server/pom.xml
> 
> Modified: incubator/sling/trunk/jcr/jackrabbit-server/pom.xml
> URL: http://svn.apache.org/viewvc/incubator/sling/trunk/jcr/jackrabbit-server/pom.xml?rev=613154&r1=613153&r2=613154&view=diff
> ==============================================================================
> --- incubator/sling/trunk/jcr/jackrabbit-server/pom.xml (original)
> +++ incubator/sling/trunk/jcr/jackrabbit-server/pom.xml Fri Jan 18 05:15:17 2008
> @@ -131,15 +131,18 @@
>                              org.apache.jackrabbit.rmi.*,
>  
>                              EDU.oswego.cs.dl.util.concurrent.*,
> -                            org.apache.lucene.*, org.apache.derby.*
> +                            org.apache.lucene.*, org.apache.derby.*,
> +                            
> +                            <!-- needed since the move to Jackrabbit 1.4 -->
> +                             org.apache.jackrabbit.spi.commons.conversion.*,
> +                             org.apache.jackrabbit.spi.commons.namespace.*,
> +                             org.apache.jackrabbit.spi.*
>                          </Private-Package>
>                          <Import-Package>
>                              org.apache.sling.jcr.api,
>  
>                              org.apache.jackrabbit,
> -                            org.apache.jackrabbit.name,
>                              org.apache.jackrabbit.util,
> -                            org.apache.jackrabbit.util.name,
>                              org.apache.jackrabbit.uuid,
>                              org.apache.jackrabbit.value,
>  
> 
> 


Re: Not Exporting jackrabbit-jcr-commons classes (was Re: svn commit: r613154 - /incubator/sling/trunk/jcr/jackrabbit-server/pom.xml)

Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,

I created SLING-176 [1] on removing the jackrabbit-jcr-commons classes.

If noone oposes, I will remove these exports next week.

Regards
Felix

[1] http://issues.apache.org/jira/browse/SLING-176

Am Freitag, den 18.01.2008, 16:55 +0200 schrieb Jukka Zitting:
> Hi,
> 
> On Jan 18, 2008 4:49 PM, Felix Meschberger <fm...@gmail.com> wrote:
> > Am Freitag, den 18.01.2008, 16:40 +0200 schrieb Jukka Zitting:
> > > On a related note, I don't think jackrabbit-jcr-commons should be
> > > included in the API/Commons bundle. The commons classes are not
> > > something you should be passing around between bundles.
> >
> > So you propose to remove them from the jcr/api aka Repository API and
> > Commons Bundle ?
> 
> Yes. Probably good also to rename the bundle to just Repository API Bundle.
> 
> Mixing API interfaces and implementation classes is generally a bad
> idea. I think it's better to move jackrabbit-jcr-commons to a separate
> bundle or just include it as an internal dependency in any bundles
> that need the functionality.
> 
> BR,
> 
> Jukka Zitting


Re: Not Exporting jackrabbit-jcr-commons classes (was Re: svn commit: r613154 - /incubator/sling/trunk/jcr/jackrabbit-server/pom.xml)

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Jan 18, 2008 4:49 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Am Freitag, den 18.01.2008, 16:40 +0200 schrieb Jukka Zitting:
> > On a related note, I don't think jackrabbit-jcr-commons should be
> > included in the API/Commons bundle. The commons classes are not
> > something you should be passing around between bundles.
>
> So you propose to remove them from the jcr/api aka Repository API and
> Commons Bundle ?

Yes. Probably good also to rename the bundle to just Repository API Bundle.

Mixing API interfaces and implementation classes is generally a bad
idea. I think it's better to move jackrabbit-jcr-commons to a separate
bundle or just include it as an internal dependency in any bundles
that need the functionality.

BR,

Jukka Zitting

Not Exporting jackrabbit-jcr-commons classes (was Re: svn commit: r613154 - /incubator/sling/trunk/jcr/jackrabbit-server/pom.xml)

Posted by Felix Meschberger <fm...@gmail.com>.
Autsch ! I have to apologize !!!

I mistakenly though Betrand was adding the classes to the jcr/api bundle
whereas he added them to the jcr/jackrabbit-server bundle. Thanks Jukka
for pointing this out. So this whole discussion is pointless.

Am Freitag, den 18.01.2008, 16:40 +0200 schrieb Jukka Zitting:
> Hi,
> 
> On Jan 18, 2008 4:24 PM, Felix Meschberger <fm...@gmail.com> wrote:
> > My question was directed at the API/Commons bundle containing the SPI
> > classes, which kind of worried me, but as they are "internal" to the
> > bundle, I do not have any further issues.
> 
> I think Bertrand's change only affects the Jackrabbit repository
> bundle, not the API/Commons bundle.
> 
> On a related note, I don't think jackrabbit-jcr-commons should be
> included in the API/Commons bundle. The commons classes are not
> something you should be passing around between bundles.

So you propose to remove them from the jcr/api aka Repository API and
Commons Bundle ?

Regards
Felix



Re: svn commit: r613154 - /incubator/sling/trunk/jcr/jackrabbit-server/pom.xml

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Jan 18, 2008 4:24 PM, Felix Meschberger <fm...@gmail.com> wrote:
> My question was directed at the API/Commons bundle containing the SPI
> classes, which kind of worried me, but as they are "internal" to the
> bundle, I do not have any further issues.

I think Bertrand's change only affects the Jackrabbit repository
bundle, not the API/Commons bundle.

On a related note, I don't think jackrabbit-jcr-commons should be
included in the API/Commons bundle. The commons classes are not
something you should be passing around between bundles.

BR,

Jukka Zitting

Re: svn commit: r613154 - /incubator/sling/trunk/jcr/jackrabbit-server/pom.xml

Posted by Felix Meschberger <fm...@gmail.com>.
Hi Jukka,

Am Freitag, den 18.01.2008, 16:03 +0200 schrieb Jukka Zitting:
> Hi,
> 
> On Jan 18, 2008 3:57 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
> > I remember talks in Jackrabbit about where to put those naming/etc.
> > classes, so maybe they shouldn't really be in SPI - but the bundle
> > didn't work for me without that.
> 
> Yes, jackrabbit-spi-commons is a required dependency of
> jackrabbit-core. All the internal Name and Path handling is done using
> functionality from spi-commons.

Sure. So we would pack the packages with the bundle containing the
embedded jackrabbit and have these packages private to this bundle.

My question was directed at the API/Commons bundle containing the SPI
classes, which kind of worried me, but as they are "internal" to the
bundle, I do not have any further issues.

> 
> I don't know OSGi enough to understand why such internal packages need
> to be explicitly declared.

The point is that when creating the bundle (or jar file) we declare the
contents of the file and we have a lot of control in this. For example
we can add packages from dependencies etc.

For bundles to interoperate and share classes, this share has to made
explicit by importing and exporting packages. This allows fine grained
control of what is visible outside of a bundle.

My favourite example here is JDOM: If a bundle requires JDOM 0.5 it may
include this in the bundle, without exporting it. Anohter bundle may use
JDOM 0.9 without any problems. The use of the given JDOM version in
another is completely unknown to any bundles - as long as the packages
are not exported. This is a great feature of OSGi and helps solving a
lot of versioning problems.

Hope this helps.

Regards
Felix


Re: svn commit: r613154 - /incubator/sling/trunk/jcr/jackrabbit-server/pom.xml

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Jan 18, 2008 3:57 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
> I remember talks in Jackrabbit about where to put those naming/etc.
> classes, so maybe they shouldn't really be in SPI - but the bundle
> didn't work for me without that.

Yes, jackrabbit-spi-commons is a required dependency of
jackrabbit-core. All the internal Name and Path handling is done using
functionality from spi-commons.

I don't know OSGi enough to understand why such internal packages need
to be explicitly declared.

BR,

Jukka Zitting

Re: svn commit: r613154 - /incubator/sling/trunk/jcr/jackrabbit-server/pom.xml

Posted by Felix Meschberger <fm...@gmail.com>.
Hi Betrand,

Ok. Thanks for this info.

Regards
Felix

Am Freitag, den 18.01.2008, 14:57 +0100 schrieb Bertrand Delacretaz:
> On Jan 18, 2008 2:40 PM, Felix Meschberger <Fe...@day.com> wrote:
> > ...Do we really need "spi" packages here ? This sounds like intrusive in
> > the API and Commons bundle....
> 
> The bundle doesn't start without these packages, so I assumed adding
> them to the list of Private-Packages makes them available to the
> embedded Jackrabbit code, without polluting the class space.
> 
> I remember talks in Jackrabbit about where to put those naming/etc.
> classes, so maybe they shouldn't really be in SPI - but the bundle
> didn't work for me without that.
> 
> -Bertrand
> 
> 
> 
> 
> 
> >
> > Regards
> > Felix
> >
> > Am Freitag, den 18.01.2008, 13:15 +0000 schrieb bdelacretaz@apache.org:
> >
> > > Author: bdelacretaz
> > > Date: Fri Jan 18 05:15:17 2008
> > > New Revision: 613154
> > >
> > > URL: http://svn.apache.org/viewvc?rev=613154&view=rev
> > > Log:
> > > SLING-169 - adapt some Jackrabbit package names due to move to 1.4
> > >
> > > Modified:
> > >     incubator/sling/trunk/jcr/jackrabbit-server/pom.xml
> > >
> > > Modified: incubator/sling/trunk/jcr/jackrabbit-server/pom.xml
> > > URL: http://svn.apache.org/viewvc/incubator/sling/trunk/jcr/jackrabbit-server/pom.xml?rev=613154&r1=613153&r2=613154&view=diff
> > > ==============================================================================
> > > --- incubator/sling/trunk/jcr/jackrabbit-server/pom.xml (original)
> > > +++ incubator/sling/trunk/jcr/jackrabbit-server/pom.xml Fri Jan 18 05:15:17 2008
> > > @@ -131,15 +131,18 @@
> > >                              org.apache.jackrabbit.rmi.*,
> > >
> > >                              EDU.oswego.cs.dl.util.concurrent.*,
> > > -                            org.apache.lucene.*, org.apache.derby.*
> > > +                            org.apache.lucene.*, org.apache.derby.*,
> > > +
> > > +                            <!-- needed since the move to Jackrabbit 1.4 -->
> > > +                             org.apache.jackrabbit.spi.commons.conversion.*,
> > > +                             org.apache.jackrabbit.spi.commons.namespace.*,
> > > +                             org.apache.jackrabbit.spi.*
> > >                          </Private-Package>
> > >                          <Import-Package>
> > >                              org.apache.sling.jcr.api,
> > >
> > >                              org.apache.jackrabbit,
> > > -                            org.apache.jackrabbit.name,
> > >                              org.apache.jackrabbit.util,
> > > -                            org.apache.jackrabbit.util.name,
> > >                              org.apache.jackrabbit.uuid,
> > >                              org.apache.jackrabbit.value,
> > >
> > >
> > >


Re: svn commit: r613154 - /incubator/sling/trunk/jcr/jackrabbit-server/pom.xml

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 18, 2008 2:40 PM, Felix Meschberger <Fe...@day.com> wrote:
> ...Do we really need "spi" packages here ? This sounds like intrusive in
> the API and Commons bundle....

The bundle doesn't start without these packages, so I assumed adding
them to the list of Private-Packages makes them available to the
embedded Jackrabbit code, without polluting the class space.

I remember talks in Jackrabbit about where to put those naming/etc.
classes, so maybe they shouldn't really be in SPI - but the bundle
didn't work for me without that.

-Bertrand





>
> Regards
> Felix
>
> Am Freitag, den 18.01.2008, 13:15 +0000 schrieb bdelacretaz@apache.org:
>
> > Author: bdelacretaz
> > Date: Fri Jan 18 05:15:17 2008
> > New Revision: 613154
> >
> > URL: http://svn.apache.org/viewvc?rev=613154&view=rev
> > Log:
> > SLING-169 - adapt some Jackrabbit package names due to move to 1.4
> >
> > Modified:
> >     incubator/sling/trunk/jcr/jackrabbit-server/pom.xml
> >
> > Modified: incubator/sling/trunk/jcr/jackrabbit-server/pom.xml
> > URL: http://svn.apache.org/viewvc/incubator/sling/trunk/jcr/jackrabbit-server/pom.xml?rev=613154&r1=613153&r2=613154&view=diff
> > ==============================================================================
> > --- incubator/sling/trunk/jcr/jackrabbit-server/pom.xml (original)
> > +++ incubator/sling/trunk/jcr/jackrabbit-server/pom.xml Fri Jan 18 05:15:17 2008
> > @@ -131,15 +131,18 @@
> >                              org.apache.jackrabbit.rmi.*,
> >
> >                              EDU.oswego.cs.dl.util.concurrent.*,
> > -                            org.apache.lucene.*, org.apache.derby.*
> > +                            org.apache.lucene.*, org.apache.derby.*,
> > +
> > +                            <!-- needed since the move to Jackrabbit 1.4 -->
> > +                             org.apache.jackrabbit.spi.commons.conversion.*,
> > +                             org.apache.jackrabbit.spi.commons.namespace.*,
> > +                             org.apache.jackrabbit.spi.*
> >                          </Private-Package>
> >                          <Import-Package>
> >                              org.apache.sling.jcr.api,
> >
> >                              org.apache.jackrabbit,
> > -                            org.apache.jackrabbit.name,
> >                              org.apache.jackrabbit.util,
> > -                            org.apache.jackrabbit.util.name,
> >                              org.apache.jackrabbit.uuid,
> >                              org.apache.jackrabbit.value,
> >
> >
> >