Chcę przepakować bibliotekę httpclient apache, aby wysłać ją za pomocą aplikacji na Androida (nphttps://code.google.com/p/httpclientandroidlib/ ale z HttpClient 4.3.1)

Dlatego japobrane słoik httpclient 4.3.1 (zawiera wszystkie jego zależności) ręcznie i użył jarjar do przepakowania go:

x@x$: cd libs && for f in *.jar; do java -jar ../jarjar-1.4.jar process ../rules.txt $f out/my-$f; done

zrules.txt:

 rule org.apache.http.** my.repackaged.org.apache.http.@1

Potem użyłem mrówki, aby połączyć wyjście:

<project name="MyProject" default="merge" basedir=".">
  <target name="merge">
        <zip destfile="my-org-apache-httpclient-4.3.1.jar">
            <zipgroupfileset dir="libs/out" includes="*.jar"/>
        </zip>
  </target>
</project>

Mogę użyć tego pliku do opracowania i przetestowania mojej aplikacji, ale jeśli wdrożę go na Androidzie, zgłasza wyjątek taki jak ten, którego nie może znaleźćmy.repackaged.org.apache.logging.log4j.something przywoływany przezmy.package.org.apache.logging.whatEver.

Więc teraz chcę usunąć wszelkie zależności od rejestrowania danych przez użycie manipulacji kodem bajtowym. Dokonano tego przed:http://sixlegs.com/blog/java/dependency-killer.html

Ale zastanawiam się, jak to robię? Istnieją tylko zależności od org.apache.commons.logging.Log:

x$x$: java -jar jarjar-1.4.jar find jar my-org-apache-httpclient-4.3.1.jar commons-logging-1.1.3.jar
my/http/impl/execchain/ServiceUnavailableRetryExec -> org/apache/commons/logging/Log
my/http/impl/execchain/RetryExec -> org/apache/commons/logging/Log
my/http/impl/execchain/RedirectExec -> org/apache/commons/logging/Log
my/http/impl/execchain/ProtocolExec -> org/apache/commons/logging/Log
...

Myślę, że sposobem na to jest usunięcie tych zależności i zastąpienie ich własną implementacją, tak jak tutajhttps://code.google.com/p/httpclientandroidlib/ . Dlatego stworzyłem nowy projekt maven tylko z jedną klasąprovided zakres rejestrowania danych, który implementuje interfejs org.apache.commons.logging.Log i po prostu przenosi doandroid.utils.Log:

MyLog implements org.apache.commons.logging.Log {}

w paczcemy.log i spakowałem to w my-log-1.0.0.jar. Umieszczam ten słoik w tym samym folderze co przepakowane słoiki httpclient i użyłem mrówki, jak wspomniano powyżej, aby spakować wszystko razem w my-org-apache-httpclient-4.3.1.jar.

Podejście 1

Próbowałem ponownie użyć jarjar:

java -jar jarjar-1.4.jar process rules2.txt my-org-apache-httpclient-4.3.1.jar my-org-apache-httpclient-4.3.1-without-logging-dep.jar

zrules2.txt:

rule my.repackaged.commons.logging.** my.log.@1

ale to nie działa. Wyjątek, którego nie może znaleźćmy.repackaged.org.apache.logging.log4j.something przywoływany przezmy.package.org.apache.logging.whatEver wciąż jest rzucany.

Podejście 2

Próbowałem także usunąć dane logowania z ostatniego słoika i / lub przepakować plik my.repackaged.org.apache.log4j i zalogować się do oryginalnych pakietów:

rules2.txt v2:

rule my.repackaged.org.apache.log4j.** org.apache.log4j.@1
rule my.repackaged.org.apache.logging.** org.apache.logging.@1

ale to także wciąż rzuca wyzwanie:my.repackaged.org.apache.logging.log4j.something przywoływany przezmy.package.org.apache.logging.whatEver

PYTANIE

W jaki sposób mogę zabić / zastąpić te, które rejestrują zależności i pozbyć się wyjątku?