On Tue, 2014-01-28 at 00:09 +0000, sebb wrote: > On 27 January 2014 20:39, Oleg Kalnichevski <[email protected]> wrote: > > On Mon, 2014-01-27 at 20:14 +0000, sebb wrote: > >> On 27 January 2014 19:43, Oleg Kalnichevski <[email protected]> wrote: > >> > On Mon, 2014-01-27 at 19:33 +0000, sebb wrote: > >> >> On 27 January 2014 18:54, Oleg Kalnichevski <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
