Re: [wildfly-dev] Capabilities and Requirements - Common Definitions
On 22/05/15 14:50, Tomaž Cerar wrote:
On Fri, May 22, 2015 at 12:31 PM, Darran Lofthouse
<darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> wrote:
The first option is to do it all by convention and have no shared
constants, the down side of this is we now need to document this and
keep the document maintained. A document would also make it hard in the
future to flag certain capabilities as deprecated if preferred
alternatives are made available.
Well, deprecated can be done on two levels, one is compile time, the
other runtime.
and at runtime it is easy to add feedback that certain capability is
deprecated.
I don't really see runtime deprecation is an option here - the problem
here is unless the capability is defined in a central location there is
no central point to flag it as deprecated - the capability is kind of
our central coordination point.
There is no single provider of the capability to be the definitive
reference point to flag deprecation - hence the central definition in
the PR.
The second option would be to just define the Strings somewhere
and use
Javadoc to specify if the capability is dynamic and it's service type.
That one sounds ok, but you still need central place with constants,
even if just for compile.
The third option is defining the string and RuntimeCapability instances
in a central place so they can both be referenced as needed.
I think a String only definition means that we only have an option to
flag as deprecated at compile time - not runtime, but that may be fine.
I don't like this one at all, I know it was in initial design of
capabilities
and it was the single thing I disliked the most.
so IMO, either #1 or #2 is fine, but lest avoid #3 if possible.