This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Most (if not all) of the dependencies you listen can't be found on ibiblio. Spring Modules provides them in the -with-dependencies distribution. There is also an ivy.xml file which contains URLs for downloading the jars (note that most of the URLs are not maven repositories).

Comment

In the pom, would it be possible to mark the non-essential dependencies as <optional>true</optional>? For example, if my project only needs EhCache, I don't necessarily want to pull in JBossCache support (or vice versa). What are your thoughts?

Comment

What is the minimal required dependencies to get declarative caching working with JCS

Hi,

First of all, like what this original post says, there are many dependencies that are missing from the maven repository. I suppose you support ivy, but not maven fully.

But since I'm using maven, I want to figure out the right set of dependencies to do what I need. I want to be able to use declarative caching with JCS, so I want to exclude everything else. But I'm not 100% sure what I can exclude, so it'll be great if you can let me know what are the dependencies that I need for sure.

I'm not sure if I am supposed to use some other maven2 repository (apart central)?
Or I have to provide all these dependencies manually?

I strongly believe that the Caching Module should be split up in the following manner.

The core classes should be placed in a 'project' called cache-core (Or something else) followed by multiple providers. A provider would be something like ehcache, jboss, etc. This allows the end developer to select only the provider(s) he needs in his project without having to add multiple excludes. E.g.,

Comment

I strongly believe that the Caching Module should be split up in the following manner.

The core classes should be placed in a 'project' called cache-core (Or something else) followed by multiple providers. A provider would be something like ehcache, jboss, etc. This allows the end developer to select only the provider(s) he needs in his project without having to add multiple excludes. E.g.,

Comment

I strongly believe that the Caching Module should be split up in the following manner.

The core classes should be placed in a 'project' called cache-core (Or something else) followed by multiple providers. A provider would be something like ehcache, jboss, etc. This allows the end developer to select only the provider(s) he needs in his project without having to add multiple excludes. E.g.,

Is there any plan to do this for SpringModules? I'll be more than willing to submit a fix for this if Spring is willing to accept it.

Best Regards,
Richard L. Burton III

even better should be including in your pom
<dependency>
<groupId>org.springmodules.cache</groupId>
<artifactId>ehcache-provider</artifactId>
<version>0.9</version>
</dependency>
and the cache-core should be a dependency of ehcache-provider

Comment

I agree, this is a huge pain. I'm not a Maven user, but use Ivy instead. Ideally, Spring's own Ivy repository would include Spring Modules (It amazes me that they don't even publish to their own repository), but a Maven repository somewhere would be fine, too, as I can load my Ivy repo from a public Maven repo.

A huge part of the Spring community uses dependency mgmt tools like Maven and Ivy, so having to do it manually seems like an unnecessary step.

Comment

There seems to be no resolution to this issue even today, 3 years after it has been posted.
Are spring-modules (especially cache) still active? Any plans to make a life a bit easier for people using maven?