wow. it only took 2 hours for this email to show up. woo hoo?
Justin Lee wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>