hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [jira] Issue Comment Edited: (HTTPCLIENT-865) HttpClient OSGi Export-Package doesn't specify version
Date Wed, 05 Aug 2009 13:59:49 GMT
On Wed, Aug 05, 2009 at 02:44:01PM +0100, sebb wrote:
> On 05/08/2009, Oleg Kalnichevski <olegk@apache.org> wrote:
> > On Wed, Aug 05, 2009 at 02:17:38PM +0100, sebb wrote:
> >  > On 05/08/2009, Joerg Bullmann <jb@heilancoo.net> wrote:
> >  > > I have a little bit of feedback to give here.
> >  > >
> >  > >  For a while now I have been using HttpCore in an application that is
OSGi/Eclipse based. What I have done is take the bog standard HttpCore jar file and wrapped
it in an Eclipse plug-in (OSGi bundle). This cost me less than a minute and I have the whole
thing nicely isolated from my other plug-ins etc. Admittedly I have to keep this HttpCore
plug-in up-to-date myself but that's not really a hassle at all. I get all the HttpCore goodness
I need and all the plug-in flexibility too.
> >  >
> >  > I think that's what the Http OSGI module is for?
> >  >
> >  > >  Maybe just as a bit of food for thought in the direction of keeping
things simple on your side. If my musings don't make sense, then please just disregard.
> >  >
> >  > AFAIK, the Commons components work fine with OSGI, but they include
> >  > the OSGI stuff in the normal jars, rather than having a separate
> >  > module to provide the OSGI wrappers.
> >  >
> >  > Maybe that is where the difficulties have arisen?
> >  >
> >  > Might be worth trying the approach taken in the Commons Parent POM and
> >  > see if that generates jars with the correct headers?
> >  >
> >
> >
> > Yes, this is precisely the case. But with bundles one can make encapsulate
> >  transitive dependencies which is clearly an advantage in case of HttpClient.
> >  For instance one can use a different version of Commons Codec and Mime4j
> >  without running into a compatibility issues with HttpClient due to its
> >  transitive dependencies.
> 
> The OSGI headers for Jexl for example are:
> 
> Export-Package: org.apache.commons.jexl.parser;version="2.0.0.SNAPSHOT
>  ",org.apache.commons.jexl;version="2.0.0.SNAPSHOT",org.apache.commons
>  .jexl.util;version="2.0.0.SNAPSHOT",org.apache.commons.jexl.util.intr
>  ospection;version="2.0.0.SNAPSHOT",org.apache.commons.jexl.scripting;
>  version="2.0.0.SNAPSHOT",org.apache.commons.jexl.junit;version="2.0.0
>  .SNAPSHOT",org.apache.commons.jexl.context;version="2.0.0.SNAPSHOT"
> 
> Import-Package: javax.script,junit.framework,org.apache.commons.jexl;v
>  ersion="2.0.0.SNAPSHOT",org.apache.commons.jexl.context;version="2.0.
>  0.SNAPSHOT",org.apache.commons.jexl.junit;version="2.0.0.SNAPSHOT",or
>  g.apache.commons.jexl.parser;version="2.0.0.SNAPSHOT",org.apache.comm
>  ons.jexl.scripting;version="2.0.0.SNAPSHOT",org.apache.commons.jexl.u
>  til;version="2.0.0.SNAPSHOT",org.apache.commons.jexl.util.introspecti
>  on;version="2.0.0.SNAPSHOT",org.apache.commons.logging
> 
> Only the Jexl packages have versions attached to them, so I assume it
> can be used with different versions of commons logging if required.
> 
> Isn't that exactly what HttpClient wants too?
> Or am I missing something vital?
> 

I have to plead almost complete ignorance of OSGi details, but I assume the
issue can be that given there is no version on a package import the OSGi
container can pick up pretty much any version it pleases. 

Oleg



> >  Besides, HttpClient is much more complex for packaging than HttpCore, which has
> >  no external dependencies at all.
> >
> >
> >  Oleg
> >
> >
> >  > I *might* have time to try that tomorrow.
> >  >
> >  > >  Cheers,
> >  > >  Joerg
> >  > >
> >  > >  On Wednesday, 5 August, 2009 2:30pm, "Oleg Kalnichevski (JIRA)" <jira@apache.org>
said:
> >  > >
> >  > >  >
> >  > >  >     [
> >  > >
> >  > > > https://issues.apache.org/jira/browse/HTTPCLIENT-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739452#action_12739452
> >  > >  > ]
> >  > >  >
> >  > >  > Oleg Kalnichevski edited comment on HTTPCLIENT-865 at 8/5/09 5:28
AM:
> >  > >  > ----------------------------------------------------------------------
> >  > >  >
> >  > >  > Having to manually set a version on each and every imported package
would be a
> >  > >  > _major_ pain in the rectum and simply defeats the whole point of
using the damn
> >  > >  > bundle plugin.
> >  > >  >
> >  > >  > Besides, if we set an explicit version on HttpCore imports it would
render
> >  > >  > HttpClient OSGi bundle incompatible with officially released OSGi
bundles of
> >  > >  > HttpCore.
> >  > >  >
> >  > >  > Oleg
> >  > >  >
> >  > >  >       was (Author: olegk):
> >  > >  >     Having to manually set a version on each and every imported
package would be a
> >  > >  > _major_ pain in the rectum and simply defeats the whole point of
using the
> >  > >  > damn bundle plugin.
> >  > >  >
> >  > >  > Besides, if we set an explicit version on HttpCore imports it would
render
> >  > >  > HttpClient OSGi bundle with officially released OSGi bundles of
HttpCore.
> >  > >  >
> >  > >  > Oleg
> >  > >  >
> >  > >  >> HttpClient OSGi Export-Package doesn't specify version
> >  > >  >> ------------------------------------------------------
> >  > >  >>
> >  > >  >>                 Key: HTTPCLIENT-865
> >  > >  >>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-865
> >  > >  >>             Project: HttpComponents HttpClient
> >  > >  >>          Issue Type: Bug
> >  > >  >>          Components: HttpClient
> >  > >  >>    Affects Versions: 4.0 Beta 2
> >  > >  >>            Reporter: Richard Wallace
> >  > >  >>             Fix For: 4.0 Final
> >  > >  >>
> >  > >  >>
> >  > >  >> The "Export-Package" manifest entry doesn't specify the version
of the package
> >  > >  >> being exported.  This means that packages importing it can't
specify a version to
> >  > >  >> import.
> >  > >  >
> >  > >  > --
> >  > >  > This message is automatically generated by JIRA.
> >  > >  > -
> >  > >  > You can reply to this email to add a comment to the issue online.
> >  > >  >
> >  > >  >
> >  > >  > ---------------------------------------------------------------------
> >  > >  > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> >  > >  > For additional commands, e-mail: dev-help@hc.apache.org
> >  > >  >
> >  > >  >
> >  > >
> >  > >
> >  > >
> >  > >  ---------------------------------------------------------------------
> >  > >  To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> >  > >  For additional commands, e-mail: dev-help@hc.apache.org
> >  > >
> >  > >
> >  >
> >  > ---------------------------------------------------------------------
> >  > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> >  > For additional commands, e-mail: dev-help@hc.apache.org
> >  >
> >
> >  ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> >  For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message