+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.
