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: SourceForge.net <no...@so...> - 2004-05-25 09:48:39
|
Bugs item #960005, was opened at 2004-05-25 09:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=547854&aid=960005&group_id=76664 Category: C++ Generators Group: 0.3 Series Status: Open Resolution: None Priority: 5 Submitted By: Joerg Faschingbauer (jfasch) Assigned to: Nobody/Anonymous (nobody) Summary: Include files in same directory are include as full path Initial Comment: This introduces a bootstrap problem as an include file is visible under its full include path only after compilation. The concrete case was discovered in the CCM_Local generated interfaces directory by looking over the source. It is not currently a real problem as there is no implementation there which is compiled (only .h files), but will become one once the ccmtools generate code for the interfaces. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=547854&aid=960005&group_id=76664 |
|
From: <ben...@id...> - 2004-05-22 12:10:00
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Egon T. <ego...@ut...> - 2004-05-13 20:36:01
|
Hi!
I have changed the output of the idl3 generator.
Granted that a single idl file has been generated from a UML diagram
(using Robert's uml2idl tool).
A ccmtools call can subdivide this file into a bunch of idl files:
$ ccmtools-generate idl3 -o idl3 a_single_file.idl
All files generated by the idl3 generator are arranged in the following
directory structure:
idl3/interface/<namespace>/<struct-name>.idl
/<exception-name>.idl
/<typedef-name>.idl
/<enum-name>.idl
/<....-name>.idl
/<interface-name>.idl
/component/<namespace>/<component-name>/<component-name>.idl
/<component-home-name>.idl
This directory structure is used in a pilot project that examines the
usability of ccmtools in practice...
:-) Egon
|
|
From: Egon T. <ego...@ut...> - 2004-05-13 20:21:05
|
Hi all! I have changed the name of a component's business logic directory from src/ to impl/. The *_app.* suffix has also been changed to *_impl.* (all tests have been updated too). :-) Egon |
|
From: Joerg F. <jf...@sa...> - 2004-04-29 08:14:57
|
>>>>> "Darrell" == Darrell Schiebel <dr...@nr...> writes: Darrell> On Wednesday, April 28 2004 at 17:34+0200, Joerg Faschingbauer wrote: >>> >>> I'm trying to build this for packaging with RPM (so I can get others to >>> try ccmtools, if it looks promising). Currently I have to sed most of >>> the Makefiles to patch the repo location not to install into /usr (BTW, >>> what is the repo for?), see below. Is there an easier way to build >>> cpp-environment in an intermediate location for later >>> installation via RPM? >> >> Why don't you give the prefix you want? Like so, >> >> confix.py '--prefix=/home/drs/dev/ccmtools/cpp-environment/root' >> '--buildroot=/home/drs/dev/ccmtools/cpp-environment' --bootstrap >> --configure --make --targets=install >> >> I believe the $(prefix) macro in the Makefiles is somewhat private >> anyway, in a sense that it should not be overridden by the user. >> >> Or am I missing something (I guess so)? I've never built RPMs. Darrell> Well, (too) often packages use the 'prefix' to compile in Darrell> paths for things like finding help files, shared object files, Darrell> state files, etc. So when I build RPMs I try to specify the Darrell> final resting place as the 'prefix' and then just coerce the Darrell> install step to install to an intermediate location. This seems Darrell> to be something confix does not support (though the 'setup.py' Darrell> which builds confix does support it). I see. The fact that the repo directory is an absolute path in the generated Makefile is clearly a bug. You might want to give 1.3.pre22 (sic!) a try, where this is fixed, so substituting $(prefix) should be just fine now. Joerg |
|
From: Darrell S. <dr...@nr...> - 2004-04-28 17:55:12
|
On Wednesday, April 28 2004 at 17:34+0200, Joerg Faschingbauer wrote: >> >> I'm trying to build this for packaging with RPM (so I can get others to >> try ccmtools, if it looks promising). Currently I have to sed most of >> the Makefiles to patch the repo location not to install into /usr (BTW, >> what is the repo for?), see below. Is there an easier way to build >> cpp-environment in an intermediate location for later >> installation via RPM? > >Why don't you give the prefix you want? Like so, > >confix.py '--prefix=/home/drs/dev/ccmtools/cpp-environment/root' >'--buildroot=/home/drs/dev/ccmtools/cpp-environment' --bootstrap >--configure --make --targets=install > >I believe the $(prefix) macro in the Makefiles is somewhat private >anyway, in a sense that it should not be overridden by the user. > >Or am I missing something (I guess so)? I've never built RPMs. Well, (too) often packages use the 'prefix' to compile in paths for things like finding help files, shared object files, state files, etc. So when I build RPMs I try to specify the final resting place as the 'prefix' and then just coerce the install step to install to an intermediate location. This seems to be something confix does not support (though the 'setup.py' which builds confix does support it). >BTW, the repo directory contains "module descriptions" of the modules >you have built. When you are using confix to build a package that uses >the installed modules, confix uses these descriptions when building a >dependency graph and generating build instructions. You can view the >repo files using print_module.py <filename>. (print_module.py is a >script that comes with confix.) Great, thanks. That's what I guessed, but I just wanted to make sure... since looking at the files themselves offered no clue :) Darrell |
|
From: Egon T. <ego...@ut...> - 2004-04-28 16:26:37
|
Hi Darrell! > Thanks for the help Egon! OK, I've built java-environment (easy) and > most of cpp-environment (painful). I see a note in the INSTALL file for > CCM_Python: > > -------------------------------------------------------------------- o) > Install the python component's environment: > $ confix.py --packageroot=CCM_Python --bootstrap --configure --make > --targets="all install" But, it does not work because CCM_Python is > the package root directory of the Python generator environment!! > -------------------------------------------------------------------- This part of cpp-environment is currently not used by the ccmtools. Actually, Leif is working on a local C++/Python component generator that creates C++ component logic and delegates to Python business logic (in a separate CVS branch). Thus, a client handles C++ components while the Python business logic can be changed without recompiling. > I'm trying to build this for packaging with RPM (so I can get others to > try ccmtools, if it looks promising). Currently I have to sed most of > the Makefiles to patch the repo location not to install into /usr (BTW, > what is the repo for?), see below. Is there an easier way to build > cpp-environment in an intermediate location for later > installation via RPM? Hmm, we always use ccmtools together with confix. Thus I did not try to change the build process in that way. Maybe Jörg (the confix guru) can answer this question... > What I'd like to use ccmtools for is creating components which can > either be used directly from Python or remotely via a C++ CORBA > server. Do you think this is a reasonable application of ccmtools? > Also, from the tutorial diagram, it looks like the "local Python > Component Generator" and the "remote C++ Component Generator" are works > in progress (perhaps why I cannot compile CCM_Python?). Is > this right? Any idea if these represents significant work? Currently, the ccmtools project is focused on a local C++ implementation of CCM components that can be extended to remote (CORBA) components transparently. There is no generator that creates a Python wrapper for a local C++ component - but it would be possible because of the existence of local C++ components... The remote C++ generator is in progress but can be used (=experimental ;-) > Thanks for your help and sorry for all of the questions! You're welcome! :-) Egon |
|
From: Joerg F. <jf...@sa...> - 2004-04-28 16:08:47
|
> I'm trying to build this for packaging with RPM (so I can get others to > try ccmtools, if it looks promising). Currently I have to sed most of > the Makefiles to patch the repo location not to install into /usr (BTW, > what is the repo for?), see below. Is there an easier way to build > cpp-environment in an intermediate location for later > installation via RPM? Why don't you give the prefix you want? Like so, confix.py '--prefix=/home/drs/dev/ccmtools/cpp-environment/root' '--buildroot=/home/drs/dev/ccmtools/cpp-environment' --bootstrap --configure --make --targets=install I believe the $(prefix) macro in the Makefiles is somewhat private anyway, in a sense that it should not be overridden by the user. Or am I missing something (I guess so)? I've never built RPMs. BTW, the repo directory contains "module descriptions" of the modules you have built. When you are using confix to build a package that uses the installed modules, confix uses these descriptions when building a dependency graph and generating build instructions. You can view the repo files using print_module.py <filename>. (print_module.py is a script that comes with confix.) Cheers, Joerg |
|
From: Darrell S. <dr...@nr...> - 2004-04-27 21:24:44
|
On Tuesday, April 27 2004 at 10:24+0200, Egon Teiniker wrote: > >In the current version, we have skipped the ccmtools-cpp-environment >script. Now there are three packages (java-environment, cpp-environment >and ccmtools). You install *-environment first (using Ant and Confix). >After that, ccmtools can be installed and used - see chapter 3 of the >tutorial. Thanks for the help Egon! OK, I've built java-environment (easy) and most of cpp-environment (painful). I see a note in the INSTALL file for CCM_Python: -------------------------------------------------------------------- o) Install the python component's environment: $ confix.py --packageroot=CCM_Python --bootstrap --configure --make --targets="all install" But, it does not work because CCM_Python is the package root directory of the Python generator environment!! -------------------------------------------------------------------- So how do I build it? I'm trying to build this for packaging with RPM (so I can get others to try ccmtools, if it looks promising). Currently I have to sed most of the Makefiles to patch the repo location not to install into /usr (BTW, what is the repo for?), see below. Is there an easier way to build cpp-environment in an intermediate location for later installation via RPM? What I'd like to use ccmtools for is creating components which can either be used directly from Python or remotely via a C++ CORBA server. Do you think this is a reasonable application of ccmtools? Also, from the tutorial diagram, it looks like the "local Python Component Generator" and the "remote C++ Component Generator" are works in progress (perhaps why I cannot compile CCM_Python?). Is this right? Any idea if these represents significant work? Thanks for your help and sorry for all of the questions! Darrell ##============================================================================ ## cpp-environment ##============================================================================ ## WX_Utils: ##---------- mkdir ../root confix.py '--prefix=/usr' '--buildroot=/home/drs/dev/ccmtools/cpp-environment' --bootstrap --configure sed -i -e 's@/usr/repo@/home/drs/dev/ccmtools/cpp-environment/root/repo@' code/Makefile sed -i -e 's@/usr/repo@/home/drs/dev/ccmtools/cpp-environment/root/repo@' error/Makefile sed -i -e 's@/usr/repo@/home/drs/dev/ccmtools/cpp-environment/root/repo@' types/Makefile make make 'prefix=/home/drs/dev/ccmtools/cpp-environment/root' install ## CCM_Local ##---------- confix.py '--prefix=/usr' '--buildroot=/home/drs/dev/ccmtools/cpp-environment' --bootstrap --configure sed -i -e 's@^\(DEFAULT_INCLUDES = \)@\1 -I../../root/include@' HomeFinder/Makefile sed -i -e 's@/usr/repo@/home/drs/dev/ccmtools/cpp-environment/root/repo@' HomeFinder/Makefile sed -i -e 's@/usr/repo@/home/drs/dev/ccmtools/cpp-environment/root/repo@' LocalComponents/Makefile sed -i -e 's@/usr/repo@/home/drs/dev/ccmtools/cpp-environment/root/repo@' LocalTransaction/Makefile make make 'prefix=/home/drs/dev/ccmtools/cpp-environment/root' install ## external ##---------- confix.py '--prefix=/usr' '--buildroot=/home/drs/dev/ccmtools/cpp-environment' --bootstrap --configure sed -i -e 's@/usr/repo@/home/drs/dev/ccmtools/cpp-environment/root/repo@' mico/Makefile sed -i -e 's@/usr/repo@/home/drs/dev/ccmtools/cpp-environment/root/repo@' python/Makefile make make 'prefix=/home/drs/dev/ccmtools/cpp-environment/root' install ## CCM_Remote ##---------- confix.py '--prefix=/usr' '--buildroot=/home/drs/dev/ccmtools/cpp-environment' --bootstrap --configure sed -i -e 's@^\(DEFAULT_INCLUDES = \)@\1 -I../../root/include@' CCM_Session_Container/Makefile sed -i -e 's@/usr/repo@/home/drs/dev/ccmtools/cpp-environment/root/repo@' CCM_Session_Container/Makefile sed -i -e 's@/usr/repo@/home/drs/dev/ccmtools/cpp-environment/root/repo@' RemoteComponents/Makefile make make 'prefix=/home/drs/dev/ccmtools/cpp-environment/root' install ## CCM_Python ##---------- confix.py '--prefix=/usr' '--packageroot=CCM_Python' '--buildroot=/home/drs/dev/ccmtools/cpp-environment' --bootstrap --configure ##============================================================================ ## java-environment ##============================================================================ mkdir root ant install '-Dprefix=/home/drs/dev/ccmtools/java-environment/root' |
|
From: Egon T. <ego...@ut...> - 2004-04-27 08:34:20
|
Hi Darrell! Darrell Schiebel wrote: > > Hi, > > I've been looking at CCM tools/frameworks, and I got interested in > ccmtools. However, I can't make the simple hello-world example in the > tutorial work. Attached is a log of my errors, but the one that has me > stopped is: > Cannot determine build directory because root of package > compilation tree (aka BUILDROOT) not specified > The ccmtools environment cannot be installed from > /tmp/ccmtools-cpp-environment. Unfortunately, the last ccmtools release (version 0.3.2) is out of date, but you can check out a current version (0.3.3) from CVS: $ cvs -d :pserver:ano...@cv...:/cvsroot/ccmtools login Password: <press enter> $ cvs -d :pserver:ano...@cv...:/cvsroot/ccmtools co ccmtools $ cvs -d :pserver:ano...@cv...:/cvsroot/ccmtools co cpp-environment $ cvs -d :pserver:ano...@cv...:/cvsroot/ccmtools co java-environment This CVS version corresponds to the tutorial available from the ccmtools homepage. There are about 30 test cases in the ccmtools/test directory which are running through. Sorry for your troubles. In the next days, I will put an up-to-date pre-release version on the ccmtools homepage. > I can get it to put all of this stuff somewhere else by setting the TMP > (or TEMP) environment variable (surely there's a better place/way), but > still the same error persists. Setting BUILDROOT is no help, and it > seems to ignore ~/.confix completely. In the current version, we have skipped the ccmtools-cpp-environment script. Now there are three packages (java-environment, cpp-environment and ccmtools). You install *-environment first (using Ant and Confix). After that, ccmtools can be installed and used - see chapter 3 of the tutorial. > This isn't exactly a "typical" install... I created RPMs... first for > ccmtools, and then for confix (when ccmtools seemed to need it). These > are available at ftp://ftp.cv.nrao.edu/aips++/development/rpms/noarch/. > Perhaps I'll have to back out and try to get the regular install to work > first... here are the RPMs that are being used (I believe): > > antlr-2.7.2-3jpp > confix-1.3.pre21-2ds > automake-1.6.3-5 > ccmtools-jdom-0.3.2-1ds > ccmtools-doc-0.3.2-1ds > autoconf-2.57-3 > ccmtools-0.3.2-1ds > > (note that ANTLR is coming from jpackage!). Can anyone provide any > suggestions? I'd really like to give this a try. You are right, our install procedure needs some refactoring ;-) Thanks for your constructive ccmtools investigations. :-) Egon |
|
From: Darrell S. <dr...@nr...> - 2004-04-26 21:34:11
|
Hi,
I've been looking at CCM tools/frameworks, and I got interested in
ccmtools. However, I can't make the simple hello-world example in the
tutorial work. Attached is a log of my errors, but the one that has me
stopped is:
Cannot determine build directory because root of package
compilation tree (aka BUILDROOT) not specified
The ccmtools environment cannot be installed from
/tmp/ccmtools-cpp-environment.
I can get it to put all of this stuff somewhere else by setting the TMP
(or TEMP) environment variable (surely there's a better place/way), but
still the same error persists. Setting BUILDROOT is no help, and it
seems to ignore ~/.confix completely.
This isn't exactly a "typical" install... I created RPMs... first for
ccmtools, and then for confix (when ccmtools seemed to need it). These
are available at ftp://ftp.cv.nrao.edu/aips++/development/rpms/noarch/.
Perhaps I'll have to back out and try to get the regular install to work
first... here are the RPMs that are being used (I believe):
antlr-2.7.2-3jpp
confix-1.3.pre21-2ds
automake-1.6.3-5
ccmtools-jdom-0.3.2-1ds
ccmtools-doc-0.3.2-1ds
autoconf-2.57-3
ccmtools-0.3.2-1ds
(note that ANTLR is coming from jpackage!). Can anyone provide any
suggestions? I'd really like to give this a try.
many thanks,
Darrell
|
|
From: Egon T. <ego...@sa...> - 2004-03-11 18:13:39
|
Hi all! I have changed the CppLocalGeneratorImpl.java and CppLocalTestGeneratorImpl.java to prohibit changed files in src/ and test/ from overwriting. If you try to overwrite files (by calling ccmtools-c++-generate -d -a ...) you will get some WARNINGs. Instead of overwriting, the generators store the new files with the extension .new The generated code from CppLocalTestGeneratorImpl.java now contains more comments and less .ptr()-> constructs which are obsolete since using WX::Utils. Finally, I have added a test/CppGenerator/tutorial directory that hosts the example for the new tutorial version (still under construction ;-) :-) Egon |
|
From: Egon T. <ego...@sa...> - 2004-03-08 13:58:30
|
Hi all! I have added a ccmtools/test/CppDbcGenerator directory that hosts test cases for ocl and CppDbcGenerator. All these tests can be run automatically as part of the make check procedure (like the test/CppGenerator test cases). Example: Install, build and test ccmtools $ autogen.py --prefix=path/to/CcmTools $ make $ make install $ make check To get more information please read the README file in ccmtools/test/CppDbcGenerator. :-) Egon |
|
From: Robert L. <rle...@sb...> - 2004-03-03 16:41:17
|
Am Dienstag, 2. M=E4rz 2004 20:43 schrieb Egon Teiniker: > Thus, LocalComponents::CCMException can act as base exception for OCL > exceptions. CCM_OCL::OclException has now the base class LocalComponent::CCMException. Bye, Robert |
|
From: Egon T. <ego...@sa...> - 2004-03-02 20:05:09
|
Hi all! I have changed the ccmtools to use the WX::Utils package instead of CCM_Utils. Additionally, I have added LocalComponents::CCMException to user defined method signatures. Thus, LocalComponents::CCMException can act as base exception for OCL exceptions. The test/CppGenerator tests are running as well as all test/ocl test cases. If you find a bug - please let me know... :-) Egon |
|
From: Robert L. <rle...@sb...> - 2004-02-29 12:23:42
|
Hello! The OCL code generator, which creates 'design by contract' components, is now ready to work. Under "ccmtools/test/ocl" you will find some examples, which shows how to use it. Some examples have a performance test included - they will take a few minutes to run. I changed "ccmtools/CppGenerator/CppLocalTestTemplates/MComponentDef" in a way that it is now much easier to use DbC-components. You only have to define "CCM_USE_DBC". If you find any errors, please post them to the mailing-list. Bye, Robert |
|
From: Robert L. <rle...@sb...> - 2004-02-26 15:50:16
|
Hello!
I found an IDL example which doesn't work:
--- SNIP -----------------------------------------
interface Point
{
attribute double x;
attribute double y;
void move( in double dx, in double dy );
Point clone();
};
interface Line
{
attribute Point startPt;
attribute Point endPt;
void move( in double dx, in double dy );
};
component Grfx
{
provides Point point;
provides Line line;
};
home GrfxHome manages Grfx
{
};
--- SNAP -----------------------------------------
When I call "ccmtools-c++-generate", I get:
Exception in thread "main" java.lang.StackOverflowError
Error while generating IDL3 mirror files.
The problem is the "clone" operation.
Without it, the generator runs.
I'm calling "ccmtools-c++-generate" with parameters '-a' and '-d'.
Bye
|
|
From: Robert L. <rle...@on...> - 2004-02-23 11:47:29
|
Hello!
I made a little update to the documentation:
*) I added a few words to make clear, what the purpose of dtd2java is.
*) The documentation of uml2idl shows now, which circular dependencies
cannot be resolved.
Bye
--
-- Robert Lechner, rle...@sb...
--
|
|
From: Egon T. <ego...@ut...> - 2004-02-19 21:55:24
|
Hi all! I have moved the ccmtools/lib/*.jar files (except for oclmetamodel.jar) to the java-environment/lib directory. Additionally, I have removed the uml2idl and dtd2java packages from ccmtools (to the java-environment package). Now, there are three packages in the cvs repository: # Get the following packages from cvs: $ cd sandbox $ cvs -d :ext:use...@cv...:/cvsroot/ccmtools co ccmtools $ cvs -d :ext:use...@cv...:/cvsroot/ccmtools co cpp-environment $ cvs -d :ext:tei...@cv...:/cvsroot/ccmtools co java-environment The *-environment packages must be build before the ccmtools package. See the INSTALL file in each package to get an idea how to build it. Unfortunately, this build process is difficult but we can automate it before the next release is comming up... :-) Egon |
|
From: Egon T. <ego...@sa...> - 2004-02-19 15:48:12
|
Hi all! Tomorrow, I will start to replace the old CCM_Utils package with the 'new' WX::Utils package. This implies extensive changes in the CppGenerator templates and can break the tests for some days... :-) Egon |
|
From: Egon T. <ego...@ut...> - 2004-02-17 12:50:02
|
Hi Robert! I have changed the java-environment package - have a look to java-environment/INSTALL. >> java-environment/bin > What is the content of this directory? Well, we can put some scripts into this directory, e.g. to start the uml2idl tool. But, you are right, as long as we do not have any scripts we do not have to create it ;-) > Ok. Please move the documentation of 'dtd2java' and 'uml2idl' into > "java-environment/doc". Done! I have also moved the test/uml2idl directory. >> PS: Do you think that the oclmetamodel stuff (MDR/...) should be part >> of the ccmtools package, or is it a tool that can be provided by the >> java-environment? > > The metamodel for OCL should be part of the ccmtools package. > We should also keep the MDR tools where they are now, until we find (or > write) a better tool for MOF/JMI. Hmm, I agree for the oclmetamodel stuff, but I think that the mdr01.jar should be part of the java-environment (the same holds for a pretty new mof2jmi generator ;-). :-) Egon |
|
From: Robert L. <rle...@sb...> - 2004-02-16 18:56:11
|
Egon Teiniker wrote: > Hi Robert! > > Im going to build the java-environment using Ant. Do you agree with > the following structure within the java-environment package: > > java-environment/src/dtd2java > java-environment/src/uml2idl > java-environment/src/uml-parser (generated) > > java-environment/build (generated) > > java-environment/lib > Ok. > java-environment/bin > What is the content of this directory? > java-environment/doc > > I think that this is a practical structure for a Java project (also > for using Eclipse). If you agree, I will change it tomorrow. > Ok. Please move the documentation of 'dtd2java' and 'uml2idl' into "java-environment/doc". > :-) Egon > > PS: Do you think that the oclmetamodel stuff (MDR/...) should be part > of the ccmtools package, or is it a tool that can be provided by the > java-environment? The metamodel for OCL should be part of the ccmtools package. We should also keep the MDR tools where they are now, until we find (or write) a better tool for MOF/JMI. Bye |
|
From: Egon T. <ego...@sa...> - 2004-02-16 14:12:47
|
Hi Robert! Im going to build the java-environment using Ant. Do you agree with the following structure within the java-environment package: java-environment/src/dtd2java java-environment/src/uml2idl java-environment/src/uml-parser (generated) java-environment/build (generated) java-environment/lib java-environment/bin java-environment/doc I think that this is a practical structure for a Java project (also for using Eclipse). If you agree, I will change it tomorrow. :-) Egon PS: Do you think that the oclmetamodel stuff (MDR/...) should be part of the ccmtools package, or is it a tool that can be provided by the java-environment? |
|
From: Robert L. <rle...@sb...> - 2004-02-15 13:14:31
|
Hello! You can now define a root directory for the package in "dtd2java". I also changed the package names of "dtd2java" and "uml2idl". Bye. |
|
From: Robert L. <rle...@sb...> - 2004-02-11 12:20:46
|
Am Mittwoch, 11. Februar 2004 10:19 schrieb Egon Teiniker: > > > > 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 > I added 'dtd2java' and 'uml2idl' to the java-environment module. The script 'make_it.sh' compiles both tools and creates "lib/dtd2java.jar" and "lib/uml2idl.jar". Bye |
