hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [Request for comments] HttpClient re-spin for Android
Date Tue, 28 Jan 2014 08:28:22 GMT
On Tue, 2014-01-28 at 00:09 +0000, sebb wrote:
> On 27 January 2014 20:39, Oleg Kalnichevski <olegk@apache.org> wrote:
> > On Mon, 2014-01-27 at 20:14 +0000, sebb wrote:
> >> On 27 January 2014 19:43, Oleg Kalnichevski <olegk@apache.org> wrote:
> >> > On Mon, 2014-01-27 at 19:33 +0000, sebb wrote:
> >> >> On 27 January 2014 18:54, Oleg Kalnichevski <olegk@apache.org>
wrote:
> >> >> > On Mon, 2014-01-27 at 13:24 -0500, Gary Gregory wrote:
> >> >> >> Wow this is confusing! Why not repackage the classes instead
of renaming each one with an HC4 postfix?
> >> >> >>
> >> >> >
> >> >> > That was my initial plan, too. But try re-writing the sources
using
> >> >> > regex when you have multiple classes with the same name. I had
to give
> >> >> > up after a full day of wasted efforts. My regex skills are very
basic,
> >> >> > though. So, improvements are highly welcome
> >> >> >
> >> >> > http://svn.apache.org/repos/asf/httpcomponents/httpclient-android/trunk/build.gradle
> >> >>
> >> >> How do you decide which classes need renaming, and which ones don't?
> >> >>
> >> >
> >> > By comparing different versions using reflection. It is in the script.
> >>
> >> The script contains lots of special ("magic") package and class names,
> >> so presumably a simple comparison is not sufficient.
> >> How are these exceptions determined?
> >>
> >
> > There are several differences between version 4.0-beta1 used by the
> > script and some arbitrary snapshot taken by Google. Some things
> > unfortunately have to be adjusted manually.
> 
> If they took a snapshot, there must be a corresponding revision.

How do you suggest to find it out?

> It would be trivial to create a tag once the revision has been established.
> 
> >> >> ==
> >> >>
> >> >> Are there likely to be many developers who need to provide an
> >> >> application that runs unmodified on both Android and Java?
> >> >> If not, then it would surely be sufficient to just provide a shaded
> >> >> version for Android which uses a different package name?
> >> >>
> >> >
> >> > Maybe not. But there are enough applications that are compiled against
> >> > Android APIs that cannot be used with repackaged code.
> >>
> >> Not sure I follow.
> >>
> >> If an app is compiled against the Android APIs, I don't see how it can
> >> take advantage of any new classes without changing the source and
> >> recompiling.
> >
> > How about multiple implementations of the same abstract API, one being
> > newer and containing fewer bugs?
> 
> If the implementation class name is the same, I don't see how the two
> versions can co-exist without classpath issues.
> If the implementation is a new class, I'm not sure how the existing
> binary code can take advantage of the new implementation.
> What would cause the existing code to find the newer class?
> 

Sigh. How about applications (or libraries) that rely on interfaces
instead of concrete implementation classes?

> >> In which case, would it not make sense to convert the code to use all
> >> new class names?
> >>
> >> Maybe I'm missing something, but I'm not seeing any great advantage to
> >> the proposed Android build.
> >>
> >
> > If you are familiar with Spring, think of Spring Rest template.
> 
> No, I'm afraid I have no experience of Spring.
> 

I hope this will help you understand what I am trying to achieve and why
it is important:

http://docs.spring.io/spring-android/docs/1.0.1.RELEASE/api/org/springframework/http/client/HttpComponentsClientHttpRequestFactory.html#setHttpClient%28org.apache.http.client.HttpClient%29

Oleg



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message