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 <fm...@gmail.com> on 2008/01/24 08:55:09 UTC
jackrabbit-jcr-commons
Hi all,
Based on discussions in [1] and issue SLING-176 [2], I removed the
export of the jackrabbit-jcr-commons packages from the jcr/api bundle. I
thought, that this would only be a minor issue, but was completely
wrong: These packages are used throughout Sling in multiple projects,
which caused confusion as Sling did build but not run. Sorry for any
inconvenience.
Yet, I am not happy with the current situation: There are far too many
hand-crafted inclusions of the jackrabbit-jcr-commons packages. To fix
the situation I see two possible solutions:
(1) We create a new bundle jcr/base (or similar) which would export
jackrabbit-jcr-commons
and would also take the Session pooling functionality from the
jcr/api bundle. This
is the approached proposed by issue SLING-185.
(2) Ask Jackrabbit to modify the jackrabbit-jcr-commons project to
make it an OSGi bundle.
This solution has the big advantage, that we may safely and
easily take over the
official released library from Jackrabbit and do not have to
create the bundling
outselves.
The longer I think of it, the longer I like the second solution. WDYT ?
Regards
Felix
[1] http://markmail.org/message/q25llm4f5z4djrbl
[2] http://issues.apache.org/jira/browse/SLING-176
[3] http://issues.apache.org/jira/browse/SLING-185
Re: jackrabbit-jcr-commons
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Jukka,
Am Donnerstag, den 24.01.2008, 10:05 +0200 schrieb Jukka Zitting:
> PS. Perhaps something for Apache Felix, couldn't the OSGi runtime just
> come up with reasonable default settings for using normal un-annotated
> jar files as bundles? Especially if it has access to the Maven POM
> (included in the jar file). What's the extra metadata that's currently
> missing?
I don't think that would be a good idea: The OSGi spec states the
requirements for bundles by defining the required headers in the
Manifest. Building some workaround for "non-bundles" in a specific
framework would lead to vendor-lockin and confusion. Therefore, I would
vote against such an addition.
In addition, creating these headers is very simple with the
maven-bundle-plugin from Apache Felix.
Regards
Felix
Re: jackrabbit-jcr-commons
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 24, 2008 9:55 AM, Felix Meschberger <fm...@gmail.com> wrote:
> (2) Ask Jackrabbit to modify the jackrabbit-jcr-commons project to
> make it an OSGi bundle. This solution has the big advantage, that
> we may safely and easily take over the official released library from
> Jackrabbit and do not have to create the bundling outselves.
+1 I don't see any reason why Jackrabbit couldn't do that.
PS. Perhaps something for Apache Felix, couldn't the OSGi runtime just
come up with reasonable default settings for using normal un-annotated
jar files as bundles? Especially if it has access to the Maven POM
(included in the jar file). What's the extra metadata that's currently
missing?
BR,
Jukka Zitting
Re: jackrabbit-jcr-commons
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi all,
>
> Based on discussions in [1] and issue SLING-176 [2], I removed the
> export of the jackrabbit-jcr-commons packages from the jcr/api bundle. I
> thought, that this would only be a minor issue, but was completely
> wrong: These packages are used throughout Sling in multiple projects,
> which caused confusion as Sling did build but not run. Sorry for any
> inconvenience.
>
> Yet, I am not happy with the current situation: There are far too many
> hand-crafted inclusions of the jackrabbit-jcr-commons packages. To fix
> the situation I see two possible solutions:
>
> (1) We create a new bundle jcr/base (or similar) which would export
> jackrabbit-jcr-commons
> and would also take the Session pooling functionality from the
> jcr/api bundle. This
> is the approached proposed by issue SLING-185.
>
> (2) Ask Jackrabbit to modify the jackrabbit-jcr-commons project to
> make it an OSGi bundle.
> This solution has the big advantage, that we may safely and
> easily take over the
> official released library from Jackrabbit and do not have to
> create the bundling
> outselves.
>
> The longer I think of it, the longer I like the second solution. WDYT ?
>
Yepp, I would prefer [2] as well.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: jackrabbit-jcr-commons
Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,
Well then, in the meantime I managed to modify the Jackrabbit libraries
to be valid OSGi bundles. So we will probably in the near future remove
the respective bundle inclusions again and just add the
jackrabbit-jcr-commons bundle to the list of bundles to be installed.
Regards
Felix
Am Donnerstag, den 24.01.2008, 08:55 +0100 schrieb Felix Meschberger:
> Hi all,
>
> Based on discussions in [1] and issue SLING-176 [2], I removed the
> export of the jackrabbit-jcr-commons packages from the jcr/api bundle. I
> thought, that this would only be a minor issue, but was completely
> wrong: These packages are used throughout Sling in multiple projects,
> which caused confusion as Sling did build but not run. Sorry for any
> inconvenience.
>
> Yet, I am not happy with the current situation: There are far too many
> hand-crafted inclusions of the jackrabbit-jcr-commons packages. To fix
> the situation I see two possible solutions:
>
> (1) We create a new bundle jcr/base (or similar) which would export
> jackrabbit-jcr-commons
> and would also take the Session pooling functionality from the
> jcr/api bundle. This
> is the approached proposed by issue SLING-185.
>
> (2) Ask Jackrabbit to modify the jackrabbit-jcr-commons project to
> make it an OSGi bundle.
> This solution has the big advantage, that we may safely and
> easily take over the
> official released library from Jackrabbit and do not have to
> create the bundling
> outselves.
>
> The longer I think of it, the longer I like the second solution. WDYT ?
>
> Regards
> Felix
>
> [1] http://markmail.org/message/q25llm4f5z4djrbl
> [2] http://issues.apache.org/jira/browse/SLING-176
> [3] http://issues.apache.org/jira/browse/SLING-185