Maven eclipse:eclipse - neuen sourcefolder angeben

[reibi]

Hallo

Habe beim MavenDokuLesen festgestellt, dass man die Konfiguration eines Projektes unter "src/main/config" ablegen kann; und zwar hier:

Maven - Introduction to the Standard Directory Layout

Wenn ich nun aber "mvn eclipse:eclipse" aufrufe, dann macht er mir zwar aus dem "src/main/resources" ein SRC-Folder aber aus "src/main/config" leider nicht! --- hierbei handelt es sich ganz offensichtlich um einen Bug im mvn-plugin für eclipse.


Gibt es eine Möglichkeit, im pom festzulegen, welches Verzeichnis ein SRC-Folder sein soll?

Dann könnte man das nämlich selber so eintragen und nicht bei jedem Aufruf von "mvn eclipse:eclipse" dem SRC-Folder selber wieder hinzufügen, weil er ihn automatisch rausschmeisst.

Grüsslinger ;-)

 

[maki]

src/main/config ist kein Source Folder imho

 

[reibi]

Sollte aber in eclipse sein... sonst kann man nämlich keine Konfiguration über Classpath laden.

 

[maki]

Config sollte imho nur ressourcen enthalten die dann explizit kopiert werden, also kein Source folder.

 

[reibi]

Alles was in Config steht, wird explizit nicht mit gebuildet... deshalb

 

[maki]

Eben, weil es KEIN Sourcefolder ist.

Wir drehen uns hier im Kreis, merkst du das?

 

[reibi]

Dann mach doch mal n Beispiel für was der sonst gut sein sollte

 

[maki]

Um mich selber zu zitieren:

Config sollte imho nur ressourcen enthalten die dann explizit kopiert werden, also kein Source folder.

 

[reibi]

Hi Maki

Also resourcen sollen doch in das "resources" deshalb heisst es ja auch so. In Config sollen Konfigurationen. Maven buildet diese explizit nicht mit ein. ziel der übung soll sein, dass Du ungebunden die Konfiguration ändern kannst und wenn der Artifakt n jar-file ist dann sollst Du deine Konfiguration in nem extra verzeichnis bearbeiten können. Wenn die Konfig in das jarfile mit reingebuildet würde, könnte niemand sie anpassen.

 

[maki]

Reibi,

ich sagte dir doch bereits das src/main/config nit im Classpath ist.
Ich sagte dir auch, dass da Ressourcen reinkommen die Explizit kopiert werden (resources plugin, am besten in einem Profil).

Du brauchst offensichtlich weder Ressourcen noch Configs, sondern ein neues Artifakt, womöglich mit eigenem classifier (siehe dazu das build helper plugin), denn es soll ja nicht ins Jar... oder du lässt deine App selber eine Standard konfig schreiben, die dann vom user geändert werden kann, fertig.

 

[reibi]

Hi Maki

warum heisst es dann "config" und warum steht auf dieser Seite:
Maven - Introduction to the Standard Directory Layout

das hier:

src/main/config Configuration files


?

 

[maki]

Weil da Konfigurationsdateien drinn stehen... was aber nicht unbedingt dasselbe ist wie deine Konfigdateien...

 

[reibi]

Und Maki, für was sind Konfigurationen da? Zum anpassen, oder? Wenn ich diese mit ins Artifakt builden würde, dann könnte ich sie ja nicht mehr anpasssen. richtig?
Deshalb buidet man sie auch nicht mit ins Artifakt. Wenn eine Konfiguration nötig ist, dann ist die ausserhalb des Artifakts abzulegen ... richtig?

Meiner Meinung, also ich interpretiere die Seite(von Maven) so, dass die Konfigs dort gehöstet werden sollen.

Gruss

 

[maki]

reibi,

k.A worauf du hinaus willst, ich erkläre dir nur wie das funktioniert, wenn du das anders siehst, ist das ok, aber für mich macht es wenig Sinn so eine Diskussion zu führen, denn ich habe deine Probleme nicht

Wenn du die Sache anders siehst/interpretierst, dann mach es doch wie du meinst dass es stimmt.
Für mich ist so eine Diskussion nur unsinnig & Zeitverschwendung..

 

[reibi]

maki,

das diese disko nicht ausartet, möchte ich erst mal was klarstellen: Ich bin "bei meinen Problemen" immer für Deine Lösungen super dankbar. Vorallem weil Du immer Service bist und ich Konsument ;-) Und wenn man mal aneinander vorbeiredet ist das kein Grund eingeschnappt zu sein oder bei Eskalation sich schriftlich anzuschreien .. ja ;-)

