[wildfly-dev] Capabilities and Requirements - Common Definitions

[Darran Lofthouse]

On 22/05/15 14:50, Tomaž Cerar wrote:
>
> On Fri, May 22, 2015 at 12:31 PM, Darran Lofthouse
> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at 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.
>
>