ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: JCache dependency
Date Mon, 28 Mar 2016 08:14:51 GMT
John,

I am still a bit confused. I was talking about the version of the JCache
spec API, essentially only interfaces. The spec does not have any
implementation, nor implies that every project importing or depending on
the spec must be compliant with the spec.

In my view implementation and TCK compliance are a different matter, and it
should be up to the project community itself to declare the compliance with
a certain spec and pass the TCK.

Am I wrong?

D.

On Sun, Mar 27, 2016 at 9:01 AM, John D. Ament <johndament@apache.org>
wrote:

> Dmitriy,
>
> I think what Romain is referring to is other TCKs.  Generally, geronimo
> JAR versions don't reflect the version of spec that they implement.  There
> may be alpha releases that match EDRs, or alphas that are based on the
> final version but with minor tweaks.
>
> For reference, Apache ActiveMQ Artemis relies on alpha2 of the JMS 2 spec.
> https://github.com/apache/activemq-artemis/blob/master/pom.xml#L131
> It's feature complete, and Artemis passes the TCK, its just alpha2 because
> we haven't done a thorough enough job of making sure the API is sane.
>
> John
>
>
> On Sun, Mar 27, 2016 at 11:54 AM Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
>
>> Romain, I am not sure what you mean by not having access to TCK. Are you
>> talking about validating compatibility with JCAche using the TCK [1]? In
>> this case, Apache Ignite does pass the TCK. Moreover, the TCK seems to be
>> licensed under Apache 2.0 [2]. Can you please explain?
>>
>> [1] https://github.com/jsr107/jsr107tck
>> [2] https://github.com/jsr107/jsr107tck/blob/master/LICENSE.txt
>>
>> On Sun, Mar 27, 2016 at 2:35 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>>
>>> Alpha cause asf doesnt have oracle tck so we cant validate binary compat
>>> but it targets jcache 1.0. More a legal thing than anything else. If you
>>> have access to tck and can validate the binaries we can move on 1.0
>>> Le 27 mars 2016 00:21, "Dmitriy Setrakyan" <dsetrakyan@apache.org> a
>>> écrit :
>>>
>>> > Hi Romain,
>>> >
>>> > The only issue I see is the version. JSR107 spec is on version 1.0.0
>>> [1],
>>> > while the Geronimo JCache jar is on version 1.0-alpha-1.
>>> >
>>> > Any chance you can upgrade the version?
>>> >
>>> > [1] https://github.com/jsr107/jsr107spec/tree/v1.0.0
>>> >
>>> > D.
>>> >
>>> > On Sat, Mar 26, 2016 at 1:36 PM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com
>>> > > wrote:
>>> >
>>> >> Hi Dmitriy,
>>> >>
>>> >> why not reusing geronimo jar? Generally @apache spec are owned by
>>> >> geronimo and reused as much as possible using geronimo as umbrella
>>> >> spec project. What's the issue you hit?
>>> >>
>>> >> Romain Manni-Bucau
>>> >> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>> >>
>>> >>
>>> >> 2016-03-26 21:20 GMT+01:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
>>> >> > Sorry, this is the JCache maven dependency I was referring to:
>>> >> >
>>> >>
>>> http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-jcache_1.0_spec
>>> >> >
>>> >> >
>>> >> > On Sat, Mar 26, 2016 at 1:18 PM, Dmitriy Setrakyan <
>>> >> dsetrakyan@apache.org>
>>> >> > wrote:
>>> >> >>
>>> >> >> Hello Geronimo community!
>>> >> >>
>>> >> >> I have noticed that Geronimo implements JCache spec and is
using
>>> its
>>> >> own
>>> >> >> JCache library hosted in Apache maven and licensed under Apache
2.0
>>> >> license
>>> >> >> [1].
>>> >> >>
>>> >> >> We, in Apache Ignite community also have implemented JCache
>>> >> specification
>>> >> >> and would like to do something similar. Do you know what steps
do
>>> we
>>> >> need to
>>> >> >> take in order to have the latest JCache spec version licensed
under
>>> >> Apache
>>> >> >> 2.0?
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Dmitriy Setrakyan
>>> >> >> Apache Ignite, PMC chair
>>> >> >
>>> >> >
>>> >>
>>> >
>>> >
>>>
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message