Robo wrote:
Hello Al.
I worked on some big project where Maven was used(or misused) and form that tme
I refuse to solve Maven troubles so Skipping the Maven stuff as this is nto the
case:
I used to manage dependencies myself and I buil Hello WOrld Application from
scratch. Just Hello World. Until I put velocity-1.4.jar and
velocity-dep-1.4.jar I have got following errors at deploy time.
--------------------
5.9.2007 14:31:37 org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter HelloWorldApplication
java.lang.NoClassDefFoundError:
org/apache/commons/collections/ExtendedProperties
at
org.apache.velocity.runtime.RuntimeInstance.(RuntimeInstance.java:160)
at
org.apache.velocity.runtime.RuntimeSingleton.(RuntimeSingleton.java:95)
at org.apache.velocity.app.Velocity.init(Velocity.java:106)
.....
5.9.2007 14:31:38 org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter HelloWorldApplication
java.lang.NoClassDefFoundError:
org/apache/commons/collections/ExtendedProperties
at
org.apache.velocity.runtime.RuntimeInstance.(RuntimeInstance.java:160)
at
org.apache.velocity.runtime.RuntimeSingleton.(RuntimeSingleton.java:95)
at org.apache.velocity.app.Velocity.init(Velocity.java:106)
.....
--------------------
So there is sure dependency in Wicket why developer needs to include these two
velocity packages. This is the plus and cons of self managing libraries ... :-)
You say, "until I put velocity-1.4.jar", but if you look at your stack
trace, you'll see it's actually bitching about your not having
commons-collections (or not the right version at least). It's running
code in org.apache.velocity.app.Velocity, which means that it can find
that class, which means you're including it from somewhere (i.e. you
must have velocity.jar on your classpath already, even if you didn't
think you did).
That commons-collections class appears to be included by
velocity-dep.jar, which is a pretty hideous way of doing things IMO, as
it'll probably break things if you include commons-collections
separately, etc.
Anyway...
Wicket categorically does not require Velocity for standard usage.
You don't provide a complete stack trace, or any further information
about what you're doing. If you did, we might be able to point out why
you're having issues.
"....." isn't very helpful. ;-)
Sure one can find libraries in examples folder but this is not conceptual
aproach. I need runtime libraries and expect them exactly where they has to be
and not looking for needed libs in examples/demo/tutor directories. There is so
much wicket*.jar duplicated libraries that duplicating log4j and velocity is
minor in package size question. So if you do not want duplicity do not
duplicate even wicket libs, or if you wanrt completness include also libs
needed to be wicket usable out of the box :-)
It's not just log4j and velocity. 3rd party libraries for
wicket-examples total 6Mb out of the 8Mb in the lib folder. That is not
minor - it's 75% of the size of the WAR and thus the distribution, give
or take.
That said, maybe we should provide a separate ZIP with the dependencies.
I guess if you're using Ivy or Maven 2, you're not going to be
downloading the ZIP at all. There may be licensing issues with this,
though. What do people think? Martijn?
Regards,
Al
--
Alastair Maw
Wicket-biased blog at http://herebebeasties.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
