> Not convinced Doclet is the right tool. Feels like we really need reflection > to get annotations + the actual values of the config keys.
But, with Doclets you get access to the content of Javadoc doc-comments, which gives further detail. Admittedly, we have the description in the annotation, and not every field has these comments, but may be useful... Andrew. -- -- andrew kennedy ? cloud engineer : http://blog.abstractvisitorpattern.co.uk/ ; On 12 August 2014 15:56, Aled Sage <[email protected]> wrote: > +1 to Duncan's request. > > Not convinced Doclet is the right tool. Feels like we really need reflection > to get annotations + the actual values of the config keys. > > For example, the following code defines a ConfigKey. From that, we want to > extract the simple name in the annotation, the full name, the description > and the default value. The best way to do that is to get the ConfigKey > object, and call configKey.getDescription() etc. > > @SetFromFlag("bindAddress") > BasicAttributeSensorAndConfigKey<String> BIND_ADDRESS = > new StringAttributeSensorAndConfigKey("jboss.bind.address", > "Address of interface JBoss should listen on, defaulting > 0.0.0.0 (but could set e.g. to attributeWhenReady(HOSTNAME)", > "0.0.0.0"); > > I suggest we use Reflections, and have a simple tool that will scan the > classpath (either the current classpath, or optionally scan a given jar). > > This will work for entities, policies, enrichers, etc. > > --- > That tool can spit out some intermediate format. For example, a YAML file > giving the details. > > We can then have a second tool that generates static HTML from a YAML input. > In that way,the "simple classpath scanning tool" will not need to change > much, e.g. when we're changing the html. > > --- > Medium/long term, we'll want to figure out what additional annotations (or > fields of annotations) to add, for additional meta-data about each entity. > > I suggest we add @Catalog annotations to pretty much every entity. That > would be a good place to put a short description of the entity. > > --- > I plan to play around with a reflections-based scanner. > > Thoughts? > > Aled > > > > On 12/08/2014 15:46, Andrew Kennedy wrote: >> >> I think we could probably re-purpose the Javadoc Doclet processor that >> enumerates information about everything implementing the Entity >> interface, and outputs the public static final ConfigKeys, Attributes >> and Effectors with their documentation as a series of HTML pages, one >> per entity. >> >> Andrew. >> -- >> -- andrew kennedy ? cloud engineer : >> http://blog.abstractvisitorpattern.co.uk/ ; >> >> >> On 12 August 2014 12:39, Richard Downer <[email protected]> wrote: >>> >>> Good idea. We are overdue with filling the website with content so >>> I've posted a proposal to kick-start a discussion about the website, >>> and included a space for a description of the core entities. >>> >>> Richard. >>> >>> On 8 August 2014 12:37, Duncan Johnston Watt >>> <[email protected]> wrote: >>>> >>>> Could we follow the jclouds provider model[1] and make sure that every >>>> entity supported in core brooklyn is listed on the site and also visible >>>> via catalog? >>>> >>>> For the latter I assume any entity will need to ship with stock >>>> blueprint(s). These can of course be improved with time too. >>>> >>>> [1] http://jclouds.apache.org/reference/providers/ >>>> >>>> Best >>>> -- >>>> Duncan Johnston-Watt >>>> CEO | Cloudsoft Corporation >>>> >>>> Twitter | @duncanjw >>>> Mobile | +44 777 190 2653 >>>> Skype | duncan_johnstonwatt >>>> Linkedin | www.linkedin.com/in/duncanjohnstonwatt >>>> >>>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. >>>> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP >>>> >>>> This e-mail message is confidential and for use by the addressee only. >>>> If >>>> the message is received by anyone other than the addressee, please >>>> return >>>> the message to the sender by replying to it and then delete the message >>>> from your computer. Internet e-mails are not necessarily secure. >>>> Cloudsoft >>>> Corporation Limited does not accept responsibility for changes made to >>>> this >>>> message after it was sent. >>>> >>>> Whilst all reasonable care has been taken to avoid the transmission of >>>> viruses, it is the responsibility of the recipient to ensure that the >>>> onward transmission, opening or use of this message and any attachments >>>> will not adversely affect its systems or data. No responsibility is >>>> accepted by Cloudsoft Corporation Limited in this regard and the >>>> recipient >>>> should carry out such virus and other checks as it considers >>>> appropriate. > >
