Community
Participate
Working Groups
One issue that has come up is that recently a class in the jst.jsp.core plugin needed to provide a JSP version as part of (soon to be public) API. However, this particular plugin has no need (other than the JSP constants currently found in J2EEVersionConstants) for the jst.j2ee.core plugin and currently does not pre-req it. In general, in order to keep the use of these J2EE version constants standardized throughout WTP, while keeping plugin dependencies logical and minimal, it would be adviseable to move the various constants found in J2EEVersionConstants (soon to be made public according to Bug 98577) into their various respective plugins - JSP/Taglib constants into jst.jsp.core, EJB constants into jst.ejb, etc. Otherwise either potentially non-standardized use of version constants OR complicated and unnecessary plugin deps may result.
I might agree with this specifc case, but in general, we need to be use care anytme we make thinkgs like "1.4" an API Constant. Seems little need for it, and there is always the problem that it makes it harder to "catch up" with future versions. I certainly agree with not having plugin dependancies for things like "1.4", that'd be even worse! :) I'll look at details, eventually. Let us know if it critical for your use case. Thanks.
The util and constants classes should be made API if clients are trying to access them.
*** Bug 98577 has been marked as a duplicate of this bug. ***
