#449 Re-add OSGi headers to all modules.#450
Conversation
|
@raulk how do I verify they were added? |
|
I see the following in From 8.17.0 I see I'd like a plus one from someone not me and not the author that the above is sufficient. |
|
IIRC the only thing that really matters is the Export/Import-Package and that looks sane. If the author says it works I think that's good enough for me. But how are we generating this data (the versions must change for every release)? |
|
@dsyer |
|
I don't understand the nuance of import export, but is it normal for feign On Sat, Aug 27, 2016 at 12:21 AM, Spencer Gibb notifications@github.com
|
|
OSGi has a select set of headers, out of which the important ones are Many of the manifest headers in 8.18.0 were not OSGi related. I suppose We do not export javax.net.ssl. If you look closely, that package is part Version ranges are updated automatically by the maven-bundle-plugin as the On 27 Aug 2016 02:14, "Adrian Cole" notifications@github.com wrote:
|
|
Ahh ok. Any way to test this so that we dont break it again? Ex. an invoker test in src/main/it or something? On 29 Aug 2016 07:11, "Raúl Kripalani" notifications@github.com wrote:
|
|
Hmmm... We could consider a Pax Exam test. I'll look into that separately. On 29 Aug 2016 00:55, "Adrian Cole" notifications@github.com wrote:
|
|
Yeah sure. I think i remember PAM used in jclouds and it did catch when On 29 Aug 2016 07:57, "Raúl Kripalani" notifications@github.com wrote:
|
|
LGTM
|
|
This doesn't work with google-gson 2.7 in an actual OSGi environment, Eclipse P2 OSGi container to be precise. Reason being feign-gson module has imports to google-gson internal packages [1] which are not exported from google-gson. google-gson has been explicitly instructed not to export internal packages [2]. Problem is not with this PR, but we need to fix DoubleToIntMapTypeAdapter before anyone could make use of this. [2] https://github.com/google/gson/blob/master/gson/pom.xml#L28 |
|
we are not required to make all things work in OSGi, particularly as it is GsonDecoder(Gson gson) |
|
IMHO if we accept to make OpenFeign OSGi ready then it should be required to work in OSGi environment. Or else it would be better not to have it at all. |
|
Opinion noted, and if strict OSGi compliance for all aspects of all code For now, you can either choose to use the workaround, choose to put in On 29 Aug 2016 13:18, "Akila Ravihansa Perera" notifications@github.com
|
|
My goal with this ticket was to fix a regression whereby newest versions of Feign stopped generating OSGi headers altogether. We could discuss about OSGi in a broader context – and how to make things nicer for Gson, but I don't think it should prevent this PR from being merged. |
|
@ravihansa3000 – I wouldn't deploy feign-gson as an OSGi fragment of Gson, that makes little sense technically speaking, because your fragment would have to declare the If anything, I would consider creating a little helper OSGi fragment that does nothing but attach to Gson and export the internal package you need, e.g. feign-gson-osgi-helper. That or change feign-gson so that it doesn't rely on internal classes of Gson, if at all possible. |
|
@spencergibb – thanks for the merge 👍 |
|
@adriancole thank you for suggesting a workaround. @raulk I agree. I'll try to initiate a discussion on this in Gitter. |
Via the maven-bundle-plugin.