<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 22, 2015 at 12:31 PM, Darran Lofthouse <span dir="ltr"><<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The first option is to do it all by convention and have no shared<br>
constants, the down side of this is we now need to document this and<br>
keep the document maintained. A document would also make it hard in the<br>
future to flag certain capabilities as deprecated if preferred<br>
alternatives are made available.<br>
<br></blockquote><div>Well, deprecated can be done on two levels, one is compile time, the other runtime.<br></div><div>and at runtime it is easy to add feedback that certain capability is deprecated.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The second option would be to just define the Strings somewhere and use<br>
Javadoc to specify if the capability is dynamic and it's service type.<br>
<br></blockquote><div>That one sounds ok, but you still need central place with constants, even if just for compile.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The third option is defining the string and RuntimeCapability instances<br>
in a central place so they can both be referenced as needed.</blockquote></div>I don't like this one at all, I know it was in initial design of capabilities <br>and it was the single thing I disliked the most.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">so IMO, either #1 or #2 is fine, but lest avoid #3 if possible.<br></div><div class="gmail_extra"><br><br></div></div>