well, the javax.* namespace is not a problem. We do all those centralized over in the geronimo specs project [1][2]. There you find all EE specs with ALv2 licenses. This is perfectly fine and there is also no legal issue involved. We need the jcache-api jar anyway, so this would be a good chance to hack it down.
The implementation itself is another story. We can of course use the JSR-107 annotations and should at least 'loosely' follow the specification. But as long as we do not claim we are a compliant JCache implementation we do not need to implement all the functionality and pass the TCK. I quickly did read through the spec license and it's full of the usual nonsense which doesn't hold in front of any court and is only there to shy away small kids ;) The TCK is available for Open Source projects free of charge it seems. Well we are drifting away it seems. Imo we should only do a minimal implementation which might use some JSR-107 annotations if they area of any help - but if we aim to do a full implementation then this should be a project completely on it's own. LieGrue, strub [1] https://svn.apache.org/repos/asf/geronimo/specs/trunk/ [2] http://repo1.maven.org/maven2/org/apache/geronimo/specs/ ----- Original Message ----- > From: Harald Wellmann <[email protected]> > To: "[email protected]" > <[email protected]> > Cc: > Sent: Saturday, December 8, 2012 7:25 PM > Subject: Re: Cache module > > Hi all, > > thanks for your feedback. > > This module draft is just a spin-off of migrating an application from > Spring 3.1 to Java EE 6 and I didn't really have JSR-107 on radar at > that time. > > On the one hand, I'm all for being standard-compatible, on the other > hand, I'd rather have a working solution soon than a JSR-107 compliant > implementation some time in 2014... > > Then there's the issue about the javax.* namespace. As long as the JSR > isn't finalized, I'm not sure if its a good idea or even legally > possible to publish implementations containing API classes in this > namespace. There is a javax.cache 0.2 artifact on Maven Central but > that's not in sync with the sources at > https://github.com/jsr107/jsr107spec (0.6-SNAPSHOT). > > To have the best of both worlds, org.apache.deltaspike.cache.api could > be made syntactically equivalent to a current javax.cache version to > minimize the impact on users. Ideally, they'd only have to rename > packages in their own sources once javax.cache is released. > > What do you think? > > Best regards, > Harald > > Am 08.12.2012 17:03, schrieb Adrian Gonzalez: >> Hello, >> >> Looks interesting, but why don't you use JCache CDI annotations as > mentioned in [1] ? >> >> I know that JCache isn't finished yet, but I think it's already > usable. >> I'm using them in a sample app and it works great with ehcache impl > (using 0.4 version). >> >> Perhaps I've missed something though. >> If not, aren't we going to duplicate standard > javax.cache.interceptor.CacheResult annotation with > org.apache.deltaspike.cache.api.Cacheable ? >> >> [1] http://java.dzone.com/articles/using-cdi-access-infinispan >> >> Extract from [1] : >> @CacheResult(cacheName="user-cache") public User findUser(long > id) { User user = …; // retrieve the user with the given id return user; } >> >> ________________________________ >> De : Harald Wellmann <[email protected]> >> À : [email protected] >> Envoyé le : Samedi 8 décembre 2012 15h57 >> Objet : Cache module >> >> I've started working on what might become a new DeltaSpike module for > caching, see https://issues.apache.org/jira/browse/DELTASPIKE-282. >> >> The sources are at >> > https://github.com/hwellmann/incubator-deltaspike/tree/hwellmann/deltaspike/modules/cache >> >> If you think this is useful, please let me know what it takes to get this > stuff into DeltaSpike. >> >> Best regards, >> Harald >> >
