We use Eclipse and have around 130 external jar dependencies. Any external jar needs to be moved in a common folder in dev, test and production. All the components are pulling their external dependencies from this single folder, no per component private jars are allowed. All of them are in the class path of all the JVMs we start as soon as the code gets in test. We add our own generated jars to this folder when we migrate in test and all of this is migrated to prod when ready.
The only exception to this are some standalone components we need to generate using leiningen. We use an internal maven repository to store our artifacts and we manage our project.clj files accordingly. Checking them against a common folder content is easy to make sure they do not pull anything odd. In dev, we use the same principles but allow people to pull out only the jars needed for dependencies from this common folder in the class path of individual projects. Our internal project dependencies are managed with Eclipse and whatever is in our source repository, at this stage we do not use jars for our own stuff. They are created when ready to migrate to test. We find it easier to control common jar versions this way than spreading subsets everywhere. A change of version of a common jar file is obvious and we would rather deal with it early in the dev cycle than find out later that different versions are used by different components. We are looking at improving synchronisation (keeping the project.clj files, the common folder content and our maven repo) automation but it's a lot less work than letting this loose. As Stuart said, there's no significant overhead until you start to ask to load classes. Luc P. On Sun, 2010-05-23 at 21:22 -0700, Imran wrote: > Ok, so as long as I manage jar versions appropriately, there's not > much to be gained by selectively including jars on the CLASSPATH. Just > put them all in there. > > Thanks Stuart. > > On May 23, 6:54 pm, Stuart Campbell <stu...@harto.org> wrote: > > > JVM newbie question here. Aside from the clojure & clojure-contrib jars, > > > is > > > there any downside to automatically setting up my CLASSPATH so that all > > > jars > > > on my box are available - even if I might only be using 1 or 2 for the > > > code > > > I'm working on at the moment? > > > > The problem with such a scheme is inclusion of multiple versions of the same > > library. This can result in obscure 'unresolved compilation' errors cropping > > up when you try to use a method or class that doesn't exist in whichever > > library the JVM happened to choose. > > > > Does the jvm do any expensive initialisation for each jar? Or does it not > > > > > make a difference until I explicitly import a jar in my clojure code? > > > > I don't think it would make a difference. Static initialisation etc. doesn't > > happen until a class is explicitly loaded. > > > > Regards, > > Stuart > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group > > athttp://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
