Denis Magda created IGNITE-4649:
---
Summary: Upgrade JCache dependency when Apache 2.0 license
migration finalized
Key: IGNITE-4649
URL: https://issues.apache.org/jira/browse/IGNITE-4649
Project: Ignite
Just checked and our spec jar passes sigtest. Not sure for this week
but think we can run a vote next one if nobody objects - don't
hesitate to ping if nothing happens ;).
Romain Manni-Bucau
@rmannibucau | Blog | Github | LinkedIn | Tomitriber
2016-03-30 9:20 GMT+02:00 Dmitriy Setrakyan
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
wrote:
> Le 30 mars 2016 01:45, "Dmitriy Setrakyan" a
>
Le 30 mars 2016 01:45, "Dmitriy Setrakyan" 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
I just mention to mention that Apache Ignite passes JCache TCK with flying
colors :)
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
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
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.
Is there any
Le 28 mars 2016 10:15, "Dmitriy Setrakyan" 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
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
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]
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" a écrit :
> Hi
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
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
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
wrote:
> Hello Geronimo community!
>
> I have noticed that Geronimo
14 matches
Mail list logo