Ant an Kompilation hindern?

[Оlе Ѕtrеісhеr]

Hallo,

ich habe einen Quelltextbaum, den ich nur teilweise kompilieren
möchte. Der Rest steht als jar-Archiv zur Verfügung. Etwa so:

my/path/p1/C1.java
my/path/p2/C2.java

und ein jar, ds C2.class enthält. Im Ant-Target have ich entsprechend
auch nur C1.java als "includes" eingetragen.

Wenn C1 aber C2 importiert, dann wird auch C2 neu kompiliert (was nicht
funktioniert, weil es eine Änderung benötigen würde). Wie kann ich
erreichen, dass C2 unbedingt aus dem jar genommen und nicht neu
kompiliert wird, ohne dass ich C2.java lösche? Es hilft jedenfalls
nichts, es in "excludes" einzutragen.

Schöne Grüße

Ole

[Patrick Roemer]

Post by Оlе Ѕtrеісhеr
ich habe einen Quelltextbaum, den ich nur teilweise kompilieren
my/path/p1/C1.java
my/path/p2/C2.java
und ein jar, ds C2.class enthält. Im Ant-Target have ich entsprechend
auch nur C1.java als "includes" eingetragen.
Wenn C1 aber C2 importiert, dann wird auch C2 neu kompiliert (was nicht
funktioniert, weil es eine Änderung benötigen würde). Wie kann ich
erreichen, dass C2 unbedingt aus dem jar genommen und nicht neu
kompiliert wird, ohne dass ich C2.java lösche? Es hilft jedenfalls
nichts, es in "excludes" einzutragen.

Der exakte Text Deines Targets wäre hier sinnvoll gewesen.

<snip>
$ tree
.
├── bin
├── build.xml
├── lib
│ └── foo.jar
└── src
├── bar
│ └── C2.java
└── foo
└── C1.java

5 directories, 4 files
$ cat src/foo/C1.java
package foo;

public class C1 {}
$ cat src/bar/C2.java
package bar;

import foo.C1;

public class C2 {}
$ jar tf lib/foo.jar
META-INF/
META-INF/MANIFEST.MF
foo/
foo/C1.class
$ cat build.xml
<project name="foobar" default="cmp" basedir=".">

<target name="cmp">
<javac
srcdir="src"
destdir="bin"
excludes="foo/C1.java"
classpath="lib/foo.jar"
includeantruntime="false"
/>
</target>

</project>
$ ant
Buildfile: /home/patrick/test/java/antexcl/build.xml

cmp:
[javac] Compiling 1 source file to /home/patrick/test/java/antexcl/bin

BUILD SUCCESSFUL
Total time: 0 seconds
$ tree bin/
bin/
└── bar
└── C2.class

1 directory, 1 file
</snip>

Etwa so?

Einen in sich inkonsistenten Sourcebaum halte ich allerdings für eine
äußerst schlechte Idee.

Viele Grüße,
Patrick

[Оlе Ѕtrеісhеr]

Post by Patrick Roemer

Post by Оlе Ѕtrеісhеr
ich habe einen Quelltextbaum, den ich nur teilweise kompilieren
my/path/p1/C1.java
my/path/p2/C2.java
und ein jar, ds C2.class enthält. Im Ant-Target have ich entsprechend
auch nur C1.java als "includes" eingetragen.
Wenn C1 aber C2 importiert, dann wird auch C2 neu kompiliert (was nicht
funktioniert, weil es eine Änderung benötigen würde). Wie kann ich
erreichen, dass C2 unbedingt aus dem jar genommen und nicht neu
kompiliert wird, ohne dass ich C2.java lösche? Es hilft jedenfalls
nichts, es in "excludes" einzutragen.

Der exakte Text Deines Targets wäre hier sinnvoll gewesen.

Kein Problem, es macht die Sache nur etwas komplexer:

<target name="build">
<mkdir dir="${classes.dir}"/>
<javac srcdir="${java.dir}"
includes="uk/ac/starlink/soap/**/*.java uk/ac/starlink/task/**/*.java uk/ac/starlink/ttools/**/*.java uk/ac/starlink/vo/**/*.java uk/ac/starlink/array/Type.java uk/ac/starlink/util/gui/*.java"
excludes="uk/ac/starlink/table/**/*.java" <!-- die will ich nicht compilieren -->
destdir="${classes.dir}"
includeantruntime="false"
debug="${debug}"
deprecation="${deprecation}"
optimize="${optimize}"
encoding="cp1252">

