Consider merging ri-common into ri-implementation

[brianoliver]

There's no use of the ri-common outside the ri-implementation.

Given this we should merge the ri-common into the ri-implementation to reduce the number of artifacts we need to build, distribute and for Glassfish (et al) to use.

This would also remove the need to have some duplicate classes in a few places. eg: CacheConfiguration implementations.

[gregrluck]

Fine with me.

On 30/11/2012, at 2:44 AM, Brian Oliver notifications@github.com wrote:

There's no use of the ri-common outside the ri-implementation.

Given this we should merge the ri-common into the ri-implementation to reduce the number of artifacts we need to build, distribute and for Glassfish (et al) to use.

This would also remove the need to have some duplicate classes in a few places. eg: CacheConfiguration implementations.

— Reply to this email directly or view it on GitHub.

Regards

Greg Luck

web: http://gregluck.com skype: gregrluck yahoo: gregrluck mobile: +61 408 061 622

[brianoliver]

Done. This simplified things a lot. Together with Issue #83, both the RI and TCK are easier to work with in terms of configuration. It also removes several duplicated classes.

[ryangardner]

I didn't see this come up, but the idea behind the cache-ri-common was to make it easy to implement. The stuff that was in the cache-ri-common was intended to be reusable by others implementing the spec.

The RI-common was in fact used by other places such as the two existing non-RI impls of the spec:

https://github.com/yannis666/Coherence-JSR-107/blob/master/jsr107/pom.xml

or

https://github.com/jsr107/ehcache-jcache/blob/master/pom.xml

Not having the ri-common will require implementers to either choose between copying-and-pasting large swaths of boilerplate code out of the RI (which both Yannis and I found ourselves very tempted to do when actually implementing the spec)

The idea was to keep the cache-ri-impl to be the non-performance-critical piece and to have the cache-ri-common contain only code helpful for implementers and have the code in there be held to a higher production-quality standard that the cache-ri-impl.

[yannis666]

I too was not that happy to see commons get deleted for these reasons. I updated yannis666 (coherence adapter) some time ago but keeping it in sync is getting harder without commons.

Incidentally does anyone know if there is an oracle supported coherence adapter? Also what is the status of the eh cache adapter - I think the spec has moved quite a bit recently On Jan 14, 2013 1:24 PM, "Ryan Gardner" notifications@github.com wrote:

I didn't see this come up, but the idea behind the cache-ri-common was to make it easy to implement. The stuff that was in the cache-ri-common was intended to be reusable by others implementing the spec.

The RI-common was in fact used by other places such as the two existing non-RI impls of the spec:

https://github.com/yannis666/Coherence-JSR-107/blob/master/jsr107/pom.xml

or

https://github.com/jsr107/ehcache-jcache/blob/master/pom.xml

Not having the ri-common will require implementers to either choose between copying-and-pasting large swaths of boilerplate code out of the RI (which both Yannis and I found ourselves very tempted to do when actually implementing the spec)

The idea was to keep the cache-ri-impl to be the non-performance-critical piece and to have the cache-ri-common contain only code helpful for implementers and have the code in there be held to a higher production-quality standard that the cache-ri-impl.

— Reply to this email directly or view it on GitHubhttps://github.com/jsr107/jsr107spec/issues/74#issuecomment-12240526.

[redlab]

A bit late, since it's already removed, but nothing stops us from re-abstracting a common package, perhaps this is a good idea to do it after the spec has been totally finalized and you guys know what you have been copy pasting from the RI all the time.

[ryangardner]

This makes sense. If it would simplify the process for others I could set up an unofficial jsr107 common project for implementors that would have the goal of making it easy to create a compliant implementation without having to have each implementation copy/paste from the RI - we could have less pressure on that one and as Greg mentioned the RI is Apache 2 so as long as we provide attribution a lot of the common code could be copied over On Jan 15, 2013 4:44 AM, "Balder VC" notifications@github.com wrote:

A bit late, since it's already removed, but nothing stops us from re-abstracting a common package, perhaps this is a good idea to do it after the spec has been totally finalized and you guys know what you have been copy pasting from the RI all the time.

— Reply to this email directly or view it on GitHubhttps://github.com/jsr107/jsr107spec/issues/74#issuecomment-12259567.

[vblagoje]

Ok, good idea @redlab and @ryangardner . I'll do the same - copy the boilerplate with attribution until we reach a somewhat mature JSR impl and hopefully by then we'll have some sort of mutual and beneficial agreement on how to proceed. Thank you all.

[brianoliver]

Initially the objective of the RI was that it wouldn't necessarily be performant and thus "useful" for anyone. It was simply to implement the spec semantics. This very point has changed. The objective of the RI is to provide a useful (but feature limited compared to say vendor solutions) that would be suitable for inclusion, say in Java SE/EE.

To that end, the ri-commons provided zero benefit to anyone as the RI implementation itself, once refactored, didn't use it. ie: we had an ri-commons project that we ourselves (apart from simple adapters) didn't use.

After the configuration refactoring it became even clearer that ri-commons had even less utility. eg: The Coherence Adapter wouldn't use it. From looking at the EH Cache Adapter, neither would it.

Note: this is very different from the annotations commons module - which is used across the different annotations implementations!

Lastly, based on discussions with a few of the potential implementors (vendors), it seems no one has any use for ri-commons.

For these reasons we removed it. It simplified a number of RI issues, including making the dependencies simpler.

[brianoliver]

Regarding the "Oracle Coherence Adapter", I understand an "official" implementation is planned.

[redlab]

Very valid point by @brianoliver . And if it is indeed the plan to include the RI in java SE/EE as a basic implementation (first must see it happen though. Those who want can use it from there.