On Thu, 2014-10-23 at 04:42 -0400, David Williams wrote: > 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, ... ). >
Hi David While inclusion of commons codec code was intentional that of httpcore was not. The problem has been fixed in 4.3.x and trunk [1] but not yet released. > 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, > The model where one Jar equals OSGi bundle seems to completely defeat the whole point of using bundles in my opinion. For instance, in case HttpClient I see no point imposing a dependency on Commons Codec. The fact that HttpClient makes use of Commons Codec internally should be completely irrelevant to HttpClient consumers. OSGi enables us to bundle Base64 codecs of a specific version without imposing the same dependency on the end user. Oleg [1] https://issues.apache.org/jira/browse/HTTPCLIENT-1558 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
