Spring Dependencies Deployment

Hi all,

Sorry to be a bit off topic.

Wouldn't it be easier if the spring dependency jars were in two different paths in the distribution? That would simplify the ant script for deployment and make it generic.

As I do not want to deploy every dependencies, I have to explicitely list them in my script. I'd like to be able to write a generic deploy script that would not need to be modified if I use a new Spring release. Same thing for my Eclipse project. Maybe putting all jars in the same directory would also help in simplifying an Eclipse project.

But, as I am pretty new to Eclipse and Ant, my limited knownledge may be the problem... ;-)

Starman

Starman,

I'm not entirely sure what you are suggesting with two separate directories. What I have found effective is to maintain a local copy of the exact dependencies that my application is using and include these in my distribution. I try to avoid having Ant go outside the project directory structure and I like to maintain the JAR files my app is using in version control just in case.

If this doesn't answer your question, maybe you could give me a few more details related to your problem. I may well be able to help you out with Ant :)

Rob

Hi Rob, thanx for your reply.

Doing a small app I would probably agree. However, our application will use many other projects, all distributed as jar files. They are independently released and versioned. The app also has to rely on the jdbc driver and other system level packages.

IMHO, it doesn't make sense to copy all the dependent jar files to some central project archive. I'd much prefer reference the /lib directory of the needed sub-project.

Thus, it makes it easier if I can just make one reference to spring for deployment, instead of having to list individually the spring packages.

So instead of:

<target name="dist" description="Packages iSCRAM war file">
<mkdir dir="${dist.home}" />
<jar destfile="${dist.home}/${app.name}.war">
<zipfileset dir="${mysql.home}/lib" prefix="WEB-INF/lib" includes="*.jar" />
<zipfileset dir="${spring.home}/dist" prefix="WEB-INF/lib" includes="spring.jar" />
<zipfileset dir="${spring.home}/dist" prefix="WEB-INF/lib" includes="spring-mock.jar" />
<zipfileset dir="${spring.home}/lib" prefix="WEB-INF/lib"
includes="**/velocity-1.4.jar
**/velocity-tools-generic-1.1.jar
**/jakarta-oro-2.0.8.jar
**/log4j-1.2.8.jar
**/junit.jar
**/standard.jar
**/commons-validator.jar
**/commons-beanutils.jar
**/commons-collections.jar
**/commons-digester.jar
**/commons-fileupload.jar
**/commons-lang.jar
**/commons-logging.jar
**/jstl.jar
**/jta.jar
**/hsqldb.jar
**/ehcache.jar
**/hibernate2.jar
**/odmg.jar
**/easymock.jar
**/easymockclassextension.jar
**/dom4j.jar
**/cglib-full-2.0.2.jar
**/burlap-2.1.12.jar
**/hessian-2.1.12.jar
**/aopalliance.jar" />
<zipfileset dir="${build.home}/data" prefix="WEB-INF/classes" includes="**/*.*" />
<zipfileset dir="${build.home}/shared" prefix="WEB-INF/classes" includes="**/*.*" />
<zipfileset dir="${build.home}/server" prefix="WEB-INF/classes" includes="**/*.*" />
<zipfileset dir="${build.home}/web" includes="**/*.*" />
</jar>
</target>

I could just list the /lib/deploy like:

<zipfileset dir="${spring.home}/lib/deploy" prefix="WEB-INF/lib"
includes="l**/*.jar />



Starman

Starman,

I think I see what you mean now - you would include all JARs that are needed to run Spring in one directory and all JARs needed for the build process (line junit.jar) in another.

The only drawback here is that I never include all JARs in my project anyway - just the ones I need. Why include Hibernate, JDO and OJB when you are using iBATIS?

Rob

Yes, that's it. You'll still be able to specify only the jar you need. I do that of course in production.

But while developing, you can now have a generic ant file. There are some jars that include the version number in their filename. When you upgrade Spring, you won't have to go and check if some jars have changed. And you can use the same ant file to start new projects.

So, just a bit more convenience. And for newbies like me, it'll be easier to see what jars are needed to build and what jars must be deployed.

Starman