Menu
▾
▴
ccmtools-devel — Development discussion and ideas
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(3) |
Jun
(1) |
Jul
|
Aug
(14) |
Sep
(4) |
Oct
(34) |
Nov
(25) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(29) |
Feb
(15) |
Mar
(4) |
Apr
(7) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
(6) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
(5) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: Egon T. <ego...@ut...> - 2004-02-11 09:20:26
|
Hi Robert! > Egon Teiniker wrote: >>> >>> I removed "uml2idl.jar" from CVS and added it to ".cvsignore". >>> >> >> My idea was that the uml2idl.jar file can optionally be built using >> Ant. In addition I put the uml2idl.jar file in the lib directory (like >> any other tool we use) to free autotool users from installing Ant... > > Ok. But it would be much easier to write a (simple) shell script > which compiles and installs 'uml2idl'. It don't want to up- or > download 600KB every time I change something in 'dtd2java' or > 'uml2idl'. If you agree, I will write such a script. > > But what about the java-environment module? It would be a > better place for 'dtd2java' and 'uml2idl'. > > Tell me, what you think. Yes to all your suggestions! :-) Egon |
|
From: Robert L. <rle...@sb...> - 2004-02-11 08:59:09
|
Egon Teiniker wrote: >> >> I removed "uml2idl.jar" from CVS and added it to ".cvsignore". >> > > My idea was that the uml2idl.jar file can optionally be built using > Ant. In addition I put the uml2idl.jar file in the lib directory > (like any other tool we use) to free autotool users from installing > Ant... Ok. But it would be much easier to write a (simple) shell script which compiles and installs 'uml2idl'. It don't want to up- or download 600KB every time I change something in 'dtd2java' or 'uml2idl'. If you agree, I will write such a script. But what about the java-environment module? It would be a better place for 'dtd2java' and 'uml2idl'. Tell me, what you think. Bye. -- -- Robert Lechner, rle...@sb... -- |
|
From: Egon T. <ego...@ut...> - 2004-02-10 19:04:18
|
Hi Robert! >> - The uml2idl.jar file is (per default) contained in the ccmtools/lib >> directory and can be build using Ant (build.xml file). > > I removed "uml2idl.jar" from CVS and added it to ".cvsignore". > > > Another problem: when I call "make", the file "lib/ccmtools.jar" > will not be rebuilt, so "make install" copies the wrong version. > Maybe a wrong file dependency? > My idea was that the uml2idl.jar file can optionally be built using Ant. In addition I put the uml2idl.jar file in the lib directory (like any other tool we use) to free autotool users from installing Ant... Now, if you want to built the ccmtools, type: $ ant $ autogen.py --prefix=<...> $ make $ make install :-) Egon |
|
From: Robert L. <rle...@sb...> - 2004-02-09 13:52:50
|
Am Freitag, 6. Februar 2004 16:03 schrieb Egon Teiniker: > > - The uml2idl.jar file is (per default) contained in the ccmtools/lib > directory and can be build using Ant (build.xml file). I removed "uml2idl.jar" from CVS and added it to ".cvsignore". Another problem: when I call "make", the file "lib/ccmtools.jar" will not be rebuilt, so "make install" copies the wrong version. Maybe a wrong file dependency? Bye |
|
From: Egon T. <ego...@sa...> - 2004-02-06 15:12:44
|
Hi all! I have hacked some Makefile.am files, to improve the build process of ccmtools. Now the ccmtools can be built out of the box: - No CLASSPATH extensions are needed to build the ccmtools. (The CLASSPATH only has to point to the installed <prefix>/share/java/*.jar files). - The uml2idl.jar file is (per default) contained in the ccmtools/lib directory and can be build using Ant (build.xml file). - The oclmetamodel.jar and mdr01.jar files are also stored in the ccmtools/lib directory. - I have imported a new java-environment module that can be used to host the dtd2java, uml2idl, MDR stuff (if you agree, I will move these packages in the next couple of days...) To ckeck out the (empty) java-environment type: cvs -d :ext:tei...@cv...:/cvsroot/ccmtools co java-environment :-) Egon |
|
From: Egon T. <ego...@ut...> - 2004-01-27 21:28:43
|
Hi all! I plan to introduce ant to build the ccmtools (parallel to the existing autotools mechanism). Have a look at the README.ant file to see the current status. Hey Robert, ich have changed the dtd2java/Main.jar file to prevent using System.exit() to exit the main() method - because System.exit() also exits ant's execution... If you want to check it out - install ant (http://ant.apache.org) - and type ant in the ccmtools directory. :-) Egon |
|
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 |
|
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: 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-21 11:06:19
|
Hello! The tool 'dtd2java' now creates parsers, which can read Zip files. 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: 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: 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-13 18:08:57
|
Hello! The 'UML to IDL/OCL converter' now writes OCL files. I also added a test directory with a MagicDraw file with all examples of the documentation. Robert -- -- Robert Lechner, rle...@sb... -- |
|
From: Leif J. <le...@am...> - 2004-01-09 20:20:22
|
CORRUPTED MESSAGE This is the Courier Mail Server 0.42 on ambient.2y.net. I received the following message for delivery to your address. This message contains several internal formatting errors. This is often caused by viruses that attempt to infect remote systems. Instead of blocking this message, it has been converted as a safe, text-only attachment that can be safely read with a text editor. This sometimes also happens when the sender's mail software has a bug that creates improperly-formatted messages. Although these kinds of formatting errors may often be ignored by other mail servers, this server detects and intercepts improperly-coded messages in order to prevent viruses from taking advantage of bugs in E-mail programs: ----------------------------------------------------------------------------- This message contains improperly-formatted binary content, or attachment. See <URL:ftp://ftp.isi.edu/in-notes/rfc2045.txt> for more information. ----------------------------------------------------------------------------- |
|
From: Egon T. <ego...@ut...> - 2004-01-09 09:06:05
|
Hi all!
Leif Johnson wrote:
>>When I call "make install", I get the following message:
>>
>>/bin/sh ../../mkinstalldirs /IDL3Templates
>>mkdir -p -- /IDL3Templates
>>mkdir: kann Verzeichnis »/IDL3Templates« nicht anlegen: Keine
>>Berechtigung
>>
>>Maybe a missing path-prefix or an empty variable.
>
>
> With the autotools, it's almost always a good idea to re-run
> autogen.{py|sh} if you notice that anyone has changed the configure.ac
> file. In this case, I recently modified the name of a variable in
> configure.ac, and if you don't re-run autoconf, autoheader, and
> automake, then the new variable won't be in your Makefiles.
>
> Anyway, just re-run autogen.py in the ccmtools top level directory,
> and everything should be ok. :)
Unfortunately, that's not enough. I've had the same problem.
I think there is a mismatch between the definition of the template's
install directory between the toplevel configuration files
(configure.ac, Makefile.am) and the Makefile.am files contained in the
*Template/ directories.
To make it work, I changed the *Template/Makefile.am files:
from: templatedir = $(DATA_ROOT)/CppLocalTemplates
to templatedir = $(TEMPLATE_ROOT)/CppLocalTemplates
thus, make install is working now.
Hey Leif, I will undo this changes as soon as we have fixed the
configuration mismatch.
:-) Egon
|
|
From: Leif J. <le...@am...> - 2004-01-08 22:39:34
|
CORRUPTED MESSAGE This is the Courier Mail Server 0.42 on ambient.2y.net. I received the following message for delivery to your address. This message contains several internal formatting errors. This is often caused by viruses that attempt to infect remote systems. Instead of blocking this message, it has been converted as a safe, text-only attachment that can be safely read with a text editor. This sometimes also happens when the sender's mail software has a bug that creates improperly-formatted messages. Although these kinds of formatting errors may often be ignored by other mail servers, this server detects and intercepts improperly-coded messages in order to prevent viruses from taking advantage of bugs in E-mail programs: ----------------------------------------------------------------------------- This message contains improperly-formatted binary content, or attachment. See <URL:ftp://ftp.isi.edu/in-notes/rfc2045.txt> for more information. ----------------------------------------------------------------------------- |
|
From: Leif J. <le...@am...> - 2004-01-08 22:17:29
|
CORRUPTED MESSAGE This is the Courier Mail Server 0.42 on ambient.2y.net. I received the following message for delivery to your address. This message contains several internal formatting errors. This is often caused by viruses that attempt to infect remote systems. Instead of blocking this message, it has been converted as a safe, text-only attachment that can be safely read with a text editor. This sometimes also happens when the sender's mail software has a bug that creates improperly-formatted messages. Although these kinds of formatting errors may often be ignored by other mail servers, this server detects and intercepts improperly-coded messages in order to prevent viruses from taking advantage of bugs in E-mail programs: ----------------------------------------------------------------------------- This message contains improperly-formatted binary content, or attachment. See <URL:ftp://ftp.isi.edu/in-notes/rfc2045.txt> for more information. ----------------------------------------------------------------------------- |
|
From: Robert L. <rle...@sb...> - 2004-01-08 15:15:44
|
Hi! I added the OCL package (parser and generator) to the CVS. Please add "MDR/mdr01.jar" and "MDR/oclmetamodel.jar" to your classpath! Bye |
|
From: Egon T. <ego...@ut...> - 2004-01-08 14:14:01
|
Hi Leif! I checked out the cpp-environment directory and made some changes to make it work on my box: a) The whole cpp-environment directory can't be built with a single confix call, because there are many confix packages in different directories. Thus, I did the following steps (see the INSTALL file): $ cd cpp-environment Install the local component's environment: $ confix.py --packageroot=CCM_Local --bootstrap --configure --make --targets="all install" Install the remote component's environment: $ confix.py --packageroot=external --bootstrap --configure --make --targets="all install" $ confix.py --packageroot=CCM_Remote --bootstrap --configure --make --targets="all install" Only the CCM_Python directory is a pure confix root package, thus $ confix.py --bootstrap --configure --make --targets="all install" would work, but that conflicts with the other directories that contains confix root packages... Maybe we make a confix package within the CCM_Python directory and can call $ confix.py --packageroot=CCM_Python --bootstrap --configure --make --targets="all install" In that case we can tune the environment as we need it (e.g. with or without remote stuff). b) To build the CCM_Remote/RemoteComponents package, the CCM.idl file must be processed by mico's IDL compiler to get CCM.h and CCM.cc before confix is running. The IDL compiler is called from the Makefile which is called from the Makefile.py in the CCM_Remote/RemoteComponents directory. I'am sure that we will find a better solution in the future ;-) OK, that's it! :-) Egon |
|
From: Robert L. <rle...@sb...> - 2004-01-08 13:52:08
|
Hello! When I call "make install", I get the following message: /bin/sh ../../mkinstalldirs /IDL3Templates mkdir -p -- /IDL3Templates mkdir: kann Verzeichnis =BB/IDL3Templates=AB nicht anlegen: Keine Berechtigu= ng make[3]: *** [install-dist_templateDATA] Fehler 1 make[3]: Leaving directory `/home/rlechner/ccmtools/IDLGenerator/IDL3Templat= es' make[2]: *** [install-am] Fehler 2 make[2]: Leaving directory `/home/rlechner/ccmtools/IDLGenerator/IDL3Templat= es' make[1]: *** [install-recursive] Fehler 1 make[1]: Leaving directory `/home/rlechner/ccmtools/IDLGenerator' make: *** [install-recursive] Fehler 1 Maybe a missing path-prefix or an empty variable. Bye |
|
From: Robert L. <rle...@sb...> - 2004-01-08 09:53:19
|
Hello! Leif Johnson wrote: > If you get a chance, I'd appreciate it if you could briefly describe > what those recently added MDR/MOF files do ... The directory MDR has the following content: mdr01.jar A subset of the Netbeans Metadata Repository (http://mdr.netbeans.org). It generates Java code out of MOF metamodels using the Java Metadata Interface (JMI). I use this tool for the OCL metamodel. oclmetamodel.jar The OCL metamodel. It is used by the DbC (design by contract) generator. MOF/OCL.* The MOF metamodel and the generated sources for OCL. We must add "mdr01.jar" and "oclmetamodel.jar" to the Java classpath, to compile and run the C++ code generator after I added the DbC generator to the CVS! That means, we should handle these files like "antlr.jar". It is possible to create "oclmetamodel.jar" from "MOF/OCL.MagicDraw.xml.zip", but the MDR tools are difficult to handle. The best thing is to add the jar-files to the classpath, and forget them :-) > However, it might take a week or so to integrate your new tools and > libraries nicely into the ccmtools. I'll work on this, too, if you > don't mind ... especially since I've got some pending autotools work > to get things working with the external environment libraries. I'll > probably want to move some of your executables to other places in the > source tree, but I'll check with you before changing stuff too much. If you put "ccmtools.uml_parser" and "ccmtools.uml2idl" in one jar-file, we can use the UML to IDL converter 'stand-alone' (without ANTLR or ccmtools). Bye -- -- Robert Lechner, rle...@sb... -- |
|
From: Joerg F. <jf...@sa...> - 2004-01-08 09:34:08
|
>>>>> "Leif" == Leif Johnson <le...@am...> writes:
I'm catching up a little late since I tried to separate fun and work
over my holidays. (I noticed that these are inseparable however.) I'll
try to comment as we go, so excuse me for commenting on something that
was already commented to death.
Leif> Over vacation I was thinking more about the CCM Tools environment files.
Leif> I came up with an idea(tm) : From a Unix perspective (small tools that
Leif> perform one task), the CCM Tools shouldn't even include environment
Leif> files. We ought to move all these environment files out of the ccmtools
Leif> source tree entirely. I started to move them into a different directory,
Leif> which I thought we could distribute separately, and include as a
Leif> separate CVS module ("cvs checkout environment", perhaps ?). But then I
Leif> realized the C++ tests in `make check' would fail since they require the
Leif> environment to be installed locally in that tree. Hmm ...
Leif> So, what do you think ? It seems that component developers should have
Leif> these environment libraries installed before they even install the CCM
Leif> Tools. By removing the environment files entirely from the ccmtools
Leif> source tree, there are two advantages and two disadvantages that I can
Leif> see.
Leif> Advantage 1 : Configurability. If the CCM Tools can expect to find
Leif> environment libraries already installed on a developer's system, we
Leif> could check for those libraries at configure time and selectively
Leif> enable/disable some of the generators based on which libraries are
Leif> present on the developer's system. For example, the Python wrapper
Leif> generator is going to require a small environment library (quite similar
Leif> to that of the remote C++ environment) ; we could check for this at
Leif> configure time and disable the Python wrapper generator if the library
Leif> is not found. Same idea for the remote generator ; we could even try to
Leif> detect several different ORBs in the ./configure file, and change the
Leif> generators appropriately somehow. This might even be a good solution for
Leif> the multi-orb selection problem.
This appears to be quite a bit of work, but it's a good idea. You'd
need a lot of conditionals (both automake and C-macro), and testing
all combinations is exponential.
Leif> Advantage 2 : Separation of interface and implementation. If the CCM
Leif> Tools do not include the implementation code for their libraries
Leif> directly, this allows for multiple implementation of those libraries,
Leif> provided the interface (API) is well defined. I am thinking specifically
Leif> of the CCM_Utils library, which is part of the in-house WX library at
Leif> Salomon (is that right ?). If the CCM Tools only care that the library
Leif> is installed and available, then we leave it up to the developer to
Leif> provide a library implementation that's appropriate for their situation.
Leif> This would be a nice way to allow the WX libraries to override the
Leif> default CCM Tools implementation.
Good idea, much less work :-)
Leif> Disadvantage 1 : More interdependencies. If the CCM Tools rely on
Leif> external libraries, inconsistencies can appear. Especially at this point
Leif> in development, when the API/ABI (application binary interface, i.e. the
Leif> size/composition of classes and structs) for environment libraries is
Leif> not stable, we would start to run into component compilation errors
Leif> related to version differences in the libraries.
Agreed, this is a disadvantage. Libtool's library versioning scheme
provides a solution to the problem, it's just that developers have to
take a lot more care. (The macros in WX/Utils/linkassert.h serve the
same purpose, but require equal care.)
But, on the other hand, even with local environment libraries you have
to make sure the user installs them after he got an update, or else he
will run into exactly the same situation.
Leif> Disadvantage 2 : Testing and Confix. If we move the environment
Leif> libraries out of the CCM Tools, then `make check' will fail as it is
Leif> now. If the environment libraries are external to the CCM Tools, then
Leif> Confix would need to support multiple repositories (does it now ?) to be
Leif> able to find the external C++ component libraries as well as using the
Leif> internal ones that the test components create. Both of these aspects are
Leif> nonnegligible, but I think we can deal with them.
Unfortunately there is no such repository overloading feature. However
I guess this is only necessary when two developers are working on the
same package, on the same machine, that depends on another package. To
share the same installation of that other package, they would share
one repository, and "overload" that one with their own. We need this
feature anyway as it is common practice here to work on the same
machine which uses to be a big one.
You can always install both packages into one
location/repository/prefix, I guess this is what you mean by dealing
with the problem.
Joerg
|
|
From: Leif J. <le...@am...> - 2004-01-08 00:39:50
|
Hi Robert - Welcome to the CCM Tools ! I haven't looked at the code for your new tools, but it looks like you've been working on them quite a bit already. It's excellent that we now have a UML -> IDL link in the CCM Tools developer chain. If you get a chance, I'd appreciate it if you could briefly describe what those recently added MDR/MOF files do ... are they for documentation, or examples, or will they be used as code generation resources somehow ? Do we need to do something to add them to the autotools build structure ? On Wed, 2004-01-07 at 21:02 +0100, Robert Lechner wrote: > To create 'uml2idl', do the following: > * enter $CCMTOOLS_HOME/dtd2java > * type "./make_tool.sh" > * type "./make_UML.sh" > * enter $CCMTOOLS_HOME/uml2idl > * type "./make_tool.sh" > > Now you can use "$CCMTOOLS_HOME/uml2idl/run.sh" to run the tool. > > I know, this way of creating and starting the tool is a hack! > Maybe we can integrate the tool into the normal build process. No problem ; the autotools are quite complex sometimes. For now, I'll add these files to the existing autotools build structure ; shouldn't be a problem at all. However, it might take a week or so to integrate your new tools and libraries nicely into the ccmtools. I'll work on this, too, if you don't mind ... especially since I've got some pending autotools work to get things working with the external environment libraries. I'll probably want to move some of your executables to other places in the source tree, but I'll check with you before changing stuff too much. :-) leif -- Leif Morgan Johnson : http://ambient.2y.net/leif/ |
|
From: Robert L. <rle...@sb...> - 2004-01-07 20:04:04
|
Hi! I developed two new tools: 'dtd2java' creates Java classes and a XML parser from DTDs (document type definition). I use this tool to get a UML parser without the need for making my own UML metamodel. With 'uml2idl', you can now design CORBA interfaces and components with UML. The "CORBA profile for UML" defines a way to that. 'uml2idl' reads the XMI file (the XML file from your UML editor) and generates IDL and OCL files => no need for hacking text files any more! Until now, only the IDL output works. OCL will come as soon as possible. A added both tools to the CVS repository: "$CCMTOOLS_HOME/dtd2java" contains the first tool and "$CCMTOOLS_HOME/uml2idl" the second one. The documentation is in "$CCMTOOLS_HOME/doc" (only german, sorry). To create 'uml2idl', do the following: * enter $CCMTOOLS_HOME/dtd2java * type "./make_tool.sh" * type "./make_UML.sh" * enter $CCMTOOLS_HOME/uml2idl * type "./make_tool.sh" Now you can use "$CCMTOOLS_HOME/uml2idl/run.sh" to run the tool. I know, this way of creating and starting the tool is a hack! Maybe we can integrate the tool into the normal build process. Robert -- -- Robert Lechner, rle...@sb... -- |
