# [MAVEN2] Wo Saple-code zur Lib platzieren?



## tuxedo (10. Okt 2009)

Hallo,

mein SIMON Projekt basiert mittlerweile auf Maven2. Ich möchte nun Beispielprogrämmchen da mit aufnehmen. Am besten so, dass diese als einzelnes Artefakt aus dem Buildprozess rausfallen. 

In der Doku zu Maven2 hab ich gefunden:



			
				http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html hat gesagt.:
			
		

> The src directory contains all of the source material for building the project, its site and so on. It contains a subdirectory for each type: main for the main build artifact, test for the unit test code and resources, site and so on.



Soweit so gut. Das klingt danach als ob ich am besten parallel zu 

src/main
src/test

auch noch ein 

src/samples

anlege. Steh aber gerade etwas auf dem Schlauch was das triggern des Builds für diese Samples angeht... Kann mich jemand in die richtige Richtung deuten? Wie/wo muss ich da das POM anpassen?

Gruß
Alex

[update]

Wenn ich src/samples anlege dann klappt das auch mit Netbeans2 nicht... Da kann ich nur einen "Source Folder" und einen "Test Source Folder" angeben. Da ist kein Platz für einen dritten Source-Ast ....?!


----------



## maki (10. Okt 2009)

> Da ist kein Platz für einen dritten Source-Ast ....?!


Richtig, war so auch nicht gemeint 

src/main/java
src/main/resources
src/main/groovy
src/test/java
usw.

Kein Platz für Samples 

Samples kannst du als eigenes Modul unterbringen, beim Directorylayout geht es darum, wo welche Dateien zu finden sind die für den Build wichtig sind.
Einen Archetype zu schreiben (sowas wie ein Template) das auch noch Samples beinhaltet wäre natürlich die eleganteste Lösung.


----------



## tuxedo (10. Okt 2009)

Hmm, sowas hab ich mir schon fast gedacht. 

hab zwischenzeitlich das hier gefunden:

Maven &amp; multiple source trees | Java.net

So ganz "gefallen" tuts mir aber noch nicht. 

Werde vielleicht doch ein extra Project dafür starten...Dann hätten andere auch gleich ein super Beispiel wie man meine Lib in Verbindung mit Maven benutzt...


----------



## kama (11. Okt 2009)

Hallo,



tuxedo hat gesagt.:


> Maven &amp; multiple source trees | Java.net


Das bezieht sich auf Maven 1 und nicht auf Maven 2. Der Vorschlag der gemacht wurden, Samples als eigenes Module zu machen war der Richtige und beste. Damit wird auch dein Produktiver Code vom Sample Code getrennt und Du must für Samples tatsächlich auch Deinen eigenen Code Nutzen (Eat Your Own Dog Food)...

MfG
Karl Heinz Marbaise


----------



## tuxedo (12. Okt 2009)

Nur damit ich da jetzt keinem Irrtum anheim falle:



> Samples als eigenes Module zu machen war der Richtige und beste.



"Eigenes Module" ... Damit meinst du ein eigenes Maven2 Projekt (eigenes pom file etc..) das als Dependency meine Library braucht? 
Oder ist das ein Maven2 Feature das ich noch nicht kenne?

- Alex


----------



## byte (12. Okt 2009)

tuxedo hat gesagt.:


> Nur damit ich da jetzt keinem Irrtum anheim falle:
> 
> 
> 
> ...



Letzteres.  Du kannst mit Maven2 ein Artefakt als Modul definieren. Dadurch hast Du dann eine Parent - Child Struktur in Deinen Artefakten. Wenn Du dann ein Build auf den Parent machst, werden automatisch alle (Child) Module mit gebuildet.

Ich weiss allerdings nicht, ob ich das in diesem Fall so machen würde. Das würde ja bedeuten, dass die eigentliche Lib in der POM auf das Samples Modul verweist. Dadurch ist die Lib an die Samples gebunden. Ist doch unschön!?

Ich würde einfach ein Samples Artefakt anlegen und das Lib Artefakt dann als Dependancy reinnehmen.


----------



## maki (12. Okt 2009)

byte hat gesagt.:


> Letzteres.  Du kannst mit Maven2 ein Artefakt als Modul definieren. Dadurch hast Du dann eine Parent - Child Struktur in Deinen Artefakten. Wenn Du dann ein Build auf den Parent machst, werden automatisch alle (Child) Module mit gebuildet.
> 
> Ich weiss allerdings nicht, ob ich das in diesem Fall so machen würde. Das würde ja bedeuten, dass die eigentliche Lib in der POM auf das Samples Modul verweist. Dadurch ist die Lib an die Samples gebunden. Ist doch unschön!?
> 
> Ich würde einfach ein Samples Artefakt anlegen und das Lib Artefakt dann als Dependancy reinnehmen.


Maven unterstützt sowohl Komposition (ein Projekt besteht aus mehreren Modulen) als  auch Vererbung( Project B erbt von Projekt A) sowie die Kombination von beidem 
Richtig eingesetzt vermeiden sie Probleme wie von dir beschrieben.

Dann kann man auch noch festlegen, dass ein Modul nur unter bestimmten Umständen Teil eines Projektes ist (am besten per Profile steuern), nützlich wenn man zB. die Integrationstests in einem eigenen Modul hat und nicht immer ausführen will.

Für den konkreten Fall:
- SIMON Parent Project
-- SIMON core
-- SIMON Samples

SIMON Parent besteht aus core & Samples.
core erbt vom Parent, Samples erbt auch von Parent.
Samples referenzeiert core als Dependency.


----------



## tuxedo (12. Okt 2009)

Danke für die vielen Hinweise und Ratschläge. Werd' mich wohl nochmal durch die Maven2 Doku kämpfen müssen ;-)

- Alex


----------



## maki (12. Okt 2009)

Kann ich empfehlen:
http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf

Vielleicht gibt es irgendwo noch eine aktuellere Version...


----------



## tuxedo (17. Okt 2009)

So, Komposition und Aggregation mit Maven2 hab ich mir nun angesehen. In beiden Fällen ist mein "Parent" vom Packaging-Typ "pom" und kann somit keinen Source enthalten. Demnach müsste ich sowohl meinen eigentliche Lib, als auch die Samples zu einem Modul des Gesamtprojekts machen (siehe maki's "Skizze")

Korrigiert mich wenn ich falsch liege...

Gefallen tut mir das alles nicht. Ich werde jetzt wohl tatsächlich zwei einzelne Projekte benutzen.

Projekt 1: Das Simon-Projekt das am ende eine JAR auswirft und für sich alleine stehen kann.
Projekt 2: Das Simon-Samples Projekt das prinzipiell auch für sich steht, also kein Modul von irgendwas ist, aber als Dependency das Projekt1 drin stehen hat damit man die Samples bauen kann.

Hat gleich den Vorteil dass das Samples-Projekt als "Muster" genommen werden kann um ein eigenes Projekt, basierend auf SIMON aufzubauen....

Komposition und Aggregation scheinen hierfür nicht geeignet zu sein. Wenn Simon jetzt aus 2 oder mehr Einzelmodulen bestehen würde welche für den Gesamtbetrieb notwendig wären, dann würde das wohl Sinn ergeben es so zu machen. 

@maki: Danke für den Link. Habs gleich zu den anderen wichtigen Dokus gelegt ...


----------

