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