I'd love to take a look at the code. I have one mostly done and would
love to compare notes. I was moving toward a more javadoc-like output
but having a pluggable output format is a definite win for everyone
involved. I've also been implementing mine as a command so it'd run in
container with access to everything at runtime so that might be an
interesting modification to this approach. Is the source available
somewhere?
Jerome Dochez wrote:
> Tim Quinn wrote:
>> Hi, Jerome.
>>
>> Jerome Dochez wrote:
>>> Hi Tim
>>>
>>> This is really cool, there is no limit on how far this tool can go.
>>> I talked with June and Abhijit few months back how we could
>>> autogenerate a lot of the domain configuration from the config model
>>> using a tool like you wrote.
>>>
>>> I understand this was a week end hack but I have a few RFEs if this
>>> is not already implementated.
>>>
>> I'm laughing to myself ;-). This was my one "fear" in publicizing
>> the tool but of course I expected it. Thanks for the suggestions.
>>> 1. would it be possible to plug an output adapter, so we can
>>> generate DTDs, wiki page and tables with cross-referencing.
>> Absolutely. This was also my first RFE; I did not want to take the
>> time to generate proper DTDs or XSDs but I thought others might want
>> those.
>> The API might well be event-driven, along the lines of the SAX
>> approach for XML parsing, to insulate the output adapter from the
>> internal implementation details (which are not too pretty, being a
>> weekend hack!). I'll take a look and see if I can do this quickly.
> I think Justin was working on the DTD generation, would be interesting
> to converge on a simple in-memory model + visitor APIs and let him to
> the DTD part.
>>> 2. could you add the notion of @Documentation to the hk2 framework,
>>> Jane could use this @Documentation annotation to enter information
>>> like the one we find today in the administration guide.
>> As you said, anything is possible. Would this be at the @Configured
>> interface level?
> everywhere really, type, attributes and elements.
>>> 3. out of this @Documentation, guess what you would start generating...
>>> 4. is this purely a reporting tool or are there possible ways of
>>> adding verification semantics to check the config interfaces are
>>> consistent ?
>> Currently it only reports, but with an event-driven adapter approach
>> like above the tool would not care what the adapter did with the
>> events - reporting, consistency checking, GUI display of the data for
>> browsing, etc.
>>
>> Given how close we are getting to the soft code freeze I have limited
>> time to work on the tool now, bu I can probably get the output
>> adapter stuff working fairly quickly.
> yes I think this is the perfectly fine, perfect example of something
> that can be done independently later.
>>
>> - Tim
>>>
>>> Jerome
>>>
>>> Tim Quinn wrote:
>>>> From time to time there have been requests for DTDs or XSDs for the
>>>> v3 domain.xml. But because the content of domain.xml is variable,
>>>> depending on what modules are installed, this is not really feasible.
>>>>
>>>> Over the weekend I hacked together a small tool that will generate
>>>> a simple text file describing the format, based on the interfaces
>>>> annotated with @Configured that are defined in the GlassFish module
>>>> JARs.
>>>>
>>>> This wiki page
>>>>
>>>> http://wiki.glassfish.java.net/Wiki.jsp?page=DomainXMLv3Structure
>>>>
>>>> describes the tool, how to download and run it, and how to
>>>> interpret the output (it's pretty simple, I hope). I have alrso
>>>> recorded a few possible errors I've seen in the @Configured
>>>> interfaces as defined currently, based on the tool's output.
>>>>
>>>>
>>>> Action Item:
>>>> Module owners, please review the sections of the generated output
>>>> related to your modules. Make sure that the structure (attributes,
>>>> subelements, etc.) is correct for your areas of the system. There
>>>> is a table on the wiki page to record errors in other areas.
>>>>
>>>>
>>>> This is not a supported part of GlassFish but might be useful for
>>>> people interested in the domain.xml format. If you find errors in
>>>> the tool itself please add a row in the tool issue list at the
>>>> bottom of the wiki page.
>>>> - Tim
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>