From: <jue...@we...> - 2003-02-18 15:45:07
|
"Reply to" address, a second time... =20 =20 -----Urspr=FCngliche Nachricht----- Von: j=FCrgen h=F6ller [werk3AT]=20 Gesendet: Freitag, 14. Februar 2003 21:00 An: Rod Johnson Betreff: Re: [Springframework-developer] Optional dependencies Rod, =20 Let's simply include the relevant JARs in the CVS lib directory. = Developers shouldn't care about some additional JARs even if they aren't = interested in them. The same rule applies to the current view = implementations that depend on Velocity and co. Of course, a dependency = table is a must, at least at the subpackage level of the Spring = codebase. =20 Regarding Struts: I guess it should be possible to include only the = relevant JARs and ignore the convenience stuff, like some of the Commons = packages. Ideally, that would mean just a struts.jar, not the whole army = that comes with a Struts distribution. Of course, the unit tests need to = be able to run, so this might be more sophisticated that I assume. =20 Concerning the distribution: I don't mind including such classes in the = standard Spring JARs, as they wouldn't need any of the third party = libraries if they are not actually used at runtime. I've used that = approach successfully numerous times within application projects, for = example in terms of separation of remote client and server classes, or = web application and applet codebase. Spring users that want to enable a = plugin should have to download the respective libraries from the third = party's site. That instructions need to be mentioned in a readme.=20 =20 Take for example Tomcat 4.x: Its distribution includes Tyrex-dependent = factory classes for its JNDI resource manager even though it doesn't = include the Tyrex libraries. Users have to download the Tyrex libraries = themselves from the ExoLab site. I don't know about Tomcat's CVS = contents, but I assume that the developers do have the Tyrex libraries = there. =20 In terms of repository size, including third party libraries should not = make a big difference. I assume that those libraries will change rarely, = at least in the Spring CVS, as we don't need to follow every minor = update. So CVS updates will usually ignore them and not cause additional = download traffic after initial checkout. =20 Regards, Juergen =20 =20 -----Urspr=FCngliche Nachricht-----=20 Von: Rod Johnson [mailto:rod...@in...]=20 Gesendet: Fr 14.02.2003 07:57=20 An: spr...@li...=20 Cc:=20 Betreff: [Springframework-developer] Optional dependencies =09 =09 Guys, =09 I've just been discussing our forthcoming Struts integration with Yann = and Paul. =09 This raises a problem that's likely to recur. This will probably = involve adding a small number of classes that are Struts-dependent. But not all developers might be interested in them. =09 In the following, read "Struts" to mean "any third party product some classes will depend on but which aren't of interest to everyone". =09 How can we prevent our whole source tree being Struts-dependent and = prevent developers uninterested in Struts from having to download the relevant = Jars? * Make it a separate CVS module? But this will lead to a profusion of = CVS modules. Harder to build etc. * Put it in the main module and change the Ant build script to compile = the necessary classes and run the the relevant tests only if it finds = Struts on the classpath? This could eventually make the build script very long = and complicated. * Better ideas I haven't thought off?? How do other projects handle = this? =09 From a distribution point of view, many users won't want the Struts = classes either. We could make them a sep download. Or we could just include = them in one of the main Jars, and they wouldn't do any harm unless they were = used without Struts. =09 From a documentation view, we'll also need a dependencies table, = showing what depends on what. =09 Regards, Rod =09 ____________________________________________________ Rod Johnson J2EE Architect and Author +44 7973 409 132 =09 Author of "Expert One-on-One J2EE Design and Development" (Wrox Press, October 2002). http://www.amazon.com/exec/obidos/tg/detail/-/1861007841/ =09 http://www.wrox.com/books/1861007841.htm =09 http://www.wrox.com/dynamic/books/find.aspx?author=3DRod+Johnson =09 =09 =09 =09 ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer =09 |