On Fri, 2014-10-24 at 08:58 -0400, Gary Gregory wrote: > Can we give our users a choice? > > - Still produce the existing OSGi bundles as is > - Make sure our other jars are OSGi-fied. > > This would let folks pick to their liking. But that does not sound possible > without some jar hell? >
I do not know OSGi well. I can't say. If someone is willing to step in and do all the work, though, I will not stand in the way. Oleg > Gary > > On Thu, Oct 23, 2014 at 5:31 AM, Oleg Kalnichevski <[email protected]> wrote: > > > 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] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
