[infinispan-dev] Multiple Spring modules

[Gustavo Fernandes]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev