might want to make jcl-over-slf4j an optional or provided or test dependency
if you try and use cascal on a project/vm that already has slf4j-jcl on the classpath (like trying to write a cassandra persistence adapter for activemq (ticktock/qsandra ; ) ) you get something like this
Caused by: java.lang.StackOverflowError at java.util.HashMap.get(HashMap.java:298) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:153) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:289) at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:69) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:243) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:289) at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:69) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:243) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
probably want to leave the decision as to if/whether to push JCL of slf4j or slf4j over jcl to the end user of cascal
I'll check it out. Currently switching jobs so I haven't got the project setup on my new computer - but I'll take a peek in a bit. I don't see why I would of done this purposely, so either I wasn't thinking or there was some reason I can't remember. Either way I'll investigate and try to get back to you.
no problem, its just a simple excluson placed in the cascal dependency as a workaround but thought Id let you know what i saw...