| Re: [orbit-dev] Multiple bundle recipes for httpclient-* vs. a single one for httpclient-osgi? |
Hi Gunnar, thanks for your advice. > My advice would be to not go too fine grained. The fewer bundles the > better. Let me explain why. > > Is it really necessary to have OSGi bundles with a few classes only? > Yes, it may make sense from a modularization point but keep in mind > that more bundles increase the risk for issues downstream in the > release train. How many consumers would be for just one bundle? FWIW, in the particular case of the Simultaneous Release train, most downloads would contain also fluent-hc (required by Code Recommenders and AERI) and httpclient-cache (required by AERI), as at least AERI is included in *all* EPP packages. Hence, you would only "save" httpclient-mime on the big Java EPP packages. > Additionally, from my experience quite a lot non-osgi libraries > providing osgi bundles don't understand all of the modularization > issues. Most notable are split packages and semantic versioning. > Thus, even though they "provide" multiple bundles, those bundle end > up running together only in that exact combination. Next time you > want to consume a fix in one class you have to update all bundles not > just the one containing the fix. I agree that getting all the imports and exports right is hard. Even the current, "fat" bundle (4.3.6) in Orbit still has bugs due to missing imports/exports [1]. > Thus, I would go with fewer bundles in the beginning. If possible > you should ship the http client as one bundle. It's easy to > introduce additional bundles later if there is a real demand for it. In summary, you would advise against publishing a "thin" bundle based on only httpclient (4.5.2) as introduced in Orbit S20161205183421 [2]. To me, that makes sense. But even if we decide to make the Orbit bundle a "fat" one again, it still raises the question which upstream GAVs to consume: Should the EBR depend on httpclient-osgi (and recycle its manifest) or should it depend on multiple upstream JARs (and craft the manifest from scratch, as was done in previous Orbit builds for 4.3.2). Let's hear what Roland has to say about this, as he initially went down the "thin" bundle road. Best wishes, Andreas [1] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=508270> [2] <https://dev.eclipse.org/mhonarc/lists/orbit-dev/msg04638.html> -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940
Attachment:
signature.asc
Description: OpenPGP digital signature