search

osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

[RFC 193] Require that a CDI implementation provide an osgi.contract for javax.inject package #2430

Closed bjhargrave closed 10 years ago

bjhargrave commented 11 years ago

Original bug ID: BZ#2562 From: @bosschaert Reported version: R6

bjhargrave commented 11 years ago

Comment author: @bosschaert

Currently the CDI CT simply does an import of the javax.inject package, but it must be modified to import this package as follows

Import-Package: javax.inject Require-Capability: osgi.contract; filter:="(&(osgi.contract=JavaInject) (version=1.0))"

bjhargrave commented 11 years ago

Comment author: @bjhargrave

Not sure this is a must. The CT certainly can require the contract assuming all providers of javax.inject package provide the contract. A safer and simpler thing would be to just import the package a the [1.0,2.0) version range since there are no other versions than 1.0 and there is only a single package involved.

bjhargrave commented 11 years ago

Comment author: @bosschaert

(In reply to BJ Hargrave from comment BZ#1)

Not sure this is a must. The CT certainly can require the contract assuming all providers of javax.inject package provide the contract. A safer and simpler thing would be to just import the package a the [1.0,2.0) version range since there are no other versions than 1.0 and there is only a single package involved.

I don't think I agree. It's all about eating your own dogfood and while the javax.inject package might be uncontroversial, this is not true for other packages in other CTs and I think we should be consistent in our approach here.

Additionally using the requirement in the CT also allows us to test that the implementation actually provides the capability, which it should.

bjhargrave commented 11 years ago

Comment author: @bjhargrave

(In reply to David Bosschaert from comment BZ#2)

I don't think I agree. It's all about eating your own dogfood and while the javax.inject package might be uncontroversial, this is not true for other packages in other CTs and I think we should be consistent in our approach here.

Additionally using the requirement in the CT also allows us to test that the implementation actually provides the capability, which it should.

Remember, the CT is a compliance test not a functional test or a system test. And so its purpose is to test assertions in the spec. Unless there is an assertion that the CDI spec implementation must provide the JavaInject contract, requiring that contract in the CT is testing an unspecified assertion and will fail on valid implementations of the CDI spec that do no provide a JavaInject contract.

I looked at RFC 183 and nowhere in the technical design does it mention a JavaInject, or any other, contract.

bjhargrave commented 11 years ago

Comment author: @bosschaert

(In reply to BJ Hargrave from comment BZ#3)

I looked at RFC 183 and nowhere in the technical design does it mention a JavaInject, or any other, contract.

Right, I agree that if the CT is going to test for it the RFC and spec should mention it.

bjhargrave commented 11 years ago

Comment author: @bjhargrave

(In reply to David Bosschaert from comment BZ#4)

Right, I agree that if the CT is going to test for it the RFC and spec should mention it.

Then this bug can be re-purposed to request a change to the RFC to mandate that the JavaInject (and other) contract be provided by implementations.

bjhargrave commented 11 years ago

Comment author: @bosschaert

Done.

bjhargrave commented 11 years ago

Comment author: @bosschaert

(In reply to David Bosschaert from comment BZ#6)

Done.

Clarification, this means that the repurposing of this bug is done, not that the actual decision has been made yet...

bjhargrave commented 11 years ago

Comment author: @bosschaert

EEG call: The CDI CT can start using the contracts. Need to update the RFC accordingly.

bjhargrave commented 11 years ago

Comment author: @bjhargrave

(In reply to David Bosschaert from comment BZ#8)

EEG call: The CDI CT can start using the contracts. Need to update the RFC accordingly.

We agreed that it was OK for the CT implementation to make progress using the contract. No agreement was reached that it was the correct thing to do in the final CT. Further discussion is warranted.

bjhargrave commented 10 years ago

Comment author: @bosschaert

I added a section for this to RFC 193. Closing the bug as the discussion can continue in the RFC.