Ant: Abhängigkeit von einem anderen Projekt, falscher Classpath Eintrag in MANIFEST

DarthShader

Erfahrenes Mitglied
Hallo,

ich versuche gerade, ein build.xml Buildfile für Ant aufzubauen, und stoße auf folgendes Problem:

Die Ausgangssituation ist: ich habe 2 Projekte "ProjA" und "ProjB". B hängt von A ab (A ist im Prinzip nur eine Bibliothek).

Nun geht es um die Build-Datei von "ProjB". Ich baue mir zunächst einmal mein classpath so auf:

Code:
	<path id="classpath">
		<fileset dir="${lib}">
			<include name="**/*.jar" />
		</fileset>

		<fileset dir="../ProjA/dist">
			<include name="ProjA.jar" />
		</fileset>
	</path>

Im 1. Fileset sammle ich alle .jar Dateien im Verzeichnis ProjB/lib. Im 2. Fileset hole ich noch die "ProjA.har" mit an Board, denn ich sagte ja schon, dass ProjB von ProjA abhängt.

Das funktioniert auch so, ProjB kompiliert. Aber nun möchte ich aus ProjB auch eine Jar Datei erstellen, was ich so mache:

Code:
<manifestclasspath property="jar.classpath" jarfile="${dist.file}">
	<classpath refid="classpath"/>
</manifestclasspath>

<jar jarfile="${dist}/${dist.file}" basedir="${build}">
	<manifest>
		<attribute name="Main-Class" value="${main-class}"/>
		<attribute name="Class-Path" value="${jar.classpath}"/>
	</manifest>
</jar>

Was dabei nun aber heraus kommt, speziell beim Classpath in der Manifest Datei, ist mein Problem, denn dort steht (u.A.) nun:

Code:
Class-Path: ../ProjA/dist/ProjA.jar

Im Prinzip hat er natürlich recht, das ist der richtige Ort der ProjA.jar Datei. Was ich aber möchte ist "lib/ProjA.jar", da ProjA.har später sowieso ins ProjB/dist/lib Verzeichnis kopiert wird.

Also wie kriege ich es hin, dass aus "../ProjA/dist/ProjA.jar" das "lib/ProjA.jar" wird?


Oder gehe ich die Sache falsch an?


Vielen Dank für Eure Hilfe!
 
Hmm vielleicht solltest du dir für solche Zwecke mal Maven oder Ivy anschauen.

Man kann ansonsten mit Ant auch ganz gut Pfade umformen:
Code:
<fileset id="lib.files" dir="${deploy}/lib">
                                        <include name="*.jar"/>
                                        <include name="linux/**/*.jar"/>
                                        <include name="windows/**/*.jar"/>
                                </fileset>
                
                <pathconvert pathsep=" " property="jarfiles" refid="lib.files">
                                        <chainedmapper>
                                                <!-- Linux systems need forward slash -->
                                                <regexpmapper from="(.*)[//\\]lib[//\\](.*)"
                                                        to="lib\/\2"/>
                                                <filtermapper>
                                                  <replacestring from="\" to="/"/>
                                                </filtermapper>
                                        </chainedmapper>
                                </pathconvert>
 
Hallo zeja,

danke für Deine Antwort - die Funktionalität mit den regulären Ausdrücken kannte ich noch nicht von Ant.

Ich denke ich würde mit meinem "Problem" auch weiter kommen, wenn es eine Möglichkeit gibt Pfade relativ aus Sicht eines anderen Pfades zu konvertieren. So wird z.B. aus

Code:
dist/lib/test.jar

relativ zum Verzeichnis "dist" wird daraus dann

Code:
lib/test.jar

Gibt es sowas vielleicht als fertiges Ant Task? Ich habe zwar in die Doku geschaut, aber nichts dergleichen gefunden. Falls nicht, muss ich mir sowas ähnliches selbst schreiben oder auf ein gewisses Maß an Automation verzichten :)
 
Zuletzt bearbeitet:
Ich hätte gerade noch eine viel wichtigere Sache, die damit auch zusammenhängt. Ich versuche so die Pfade zu konvertieren (nach Deiner Idee, zeja):

Code:
<pathconvert property="classpath.manifest" refid="classpath">
	<regexpmapper from="^(.*)$$" to="\1"/>
</pathconvert>

Der eigentliche Regex ist hier nur ein Beispiel, er matcht einfach alles und konvertiert es wieder genau zu der originalen Zeichenfolge. Damit sollte das property "classpath.manifest" ja mit den Einträgen aus "classpath" gefüllt werden - habe ich das richtig verstanden?

Nun zu dem Problem. Wenn ich genau danach folgendes mache:

Code:
<manifestclasspath property="jar.classpath" jarfile="${dist.file}">
	<classpath refid="classpath.manifest"/>
</manifestclasspath>

So sagt mir Ant:

Code:
build.xml:102: Reference classpath.manifest not found.

Aber warum kann er "classpath.manifest" nicht finden, obwohl es direkt davor vom "pathconvert" Task gesetzt wird?

Ant raubt mir langsam den letzten Nerv....


Vielen Dank für Eure Hilfe!
 
Hm gut, dann geht das so nicht. Aber langsam wirds ja echt kompliziert, denn den Manifest Task sowie Manifestclasspath Task benutze ich bereits:

Code:
<manifestclasspath property="jar.classpath" jarfile="${dist.file}">
	<classpath refid="classpath"/>
</manifestclasspath>

<jar jarfile="${dist}/${dist.file}" basedir="${build}">
	<manifest>
		<attribute name="Main-Class" value="${main-class}"/>
		<attribute name="Class-Path" value="${classpath.manifest}"/>
	</manifest>
</jar>

"manifestclasspath" nutze ich, um die Dateien im classpath relativ zum release-JAR File (das ich generieren will) zu machen. So stehen im Manifest nachher keine absoluten Pfade, sondern relative, z.B. "lib/project.jar".

Gibt es denn keine Möglichkeit, als Ergebnis eines Pathconverts wieder eine Path-Like Structure zu haben bzw., eine vorhandene direkt zu manipulieren?

Was ich habe ist ein classpath, den möchte ich manipulieren, das dann an den "manifestclasspath" task geben und anschließen als Attribut des "manifest" Tasks setzen. Aber dieses Vorhaben scheint einfach nicht zu gehen.
 
Machs doch halt erstmal so bevor du gar nicht weiterkommst:

XML:
<manifest file="MANIFEST.MF">
    <attribute name="Class-Path" value="${classpath}"/>
</manifest>

Aber wie gesagt ich würde dafür Ant mit Ivy benutzen oder Maven.
 
Zuletzt bearbeitet von einem Moderator:
Ja, ich habe es nun auch etwas "statischer" gemacht, damit ich endlich mal voran komme.

Ich habe mich in die Doku von Ivy schonmal reingelesen, habe aber in Erinnerung, dass ich es ganz schön kompliziert fand. Ich werde es mir aber auf jeden Fall nochmal vornehmen.
 
Zurück