I was thinking more along the lines of spring-jdbc for instance. But I understand what you're talking about.
On 9 June 2014 21:42, Gary Gregory <[email protected]> wrote: > JDBC is part of the JRE, as such I do not see the _need_ for it to be in a > separate jar, and personally I certainly do not _want_ it in a new jar. > > If you use JDBC, you MUST specify at least one other jar for your driver > (some driver are delivered as more than on jar, further complicating > things). Adding another jar on top of that for this or that connection > pooling is no big deal. > > If I had the time, I'd create a -all jar with a much as possible in one > place (like for our apps at work) that do all logging through Log4j. > > In general, for the third party components our products at work deliver > that are sliced and diced in a billion jars, it's such a pain to tell our > customer: oh, you want to use this bell or whistle, well, make sure you > have foo-feature1.jar in on your classpath, a different feature? ah, that's > in foo-feature2.jar. And gosh forbid that we forget to deliver one of those > little jar... some customers are not allowed to just fetch some jar from > the web and slap it on their servers, our product passes some review and > that's what they are allowed to use, no more. It is also not uncommon for > POM files and manifests to be incorrect, sometimes jars are not available > through Maven repos for our builds, and blah blah, I'm done ranting. > > Summary: the fewer jars, the better. And no we do not care too much about > OSGi as we are our own container. > > At least in Java 6 I can now add somedir/* to a classpath to pick up all > jars in a folder, which at least simplifies our apps start/stop scripts. > > Gary > > > On Mon, Jun 9, 2014 at 8:49 PM, Matt Sicker <[email protected]> wrote: > >> Using DriverManager on its own is rather worthless in this context, and >> we can't do much without connection pooling. Of course, the stuff that >> works via a DataSource would work well in theory since that should always >> be backed by a connection pooling library like dbcp2. However, it might be >> beneficial to provide support for that in a separate JAR with extra >> dependencies. That, or make it optional as usual. >> >> -- >> Matt Sicker <[email protected]> >> > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker <[email protected]>
