Externe Bibliotheken mit ins SVN-Repository?

[TSH]

Hallo,

ich möchte eine Webapp bauen, die dann zB im Tomcat laufen soll. Ich muss externe Bibliotheken einbinden und möchte für mein Projekt Subversion nutzen.

Ganz naiv würde ich nun alle externen Bibliotheken ins WEB-INF/libs Verzeichnis kopieren und das alles mit ins SVN-Repository packen.

Dämliche Frage: Macht man das so oder gibt's da elegantere Möglichkeiten? Evtl. immer beim Bauen von irgendwo ziehen und ins Zielverzeichnis kopieren (ein ANT oder MAVEN Skript muss ich noch schreiben bzw. mich einarbeiten)?

 

[kama]

ich möchte eine Webapp bauen, die dann zB im Tomcat laufen soll. Ich muss externe Bibliotheken einbinden und möchte für mein Projekt Subversion nutzen.

Schon mal sehr löblich, den Einsatz einer Versionskontrolle ;-)

Ganz naiv würde ich nun alle externen Bibliotheken ins WEB-INF/libs Verzeichnis kopieren und das alles mit ins SVN-Repository packen.

Kann man machen. Ist auch durchaus Üblich. Machen sehr viele Projekte, nicht nur für Web-projekte so....J2EE auch...

Dämliche Frage: Macht man das so oder gibt's da elegantere Möglichkeiten? Evtl. immer beim Bauen von irgendwo ziehen und ins Zielverzeichnis kopieren (ein ANT oder MAVEN Skript muss ich noch schreiben bzw. mich einarbeiten)?

Du solltest dich schon entscheiden, ob Du Ant oder Maven nutzt, da die Unterschiede doch recht groß sind.
Wenn Du maven verwendest, kann Du die Bibliotheken ja als dependencies definieren, dann werden die sowohl beim build als auch beim deployen entsprechend mit eingebunden. Man kann u.U. überlegen, sie nicht mehr mit ins Projekt ins Subversion einzuckecken...aber das ist Geschmacksache...
Bei Ant musst Du sie definitv in dem lib Ordner haben und beim Compilieren auch entsprechend mit im Classpath haben.

BTW: Falls Du dich eventuell am Anfang dafür entscheidest erstmal Ant zu machen, dann aber trotzdem die Verzeichnisstruktur schon wie für Maven anlegen....dann ist der Umstieg später einfacher..

MfG
Karl Heinz Marbaise

 

[Guest]

Klar. Ich mache dies seit Jahren so. Zusätzlich noch eine Doku zu den Libraries
bzw. eine Zusammenfassung wofür, welche Libraries benötigt werden, Version
und welche Abhängigkeiten sie zueinander haben. Oft weiss man nach Jahren
nicht mehr, wofür irgendeine spezielle Jar Datei nötig ist/war.
Auch eine Trennung von Libraries, die nur zur Entwicklungszeit benötigt werden.
Bei jedem Versionswechsel werden die einzelnen Libraries ausführlich getestet,
um keine Überraschung zu erleben, wenn eine neuere Version ein anderes Verhalten
zeigt.
Auch die Entwicklungsumgebung (sagen wir mal Eclipse) gehört zum Projekt.
Zwar nicht ins SVN, aber eine vorkonfigurierte Kopie, die in einem Projekt verwendet
wird, wird gesichert (ZIP auf Backup)
Kommt ein anderer Entwickler ins Team, kriegt er ein Installationsskript, entpackt
das Zeug, richtet seine Umgebung so ein, dass sie zu den Entwicklungsumgebungen
anderer Leute passt und kann innerhalb von einer halben Stunde loslegen. Er braucht
nicht mehr die Zeit für die Konfiguration benötigter Plugins zu verschwenden.
(z.B. Hibernate, Serverkonfigurationen, Hilfsplugins jeglicher Art etc...)

Gruß,
semi

 

[kama]

Hallo,

Auch eine Trennung von Libraries, die nur zur Entwicklungszeit benötigt werden.

Sprich meist nur zum Test (so sachen wie junit, checkstyle, findbugs etc.).

Bei jedem Versionswechsel werden die einzelnen Libraries ausführlich getestet,
um keine Überraschung zu erleben, wenn eine neuere Version ein anderes Verhalten
zeigt.

Für so etwas verwendet man einen Branch. Auf dem Branch wird die neue Release der Library hinzugefügt und das Ganze getestet. Wenn alles gut geht, dann wird das wieder in die Mainline integriert.

Auch die Entwicklungsumgebung (sagen wir mal Eclipse) gehört zum Projekt.
Zwar nicht ins SVN,

Genau über den Punkt kann man durchaus streiten...ich stecke zum Teil mein Eclipse auch in Subversion rein, damit ich PlugIns bzw. die Verträglichkeit untereinander Testen kann. Wenns nicht klappt einfach eine Version zurück und fertig..

aber eine vorkonfigurierte Kopie, die in einem Projekt verwendet
wird, wird gesichert (ZIP auf Backup)

Das ist auf jeden fall eine gute Sache. Auspacken und mithilfe eines Team-Project Files alles auschecken was genötigt wird.


MfG
Karl Heinz Marbaise

 

[TSH]

