Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Message-ID: <5448BF73.7070804@linux.vnet.ibm.com>
Date: Thu, 23 Oct 2014 04:42:27 -0400
From: David Williams <david_williams@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: dev@hc.apache.org
Subject: Question/Suggestion on your OSGi bundles
Content-Type: multipart/alternative;
 boundary="------------080908060705090804020400"

--------------080908060705090804020400
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


Greetings,

I work on the Orbit project at Eclipse, where we make "OSGi bundles" 
from "third party" software.

And, I've noticed, you yourselves have started to provide OSGi bundles 
on your download page -- so that's good! :)

But, you do them a differently than we would in Orbit, or Eclipse, so 
thought I'd ask if there is a reason for it, and/or suggest a different 
approach.

I first looked at your OSGi bundle for 4.3.5 and was surprised to see it 
literally contain all the "prereqs" it needed, including "httpcore", 
commons-logging, commons-codec, ... ).

Ordinarily we (at Eclipse) would simply have the OSGi bundle for 
"httpclient" "import package" or "require bundle" for it's pre-reqs, but 
leave the code separate. Then some other layer would be responsible for 
"collecting" what is needed. In our (Eclipse) case, we use often use 
"features", but I understand not everyone does, but seems to me, it'd be 
better to provide a new bundle, maybe called "httpclient.collection" or 
something, if that is the way you wanted to "distribute everything 
needed". For Eclipse, we would not even *have* to use features for a 
case like this since installers, such as p2, will "install" what ever 
the httpclient needs, as long as it's in a reachable repository.

I was especially motivated to write this note after seeing you just come 
out with a new version of httpcore (4.3.3) and make me wonder ... are 
those fixes included in httpclient 4.3.5, or will there now have to be a 
new client at version 4.3.6, just to include the new 4.3.3 core? (And, I 
think the answer is "yes" -- though, I see from some JIRA entries, there 
may be other reasons to have a 4.3.6 -- but, some of those are in part 
related to this very issue I am writing about).

It seems to me to be a better "component model" to leave your OSGi 
bundles seperate, and then would "match" your "Java jars" in terms of 
content (only adding the OSGi required stuff) and then control the 
packaging in some other way -- features, or installers that understood 
OSGi required items, etc. -- and either leave that up to the consumer to 
do, or if you really wanted to provide "one bundle with everything" to 
create a new bundle, called "collection" or similar. I know we (Eclipse) 
are only one case but we would not need that "collection" bundle. We'd 
just need the pieces.

Given all that, is there a reason you do your bundles the way you do, 
that I am just not aware of? Or is there any merit to my suggestion?

Thanks,


--------------080908060705090804020400--