asbachb commented on PR #6212: URL: https://github.com/apache/netbeans/pull/6212#issuecomment-1657100710
@matthiasblaesing what do you think about splitting the question if the used ejb spec is technical compatible vs functional compatible? Like `TechnicalEJBCompatibility` vs `FunctionalEJBCompatibility` where things could be handled differently. Big picture: I want to lower the maintenance efforts needs to be done by a maintainer / contributor. Fact is that some enterprise features are broken (like the missing button) based on the fact that a new method was introduced to `J2eeProjectCapabilities`, but the calls to the `isEjbXX` was not analyzed. So NetBeans interpreted this that EJB 4 does not provide the same functionality as EJB 3.1. When we'd assume that a new EJB release is backward compatible - like most of the time - we would not run in that situation. With EJB 4 it might create wrong namespaces, but at least the features are not completely absent / broken. Don't know if `J2eeProjectCapabilities` is the right place to do that. But from my point of view assuming that a new release is backward compatible is much more likely than assuming a maintainer / contributor will add new Jakarta EE releases on all necessary places (as this is the reason why the features are fully broken). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
