Menu
▾
▴
ccmtools-devel
|
From: Leif J. <le...@am...> - 2004-01-16 21:49:49
|
Hi all -
I'm having organization thoughts about the ccmtools. Here they are,
numbered for easy reference :
1. We should move the library-type .jar files (MDR/*.jar) into the
directory with the other .jar files (lib/).
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 ?
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.
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.
I'm going to keep this one from getting too long. Let me know what you
think ; I'm much in favor of keeping generated files out of CVS, since
they can be generated (duh). In particular, I think the above things
would be easy to implement, and they would help keep the source tree and
namespaces consistent.
leif
--
Leif Morgan Johnson : http://ambient.2y.net/leif/
|
|
From: Robert L. <rle...@sb...> - 2004-01-17 14:08:58
|
Leif Johnson wrote:
> Hi all -
>=20
> I'm having organization thoughts about the ccmtools. Here they are,
> numbered for easy reference :
>=20
> 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?
>=20
> 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.
>=20
> 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.=20
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.
>=20
> 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.
>=20
> 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.
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'
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?)
*) make our own MOF-JMI-generator =3D> no need for MDR tools or extra =
jar-files
=3D> create an independent package "ccmtools/Metamodel/OCL"
bye
--
-- Robert Lechner, rle...@sb...
--
|
|
From: Robert L. <rle...@sb...> - 2004-01-17 16:36:14
|
> *) make our own MOF-JMI-generator =3D> no need for MDR tools or extra > jar-files =3D> create an independent package = "ccmtools/Metamodel/OCL"=20 Of course, we could also implement the OCL metamodel by hand! bye |
|
From: Egon T. <ego...@ut...> - 2004-01-21 20:44:57
|
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
|
|
From: Robert L. <rle...@sb...> - 2004-01-22 09:23:10
|
Egon Teiniker wrote: > > 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 ;-) Yes, a very good idea! > > 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? Yes. > > 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). Or ccmtools/Metamodel/OCL (corresponding to the name of the IDL model). > But, using the MDR stuff in a offline manner, we should put the files > in the java_environment source tree. Ok. > > I also think that it would be nice to have a structure like that: > OCL >> -- parser >> -- generator > `-- utils Yes, I think it's better to have an OCL source tree than a separate OCLParser directory. It should be now problem to extract the parser from utils and remove the circular dependencies. > > 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 ;-) Excellent! > > 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... A good idea. > 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) I think there are two possibilities: 1) Put all the code of the java_environment source tree into ccmtools.jar (except oclmetamodel.jar, mdr01.jar). No "dtd2java.jar" file. 2) Create a Jar file for each main package. For ccmtools users (and developers), it would be more comfortable to create one Jar file (ccmtools.jar). > I vote for a java_environment source tree (like the cpp_environment) Yes! > >> *) 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...? Well, it's not that difficult. We could use 'dtd2java' to create a MOF model, convert UML to MOF (no UML editor has a MOF mode) and use the JMI specification to build Java-interfaces and classes. I would (and could) do the work, but the problem is: time. I have to finish the DbC component generator and my master thesis. My contract with Salomon ends this month, so I don't want to spent more time with another tool (like dtd2java and uml2idl), which is not part of my master thesis. Bye |
|
From: Robert L. <rle...@sb...> - 2004-01-27 09:01:26
|
Robert Lechner wrote: >> >> I also think that it would be nice to have a structure like that: >> OCL >>> -- parser >>> -- generator >> `-- utils > > Yes, I think it's better to have an OCL source tree > than a separate OCLParser directory. It should be now problem > to extract the parser from utils and remove the circular dependencies. The OCL parser has now it's own package and is independent of the other OCL packages. Bye |
Thanks for helping keep SourceForge clean.
X