Hello guys, I've been spending a couple of days trying to figure out what the spec says or does not. I also looked at the TCK tests we currently do not pass as well as what OWB/Weld do in both situations. I've also augmented the TCK tests to understand and test some other edge cases.
*Important note*: I created a couple of challenges already and PRs to fix the spec/TCK and I'm happy to create more challenges. Mind that the process to create challenges is very well defined https://jakarta.ee/committees/specification/tckprocess/ In essence, a challenge cannot be filed if we don't agree with the spec or if the spec is stupid, or else. We can only fill a challenge, if the TCK does not match something in the spec, if it's more restrictive, etc. << Good or bad, the spec is as it is now. The past/future does not matter >> I'm not sure about the history and if the spec evolved in the past and we did not follow, or if the spec introduced things we did not agree on and decided to not implement. As of now, we need changes if we want to ever be compliant. I'd like to discuss how to handle the breaking changes. I do think if we claim to implement CDI we must implement it all and correctly. I'm ok if we have a "compliance" flag if we don't want to break backward compatibility. But to me, it's a major version and jakarta namespace is already a huge backward compatibility issue. So for sure it's preferred we catch up with all breaking changes now and participate in the spec so we avoid future backward compatibility issues. If we don't do it now, of course it will be harder to do it later for our users and it means we'll never be able to claim compliance. It is obviously not a vote. But I think it's an important discussion. What do you think? -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
