# eclipse web project - warum in den "build"-ordner kompilieren ???



## ruutaiokwu (21. Okt 2010)

hallo zusammen,

mir ist das was aufgefallen, was mich irritiert:

wenn ich ein webprojekt unter eclipse erstelle, mache ich normalerweise kein "web projekt", sondern ein normales java-projekt. den rest (application server, build-path etc.) konfiguriere ich manuell.

nun hatte ich aber den fall, dass ich ein "web project" erstellen musste. wie ich gesehen habe, werden per default dort die kompilierten java-klassen unter workspace/mywebproject/build abgelegt.

daneben gibt es ja noch ein verzeichnis namens "WebContent", das dann letztendlich dem deployment entsprechen sollte? meine frage ist: warum werden die java-klassen nicht direkt nach workspace/mywebproject/WebContent/WEB-INF/classes kompiliert???

(es ist mir bekannt, dass ich das mit dem build path ändern kann, was ich auch gemacht habe...)

aber warum wird nicht "per default" dorthin kompiliert? dann wäre die struktur innerhalb von "WebContent" 1:1 richtig zum deployen...

warum sollte ich schlussendlich z.b. per ant-script einen teil aus den "build"-verzeichnis, den anderen teil aus den "WebContent" holen um ein .war-file daraus zu erstellen? was haben sich die entwickler hierbei gedacht?


grüsse, jan


----------



## mvitz (21. Okt 2010)

Ganz einfach, dadurch werden Sourcen (HTML, CSS, etc.) und Artefakte (.class) voneinander getrennt.


----------



## ruutaiokwu (21. Okt 2010)

aber was ist der sinn dahinter, wenn am schluss zum deployen trotzdem alles wieder zusammengefügt werden muss?


----------



## mvitz (21. Okt 2010)

Naja, die Dateien unter WebContent sind halt die Sourcen und das was nachher deployed wird, sind die Artefakte. Da man nun HTML nicht kompilieren muss, entsprechen halt in diesem Fall die Sourcen den Artefakten.


----------



## maki (21. Okt 2010)

mvitz hat gesagt.:


> Naja, die Dateien unter WebContent sind halt die Sourcen und das was nachher deployed wird, sind die Artefakte. Da man nun HTML nicht kompilieren muss, entsprechen halt in diesem Fall die Sourcen den Artefakten.


Ist aber auch nicht sicher, ausser in simplen Fällen 

Man denke zB. an die Ressourcenfilter von Maven, kann gut sein dass JSPs/Property Dateien/XML Dateien sich doch noch ändern auf dem Weg ins Target


----------



## mvitz (21. Okt 2010)

maki hat gesagt.:


> Ist aber auch nicht sicher, ausser in simplen Fällen
> 
> Man denke zB. an die Ressourcenfilter von Maven, kann gut sein dass JSPs/Property Dateien/XML Dateien sich doch noch ändern auf dem Weg ins Target



Stimmt natürlich, aber da hier explizit von nem Eclipse Projekt die Sprache war, bin ich davon ausgegangen, dass dsa hier nicht der Fall ist.

Dein Beispiel ist damit aber ein gutes Argument dafür, wieso man die beiden Ordner trennt.


----------



## maki (21. Okt 2010)

mvitz hat gesagt.:


> Stimmt natürlich, aber da hier explizit von nem Eclipse Projekt die Sprache war, bin ich davon ausgegangen, dass dsa hier nicht der Fall ist.


Hast recht, wollte auch nur Haare spalten


----------



## ruutaiokwu (21. Okt 2010)

danke für eure antworten, nun bin ich etwas schlauer!

finde es aber komisch, dass eclipse das per default macht; meiner meinung nach braucht man das eher für spezialfälle...

und wenn ich alles von grund auf im WebContent-verzeichnis habe, kann ich das ganze über einen filesystem-link (bei mir bei windows "nfts junction-point") auf das deployment-verzeichnis anderer application-server "mounten"...

so entwickle ich überigens wenn ich KEIN web-projekt, sondern ein normales java-projekt für eine webapp erstelle.


grüsse, jan


----------



## mvitz (22. Okt 2010)

Man kann das ganze doch auch direkt per Eclipse Laufen lassen, wenn es ein Dynamic Web Projekt ist.


----------



## ruutaiokwu (22. Okt 2010)

@mvitz: ja, ist so. nur passt mir das nicht wirklich. in der firma nutzen wir das auch. dann spielt es keine rolle wie die dateien/klassen/resourcen verteilt sind, wenn man das ganze unter eclipse laufen lässt. wenn man aber alles in einen order packt, der bereits die struktur des (zukünftigen) deployments besitzt, kann man wie gesagt das ganze verzeichnis in einen "externen" application server (-> deployment-verzeichnis) per junction point linken... vorausgesetzt "hot deployment" und "expanded archives" sind aktiviert.

gruss, jan


----------



## mvitz (23. Okt 2010)

Das ist mir schon klar  Ist halt trotzdem nicht das ideale, da du so wie gesagt Sourcen und Artefakte vermischst.

Aber wenn du damit klar kommst, kannst du das ja machen, spricht meiner Meinung nach nichts gegen, die Frage ist ja nun geklärt.


----------

