Hi, Think there are multiple points there and we should absolutely avoid a compliance flag in owb-core/se modules until it is requires and we ack the change. For other changes (the one we dont want, we can just use our spi mecanism and change the behavior in an owb-compliancy module maybe.
For me the points are: * Did the spec broke something for good -> add a toggle * Did the spec broke without reason -> need to check if intended, if so compliancy module else ignore * Is the spec clear about the impl it expects (for ex it is not for container events) -> if yes then impl else discuss and if no compromise then compliancy module Side note: if the toggle is a one liner the compliancy module just enables it in openwebbeans.properties, no need to split the impl in multiple parts or add a SPI if simple. Overall my fear right now is core become bloated because each version of the spec adds what is already there but in a new package or way so I hope we can keep a core light and be compliant in a module marked as "they did it wrong but you can get it too". Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 27 févr. 2023 à 20:58, Jean-Louis Monteiro <jlmonte...@tomitribe.com> a écrit : > 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 >
