# `build.gradle` so konfigurieren dass es mehrere .jar's z.b. mit org.junit erlaubt, oder...



## ruutaiokwu (2. Jul 2020)

...das ANT-Skript so einstellen dass es z.B. verhindert ein Verzeichnis `org/junit` reinzupacken:

- Also ersteres scheint wieder mal völlig unmöglich zu sein - und zwar für den Fall dass ich bei mehreren selbst gepackten .jar-Libraries (Bis jetzt ein HTTP- sowie ein SMTP-Client) halt noch die für die JUnit-Test erforderlichen Abhängigkeiten "reinpacke"... es ist dann halt der Fall, dass mehrere .jar's das Verzeichnis `org/junit/...` inne haben.

Dann reklamiert natürlich Android Studio über die versch. JAR-Dateien mit redundanten Daten, klar. Aber da kann man zum `exclude`-Parameter im "Rumpf" von gradle.config's `compile`- oder `implementation`-Einträgen wieder mal das halbe Internet durchforsten und man findet im Prinzip nur nicht-funktionierenden Quatsch...

Mit 2 "normalen" Klammern:


```
implementation files('libs\\AndroidCompatibleSMTPClient.jar') {
...
}
```



Mit 4 "normalen" Klammern:


```
implementation files(('libs\\AndroidCompatibleSMTPClient.jar')) {
...
}
```


Was den Inhalt des Rumpfs (also innerhalb von { .... }) betrifft, so gibt's schätzungsweise 27 im Netz beschriebene Varianten - dabei funktioniert KEINE EINZIGE (!!!). Auf das kann ich jetzt nicht weiter eingehen, da ich schätzungsweise 3 Stunden brauchen würde um die ganzen 27 im Internet beschriebenen Möglichkeiten aufzufinden


Was ich bei ANT machen soll, damit es VON ANFANG AN verhindert, irgendwelche Abhängigkeiten reinzupacken ist mir irgendwie auch völlig unklar.

Nun habe ich es jedenfalls so gelöst:


```
<!-- Custom { -->
        <unzip src="${dir.jarfile}/AndroidCompatibleHTTPClient.jar" dest="C:/Windows/Temp/AndroidCompatibleHTTPClient" />
        <delete file="C:/Windows/Temp/AndroidCompatibleHTTPClient/LICENSE-junit.txt" />
        <delete dir="C:/Windows/Temp/AndroidCompatibleHTTPClient/junit" />
        <delete dir="C:/Windows/Temp/AndroidCompatibleHTTPClient/org/junit" />
        <delete dir="C:/Windows/Temp/AndroidCompatibleHTTPClient/org/hamcrest" />
        <delete dir="C:/Windows/Temp/AndroidCompatibleHTTPClient/org/apache" />
        <delete file="AndroidCompatibleHTTPClient.jar" />
        <zip basedir="C:/Windows/Temp/AndroidCompatibleHTTPClient" destfile="AndroidCompatibleHTTPClient.jar" />
        <delete dir="C:/Windows/Temp/AndroidCompatibleHTTPClient" />
        <!-- } Custom -->
```

Oder aber auch so:


```
<!-- Custom { -->
        <unzip src="${dir.jarfile}/AndroidCompatibleSMTPClient.jar" dest="C:/Windows/Temp/AndroidCompatibleSMTPClient" />
        <delete file="C:/Windows/Temp/AndroidCompatibleSMTPClient/LICENSE-junit.txt" />
        <delete dir="C:/Windows/Temp/AndroidCompatibleSMTPClient/junit" />
        <delete dir="C:/Windows/Temp/AndroidCompatibleSMTPClient/org/junit" />
        <delete file="AndroidCompatibleSMTPClient.jar" />
        <zip basedir="C:/Windows/Temp/AndroidCompatibleSMTPClient" destfile="AndroidCompatibleSMTPClient.jar" />
        <delete dir="C:/Windows/Temp/AndroidCompatibleSMTPClient" />
        <!-- } Custom -->
```

...vielleicht kann mit aber jemand einen "vernünftigeren" Weg darlegen?

a.) Entweder ein "sauberes" ANT-Script, bei dem von ANFANG AN verhindert wird dass das Zeugs reingeht - also nix im Nachhinein rauslöschen

ODER

b.) gradle.config so konfiguirieren dass es .jar-Dateien mit mehreren gleichen Einträgen mit .class-Files erlaubt.


Besten Dank für die Feedbacks.


----------



## mihe7 (2. Jul 2020)

jmar83 hat gesagt.:


> ...vielleicht kann mit aber jemand einen "vernünftigeren" Weg darlegen?


Klar: pack die externen Abhängigkeiten nicht ins Jar; die haben da drin nichts verloren.


----------



## ruutaiokwu (2. Jul 2020)

Vielen Dank! 

Mache ich ja auch, jedoch lieber ohne solches "Zeugs":