Danke für die Hinweise. Jetzt hab ich aber das Gefühl, dass Tomcat die Bibliotheken in webapps/meineWebApp/WEB-INF/lib/ nicht erkennt. Jedenfalls sind sie da drin und wenn ich eine entsprechende URL aufrufe, bekomm ich eine Exception, dass diese Klasse nicht gefunden werden kann.

Muss ich noch irgendwas tun, damit Tomcat die Dateien in meineWebApp/WEB-INF/classes und meineWebApp/WEB-INF/lib erkennt?

 

[kama]

Hi,

hast Du denn ein SAR/WAR/EAR erstellt, dass Du deployst?

MfG
Karl Heinz Marbaise

 

[TSH]

Nein, ein WAR kann mein ANT-File noch nicht. Ich deploye es so:

<target name="deploy" depends="compile" description="Deploy application">

  <copy todir="${tomcat.home}/webapps/${webapp.name}" preservelastmodified="true">
    <fileset dir="${web.dir}">
      <include name="**/*.*"/>
    </fileset>
 </copy>

 <copy todir="${tomcat.home}/webapps/${webapp.name}/WEB-INF/classes" preservelastmodified="true">
   <fileset dir="${build.dir}/classes"/>
 </copy>

</target>

Ich hab dann diese Struktur:

/webapps/meineapp/
-- images/
-- META-INF/
-- WEB-INF/
-- -- classes/
-- -- jsp/
-- -- lib/
-- -- meineapp-servlet.xml
-- -- web.xml

 

[kama]

Hi,

ist ein WAR file so schwer?
Hier die Doku zu Ant http://ant.apache.org/manual/CoreTasks/war.html

	<target name="war" depends="compile" description="Create war file">
		<war destfile="imuresco.war" webxml="${dir.src}/web.xml">
			
			<classes dir="${dir.build.classes}" />
			<zipfileset dir="${dir.src}/com/soebes/imuresco/web" prefix="." includes="*.jsp" />
			<zipfileset dir="${dir.src}/com/soebes/imuresco/web/css" prefix="css" includes="*.css" />
			<zipfileset dir="${dir.src}" prefix="." includes="*.tld" />
			<zipfileset dir="${dir.src}" prefix="WEB-INF/classes" includes="hibernate.cfg.xml" />
			<zipfileset dir="${dir.src}" prefix="WEB-INF/classes" includes="*.properties" />
			<zipfileset dir="${dir.src}" prefix="WEB-INF" includes="faces-config.xml" />
			<zipfileset dir="${dir.src}" prefix="WEB-INF/lib" includes="*.dtd" />
			<zipfileset dir="${dir.src}" prefix="WEB-INF" includes="ehcache.xml" />
			<zipfileset dir="${dir.lib}" prefix="WEB-INF/lib">
				<include name="*.jar"/>
			</zipfileset>
		</war>
	</target>

Wenn Du war file gebaut hast, kann man auch Remote deployen oder das WAR file einfach wie gehabt deployen...

MfG
Karl Heinz Marbaise

 

[TSH]

Danke, ich hab's jetzt so hinbekommen:

	<target name="war" depends="compile" description="Packages app as war file.">
		<mkdir dir="${dist.dir}" />
	    <war destfile="${dist.dir}/${webapp.name}.war" webxml="${war.dir}/WEB-INF/web.xml">
			<classes dir="${build.dir}/classes" />
	    	<zipfileset dir="${war.dir}/WEB-INF/jsp" prefix="WEB-INF/jsp" includes="*.jsp" /> 
	    	<zipfileset dir="${war.dir}/WEB-INF/tlds" prefix="WEB-INF/tlds" includes="*.tld" /> 
	    	<zipfileset dir="${lib.dir}" prefix="WEB-INF/lib" includes="*.jar" />
	    </war>  
	</target>

Das kopier ich dann in Tomcat/webapps. Führt dann aber leider zu dem hier:

org.springframework.beans.factory.BeanDefinitionStoreException: 
IOException parsing XML document from ServletContext resource [/WEB-INF/meineapp-servlet.xml];

nested exception is java.io.FileNotFoundException:
Could not open ServletContext resource [/WEB-INF/meineapp-servlet.xml]

Ich hab dann versucht, die Datei ins War einzubinden mit:

<zipfileset dir="${war.dir}/WEB-INF" prefix="WEB-INF/" includes="meineapp-servlet.xml" />

Die Fehlermeldung bleibt aber leider.

 

[kama]

Hallo,

org.springframework.beans.factory.BeanDefinitionStoreException:
IOException parsing XML document from ServletContext resource [/WEB-INF/meineapp-servlet.xml];

Da scheint doch der Hund begraben zu sein?
Die XML Datei scheint nicht ok zu sein oder aber etwas zu Enthalten was nicht mit deployed wurde...

Schau Dir die nochmal genau an....

MfG
Karl Heinz Marbaise

 

[TSH]

Ich hab's jetzt zum Laufen bekommen. Es waren nicht alle Libs korrekt eingebunden. Dann war noch das Problem, dass ich im WEB-INF/lib Verzeichnis die Bibliothek jsp-api.jar hatte. Tomcat (Version 6.0.10) hatte aber auch eine in <tomcat>/lib.

Als ich die aus WEB-INF/lib gelöscht habe gings. Aber ich kann mich ja nicht drauf verlassen, dass jeder Servlet-Container jsp-api.jar schon eingebunden hat, oder? Wie geht man mit sowas um, damit doppelte Bibliotheken vermieden werden können?