Also: Dann nochmal anders: Wohin mit meinen Konfigurationen, wenn sie nicht ins Artifakt gebuildet werden sollen?

 

[maki]

Du hast ja nicht unrecht reibi, aber es ist nicht mein Fehler

Der Fehler: Laut Maven Doku ist der src/main/config Ordner für Konfigurationen gedacht.
Mehr steht da leider nicht, es gibt weder Hinweise wie der zu benutzen ist, noch Plugins die ihn nutzen.
So wie es für mich aussieht, hat man damals festgelegt, der Ordner wäre für Configs zu nutzen, aber dann vergessen, ihn wirklich auch zu nutzen ...
Wenn jemand etwas anderes weiss bitte melden
Ich hab den nur so verwendet: Das Ressource Plugin kopiert je nach Profil andere Konfigurationen aus src/main/config zu den anderen Ressourcen (target/classes bzw. target/test-classes)

Zu deinem Problem:
Maven geht ja per default von einem einzigen Artifakt (Jar, War, etc. pp.) pro Pom aus, fertig.
Man braucht aber manchmal mehrere(sourcen, javadocs, eigene, etc. pp.), das kann man mittlerweile per buid-helper-plugin steuern, die Artifakte werden per classifier unterschieden.

Du könntest:
- 2 zus. Modul Lösung: ein eigenes Modul nur für die Konfig machen, dann in einem eigenen Assembler Modul deine Jar + Config Datei zu einem Zip zusammenbauen

- 1 zus. Modul Lösung: in deinem jetzigen Modul das Build-helper-plugin nutzen, um die Konfig als zus. Artifakt ins Repo zu werfen, dann in einem eigenen Assembler Modul deiner Jar + Config zu einem Zip zusammenbauen

- 0 zus. Modul Lösung: Deine App kopiert selber eine default Config beim ersten starten dorthin, wo du die Config brauchst

Ich sehe jetzt keine weiteren sinnvollen Lösungen, aber vielleciht weiss jemand anders mehr (kama? Noctarius? fancy? etc.pp.?)

Nix für ungut reibi, bin manchmal nervös vor Zahnartzt Terminen

 

[reibi]

Werd morgen drauf antworten.
Alles Gute beim ZA. is hoffentlich ne Zahnärtztin, schick und kompetent gleichzeitig ;-)

 

[maki]

Das mit dem ZA hatte ich schon hinter mir bei meinem letzten Post
Hübsche Assistentinnen, glaube aber nicht dass die sich für Typen mit einem Amalgamgebiss interessieren :lol:

 

[reibi]

Hi Maki

"Konvention über Konfiguration" das ist die Devise; daran will ich mich auch halten. Ich bin immer, grundsätzlich angehalten eine "saubere Lösung" zu bauen. Ich erwarte von anderen auch saubere Lösungen, da nur diese zu lesen sind.

Die Komplexität is n ganz anderes Thema. Ohne Zweifel muss man aber sagen, das Maven die Arbeit zwar erleichtert aber auch ein viel fortgeschritteneres Grundverständnis verlangt.

Die Komplexität gering zu halten sollte also auch auch Priorität haben. Bei hat es das!

Deshalb:
//erstmal Danke für die 3 Vorschläge ;-) aber:

1+2. Lös) Die Configuration in ein eigenes Modul zu packen ist zwar möglich, meinetwegen auch sauber, aber für mich etwas zu komplex... vor allem wenn ein projekt soieso schon aus 40 Artifakten besteht, wovon 20 selber gebaut sind und diese 20 noch weitere 20 bekommen sollen und Konfigurationen abzubilden.

Das ist mir zu komplex!
Will damit aber nicht sagen, das es ein schlechter Lösungsansatz ist, für kleinere Projekte bestimmt.

3. Lös) Versteh ich auch, is für mich aber auch keine Option, weil:
Manchmal hat man Artifakte als Implementation einer API-Spezifikation. Diese Artifakte sind dann austauschbar.(Beispiel JDBC-Treiber ... nur in einener Anwendung). Wenn diese Artifakte selber Configurationen schreiben, bin ich nur noch am konfigurieren.


Mal n anderer Ansatz, Mihc würde Deine Meinung zu dem Ansatz auf jeden Fall interessssieren:

Ich packe meine Konfigurationsdateien nicht in ein package namens "conf" sondern in ein Verzeichnis namens "conf".

Damit Du weisst wie male ich das schnell mal auf:

Also nicht so:
my-artifact/src/main/resources/conf/my.config

Sondern so:
my-artifact/conf/my.config

Dann ziehe ich meine Konfiguration zwar nicht mehr über den Klassenpfad an sondern so:

myProperties.load(new FileInputStream(new File("conf/my.conf")));

