maven für javaEE projekt

[dermoritz]

hallo zusammen,

ich bin gerade dabei mich in die javaEE-Welt einzuarbeiten. Nun mache ich erste Beispiele anhand des Buches " Beginning Java™ EE 6 Platform with GlassFish™ 3: From Novice to Professional" (APRESS.COM : Beginning Java™ EE 6 Platform with GlassFish™ 3: From Novice to Professional : 9781430219545). Nun geht es um erste Persistenzbeispiele.

Meine Frage dreht sich aber eher um Maven: sobald ich nähmlich ein "@Entity" eintippe heult Eclipse rum - kenn ich nich -logisch. ich muss dem Porjekt ja sagen, dass es ein javaee Projekt ist. Nun gibt es offensichtlich mehrere Wege dies zu tun.
1. externe Jar-Dateien einbinden die JavaEE implementieren (sind die irgendwo im Glassfish order?? -welche Datei(en) wäre(n) das?)
2. in die maven pom.xml direkte Abhängigkeiten eintragen wie : "javax.persistence" (so macht es das Beispiel im Buch)
3. in der pom.xml "properties" eintragen: <glassfish-version>3.0-b70</glassfish-version> So wird es im Beispielcode gemacht den es zum Buch gibt.
4. gibt es noch eine möglichkeit?

Da ich alles schön über Maven abwickeln will fällt Alternative 1 flach,oder? Was die andere Alternativen betrifft: Bei der zweiten Alternative werden die entsprechenden jar's ja runtergeladen. Da ich Glassfish aber schon hab wäre das Blödsinn, oder? Also ist mir die 3. Alternative die liebste - dort wird nix runtergeladen und trotzdem findet er alle "Typen" - eben auch "@Entity". Nur weiß ich nicht genau welche "Properties" ich für JavaEE brauche. Und ich würde auch gern wissen welche Version ich lokal hab, um genau diese einzutragen.
Also wie hängen die ALternativen zusammen, und wie funktioniert insbesondere die 3.?

danke im voraus

 

[maki]

Da ich alles schön über Maven abwickeln will fällt Alternative 1 flach,oder?

Ja.

Was die andere Alternativen betrifft: Bei der zweiten Alternative werden die entsprechenden jar's ja runtergeladen.

Ja.

Da ich Glassfish aber schon hab wäre das Blödsinn, oder?

Nein.
Autom. Build mit eingebautem Dependency Management interessiert sich nicht für das was du runtergeladen hast, muss ja schliesslich auhc bei anderen funktionieren.

Also ist mir die 3. Alternative die liebste - dort wird nix runtergeladen und trotzdem findet er alle "Typen" - eben auch "@Entity".

Falsch, offensichtlich wurden da Properties genutzt um Versionen zu parametrisieren und zentral zu verwalten, ist nicht unüblich, ändert aber nix daran dass die Abhängigkeiten aus einem Repo aufgelöst werden bzw. wie Maven2 arbeitet.

Wenn du es richtig machst hast du nur Punkt 3 und sonst keine Alternativen, Punkt 4 kann man immer nuzten, am besten nur wenn es auch Sinn ergibt.

 

[dermoritz]

vielen dank für die schnelle Antwort,

also reden wir ab jetzt nur noch über ALternative 3 (JavaEE Abhängigkeiten über "Properties"):
mich interessiert z.B. wie die Abhängigkeiten aufgelöst werden. Denn in der Beispiel Anwendung stehen sie in den Properties, andererseits sind die entsprechenden Files aber nicht im lokalen Repository - im Gegensatz zu JUnit welches unter "Dependencies" steht. Also woher holt er sich die JavaEE Dateien? (in der Readme steht, dass man zum kompilieren eine Glassfish-Installation braucht, also er scheint irgendwie auf lokalen kram zuzugreifen?!)
Und die nächste Frage ist welche Version gebe ich an (unter Properties)? Die Versionen die ich lokal installiert hab?

 

[maki]

Zeig doch mal die (alle) POM(s) her bevor du anfängst zu beschreiben was da drinn steht

 

[dermoritz]

