I don't have a problem with dependencies, as long as we have a reasonable need of them. Velocity is pretty much required for code generation. Runtime might be a different story.
On Thu, Dec 19, 2013 at 6:31 AM, Andrus Adamchik <[email protected]> wrote: > Aha, JdbcPkGenerator uses SQLTemplate internally. Should probably change that. > > FWIW, Velocity dependency bothers me more than the recently discussed > commons-logging. > > A. > > On Dec 19, 2013, at 4:37 AM, Mike Kienenberger <[email protected]> wrote: > >> The commons-lang dependency looks like it may have to do with primary >> key generation. This is an h2 database using the default pk generator >> -- I haven't taken the effort to set up sequences yet. >> >> Exception in thread "main" java.lang.NoClassDefFoundError: >> org/apache/commons/lang/StringUtils >> at >> org.apache.velocity.runtime.VelocimacroFactory.initVelocimacro(VelocimacroFactory.java:189) >> at >> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:261) >> at >> org.apache.cayenne.access.jdbc.SQLTemplateProcessor.initVelocityRuntime(SQLTemplateProcessor.java:84) >> at >> org.apache.cayenne.access.jdbc.SQLTemplateProcessor.<clinit>(SQLTemplateProcessor.java:58) >> at >> org.apache.cayenne.access.jdbc.SQLTemplateAction.performAction(SQLTemplateAction.java:102) >> at >> org.apache.cayenne.access.DataNodeQueryAction.runQuery(DataNodeQueryAction.java:87) >> at org.apache.cayenne.access.DataNode.performQueries(DataNode.java:280) >> at >> org.apache.cayenne.dba.JdbcPkGenerator.longPkFromDatabase(JdbcPkGenerator.java:310) >> at >> org.apache.cayenne.dba.JdbcPkGenerator.generatePk(JdbcPkGenerator.java:268) >> at >> org.apache.cayenne.access.DataDomainInsertBucket.createPermIds(DataDomainInsertBucket.java:171) >> at >> org.apache.cayenne.access.DataDomainInsertBucket.appendQueriesInternal(DataDomainInsertBucket.java:76) >> at >> org.apache.cayenne.access.DataDomainSyncBucket.appendQueries(DataDomainSyncBucket.java:78) >> at >> org.apache.cayenne.access.DataDomainFlushAction.preprocess(DataDomainFlushAction.java:188) >> at >> org.apache.cayenne.access.DataDomainFlushAction.flush(DataDomainFlushAction.java:144) >> at org.apache.cayenne.access.DataDomain.onSyncFlush(DataDomain.java:853) >> at org.apache.cayenne.access.DataDomain$2.transform(DataDomain.java:817) >> at >> org.apache.cayenne.access.DataDomain.runInTransaction(DataDomain.java:877) >> at >> org.apache.cayenne.access.DataDomain.onSyncNoFilters(DataDomain.java:814) >> at >> org.apache.cayenne.access.DataDomain$DataDomainSyncFilterChain.onSync(DataDomain.java:1031) >> at org.apache.cayenne.access.DataDomain.onSync(DataDomain.java:785) >> at >> org.apache.cayenne.access.DataContext.flushToParent(DataContext.java:817) >> at >> org.apache.cayenne.access.DataContext.commitChanges(DataContext.java:756) >> at >> org.gamenet.duplicateFileOrganizer.DuplicateFileOrganizer.categorizeDirectory(DuplicateFileOrganizer.java:50) >> at >> org.gamenet.duplicateFileOrganizer.DuplicateFileOrganizer.main(DuplicateFileOrganizer.java:25) >> Caused by: java.lang.ClassNotFoundException: >> org.apache.commons.lang.StringUtils >> at java.net.URLClassLoader$1.run(URLClassLoader.java:366) >> at java.net.URLClassLoader$1.run(URLClassLoader.java:355) >> at java.security.AccessController.doPrivileged(Native Method) >> at java.net.URLClassLoader.findClass(URLClassLoader.java:354) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) >> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) >> ... 24 more >> >> On Wed, Dec 18, 2013 at 11:59 AM, Mike Kienenberger <[email protected]> >> wrote: >>> On Wed, Dec 18, 2013 at 11:43 AM, Andrus Adamchik >>> <[email protected]> wrote: >>>> “Got hit” in what way? >>> >>> Got hit with a ClassNotFound exception if I remember right. >>> I'll try to provide a stack trace the next time I turn that system on. >>> >>> >>>> Are you using Maven? >>> >>> No, this is a simple just-started project in Eclipse at this point >>> with no build system. >>> >>> >>>> On Dec 18, 2013, at 7:21 PM, Mike Kienenberger <[email protected]> wrote: >>>> >>>>> Yes, commons-lang is from velocity. I'm not using SQLTemplate nor >>>>> EJBQL so far as I can tell, but I still got hit with the dependency on >>>>> a new 3.1 project. I haven't been required to have oro, only >>>>> commons-lang. >>>>> >>>>> On Wed, Dec 18, 2013 at 1:53 AM, Andrus Adamchik <[email protected]> >>>>> wrote: >>>>>> Cayenne does not have commons-lang dependency. I think it is a >>>>>> dependency of Velocity. Velocity 1.6.3 depends on commons-lang 2.4 (and >>>>>> also oro 2.0.8 - why in the world people would still use oro?) >>>>>> >>>>>> So commons-lang will be needed if you are running SQLTemplate and EJBQL >>>>>> queries (that are using Velocity). Yeah, I think we need to somehow >>>>>> address that either in the docs and/or by packaging those in >>>>>> third-party/ .. >>>>>> >>>>>> I also wish we reduce / remove our dependency on Velocity. Then we’ll be >>>>>> pretty close to dependency-free holy grail for a typical user :) >>>>>> >>>>>> A. >>>>>> >>>>>> On Dec 18, 2013, at 6:08 AM, Mike Kienenberger <[email protected]> >>>>>> wrote: >>>>>>> This was on the windows distribution. I haven't checked the other ones. >>>>>>> >>>>>>> On Tue, Dec 17, 2013 at 10:07 PM, Mike Kienenberger >>>>>>> <[email protected]> wrote: >>>>>>>> We state: >>>>>>>> >>>>>>>> ============= >>>>>>>> >>>>>>>> When using cayenne-server-x.x.jar you'll need a few third party jars >>>>>>>> (all included in lib/third-party directory of the distribution): >>>>>>>> >>>>>>>> Apache Velocity Template Engine, version 1.6.x (and all its >>>>>>>> dependencies bundled with velocity-dep) >>>>>>>> >>>>>>>> Apache Commons Collections, version 3.2.1 >>>>>>>> >>>>>>>> Apache Commons Logging, version 1.1 >>>>>>>> ============= >>>>>>>> >>>>>>>> http://cayenne.apache.org/docs/3.1/cayenne-guide/including-cayenne-in-project.html#jar-files-and-depdendencies >>>>>>>> >>>>>>>> However, we are missing commons-lang-2.6 >>>>>>> >>>>>> >>>>> >>>> >> >