--> hätte aber den Vorteil, dass es zum einen von Eclipse aus angezogen würde und zum zweiten, dass es mir nicht mit ins JAR_File gebunden würde.

verstehste?

Das allereinzigste Problem was ich dann noch hätte wäre:

Artifakt 1: main-prj
Artifakt 2: lib-prj

Wenn ich mein "lib-prj" vom "main-prj" aufrufe, dann müsste die configuratin im "conf"-verzeichnis des "main-prj"s rumliegen.


So... lange erklärung... vielleicht kannste dazu kurz n ein oder mehrzeiler hinterlassen..

Grüssli reibsen ;-)

 

[maki]

Ich packe meine Konfigurationsdateien nicht in ein package namens "conf" sondern in ein Verzeichnis namens "conf".

Damit Du weisst wie male ich das schnell mal auf:

Also nicht so:
my-artifact/src/main/resources/conf/my.config

Sondern so:
my-artifact/conf/my.config

Dann ziehe ich meine Konfiguration zwar nicht mehr über den Klassenpfad an sondern so:

myProperties.load(new FileInputStream(new File("conf/my.conf")));

--> hätte aber den Vorteil, dass es zum einen von Eclipse aus angezogen würde und zum zweiten, dass es mir nicht mit ins JAR_File gebunden würde.

Persönlich finde ich das gar nicht gut, verstösst gegen die Konventionen, da kannst du auch gleich src/main/config nehmen, ausserdem funzt dass doch nur in deiner IDE, zielist aber dass es auch nur mit Maven2 funzt.

Erklre doch mal, welche module sollen die Config nutzen können?
Nur main-prj?

 

[reibi]

Erklre doch mal, welche module sollen die Config nutzen können?
Nur main-prj?

Also die Konfiguration gehört ja zu "lib-prj". Wenn ich mein Testprogramm von "lib-prj" benutze, dann natürlich der Artifakt(das Modul selbst). Benutzt "main-prj", dann braucht man diese Konfig ja auch, weil das "main-prj" ja diesen Artifakt anzieht.

Stell Dir mal vor Du hättest Apache-Derby gebaut(.. doch mach mal! ..). Dann hättest Du ein Artifakt welches heisst "derby-connector-1-0-1". Dieser will eine Connection haben zB diese "jdbc:derby://localhost:1527/derbyDB". diese speicherst Du für Deinen unitTest des Artifakts in einen Configfile ab. Das Configfile heisst.: "db.properties".

1.) Wenn Du Dein "derby-connector-1-0-1" testen willst, wird diese Config angezogen.

2.) Wenn Du einen zweiten Artifakt hast, ganz unabhängig von Deiner DB-Entwicklung, dann ziehst Du einfach den "derby-connector-1-0-1" an. Dann muss Dein "main-prj" diese Info haben um sie in den "derby-connector-1-0-1" zu injecten ;-)

GENERELL.) Dein "main-prj" is natürlich so gebaut, dass es die DB austauschen kann. Dann zieht es einfach den Artifakt "mysql-connector an".

Weste wie? ;-)

Der KLUE is nun(DAS IS ne wichtige ANNAME!) für die 2 Connectoren gibts unterschiedliche Properties...auch die Filenamen "db.properties" und "mysql-db.properties" sind unterschiedlich.

Wo hebe ich diese Files auf?
A) Im Artifakt "XY-connector" selber? Schlecht - Dann kann ich sie nicht mehr konfigurieren, weil sie ins Artifakt gebunden sind.
B) IM ARTIFAKT "main-prj" ? Schlecht - Dort gehören sie nicht hin, ich kann nicht für 20 mögliche Connectoren, 20 verschiedene File hosten.

C) im Filesystem des "XY-connector"s, aber ausserhalb der Maven-Struktur. Schlecht! Ich kann nicht mehr über classpath zugreifen, sondern über File(-URL). Bringt den nachteil, dass ich von "main-prj" gar nicht mehr zugreifen kann. Aber kleiner Vorteil: Das config-file wird nicht mehr in den Artifakt gebunden.

Ich hasse Misthaufen!

Grusslinger ;-)

 

[mvitz]

Dann gehört die Config direkt in das Projekt, welches den DB Connector nutzt. Willst du einen anderen Connector nutzen, musst du halt die Config anpassen.

 

[reibi]

OK mvitz,

drück dich mal genauer aus?

-Ins Eclipse-prj? Das isses immer
- Ins Maven prj? Dann kann mans über classpath anziehen, aber es wird ins jar-file mit reingebuildet, --> jetz kommts: "wie willste das verhindern ?" <-- Das interessiert mich

