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 <[email protected]> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
