Re: [ccmtools-devel] source reorganization ideas

[Egon T. <ego...@ut...>]

Hi all,

there is my view about these ideas:

Robert Lechner wrote:
> Leif Johnson wrote:
>>1.  We should move the library-type .jar files (MDR/*.jar) into the
>>    directory with the other .jar files (lib/).
>
> Ok. Maybe we can replace the MDR-library and make our own
> MOF-JMI-generator?

At this point (using the painful MDR stuff) I think the MDR/ directory 
should be put into a separate java_environment source tree and a script 
(or Ant) should copy the *.jar files to <ccmtools-install-path>/lib at 
build/install time - because they are like the antlr.jar file.
A working MOF-JMI-generator would be a perfect dream ;-)


>>2.  We should move all of our metamodel .java files into the
>>    Metamodel/ directory, so the subdirs of that directory will be
>>    BaseIDL, ComponentIDL, OCL, etc. Can we do this ?
> 
> 
> No. The OCL metamodel (source: ccmtools/MDR/MOF/OCL.src.zip
> jar: ccmtools/MDR/oclmetamodel.jar) has the Java package name
> "oclmetamodel". The MDR-tools cannot handle package names
> like "ccmtools/Metamodel/OCL". This is one reason, why we should
> replace the MDR tools.

Robert, you have created the OCL.MagicDraw.xml.zip metamodel file, and 
you have generated, compiled and packaged the
JMI interfaces to the oclmetamodel.jar file.
The oclmetamodel.jar file together with the mdr01.jar file are used by 
the OCL parser/generator to build/use the OCL model - right?

I think that (if we would have a pure OCL metamodel library, without the 
MDR stuff) this package should be put in ccmtools/metamodel/ocl 
(corresponding to the package name).
But, using the MDR stuff in a offline manner, we should put the files in 
the java_environment source tree.


>>3a. Why don't we make an OCLParser directory and put the OCL*.g files
>>    in there, along with any needed support files from OCL/utils ?
>>    Then we could build that directory just like the IDL3Parser
>>    directory, and not have to keep the
>>OCL{Parser|Lexer|TokenTypes}.java files in CVS. 
> 
> I put the parser source into the "utils" package, because of circular
> class dependencies. I will try to separate the parser code from
> the utils package.

I also think that it would be nice to have a structure like that:
OCL
|-- parser
|-- generator
`-- utils


>>3b. It looks like we can do the same thing with the uml2idl directory
>>    ; put it in a UMLParser directory, and generate lots of it
>>    automatically during the build process.
>>
>>    In fact, if we build the UMLParser directory first, then we could
>>    use that part of the library to generate the necessary files for
>>    the OCLParser directory. Then we could just keep the OCL.xml and
>>    OCL.dtd files in CVS.
> 
> 
> Ooops. I think, you mixed up UML and OCL:
> 
> *)  The OCL parser reads OCL-statements from plain text files. No XML.
>       It uses the OCL metamodel, which uses the MDR tools.
>       The file ccmtools/MDR/MOF/OCL.xml is needed at runtime
>       by the MDR tools.
>       The file ccmtools/MDR/MOF/OCL.MagicDraw.xml.zip could
>       be used to create ccmtools/MDR/oclmetamodel.jar
>       But it is difficult to add this step to the normal
>       build process of the ccmtools.
> 
> *)  The uml2idl converter creates OCL and IDL text files from UML.
>       The UML model is stored in XMI (XML) files.
>       It uses the uml_parser package, which was created by dtd2java.
>       None of these packages uses any other ccmtools package or is
>       used by any ccmtools package.
>       It is easy to rename the package uml_parser into UMLParser.

I played with Ant and made a build.xml file that can be used to build 
both the dtd2java.jar and the uml2idl.jar file (containing uml_parser).
Also, I will try to make a build.xml file to build the whole ccmtools 
(parallel to the autotools build process ;-)

Maybe, we can put the dtd2java tool into the java_environment source 
tree. There, we will use Ant to build the java source and install the 
*.jar file in <ccmtools-install-path>/lib (in the same way as we copy 
the mdr01.jar and oclmetamodel.jar files).
The dtd2java tool is so flexible that it may be used in a standalone way 
too. But, that's just an idea...

> Summary:
> 
> *)  "dtd2java" needs 'antlr.jar' and is needed to generate "uml_parser"
> *)  "uml_parser" needs only Java 1.4
> *)  "uml2idl" needs "uml_parser" and creates IDL and OCL files
> *)  "OCL" needs "oclmetamodel" and 'antlr.jar'
> *)  "oclmetamodel" needs 'MDR/mdr01.jar' and 'MDR/MOF/OCL.xml'

Thus, after make install, the <ccmtools-install-dir>/lib directory 
should contain:
antlr.jar, oclmetamodel.jar, mdr01.jar, dtd2java.jar and ccmtools.jar 
(containing uml_parser and uml2idl)


> The best things to do would be:
> 
> *)  add dtd2java, uml_parser and uml2idl to the normal build process
>      (or maybe move it from the ccmtools tree into its own source tree?)

I vote for a java_environment source tree (like the cpp_environment) for 
the .

> *)  make our own MOF-JMI-generator => no need for MDR tools or extra jar-files
>      =>  create an independent package "ccmtools/Metamodel/OCL"

Great, when can you start...?

;-) Egon