I prefer #1, since it decouples Spring 3 from Spring 4. For example,
Spring 4.1 is bringing many improvements on Cache [1], which I'm not
sure if it will available on 3.2.x maintenance branch.
[1]
http://spring.io/blog/2014/06/16/further-cache-improvements-in-spring-4-1
Gustavo
On Tue, Oct 14, 2014 at 2:23 PM, Sebastian Łaskawiec
<slaskawi(a)redhat.com> wrote:
Hey!
Currently I'm working on Spring 3 and 4 support and because these
versions are not compatible (in terms of Cache API), we probably would
need to have 2 modules for Spring.
Now the question is - how to maintain them? Here are the options which
comes into my mind:
1. Create copy of Spring 3 module and put everything into newly created
Spring 4, then update versions and implement new methods in Cache
interface.
Pros:
- 1 OSGi bundle - transparent upgrade - just replace spring bundle
- Easy to maintain Spring 4 only fixes
Cons:
- Code duplication
2. Extract common part and create 2 modules which depend on it - very
hard because Cache interface is logically at the bottom of the
structure. Everything depends on it.
Pros:
- No code duplication
Cons:
- Increased code complexity
- 2 bundles needed - common + spring 3/4
3. Make Spring 4 module depend on Spring 3 and replace Cache
implementations, run Maven Shade plugin to put everything together
Pros:
- No code duplication
Cons:
- Hacking into code, no intuitive design
- Will probably work in this specific case, further maintenance
might be hard.
4. Implement 2 missing methods in Spring module without @override
annotation. This way it should work against Spring 3 and 4
Pros:
- Really small change and single jar will support both spring 3
and 4
Cons:
- Spring version ranges in pom (not sure if it fits into
Infinispan design and BOMs)
- Not intuitive
I like option #1 - much easier maintenance + we might start using Spring
4 features without breaking Spring 3 module. Option #4 is also not that
bad...
Which option would you prefer?
Best regards
Sebastian
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev