Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Multiple bundle recipes for httpclient-* vs. a single one for httpclient-osgi?

Hi Andreas,

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?

In the case of http client - The fluent api requires http client. Thus consumers would in all cases need at least both bundles. The fluent api itself adds value to regular users. Not having it available by default might cause confusion.

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.

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.

-Gunnar

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/






On 17 Jan 2017, at 09:53, Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx> wrote:

Hi all,

a while ago, when Roland announced S20161205183421, I pointed out on
this list [1] that the new org.apache.httpcomponents.httpclient bundle
didn't contain certain packages anymore, e.g.,
org.apache.http.client.fluent or org.apache.http.client.cache.

We said back then that this was intentional and that there should be
more fine-grained o.a.h.httpclient.* bundles at Orbit in the future,
e.g., o.a.h.httpclient.fluent or o.a.h.httpclient.cache.

While preparing recipes for the two bundles, however, I noticed that the
upstream project *does* provide OSGi-bundles (i.e., JARs with OSGi
manifests), but just not at the granularity they provide ordinary JARs at.

On Maven Central, there exists an OSGi bundle at GAV
org.apache.httpcomponents:httpclient-osgi:4.5.2 (Bundle-SymbolicName
org.apache.httpcomponents.httpclient), that contains code for at least
the following non-OSGi JARs: GAV
org.apache.httpcomponents:httpclient:4.5.2 [3],
org.apache.httpcomponents:fluent-hc:4.5.2 [4]
org.apache.httpcomponents:httpclient-cache:4.5.2 [5].

While I personally think that this inconsistency is a bad idea on part
of the Apache HttpComponents project, it raises the interesting question
which "cut" of HttpComponents bundles Orbit should contain:

1. Should it contain just an EBR recipe for
org.apache.httpcomponents:httpclient-osgi:4.5.2 [2], the argument being
that it contains the "official" OSGi-manifest for HttpClient

or

2. Should it contain EBR recipes for all the fine-grained HttpClient
JARs that are available at Maven Central [3,4,5], the argument being
that these are the "primary" output of the HttpComponents project and
that the httpclient-osgi artifact was merely added as an "afterthought"
by them.

I honestly don't have a good answer to this right now, but I think it
should be discussed on orbit-dev (and before I spend a lot of time on
EBRs and CQs ;-).

That being said, I think that we should (in the long run) work with the
HttpComponents project towards option 3:

3. The HttpComponents project should include OSGi manifests with all
their fine-grained JARs, which Orbit would then contain. (Maybe then
drop the httpclient-osgi umbrella bundle or simply let it reexport the
others' packages.)

What do you think?

Best wishes,

Andreas

[1] <https://dev.eclipse.org/mhonarc/lists/orbit-dev/msg04639.html>
[2]
<http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.httpcomponents%22%20AND%20a%3A%22httpclient-osgi%22>
[3]
<http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.httpcomponents%22%20AND%20a%3A%22httpclient%22>
[4]
<http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.httpcomponents%22%20AND%20a%3A%22fluent-hc%22>
[5]
<http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.httpcomponents%22%20AND%20a%3A%22httpclient-cache%22>

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

_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orbit-dev


Back to the top