Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.java > #13060 > unrolled thread

Ant an Kompilation hindern?

Back to article view | Back to de.comp.lang.java

Contents

  Ant an Kompilation hindern? ole-usenet-spam@gmx.net (Оlе Ѕtrеісhеr) - 2016-12-20 14:38 +0100
    Re: Ant an Kompilation hindern? Patrick Roemer <sangamon@netcologne.de> - 2016-12-20 17:24 +0100
      Re: Ant an Kompilation hindern? ole-usenet-spam@gmx.net (Оlе Ѕtrеісhеr) - 2016-12-21 13:48 +0100
        Re: Ant an Kompilation hindern? Patrick Roemer <sangamon@netcologne.de> - 2016-12-21 15:44 +0100
          Re: Ant an Kompilation hindern? ole-usenet-spam@gmx.net (Оlе Ѕtrеісhеr) - 2016-12-21 15:52 +0100
            Re: Ant an Kompilation hindern? Patrick Roemer <sangamon@netcologne.de> - 2016-12-21 17:12 +0100

#13060 — Ant an Kompilation hindern?

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

[toc] | [next] | [standalone]

#13061

Responding to Оlе Ѕtrеісhеr:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#13062

Patrick Roemer <sangamon@netcologne.de> writes:
> Responding to Оlе Ѕtrеісhеr:
>> 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.
>
> 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>

> <snip> [...] </snip>

So in etwa.

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

> 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

[toc] | [prev] | [next] | [standalone]

#13063

Responding to Оlе Ѕtrеісhеr:
>> $ 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

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.

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

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

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

[toc] | [prev] | [next] | [standalone]

#13064

Patrick Roemer <sangamon@netcologne.de> writes:
> Responding to Оlе Ѕtrеісhеr:
> 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

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

> 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

[toc] | [prev] | [next] | [standalone]

#13065

Responding to Оlе Ѕtrеісhеr:
> $ javac -version
> javac 1.8.0_111

Oracle oder openjdk?

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

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.java

csiph-web