```
<!-- Custom { -->
        <unzip src="${dir.jarfile}/AndroidCompatibleSMTPClient.jar" dest="C:/Windows/Temp/AndroidCompatibleSMTPClient" />
        <delete file="C:/Windows/Temp/AndroidCompatibleSMTPClient/LICENSE-junit.txt" />
        <delete dir="C:/Windows/Temp/AndroidCompatibleSMTPClient/junit" />
        <delete dir="C:/Windows/Temp/AndroidCompatibleSMTPClient/org/junit" />
        <delete file="AndroidCompatibleSMTPClient.jar" />
        <zip basedir="C:/Windows/Temp/AndroidCompatibleSMTPClient" destfile="AndroidCompatibleSMTPClient.jar" />
        <delete dir="C:/Windows/Temp/AndroidCompatibleSMTPClient" />
        <!-- } Custom -->
```

...also von Anfang an "excluden" und nicht das .jar-File nach C:\Windows\Temp entpacken, dann den ganzen Kram entfernen und wieder erneut zusammenpacken.

Das klappt zwar, ist aber einigermassen besch***en... ;-)


----------



## ruutaiokwu (2. Jul 2020)

Im ANT-Skript steht auch nix explizit dass das junit-jar-File reingepackt wird.

Nur welche Teile davon offenbar (?) nicht reingepackt werden:
<zipfileset excludes="META-INF/*.SF" src="${dir.workspace}/AndroidCompatibleSMTPClient/lib/junit-4.13.jar"/>

...den Rest macht ANT "einfach mal so" !!


----------



## mihe7 (2. Jul 2020)

Wieso verwendest Du ant? Wenn Du ant verwenden willst, dann gibt es unter https://ant.apache.org/manual/index.html eine entsprechende Doku. Da sollte es einen jar-Task geben und in dem Task kannst Du mit includes, excludes und filesets arbeiten. Der übliche ant-Task für ein Jar sieht z. B. etwa so aus: 


```
<jar destfile="${dist}/lib/app.jar" basedir="${build}/classes"/>
```
Setzt natürlich voraus, dass Deine Klassen/Ressourcen nach ${build}/classes geschrieben wurden.


----------



## ruutaiokwu (2. Jul 2020)

Warum nicht ANT? Wieder komplett neues Zeugs von Grund auf lernen -> KEINE LUST !!!

War ca. bis heute morgen um 3:00 dran (und um 9:00 wieder bei der Arbeit ;-)) und habe nix entsprechendes gefunden ...na ja, dann ist meine Methode dann wohl doch einfacher. Lassen wir's mal so, vielen Dank.


----------



## ruutaiokwu (2. Jul 2020)

Also excludes habe ich in allen möglichen Varianten "umgedreht", das hat jedenfalls nie geklappt... da war meine Lösung mit C:\windows\temp dann irgendwie doch viiiiiiiiiiiiiiiel schneller. (paar Min. oder so, am "exclude"-Gezeugse hab ich ca. 2 Stunden gebastelt und NULL & NIX erreicht...)


----------



## mihe7 (2. Jul 2020)

jmar83 hat gesagt.:


> Wieder komplett neues Zeugs von Grund auf lernen -> KEINE LUST !!!


Die Zeit, die Du mit ant verschwendest, holst Du Tausendfach mit vernünftigen Buildtools wieder rein. Sofern Dein Projekt nicht wirklich etwas außergewöhnliches macht, ist Maven für meine Begriffe am einfachsten. Damit hast Du praktisch gar keine Arbeit und wird von jeder IDE unterstützt.

Hier mal ein minimalistisches Maven-POM (pom.xml)

```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.javaforum.mihe7</groupId>
    <artifactId>ARTIFACT</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>
    <dependencies>
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>4.12</version>
          <scope>test</scope>
        </dependency>
    </dependencies>
    <properties>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
    </properties>
</project>
```
Der Quellcode liegt unter src\main\java, die Ressourcen unter src\main\resources. Testgedöns entsprechend unter src\test\java bzw. src\test\resources (wenn Du extra Test-Ressourcen hast). Das wars.

Die Artefakte werden durch die groupId, artifactId und version eindeutig beschrieben. Abhängigkeiten werden also einfach über diese "Koordinaten" angegeben. Du musst nichts runterladen, keine Jars verwalten -> macht Maven alles automatisch für Dich. Gradle macht das natürlich auch (apropos: wieso hast Du im Titel build.gradle, wenn Du ant verwendest?!?), ist aber IMO komplizierter zu verwenden als Maven.


----------



## ruutaiokwu (2. Jul 2020)

Vielen Dank, werde es bei Gelegenheit anschauen!

Die Sache mit builld.gradle habe ich erwähnt weil ich gedacht habe man könne es irgendwie ausschalten dass es über redundante Klassen in versch. Libraries keinen Stress macht:

*` b.) gradle.config so konfiguirieren dass es .jar-Dateien mit mehreren gleichen Einträgen mit .class-Files erlaubt. `*


----------



## mihe7 (2. Jul 2020)

jmar83 hat gesagt.:


> werde es bei Gelegenheit anschauen!


Jetzt *ist* die Gelegenheit.


----------



## ruutaiokwu (2. Jul 2020)

OK, das kann ich kaum dementieren!! ;-)


----------



## ruutaiokwu (2. Jul 2020)

Vielen Dank, Problem soweit gelöst, wenn es mit Maven Stress geben wird werde ich mich mit einem neuen Thread melden.


----------

