verschiedene Versionen "builden" für Test und Lifebetrieb

[dermoritz]

Ich hab eine kleine DB-Anwendung gemacht (die hier implizit schon durch Forum geistert) die bestimmte Interaktionen mit einer einfachen DB erlaubt. Nun hab ich das klassische Problem, dass ich im Testbetrieb (Debugging neue Features probieren) natülich nicht mit der Life-DB interagieren möchte sondern mit einer Test-DB (in der Anwendung soll es keine Möglichkeit geben die Verbindung zu wechseln).

Ich frage mich nun wie ich diese 2 Versionen nun am praktischsten Realisiere. Mit Maven scheint es da einige Möglichkeien zu geben? Nur was ist "Best Practice"?

Ich hab im Moment 2 Varianten ersonnen: 1. Ein "Resource-Bundle" bzw. zwei Property-Dateien die die jeweiligen Verbindungsparameter enthalten. Wie veranlasse ich Maven/m2Eclipse eine zu wählen? Ich bräuchte ja irgendwie 2 Buildtargets?

2. Ich würde 2 sehr einfache Module basteln (DB-Verbindungsmodule, eventuell inkl. einder DB-Verbindungsschnittstelle) die jeweils genau eine DB-Verbindung liefern. Hier stellt sich eine ähnlich Frage: Wie sage ich Maven/m2Eclipse unter welchen Umständen welches Modul einzubinden ist.

 

[Geeeee]

Also ich hab es bei mir (frag mich bitte nicht, ob das best practice ist) über project profile gelöst. Also einfach deine Hibernate (/ Spring) config mit Placeholdern ausstatten.
Kleine Anleitung hab ich in meine Blog stehen. Der ist mehr oder weniger für mich selber auch gedacht, weil ich da u.a. meine Mavenlernschritte selbst verfolge Aber vielleicht hilft dir das ein wenig.

 

[dermoritz]

ahh - danke, ich werd mir das mal durchlesen, Fragen folgen ;-)...

... nun hab ichs gelesen und muss sagen, genau so wollte ich es mache hätte ich gewusst wie . Nun hab ich noch eine andere Frage: da ich so ein Fan von Eclipse bin und auch von m2Eclipse - kann ich diese Pofile-Angabe auch irgendwie als maven2-Run-Configuration unterbringen?

(eine Ähnlich Frage ist in einem anderen thread- da wollte ich wissen wie ich "Deploy" per Klick hinkriege.)

 

[maki]

Suche mal nach Maven Profilen, nebenbei, deine Integrationstests solltest du unbedingt in ein eigenes Modul auslagern.

 

[tuttle64]

Ich frage mich nun wie ich diese 2 Versionen nun am praktischsten Realisiere. Mit Maven scheint es da einige Möglichkeien zu geben? Nur was ist "Best Practice"?/QUOTE]


java hat die option -D(name)=value. Innerhalb deines Codes kannst Du mit einer relativ trivialen Abfrage die value abfragen und dann gemäss Ausprägung entweder mit der Test-DB connecten, ansonsten mit der produktive DB. Der Vorteil dieses Verfahrens ist, dass der Anwender nichts mitbekommt.

 

[maki]

java hat die option -D(name)=value. Innerhalb deines Codes kannst Du mit einer relativ trivialen Abfrage die value abfragen und dann gemäss Ausprägung entweder mit der Test-DB connecten, ansonsten mit der produktive DB. Der Vorteil dieses Verfahrens ist, dass der Anwender nichts mitbekommt.

Aua... :autsch:

Den Code hat es nicht zu interessieren wie er ausgeführt wird (Unittests, Testumgebung, Produktiv,. ..), der von dir vorgeschlagene Weg ist sehr riskant & unsauber.

Einerseits hast du mehr Code, andererseits hat der Code alle Daten über u.U. nicht existierende Umgebungenm, und wenn ein bug drinn ist und Test mit Prodsystem verwechselt wird, ist alles möglich, auch gelöschte Datenbanken, schliesslich soltle es ja nur ein Testsystem sein...

Man baut für jede Umgebung, da bekommt der Anwender nix mit, und der Code auch nicht
Braucht halt ein vernünftiges Build Tool, am besten mit Dependency Management, wie Ant+Ivy, Buckminster, Maven2, Gradle, etc. pp.

 

