On Wed, Aug 05, 2009 at 02:44:01PM +0100, sebb wrote: > On 05/08/2009, Oleg Kalnichevski <[email protected]> wrote: > > On Wed, Aug 05, 2009 at 02:17:38PM +0100, sebb wrote: > > > On 05/08/2009, Joerg Bullmann <[email protected]> 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)" > > <[email protected]> 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: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
