# Wie mache ich verschiedene Builds in Eclipse?



## Thallius (31. Aug 2014)

Hi,

Ich habe eine App die mitlerweile von mehreren Kunden verwendet wird. Jetzt muss ich für einen Kunden Änderungen vornehmen die die anderen Kunden nicht bekommen werden. Wie kann ich also z.b. Von einer Class datei zwei verschiedene Versionen haben wobei die eine für einen anderen Build als für den anderen Build benutzt wird. Gibt es dafür eine komfortable Lösung in Eclipse?

Gruss

Claus


----------



## JavaMeister (31. Aug 2014)

Mit einem SCM kann man das leicht machen. 

Konfigurativ (z.B. DI)

Oder eben Plugins.

Buildtool verwenden, wie maven oder ein ANT Script.

Bestimmt viele möglichkeiten.


----------



## Thallius (31. Aug 2014)

Das es viele Möglichkeiten gibt ist mir klar. 

Deswegen fragten ich nach einer oder meinetwegen auch der komfortabelsten. Sprich die wo man am wenigsten installieren und konfigurieren muss.

Gruss

Claus


----------



## JavaMeister (31. Aug 2014)

Da wir deine Software Architektur nicht kennen, unmöglich zu sagen.

Ich kann dir nur sagen "am wenigsten installlieren" kann ein Kriterium sein, sollte aber prio C haben.

Uploade dein SourcCode, dann kann ich da drüber schauen.


----------



## nvidia (31. Aug 2014)

JavaMeister hat gesagt.:


> Mit einem SCM kann man das leicht machen.



Davon würde ich Abstand nehmen auch wenn es verlockend ist. Was man effektiv damit erreicht ist, dass man keinen wirklichen Hauptzweig mehr hat und irgendwan n-Versionen pflegen muss die alle irgendwie schräg auseinanderlaufen. Das macht Bugfixing unnötig kompliziert, neue Features für alle können schlecht eingebaut werden, es erhöht den Wartungsaufwand etc.  

Die mir bisher untergekommenen, wirksamen Mittel sind eine gemeinsame Codebasis und im Code selbst dann Feature-Switches oder das (von der SW-Architektur schönste) ein Aufbau der Software der von Grund auf auf Modularisierung ausgelegt ist und ermöglicht Funktionalitäten auszutauschen.


----------



## Thallius (31. Aug 2014)

U





JavaMeister hat gesagt.:


> Da wir deine Software Architektur nicht kennen, unmöglich zu sagen.
> 
> Ich kann dir nur sagen "am wenigsten installlieren" kann ein Kriterium sein, sollte aber prio C haben.
> 
> Uploade dein SourcCode, dann kann ich da drüber schauen.



Du glaubst jetzt nicht wirklich dass ich den Source einer kommerziellen App hier uploade oder?

Und ehrlich gesagt erschließt sich mir auch nicht die Notwendigkeit. Es ist ein großes Projekt mit über 80 sourcen und Klassen. Da würde dir der Source sowiso nichts nützen.

Claus


----------



## Thallius (31. Aug 2014)

Also bei OSX kann ich in Xcode einfach mehrere Targets anlegen und dann jedes Sourcefile beliebig vielen Targets zweisen. Jedes Target hat dann seine eigenen Build-Settings etc.

Gibt es so etwas ähnliches nicht auch in Eclipse?

Gruss

Claus


----------



## dzim (1. Sep 2014)

Kannst du den Aufbau deiner Projekte etwas spezifizieren?

OSGi-Anwendung? Wenn ja, dann kannst du für spezifische Teile Fragmente definieren. Ich bin da leider schon eine Weile raus, aber Grundsätzlich ist es dann so, dass du in verschiedenen Product-Files (per Kunde also eins) jeweils das "richtige" Fragment mit anhängst, dass dann die gewünschte Funktion implementiert. Soweit ich weiss, gibt es dann weiter einen (Eclipse-spezifischen-)Ant-Taks, der dann dieses Product-File ausweitet und entsprechend desses den eigentlichen Build macht.

Das blöde ist nur: Ich hab früher eigentlich nur für Intern gebaut - und updates kamen auch nur sporadisch, wenn es was neues gab - da musste ich gar nicht erst einen Build-Server etc. aufsetzen. Und wie gesagt: ich bin aus dem Teil ein wenig raus und aus der Übung.


----------



## Ruzmanz (4. Sep 2014)

Thallius hat gesagt.:


> Das es viele Möglichkeiten gibt ist mir klar.
> 
> Deswegen fragten ich nach einer oder meinetwegen auch der komfortabelsten. Sprich die wo man am wenigsten installieren und konfigurieren muss.
> 
> ...



Wirklich kurz gefasst ist ANT wie ein plattformunabhängiges Shell-Script. Maven setzt auf den Ansatz "Convention over configuration". Wenn es ein Build ohne sehr spezielle Anforderungen ist, dann ist Maven wahrscheinlich einfacher/schneller einzurichten.


----------



## JavaMeister (4. Sep 2014)

Also zum einen wäre maven für ein 80 sourcen miniprojekt überdimensioniert. Er müsste erhebliches Refactoring und oder Konfigurationen vornehmen um sein Projekt mit verschiedenen Targets zu bauen. 

Bei einem solchen kleinen Projekt eignet sich imho dependency Injection am besten. 

Nur so als vergleich: mein kleinstes privates Projekt hat schon über 500 Klassen. ( klar das kleinste, was nicht gerade ein Taschenrechner ist )


----------



## turtle (4. Sep 2014)

> Wie kann ich also z.b. Von einer Class datei zwei verschiedene Versionen haben wobei die eine für einen anderen Build als für den anderen Build benutzt wird


Nun werfe ich meinen Hut in den Ring, obwohl eigentlich "alles" schon richtig beantwortet wurde.

Da aber gegen SCM "gewettert" wurde, möchte ich anmerken, das ich das trotzdem eine gute Idee finde. 

In der Tat KANNST du eine Datei kundenspezifisch anlegen, allerdings mit allen bereits angesprochenen Nachteilen. Ist diese Datei bei 50 Kunden "etwas" anders, musst du die bei Fehlern eventuell 50 mal ändern und zum Kunden entsprechend ausliefern. Hier ist sorgfältiges Design der Applikation und der Einsatz eines guten SCM notwendig. Git beispielsweise kann ganz ordentlich mit Branches und Merges umgehen. Vielleicht kann die Datei auch in eine allgemeine Datei(für alle Kunden) und Dateien, die kundenspezifisch sind, geteilt werden (Stichwort: Designpattern)?

Fazit: Ich würde ein Git-Repository aufsetzen und mir Eclipse einrichten.


----------

