Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 74.125.82.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1390855184.10865.8.camel@ubuntu>
References: <883s4hfbauquoc5096ffv1td.1390847083767@email.android.com>
	<1390848872.8989.3.camel@ubuntu>
	<CAOGo0VZmqhr2VE5nvHMHu7QRDwPQVT=i5KqtyYUbandMwusmKQ@mail.gmail.com>
	<1390851832.8989.7.camel@ubuntu>
	<CAOGo0VZpTntez9os+sEABOHNhM1jzO+1HDcTL=PDxTNTN3H9GQ@mail.gmail.com>
	<1390855184.10865.8.camel@ubuntu>
Date: Tue, 28 Jan 2014 00:09:53 +0000
Message-ID: 
 <CAOGo0VZUu1igj-4RDP4kBuFmSeogiDdCOkSxo3U8EadXu=C=gA@mail.gmail.com>
Subject: Re: [Request for comments] HttpClient re-spin for Android
From: sebb <sebbaz@gmail.com>
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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.
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?

>> 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.

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

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