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? > 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]
