Jar file versioning questions

[Steve Garcia <sg...@media-publisher.com>]

One other thing I want to do is to build part of our application using OSS and not proprietary software.  (yea!)  I have identified several Jakarta projects that I could use to replace our proprietary software, including

Maven/Ant - for build/project management
OJB - object persistence
Torque - generate ddl and java classes
Tomcat - servlet container
Avalon - services/component framework for app services
Slide - WebDAV compatible cms
log4J - logging module
ECS - creating dynamic html/xml
Struts - mvc stuff
Velocity - would like that too, not sure how it fits in yet
JUnit - test all this stuff
Commons VFS - such a cool idea

OK, I look at this and say "cool, how sweet would this be" then I start looking at the dependencies for all of these software pieces and it's ENORMOUS.  I'll probably have to include just about every project distribution jar that is available from Jakarta.

And therein lies the problem, each project above relies not only on a dependency artifact but a particular artifact version as well.  Suppose (hypothetically) all of the projects above require me to have in my runtime classpath 5 different versions of log4J.  This is possible, right, because each stable build of the projects above may have occured with log4J 1.2.5, 1.2.2, 1.2.1, 1.2.8, etc.  

I may have not gotten the right build versions correct with log4J, but I think you'll understand my dilemma.  I'm afraid that there will be compile/runtime exceptions galore if I attempt to integrate all of these projects above into an Uber application.  I'll need 4 different versions of commons-beanutils, 3 versions of commons-logging, 2 of jelly, all this stuff.

Am I completely wrong?  How am I supposed to handle this?  I know Maven can handle versions of the same artifact but configuring the correct classpath seems to be a trial and error process.  And with 50-100 jars, that could be a long process!

Any thoughts?

Thanks, Steve

 

Re: Jar file versioning questions

[nicolas frank <ni...@laposte.net>]

OK usually you can peek the most recent version of a jar... the dependency
information can be taken as a "We tried it with this version and it works
!". Usally a new version add new functionalities (ex struts 1.0 and Struts
1.1), and often is backward version compatible (but no guaranty !)... You
can also check each dependante project site to see if they talk about
versions incompatibilities...
But anyway after changing dependancies, try your software carefully to be
sure not to have runtime problems...

----- Original Message ----- 
From: "Steve Garcia" <sg...@media-publisher.com>
To: <us...@maven.apache.org>
Sent: Saturday, May 10, 2003 12:56 AM
Subject: Jar file versioning questions


> One other thing I want to do is to build part of our application using OSS
and not proprietary software.  (yea!)  I have identified several Jakarta
projects that I could use to replace our proprietary software, including
>
> Maven/Ant - for build/project management
> OJB - object persistence
> Torque - generate ddl and java classes
> Tomcat - servlet container
> Avalon - services/component framework for app services
> Slide - WebDAV compatible cms
> log4J - logging module
> ECS - creating dynamic html/xml
> Struts - mvc stuff
> Velocity - would like that too, not sure how it fits in yet
> JUnit - test all this stuff
> Commons VFS - such a cool idea
>
> OK, I look at this and say "cool, how sweet would this be" then I start
looking at the dependencies for all of these software pieces and it's
ENORMOUS.  I'll probably have to include just about every project
distribution jar that is available from Jakarta.
>
> And therein lies the problem, each project above relies not only on a
dependency artifact but a particular artifact version as well.  Suppose
(hypothetically) all of the projects above require me to have in my runtime
classpath 5 different versions of log4J.  This is possible, right, because
each stable build of the projects above may have occured with log4J 1.2.5,
1.2.2, 1.2.1, 1.2.8, etc.
>
> I may have not gotten the right build versions correct with log4J, but I
think you'll understand my dilemma.  I'm afraid that there will be
compile/runtime exceptions galore if I attempt to integrate all of these
projects above into an Uber application.  I'll need 4 different versions of
commons-beanutils, 3 versions of commons-logging, 2 of jelly, all this
stuff.
>
> Am I completely wrong?  How am I supposed to handle this?  I know Maven
can handle versions of the same artifact but configuring the correct
classpath seems to be a trial and error process.  And with 50-100 jars, that
could be a long process!
>
> Any thoughts?
>
> Thanks, Steve
>
>
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org