I do agree that we need a better mechanism than that existing for PGML but I'm not sure which way to go.
I think we can improve on the current writing and parsing. Writing PGML has the following issues. It uses the GEF tee files as a template to generate PGML. This uses a great deal of reflection and so there is no compile time checking that the code is safe. This also forces methods to be made public which I would otherwise choose to have package scope. The code is proprietary to GEF and so the tee file format needs to be learned as a new language for all developers rather than using some more commonly known template engine which gets more rigourous testing with a wider user base. Reading PGML has the following issues. PGML is not designed to contain connected graph data. The extra data that is required is shoehorned into inappropriate elements and requires an extra level of parsing. The PGMLStackParser is split between some base resuable functionality in GEF and overridden in ArgoUML. This makes it difficult to refactor and fix bugs. I think all responsibility should be in ArgoUML for loading. Once again reflection is used a great deal. It would be far safer to have a factory which created the correct Fig based on tags and identifiers in the XML rather than reading the class name from the pgml and creating by reflection. The PGML groups are based on the composite structure of a Fig. If a Fig is refactored then the PGML structure saved will change to reflect that. The parser will then need to look elsewhere to find data to rebuild the Fig. The saved file cannot be loaded in previous versions of ArgoUML and previous projects need an upgrade xsl script to load in the new version. [actually the last two sentences are probably only true of changes in the sequence diagram and I hope to resolve that when I make that diagram bahave in a more standard manner] With all the above issues, a desire to move to diagram interchange format and lack of MDR support then I would hope we might be able to consider still using some template language to write the data and some parser of our own to read but I'd like to drop use of any of the GEF classes to do this. This is one of several areas where I think GEF is providing functionality beyond its scope (or its scope is too wide) and we are best not to use. As a template language I'd rather we used something better known, velocity or freemarker. A little less well known though is www.jamon.org - I like what I've seen of this because it actually generates code from the templates rather than interprets them at runtime. This gives compile time checking that I don't think we'd get with any other template language. Bob. On 9/22/06, Tom Morris <[EMAIL PROTECTED]> wrote:
Linus asked: > What would it take to update MDR to the correct versions of > MOF and XMI? - Formalization of a MOF 2.x compatible JMI either in the JCP, OMG, or an independent group (perhaps just a set of collaborating projects) - Implementation of MOF 2.x semantics in MDR (it currently implements MOF 1.4). EMOF isn't sufficient since the UML metamodels use CMOF, but it might not be necessary to implement the full CMOF semantics. This would require more investigation. MagicDraw was claimed (by the AndroMDA team) to have started an open source upgrade of MDR for UML 2.x, but have supposedly dropped it because of unacceptable performance. > Is there another open source MOF/CWM tool out there with a > better roadmap for this? Not that I've found. Brian Topping of Dentaku http://dentaku.codehaus.org/ was interested in perhaps doing a rewrite. AMOF2 might be another possible starting point visit: http://www2.informatik.hu-berlin.de/sam/meta-tools/aMOF2.0forJava/index.html http://developer.berlios.de/projects/amof2/ Another possibility would be to give up on the standards-based approach and just use EMF/UML2. They don't currently do Diagram Interchange and each additional MOF2 based model (eg SysML) would require proprietary IBM magic to convert from CMOF to something usable with EMF. There have been discussions on both the JMI and MDR lists about this periodically over the last year without anyone offering any good solutions. The last JMI discussion was May 2006 (see "State of JMI" thread) http://archives.java.sun.com/archives/jmi-interest.html. The most recent substantive MDR discussion was Nov/Dec 2005 http://mdr.netbeans.org/servlets/SummarizeList?listName=users I try and keep at least one eye open for new developments that would present away forward from our current roadblock, but I'd be more than happy to hear other suggestions. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
