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

ruutaiokwu

Top Contributor
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
 
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.
 
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 😉
 
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.
 
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: 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
 
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. 🙂
 

Neue Themen


Zurück
Oben