TCK does contain the sigtest: https://github.com/jsr107/jsr107tck/tree/master/sigtest
Looking forward to getting the 1.0 version :) D. On Tue, Mar 29, 2016 at 11:12 PM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Le 30 mars 2016 01:45, "Dmitriy Setrakyan" <dsetrak...@apache.org> a > écrit : > > > > I just mention to mention that Apache Ignite passes JCache TCK with > flying colors :) > > > > True! Totally forgot tck were open! Didn't check sigtest, is it there too? > If so nothing blocking a 1.0. > > > We have it integrated into our build routine and verify it using our CI > tests. In addition, it was verified by one of the JCache spec leads, Greg > Luck, who confirmed that Ignite complies with the spec. > > > > Given the above, can Geronimo provide us with JCache 1.0 spec JAR? > > > > D. > > > > On Tue, Mar 29, 2016 at 1:41 PM, Romain Manni-Bucau < > rmannibu...@gmail.com> > wrote: > >> > >> ok, let me try to make it clearer (and don't hesitate to shout if still > not ;)): > >> > >> TCK are not only @Test but also some bianary validations (aka sigtest > >> or signature tests) the spec jars need to pass. It basically checks > >> you respect the spec signature for the supported java version of the > >> spec. Not having TCK and not being related to a public spec (like BVal > >> or JBatch) makes this sigtest validation missing @asf side so until we > >> get this or somebody checks generated bytecode of spec jars (and not > >> sources) then we'll not use final versions to not show a spec > >> compliance we maybe don't have. > >> > >> Romain Manni-Bucau > >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >> > >> > >> 2016-03-29 21:33 GMT+02:00 John D. Ament <johndam...@apache.org>: > >> > > >> > > >> > On Tue, Mar 29, 2016 at 3:04 PM Dmitriy Setrakyan < > dsetrak...@apache.org> > >> > wrote: > >> >> > >> >> We will switch the Ignite JAR to the 1.0-alpha-1 version from > Geronimo, > >> >> but I am still very confused. > >> >> > >> >> I do not understand why we need to check any TCK compliance when > creating > >> >> a JAR for the JSR107 spec. The TCK compliance should be checked > against an > >> >> implementation, not a spec. > >> >> > >> > > >> > I'm confused by this statement as well. TCK is only applied to impl > so not > >> > sure why you might think that. > >> > > >> > What Romain was trying to convey was that the alpha-1 release > indicates that > >> > no implementation has checked it as TCK compliant. One of the JSR > >> > requirements though is to produce a valid API JAR. If someone can do > that, > >> > then this can likely be promoted to a 1.0 release. > >> > > >> >> > >> >> Is there any place in Apache documentation explaining this process? > >> >> > >> >> D. > >> >> > >> >> On Mon, Mar 28, 2016 at 1:57 AM, Romain Manni-Bucau > >> >> <rmannibu...@gmail.com> wrote: > >> >>> > >> >>> Le 28 mars 2016 10:15, "Dmitriy Setrakyan" <dsetrak...@apache.org> > a > >> >>> écrit : > >> >>> > > >> >>> > 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? > >> >>> > > >> >>> > >> >>> Yes, while not passing sigtest practise is to not release 1.0. > >> >>> > >> >>> > D. > >> >>> > > >> >>> > > >> >>> > On Sun, Mar 27, 2016 at 9:01 AM, John D. Ament < > johndam...@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 > >> >>> >> <dsetrak...@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 < > >> >>> rmannibu...@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" < > dsetrak...@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 < > >> >>> rmannibu...@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 > >> >>> >>>> >> <dsetrak...@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 < > >> >>> >>>> >> dsetrak...@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 > >> >>> >>>> >> > > >> >>> >>>> >> > > >> >>> >>>> >> > >> >>> >>>> > > >> >>> >>>> > > >> >>> >>> > >> >>> >>> > >> >>> > > >> >> > >> >> > >> > > > > > >
