# Multi-Tier-Entwicklung in Eclipse



## Gorco (17. Nov 2009)

Hallo,

ich muss eine Multi-Tier-Anwendung in Java erstellen. Das Programm gliedert sich z.B. in folgende Ebenen auf: Client.SWT, Client.WEB, Server, Business.Engine, Database.Engine, Core.Utils. Ich möchte sehr modular arbeiten so das gemeinsam genutzte Funktionen nicht redundant entwickelt werden müssen. Jetzt meine Frage: Wie legt man diese Projekte am besten in der Eclipse an? Erstelle ich für jede Anwendungsschicht ein eigenes Projekt? Die Nachteile sind hier für mich das ich in meinem Workspace die Projekte nur linear ablegen kann. Oder erstelle ich mir einen einzigen Projektordner und verwalte darin mehrere Run's und halte dafür den komplette Quellcode anhand der Package-Namen zusammen? Habt Ihr mit so etwas Erfahrung bzw. könnt Ihr mir ne Doku oder Buch empfehlen?

Danke im Vorraus!

Gruß
Gorco


----------



## maki (17. Nov 2009)

Würde da Maven2 empfehlen, das unterstützt von Haus aus Module, Dependency Resolution und autom. Build.


----------



## byte (17. Nov 2009)

Theoretisch könntest Du natürlich auch alles in ein Projekt knallen, aber die einzelnen Builds (SWT Client, Web Client, Server) wären dann ziemlich kompliziert.
Es ist definitiv sinnvoll, jedes Modul als eigenes Java-Projekt anzulegen. Du kannst die Projekte in Eclipse dann in verschiedene Working Sets gliedern, um die Übersicht zu behalten.
Makis Tipp ist sehr sinnvoll. Beim SWT Projekt bietet sich allerdings Eclipse OSGi an. Das macht den Einsatz von Maven etwas komplizierter.


----------



## reinsle (17. Nov 2009)

Hy Gorco,

also ich habe hier mehrere Projekte die sowohl in mehrere Teile unterglieder sind, als das auch Teile verschieden verwendet werden (z.B. als Plugin im SWT-Client und als JAR im Web-Server).

Wir haben das so aufgezogen das wir einerseits die Entwicklung für den SWT-Client auf OSGI-Basis machen, hier sind Federführend die Plugin-Dependencies. Die anderen Bundles werden per Maven(2) verwaltet. Was schwierig ist ist das Dependencie-Management für die Bundles, die in beiden Welten eingesetzt werden, da der Classpath entweder an den Maven-Dependencies hängt, also auch an den durch maven verwalteten Dependencies. Aber Insgesammt funktioniert hier die Entwicklung so einwandfei.

Mein "grosses" Projekt hat derzeit ca. 83 Bundles, und um hier die Übersichtlichkeit zu wahren, lege ich dir den Tipp mit den Workspaces nahe.


Robert


----------



## Wildcard (17. Nov 2009)

reinsle hat gesagt.:


> Wir haben das so aufgezogen das wir einerseits die Entwicklung für den SWT-Client auf OSGI-Basis machen, hier sind Federführend die Plugin-Dependencies. Die anderen Bundles werden per Maven(2) verwaltet. Was schwierig ist ist das Dependencie-Management für die Bundles, die in beiden Welten eingesetzt werden, da der Classpath entweder an den Maven-Dependencies hängt, also auch an den durch maven verwalteten Dependencies.


Ich verwende dafür Buckminster, weil es sowohl OSGi Bundles, Eclipse Features und Maven Components versteht.
Module sollten IMO wirklich immer eigene Projekte sein und nach möglichkeit auch OSGi, damit man packages selektiv exportieren kann. Die Bundles können anschließend ja auch ohne OSGi Framework in einer Standalone Applikation eingesetzt werden.


----------



## reinsle (17. Nov 2009)

Wildcard hat gesagt.:


> Ich verwende dafür Buckminster, weil es sowohl OSGi Bundles, Eclipse Features und Maven Components versteht.
> Module sollten IMO wirklich immer eigene Projekte sein und nach möglichkeit auch OSGi, damit man packages selektiv exportieren kann. Die Bundles können anschließend ja auch ohne OSGi Framework in einer Standalone Applikation eingesetzt werden.



Hm, im Prinzip haben wir das ja auch so, nur das ich Buckminister nicht wircklich verstanden habe. Aber auch hier möchte ich noch ein CI etablieren, wobei das imo ned ganz so einfach ist.

Und du hast recht, da OSGI-Bundles im Prinzip nur durch Meta-Informationen angereicherte Jar-Files sind, können wir das auch in beiden Welten einsetzen. Wie gesagt das ist so auch unser Stand, bis auf Buckminister.

Robert


----------



## Wildcard (17. Nov 2009)

reinsle hat gesagt.:


> Hm, im Prinzip haben wir das ja auch so, nur das ich Buckminister nicht wircklich verstanden habe. Aber auch hier möchte ich noch ein CI etablieren, wobei das imo ned ganz so einfach ist.


Es gibt ein Hudson Plugin für Buckminster 
Buckminster PlugIn - hudson - Hudson Wiki
Für Buckminster Fragen gibt es das tolle eBook von Henrik Eclipse downloads - mirror selection, die Newsgroup und ich kann auch gerne weiterhelfen wo mir das möglich ist.


----------



## reinsle (17. Nov 2009)

Hy,

vielen Dank zu den Links, werd ich mir die Tage mal angucken.

Weil ... ich suche schon länger was, womit ich meine OSGI-Bundles bauen kann.

Wie mächtig ist Buckminster? Könnte ich damit auch ne RCP-Anwendung bauen?


----------



## Wildcard (17. Nov 2009)

reinsle hat gesagt.:


> Wie mächtig ist Buckminster? Könnte ich damit auch ne RCP-Anwendung bauen?


Problemlos:
Building an RCP application with hudson (Buckminster) - Eclipsepedia
Building Eclipse RCP applications using Buckminster and Hudson


----------



## Gorco (25. Nov 2009)

Hallo,

und vielen Dank für die Tips! Da ist auf jeden Fall was Brauchbares dabei!


----------

