On 05/08/2009, Oleg Kalnichevski <[email protected]> wrote: > 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. >
I thought that was what was wanted for the HC dependencies? > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
