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?

I might have been wrong about your preferred target solution.

Just to confirm, your aim is to:

- update the existing org.apache.httpcomponents.httpclient bundle with https://mvnrepository.com/artifact/org.apache.httpcomponents/httpclient-osgi/4.5.2
- update the exiting org.apache.httpcomponents.httpccore with https://mvnrepository.com/artifact/org.apache.httpcomponents/httpcore-osgi/4.4.5?
OR: - don't touch org.apache.httpcomponents.httpccore?

-Gunnar


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






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

Gunnar Wagenknecht wrote:
Andreas, can you have a look at this feature? I'm afraid there are many
more in the train including 3rd party bundles by there bsn. Thus, we'll
likely end up with many different versions.

I can imagine the following plan:

1) provide a new bundle as you currently plan to do
2) provide "fake" bundles with the old BSN that:
 * depend on the new bundle (require bundle dependency)
 * do not export any packages

I fail to see why option 2 should be necessary *if* we use httpclient-osgi.

AFAICT, Roland has kept the BSN for org.apache.httpcomponents.httpclient
when updating from 4.3.6 (version in Neon Orbit R-build) to 4.5.2
(version in Oxygen M5 Orbit S-build). The problem is just that the
S-build version does not contain packages like
org.apache.http.client.fluent which existed in the Neon R-build version.
If we use the httpclient-osgi JAR for Oxygen, it would again contain all
packages that exist in the Neon R-build.

In my understanding, option 2 would only be necessary if we bring the
individual httpclient-* bundles to Orbit, as in that case the core
org.apache.httpcomponents:httpclient:4.5.2 JAR [1] would need a BSN
other than org.apache.httpcomponents.httpclient, as it won't contain all
packages that the same bundle from the Neon R-build contained. If we go
down that route (neither my or your preferred solution, IIRC), then I
would do the following BSN -> JAR from Central Mapping:

org.apache.httpcomponents.httpclient.core 4.5.2 ->
 org.apache.httpcomponents:httpclient:4.5.2

org.apache.httpcomponents.httpclient.fluent 4.5.2 ->
 org.apache.httpcomponents:fluent-hc:4.5.2

org.apache.httpcomponents.httpclient.cache 4.5.2 ->
 org.apache.httpcomponents:httpclient-cache:4.5.2

org.apache.httpcomponents.httpclient.mime 4.5.2 ->
 org.apache.httpcomponents:httpclient-mime:4.5.2

org.apache.httpcomponents.httpclient 4.5.2
 Umbrella bundle that reexports
   org.apache.httpcomponents.httpclient.core,
   org.apache.httpcomponents.httpclient.fluent
   org.apache.httpcomponents.httpclient.cache
   org.apache.httpcomponents.httpclient.mime

This should keep existing bundles using Require-Bundle:
org.apache.httpcomponents.httpclient working. But if the single-bundle
httpclient-osgi solution works, I would definitely go for that, as it is
a lot less complex.

Makes sense?

Andreas

[1] <http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22httpclient%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