[dermoritz]

danke nochmal - nun hab ich das mal ausprobiert und es funzt so wie es soll .

Nun nur noch eine Kleinigkeit - ich mach mir per Assembly-Plugin eine jar-Datei aus der Anwendung (nun gebe ich das Entsprechende Profil als Parameter mit), aber:

Wie kann man per Profil Parameter von solchen Plugins ändern? Ich würde gern "fileName" des Assembly Plugins setzen um zu sehen ob es ein "Test"- oder "Produktion"sbuild ist.

 

[maki]

Du kannst pro Profil eine komplett eigene Build Plugin Konfiguration haben

Ich würde gern "fileName" des Assembly Plugins setzen um zu sehen ob es ein "Test"- oder "Produktion"sbuild ist.

Was meinst du mit "sehen"?

 

[dermoritz]

wenn es fertig erstellt wurde soll im Namen der jar-Datei "Test" oder "Produktion" auftauchen - je nach aktiviertem Profil. Nun hab ich schon rausgekriegt, dass man per

<profile>
...
<build>
  <finalName>Produktion</finalName>
</build>
...
</profile>

den Namen ändern kann. Bei mir heißt das dummerweise dann "Produktion-jar-with-dependencies.jar" - also das Assembly Plugin hängt am Ende unabhängig vom Profil noch etwas dran. Ich hätte als Namen eigentlich den ursprünglichen Namen + "Produktion" oder "Test" anstelle von "jar-with-dependencies". Also dachte ich, ich müsste den Namenparameter vom AssemblyPlugin per Profil steuern (alle anderen Parameter und das Plugin selbst sollen vom Profil unabhängig sein)

 

[maki]

also das Assembly Plugin hängt am Ende unabhängig vom Profil noch etwas dran.

Die Assembly ID wird angehängt.

"classifier" sagt dir was?
Kannst ja auch den finalName als Variable übergeben, oder?

 

[dermoritz]

Die Frage wäre ob ich per Profile steuern kann was am Ende an den Namen gehängt wird. Über finalName im Profil steuere ich ja den ganzen Namen, das will ich nicht.

Es als Parameter übergeben ist keine Option, da ich das ganze eben über Profile in der pom haben will. Und "clasifier" sagt mir (in welchem Zusammenhang eigentlich?) nichts. oder meinst du das: "classifier String - Deprecated. Please use the Assembly's id for classifier instead"

 

[maki]

Wie gesagt, die Assembly ID wird angehängt, das wäre dann der classifier, kannst du im <dependency> Abschnitt anderer POMs nutzen.
Wäre es eine Option, deinen eigenen Assembly Descriptor zu verwenden?
Mir ist nicht klar wie du verschiedene Builds erzeugen willst wenn du einen Standard Assembly-Desciptor nutzt.

Nebenbei, in Profilen kann man auch Properties haben

 

[dermoritz]

wie ich verschiedenen builds erzeuge ist ja Hauptthema hier - per Profil. Per mvn assembly:assembly -PProfil1 / -PProfil2 erzeuge ich dann jeweils ein "jar-with-dependencies" (AssemblyID). Per "appendAssemblyId = false" könnte ich das anhängen dieses Strings unterbinden soviel ist nun auch klar.
Nun würde ich gerne ein Profilabhängigen String an den Namen dranhängen (ob das überhaupt etwas mit dem Assembly Plugin zu tun hat/ haben sollte - weiß ich nicht). Per "finalName" kann ich über das Profil den Gesamtnamen ändern - das ist nur bedingt tauglich, da der Name Standard bleiben soll (Abhängig von der derzeitigen Version).

Also gibt es irgend eine (Profile)-"Property" mit dem ich etwas an den Namen dranhängen kann. Oder kann ich den "finalName" abhängig vom Standardsetzen: finalName=$default+"Test"

 

[tuttle64]

Aua... :autsch:

Den Code hat es nicht zu interessieren wie er ausgeführt wird (Unittests, Testumgebung, Produktiv,. ..), der von dir vorgeschlagene Weg ist sehr riskant & unsauber.

Ist es nicht. Zu Deiner Erinnerung:

-Dproperty=value
Set a system property value.

 

[maki]

Meine Erinnerung funktioniert noch, hast du meinen Post gelesen?