Gruss ;-)

 

[mvitz]

Angenommen du hast zwei Maven-Projekte:

• Main-Project
• Lib-Project

Für Lib-Project benötigst du eine Konfiguration. Diese soll über eine Konfigurationsdatei erfolgen. Dann solltest du dir eine Konvention überlegen, wie diese Datei heißen muss und in welchem Ordner im Classpath sich diese befinden muss. (ähnlich wie z.B. für JPA) --> Konvention: lib.config soll über den Pfad config/lib.config ladbar sein.

Weiterhin benutzt Main-Project das Lib-Project. Main-Project hat jetzt die gesamte Verantwortung dafür, die Konfiguration richtig zu machen, d.h. die Datei mit richtigem Inhalt, am richtigen Ort unter dem richtigen Namen zur Verfügung zu stellen.

Für die Tests von Lib-Project kannst du die Testkonfiguration ja einfach nach src/test/resources packen. Solltest du eine Art Defaultkonfiguration anbieten wollen, dann solltest du diese Datei einfach anders benennen, z.B. config/lib-default.config und beim laden erst config/lib.config versuchen zu laden. Sollte dies nicht funktionierten lädst du halt die Defaultkonfiguration.

 

[reibi]

Für die Tests von Lib-Project kannst du die Testkonfiguration ja einfach nach src/test/resources packen.

Grundsätzlich super Idee. Darauf bin ich noch gar nicht gekommen. Mach ich ab heute genau so ;-)
Freu mich, dass Du mich darauf gebraucht hast ;-) Dafür ist das denk ich sogar da.

Solltest du eine Art Defaultkonfiguration anbieten wollen, dann solltest du diese Datei einfach anders benennen, z.B. config/lib-default.config und beim laden erst config/lib.config versuchen zu laden. Sollte dies nicht funktionierten lädst du halt die Defaultkonfiguration.

Naja das is noch das Problem:

Stell Dir vor Du müsstest mehrere "lib-prj" erstellen, welche sich um die Speicherung von Daten auf bestimmten Medien kümmern soll. Das jeweilige "lib-prj" wird dann erst in der jeweiligen produktiven Ausprägung gesetzt.

Beispiel:
1.) db-lib-prj
2.) hibernate-lib-prj
3.) file-lib-prj
4.) log-lib-prj
5.) internet-lib-prj
6.) email-lib.prj

Je nach dem was eingesetzt werden soll, braucht es unterschiedliche daten zB für die DB eine Connection oder für das Mail eine smtp bzw. pop3- information.

ich würde zBdie configurationen für:
1.) db-lib-prj --> conf/db-lib.conf nennen
...
3.) file-lib-prj --> conf/file-lib.conf

Insgesamt werden vielleicht 10 config-files eingesetzt ... aus einem Set von möglichen 100 ...

Das ist zu viel für mein config-verziechnis... welchen ja eigentlich ein Package ist.

Ne andere Möglichkeit ist, wie Du sagts "lib-default.config" zu machen und die jeweils umzubenennen. Dann muss ich aber immer 2 Sachen machen ... einmal POM-File anderen Artifakt eintragen und zweiten default-lib.conf umbenennen.

irgendwie doof.


Sag mal Deine meinung für folgendes:

main-prj/src/test/resources/conf
|_media/file-lib.conf
|_media/hibernate-lib.conf
|_media/db-lib.conf
|_ ..........
|_communication/email-lib.conf
|_communication/internet-lib.conf
|_communication/sip-lib.conf
|_communication/icq-lib.conf
|_ ..........

usw.

Das würde mir den Vorteil bringen, dass ich alles strukturiert hätte, nichts jeweils umbenennen müsste und nur jeweil im POM meinen Artifakt umhängen müsste. Die defautkonfig würde automatisch angezogen werden und trotzdem strukturiert sein.

Nachteil wäre, dass nicht alle Config-Files in einem Verzeichnis wären.

Also vielen Dank für Eure Statements

Schönes WE ;-)

 

[mvitz]

Wieso sind 10 Config Dateien zu viel für dein Verzeichnis? Wenn man nun mal ein derart viele Dinge Konfigurieren muss, dann muss man das halt machen. Und da nur der der die Library nutzt wissen kann, wie die Konfiguration aussehen muss, muss dieser diese halt bereitstellen...

 

[reibi]

Du hast recht ... sollte kein Problem sein... und selbst bei 100Dateien gibts schon ne Möglichkeit. Ich werde das alles ausprobieren. Vielen Dank für die guten Tips. Bei Nichtgelingen werd ich hier einfach was dranhängen(weiterposten).

Gruss und guten Wochenstart ;-)