Also, die pom(properties und dependencies) vom Beispielcode (für alle Kapitel) sieht so aus:

    <properties>
        <jersey-version>1.1.2-ea</jersey-version>
        <jaxrs-version>1.1-ea</jaxrs-version>
        <xmlunit-version>1.2</xmlunit-version>
        <junit-version>4.7</junit-version>
        <eclipselink-version>2.0.0-M9</eclipselink-version>
        <jaxb-version>2.1.10</jaxb-version>
        <jaxws-version>2.1.5</jaxws-version>
        <glassfish-version>3.0-b70</glassfish-version>
        <grizzly-version>1.8.6.3</grizzly-version>
        <jsf-version>2.0</jsf-version>
        <derby-version>10.5.3.0</derby-version>
        <jsr250-version>1.0</jsr250-version>
        <plugin-jar-version>2.2</plugin-jar-version>
        <plugin-war-version>2.1-alpha-2</plugin-war-version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>${junit-version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

Nun hab ich gerade entdeckt, dass die Éinzelkapitel auch extra Pom's (oder heißt es Pommes? ;-)) haben. Die für Kapitel2 (daran sitze ich gerade) sieht so aus:

<parent>
        <groupId>com.apress.javaee6</groupId>
        <artifactId>chapters</artifactId>
        <version>1.0</version>
    </parent>

    <dependencies>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>javax.persistence</artifactId>
            <version>${eclipselink-version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>eclipselink</artifactId>
            <version>${eclipselink-version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.derby</groupId>
            <artifactId>derbyclient</artifactId>
            <version>${derby-version}</version>
        </dependency>

        <dependency>
            <groupId>org.apache.derby</groupId>
            <artifactId>derby</artifactId>
            <version>${derby-version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

Mit dieser Entdeckung hab ich mir glaubve gerade meine Fragen beantwortet?!: In der "über-poms"(über <parent> referenziert?) stehen die Versionen die in den "unter-poms" per ${...} refenziert werden?
Nun ist die einzige Frage die bleibt: ich würde gerne als Versionen die jetzt aktuellen(die neueste die in irgendeinem Repository verfügbar ist) verwenden. Gibt es dafür irgend ein Automatismus? Oder muss man für alles was man braucht die neueste Version raussuchen?
Was zum Beispiel hilfreich waäre, ist zu wissen welche Versioenen beim installiertem Glassfish dabei sind - per Auto Update kann man den ja au nem neuen Stand halten. (Mir ist bewusst, das man die Veriosnen irgendwann nicht mehr ändern sollte.)

 

[maki]

ich würde gerne als Versionen die jetzt aktuellen(die neueste die in irgendeinem Repository verfügbar ist) verwenden. Gibt es dafür irgend ein Automatismus?

Nein, natürlich nciht.
Beim Dependency Management geht es u.a. darum, dass die Versionen defniert sind, wenn du neuere willst, musst du eben neure Versionen nutzen.

 

[dermoritz]

ok, das heißt praktisch, ich entscheide mich jetzt welche versionen ich voraussetzen will, schreibe diese in die "dependency" und suche dann nach repositories welche diese anbieten.
falls ich kein repository finde oder mir es zu blöd ist zu viele repositories anzugeben kann ich es auch manuell runterladen und zusammen mit einer selbstgestrickten pom in den richtigen ordner legen, oder?

letztendlich würde mich diesbezüglich best-prctices interessieren oder "wie macht ihr das so?". wie findet man zum beispiel repositories für bestimmte artefakte? (auf Welcome to Maven Repository Browser find ich z.b. keine repository für eclipselink)

 

[maki]

Best Practices?

Installiere dir einen Repo manager, wie Nexus oder Artifactory, letzteres ist mein Favourit.

Es ist immer besser vorhandene & gepflegte Dependcies einzusetzen anstatt ales selber & von Hand zu machen, speziell die transitiven Dep. können ganz schön viel arbeit machen.

 

[Noctarius]

Jopp wir nutzen auch einen Nexus als Hosting für unsere eigenen Maven Artifacts, da unser System aus mehr als 10 einzelnen Projekten besteht und auch als Proxy für externe Maven Repositories. Dann wird der Nexus als Standardmirror in der settings.xml hinterlegt.

 

[dermoritz]

ahhh vielen dank .

nun hab ich aber ein neues problem. gestern hatte ich ja junit als abhängigkeit hinzugefügt. das runterladen und auflösen der abhängigkeiten hat auch gut geklappt (kein rotes x in eclipse am test). heute hab eben den block von oben eingefügt und konkrete versionen eingetragen - auch hier hat das runterladen geklappt. Aber aus irgendeinem grund werden nun keinerlei typen mehr aufgelöst - auch junit nicht mehr. in project->properties->java build path ist unter "maven classpath container" auch junit verschwunden. müsste das maven plugin das nicht selbst nachtragen? bzw warum ist junit da verschwunden? hier mal mein derzeitige pom:

<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/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>JavaEEBookChapter02</groupId>
	<artifactId>JavaEEBookChapter02</artifactId>
	<packaging>jar</packaging>
	<version>1.0-SNAPSHOT</version>
	<name>JavaEEBookChapter02</name>
	<url>http://maven.apache.org</url>
	<repositories>
		<repository>
			<id>JBOSS</id>
			<name>JBoss Repository</name>
			<url>http://repository.jboss.org/maven2/</url>
		</repository>
		<repository>
			<id>fht esslingen</id>
			<name>fht esslingen</name>
			<url>http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/rt/eclipselink/maven.repo/</url>
		</repository>
	</repositories>

	<dependencies>

		<dependency>
			<groupId>org.eclipse.persistence</groupId>
			<artifactId>javax.persistence</artifactId>
			<version>2.0.0</version>
			<scope>provided</scope>
		</dependency>
		<dependency>
			<groupId>org.eclipse.persistence</groupId>
			<artifactId>eclipselink</artifactId>
			<version>2.0.1</version>
			<scope>provided</scope>
		</dependency>
		<dependency>
			<groupId>org.apache.derby</groupId>
			<artifactId>derbyclient</artifactId>
			<version>10.5</version>
		</dependency>

		<dependency>
			<groupId>org.apache.derby</groupId>
			<artifactId>derby</artifactId>
			<version>${derby-version}</version>
			<scope>test</scope>
		</dependency>

		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.8.1</version>
			<type>jar</type>
			<scope>test</scope>
			<optional>false</optional>
		</dependency>

	</dependencies>

</project>

und wie gesagt die entsprechenden dateien wurden runtergeladen und liegen im lokalen repository. was beduetet eigentlich scope: "provided"?

 

[Noctarius]

Wo hast du denn [c]<derby.version>[/c] definiert? und gibt es eine 4.8.1 von junit?

 

[maki]

Wo hast du denn [c]<derby.version>[/c] definiert? und gibt es eine 4.8.1 von junit?

AFAIK gibt es im Moment nur die 4.7 im Repo1.

 

[Noctarius]

AFAIK gibt es im Moment nur die 4.7 im Repo1.

Deswegen frag ich ja. Die 4.7 nutz ich nämlich auch mit Spring

 

[byte]

provided heisst, dass sie nicht im Build auftauchen. Zum Beispiel: javax.servlet API, die braucht man als Abhängigkeit, um Compilerfehler zu verhindern, muss aber nicht mit ins Build, da es schon im Webcontainer (z.B. Tomcat) vorhanden ist.

 

[dermoritz]

das mit derby version war schon gefixt - es steht 10.5 drinne. und was die verionsen angeht: im jboss repository ist 4.8.1 vorhanden. es ist auch lokal nun vorhanden. wie gesagt die runterladerei ist im moment nicht das problem, sondern das auflösen der abhängigkeiten?!
und das ist eben komisch, weil es für junit(4.8.1) schon funktioniert hat. theoretisch kann es ja nur am pom oder am maven plugin(IAM) liegen oder?
zur not mach ich wieder ein neues projekt und schaue ab wann es hakt.

edit was mir gerade auffällt(nachdem ich ein weiteres maven projekt erstellt habe): nun moniert maven die pom datei - er könne derby 10.5 nicht auflösen (er findet es nicht). das problem werd ich in den griff kriegen, aber wie bringe ich das maven plugin dazu sowas erneut zu überprüfen? also gibt es sowas we "rebuild" oder "clean" für das maven projekt - also das ich aktuelle errors von maven sehe.

 

[maki]

zur not mach ich wieder ein neues projekt und schaue ab wann es hakt.

Sieh doch einfach im lokalen Repo nach welche JUnit Versionen da liegen.

 

[dermoritz]

wie gesagt ich weiß das alles korrekt runtergeldaen wurde, weil ich dort nachgeschaut habe (deswegen hab ich auch das jboss repository drinne).

nun hab ich aber das problem gefunden: Die derby version darf nicht "10.5" lauten, sondern "10.5.3.0". nun geht alles!
ich frag mich nur wieso er wegen der falschen versionsnummer bei derby, java persistence geschichten wie "@entity" nicht auflösen kann?
ich hab ja 2x derby drinne einmal als "test" und einmal ohne scope (macht das eigentlich sinn?): als ich die version ohne scope korrigierte verschwand der maven fehler, aber alle java fehler blieben. als ich dann die zweite version von derby (scope =test) korrigierte verschwanden alle fehler!
was mich interessiert: liegt das am maven eclipse plugin, dass die fehlermelderei "komisch" ist?(der maven fehler hätte doch die ganze zeit da sein sollen - solange nicht alle versionen korrekt sind und die dinge im lokalen repository vorliegen?!)

 

[dermoritz]

ganz andere frage (eventuell ein neuer thread wert?):

wie starte/kompiliere ich ein maven projekt aus eclipse heraus? ich kann eine neue maven2 run configuration anlegen und das projekt wählen. nur was trage ich bei "goal" ein?
oder starte ich einfach als "java appplication"?

 

[byte]

- Leg eine Maven Run Configuration an.
- Gib den Pfad zum Projekt an, wo die POM drin liegt
- Gib das Goal an, z.B. "compile", "clean compile", "package" oder "tomcat:run" (siehe Maven Doku)
- Drücke Run

 

[dermoritz]

aber das "run" klicken führt dann eben nur das "compile" aus oder? das heißt wenn ich das ganze starten möchte nehme ich z.b. run as java app? (so hab ich es gerade gemacht)

 

[byte]

Was meinst Du denn mit "das ganze starten"? Willst Du eine Main Methode ausführen?

Das kannst Du prinzipiell einfach mit der IDE machen (run as java app). Dann wird aber vorher nix gebuildet. Wenn Du den Maven Build testen willst, dann mach ein "package" und führe das erzeugte Jar aus.