<classpath>
<fileset dir="/usr/share/java">
<include name="jel.jar"/>
<include name="stil.jar"/> <!-- Hier sind die Klassen drin -->
<include name="jlatexmath.jar"/>
<!-- hier folgen noch ein dutzend weitere -->
</fileset>
</classpath>
</javac>
</target>

Post by Patrick Roemer
<snip> [...] </snip>

So in etwa.

Post by Patrick Roemer
$ tree bin/
bin/
└── bar
└── C2.class
1 directory, 1 file
</snip>
Etwa so?

Ich bekomme hier:
$ ls -lR bin/

bin/:
insgesamt 8
drwxr-xr-x 2 ole ole 4096 Dez 21 13:37 bar
drwxr-xr-x 2 ole ole 4096 Dez 21 13:37 foo

bin/bar:
insgesamt 4
-rw-r--r-- 1 ole ole 121 Dez 21 13:37 C2.class

bin/foo:
insgesamt 4
-rw-r--r-- 1 ole ole 121 Dez 21 13:37 C1.class

Post by Patrick Roemer
Einen in sich inkonsistenten Sourcebaum halte ich allerdings für eine
äußerst schlechte Idee.

Er ist ja nicht inkonsistent.

Erklärung: Ich brauche das, um Debian-Pakete zu bauen. Dazu ist es
nötig, dass einige Dateien angepasst werden; u.a. weil bestimmte
Abhängigkeiten in Debian nicht verfügbar sind. Diese Anpassungen
betreffen im vorliegenden Fall C1, das ich aber schon als eigenes Paket
pflege. In dem anderen Paket ist die Datei aber enthalten, weil der
Autor (von beiden Dateien) gerne möchte, dass man C2 auch kompilieren
kann, wenn man sich nicht vorher das andere Jar-File gebaut hat. In
Debian möchte ich dagegen keine Code-Kopien verwalten, sondern die
benötigten Klassen über Abhängigkeiten einbinden.

Ein Grund hier ist, dass ich die genannten nötigen Änderungen nur an
einer Stelle pflegen möchte -- bei C1. Daher lautet meine Aufgabe:
Kompiliere C2, ohne dass die Convenience Copy C1 mitkompiliert wird (was
zu einer Fehlermeldung führen würde).

Und erstaunlicherweise scheint es bei Dir zu klappen, bei mir jedoch
nicht.

Woran könnte das liegen? Wie kann ich Ant dazu bringen, lieber einen
Fehler zu melden als eine nicht in "includes" spezifizierte Datei zu
kompilieren?

Schöne Grüße

Ole

[Patrick Roemer]

Post by Оlе Ѕtrеісhеr

Post by Patrick Roemer
$ tree bin/
bin/
└── bar
└── C2.class
1 directory, 1 file
</snip>
Etwa so?

$ ls -lR bin/
insgesamt 8
drwxr-xr-x 2 ole ole 4096 Dez 21 13:37 bar
drwxr-xr-x 2 ole ole 4096 Dez 21 13:37 foo
insgesamt 4
-rw-r--r-- 1 ole ole 121 Dez 21 13:37 C2.class
insgesamt 4
-rw-r--r-- 1 ole ole 121 Dez 21 13:37 C1.class

Wenn wir dasselbe Buildscript mit unterschiedlichen Ergebnissen laufen
lassen, liegt die Vermutung nahe, dass es an unterschiedlichen
Toolversionen/-varianten liegt. Ich habe hier

java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)

und

Apache Ant(TM) version 1.9.5 compiled on May 31 2015

Wie schaut das bei Dir aus?

Vielleicht sollte man erst mal lokalisieren, ob es an Ant oder javac
liegt...

