----------------------------------------------------- As far as content, I type in XML (is there a schema?) and it transforms to XHTML with CSS? -----------------------------------------------------
Yes - There is a schema. And that schema is used to generate an ecore model. The ecore model generates an editor. So you could just use the editor to write the documentation. Or type it in as XML straight up. So a maven archetype is used to create a project with a sample xml file. Just edit that file. And then run the mojo and it will generate the documentation plugin, with the css, eclipse specific files, etc. Almost done - Hang in there! :-) ----------------------------------------------------- > Can you help me with this one question: Is this a > stupid idea? (If true > -> I will proceed to the beer camp to immediately > prune contaminated > brain cells.) > > Could be more friendly in terms of describing what > > each StructuralFeature on each ecore element is > for... ----------------------------------------------------- Proceed to Beer Camp! It's a great idea, but Beer Camp goodddd :-) I think it would help a lot if you wrote a little guide on what to look for in terms of coupling. I'm sure there are some general "Anti Patterns" to look for. If I were to use a "Challenge" "Solution" cookbook for it, I would list a whole bunch of "Coupling" challenges that could be made more elegant according to some pattern (These may or may not exist in the code base), and then show how the Graph Tool helps illuminate how to go about refactoring. This would be good for illustrating how to avoid these in the future too. When I write the test guide, I'm going to recommend the Class + Class Helper pattern. That way all classes either depend on their helper, or a Utility Library. There will be a corresponding test generator pattern / pattern for writing the tests. If this pattern were used throughout, it would make "Anti-Pattern" coupling non-existant I would think. Could be that there are other patterns that would suit the particular sub project even better though. The Class + Class Helper pattern is just an example, although it does make automatic test generation that covers all methods possible. Personally I prefer writing a little "Challenge" and then coding something that takes care of it. OH - There's this EMF article on how to use GEF and EMF to automatically generate a database schema diagram. http://www.eclipse.org/articles/Article-GEF-editor/gef-schema-editor.html If you run the sample you'll see it does the layout for you automatically. Something like this would be cool for first drawing a package diagram showing the coupling between the packages, and then letting developers drill in to evaluate the couplings. You'll probably like this page: http://wiki.eclipse.org/index.php/GEF_Articles One of the articles shows you how to create a UML diagram with GEF. http://www.eclipse.org/articles/Article-GEF-Draw2d/GEF-Draw2d.html Incidentally - In XML Schema Annotations are used to document the Schema. If you generate an Ecore model from the Maven XML Schema, which is documented using annotations, you'll see how they translate into documentation on Ecore. Then you know how to document ecore models. Now you can could generate a diagram like the one shown in the UML draw2d tutorial, to make the documentation more elegant. HTML UML diagram would be straight forward too, and if the dynamic layout algorithm were implemented with some dojo toolkit fx code, it would make a very sexy documentation plugin addition. Make sure non of these makes you loose focus on the Beer Though :-) Cheer - Ole --- "John E. Conlon" <[EMAIL PROTECTED]> wrote: > Ole Ersoy wrote: > > John, > > > > I think you are my type of dud :-) > > > > You know that last eclipse newsgroup post in your > > mail? > > > > > http://dev.eclipse.org/newslists/news.eclipse.technology.ecp/msg00089.html > > > > This is the type of platform I'm targeting. > > > > Except for Tuscany DAS's (Pure ones hopefully, > > independent of Hibernate, although Hibernate is > really > > good). > > > When When When ??? > > Did you notice how they talked about JSF? I wrote > a > > client side JS Framework on Top of Dojo Toolkit > (And > > donated it to myfacers), so that Server Side and > > Client Side can be very much decoupled and only > pass > > JSON strings back and forth. > > > > Check it: > > > http://people.apache.org/~matzew/dojo.presentation.zip > > > http://www.mail-archive.com/[email protected]/msg18916.html > > > > This way the client side Javascript components and > the > > server side components can be generated and will > > mirror eachother. > > > Yep saw that. Must admit that I am not a javascript > guy, but it > provides the functionality needed now. I'm betting > on XForms and XQuery > to pull out in the stretch. > > OH - Documentation generation: > > > > If you had a chance to look at the Contributor > Guide > > eclipse plugin you'll see there's a lot of > symmetry > > between the recipes and the checklists. > > > It's loaded and I have looked at it. Nice > documentation vehicle. > > Right now I'm writing a Maven plugin to generate > the > > whole guide...driving it off of a checklist.xml > > document. This way it requires minimal > maintenance > > and it's just a matter of adding more content, and > > everyhting else is generated. > > > As far as content, I type in XML (is there a > schema?) and it transforms > to XHTML with CSS? > > Eclipse Infocenter TOC's can then be used to > stitch > > together many non-primary TOC's to form a whole > book. > > > > I'm hoping to have the plugin done by the end of > > today. Then it can be a starting point for > > documentation and code generation at the same > time. > > > > The Ecore Model Editor is pretty good once you get > > used to it though. It's strictly for the model > part > > of a > > Presentation - Application - Business - > Integration - > > Persistance Layered architecture. > > > I think so too - to build the models once one if > familiar with it they > would just do it by hand with the editor. I just > wanted the Graphics > for documenting the model with a standard UML look > and feel. > > Which reminds me of something else, (knowing your a > man of many > languages and are fond of documentation - and > 'automation maniac'. :-) > > I have recently experimented with a tool called > Guess. > http://graphexploration.cond.org/ > > > When I worked for what is now called Nortel Networks > I managed a team of > programmer consultants that used tools like Guess > (Those tools were not > free then and had less functionality than Guess.) to > map large ISP > networks. I am now interested in turning a tool > like this inward to > give us a way to display and potentially explore > coupling problems > between ADS subprojects. > > Can you help me with this one question: Is this a > stupid idea? (If true > -> I will proceed to the beer camp to immediately > prune contaminated > brain cells.) > > Could be more friendly in terms of describing what > > each StructuralFeature on each ecore element is > for... > > > > For the most part though - I think my favorite > camp is > > "The Beer Camp". :-) > > > Has to be German beer though, > > John > > Cheers, > > - Ole > > > > > > --- "John E. Conlon" <[EMAIL PROTECTED]> wrote: > > > > > >> Ole Ersoy wrote: > >> > >>> I think this may have some: > >>> > >>> http://www.andromda.org/ > >>> > >>> >From the description it's my wet dream in > >>> > >> cyberspace. > >> > >>> I started drooling uncontrollably when I saw it. > >>> > >>> Then there's this: > >>> > >>> > > > http://amateras.sourceforge.jp/cgi-bin/fswiki_en/wiki.cgi?page=AmaterasUML > > > >>> I've only skimmed though... > >>> > >>> And this: > >>> > >>> > >>> > > > http://wiki.eclipse.org/index.php/GMF_New_and_Noteworthy > > > >>> > >>> > >> Bingo GMF! > >> http://www.eclipse.org/gmf/gallery/index.php > >> > >> Okay here is the process: > >> Service Requirements -> Design -> Artifact > >> (component) creation-> > >> Warehousing (Repos) -> Deployment -> Component > >> dependency matrix > >> ->Execution -> Service fulfillment! > >> > >> The big problem is documentation. It is needed > >> throughout the chain. > >> Needed to always answer the archetypical question > - > >> WTF? > >> > >> But when is doco created? Before or after the > >> artifact is built, stored, > >> deployed or run? We need it up front and > through > >> out the lifecycle and > >> it can't get stale. Artifact with out docs is no > >> good, can't be > >> maintained. Doc without artifact, what's the > point? > >> One school of > >> thought is to do the documentation then the code, > >> second school says the > >> code then the documentation, third school says > >> generate docs from code, > >> and forth says generate code from docs. (Fifth > >> school drinks beer.) > >> > >> Fun times! The third and the forth camps are > >> converging, and the gap is > >> closer (touching?) now than ever. > >> > === message truncated === ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