<snip>
$ rm -r bin/*
$ javac -sourcepath src -d bin src/bar/C2.java
$ tree bin/
bin/
├── bar
│ └── C2.class
└── foo
└── C1.class

2 directories, 2 files
$ rm -r bin/*
$ javac -sourcepath src -d bin -classpath lib/foo.jar src/bar/C2.java
$ tree bin/
bin/
└── bar
└── C2.class

1 directory, 1 file
</snip>

Bekommst Du die gleichen Ergebnisse? Falls ja, ant vielleicht mal mit
"-v" laufen lassen, um den javac-Aufruf zu sehen.

Post by Оlе Ѕtrеісhеr

Post by Patrick Roemer
Einen in sich inkonsistenten Sourcebaum halte ich allerdings für eine
äußerst schlechte Idee.

Er ist ja nicht inkonsistent.

Wenn das Compilieren dieses Sourcetrees zu Fehlern führt, dann schon
irgendwie. :)

Post by Оlе Ѕtrеісhеr
Erklärung: Ich brauche das, um Debian-Pakete zu bauen. Dazu ist es
nötig, dass einige Dateien angepasst werden; u.a. weil bestimmte
Abhängigkeiten in Debian nicht verfügbar sind. Diese Anpassungen
betreffen im vorliegenden Fall C1, das ich aber schon als eigenes Paket
pflege. In dem anderen Paket ist die Datei aber enthalten, weil der
Autor (von beiden Dateien) gerne möchte, dass man C2 auch kompilieren
kann, wenn man sich nicht vorher das andere Jar-File gebaut hat. In
Debian möchte ich dagegen keine Code-Kopien verwalten, sondern die
benötigten Klassen über Abhängigkeiten einbinden.
Ein Grund hier ist, dass ich die genannten nötigen Änderungen nur an
Kompiliere C2, ohne dass die Convenience Copy C1 mitkompiliert wird (was
zu einer Fehlermeldung führen würde).

Verstehe. Finde ich immer noch herzlich unschön, aber dann liegt die
"äußerst schlechte Idee" eher beim Autor, und Du darfst den
Kollateralschaden verwalten...

Viele Grüße,
Patrick

[Оlе Ѕtrеісhеr]

Post by Patrick Roemer
Wenn wir dasselbe Buildscript mit unterschiedlichen Ergebnissen laufen
lassen, liegt die Vermutung nahe, dass es an unterschiedlichen
Toolversionen/-varianten liegt. Ich habe hier
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)
und
Apache Ant(TM) version 1.9.5 compiled on May 31 2015
Wie schaut das bei Dir aus?

$ ant -version
Apache Ant(TM) version 1.9.7 compiled on May 16 2016
$ javac -version
javac 1.8.0_111

Post by Patrick Roemer
$ javac -sourcepath src -d bin -classpath lib/foo.jar src/bar/C2.java
$ tree bin/
bin/
└── bar
└── C2.class
1 directory, 1 file

Da bekomme ich beide kompiliert.

Post by Patrick Roemer
Verstehe. Finde ich immer noch herzlich unschön, aber dann liegt die
"äußerst schlechte Idee" eher beim Autor, und Du darfst den
Kollateralschaden verwalten...

Nö; der will halt eigentlich ein vollständiges Paket anbieten. Ich will
dagegen saubere Abhängigkeiten. Wir haben einfach verschiedene
Prioritäten.

Ole

[Patrick Roemer]

Post by Оlе Ѕtrеісhеr
$ javac -version
javac 1.8.0_111

Oracle oder openjdk?

Post by Оlе Ѕtrеісhеr

Post by Patrick Roemer
$ javac -sourcepath src -d bin -classpath lib/foo.jar src/bar/C2.java
$ tree bin/
bin/
└── bar
└── C2.class
1 directory, 1 file

Da bekomme ich beide kompiliert.

Naiv hätte ich jetzt gesagt, dann liegt's vielleicht an Oracle vs
openjdk - aber ich habe gerade mal spaßeshalber openjdk-8-jdk
installiert, und damit bekomme ich dasselbe Verhalten wie mit Oracle.

Damit fiele mir als Erklärung eigentlich nur noch ein, dass irgendwas
mit Deinem jar komisch ist und C1 daher nicht von dort aufgelöst werden
kann.

Probier's mal mit "javac -verbose". Da sollte man dann eigentlich sehen,
dass er C1 aus dem jar holt:

<snip>
$ javac -verbose -sourcepath src -d bin -classpath lib/foo.jar
src/bar/C2.java
[parsing started RegularFileObject[src/bar/C2.java]]
[parsing completed 15ms]
[search path for source files: src]
[search path for class files: ...,lib/foo.jar]
[loading ZipFileIndexFileObject[lib/foo.jar(foo/C1.class)]]
[...]
[wrote RegularFileObject[bin/bar/C2.class]]
[total 160ms]
</snip>

Viele Grüße,
Patrick