db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mauricio CASTRO" <mcast...@hotmail.com>
Subject Re: mapping workbench
Date Tue, 15 Apr 2003 06:11:38 GMT
Hi,

Thank you a lot for your post Anthony. I think point 6a and 6b are very
important. I will try to post my design here, so everybody can correct and
improve it.

Thank you all.

"The question of whether computers can think is like the question of whether
submarines can swim.", Edsger Wybe Dijkstra (1930-2002).
----- Original Message -----
From: "Anthony Kong" <anthony.kong@ufjia.com>
To: "'OJB Developers List'" <ojb-dev@db.apache.org>
Sent: Monday, April 14, 2003 11:27 PM
Subject: RE: mapping workbench


> Hi, Mauricio, Florian and  all,
>
> Glad to hear some people interested in working on a mapping tool.
>
> I think to come up with list of features first to sort out we acutally
> wanted in the application is the essential step to defined the scope.
> Afterall there are many good commerical products for modeling and
> re-engineering. How far we wanna go in this direction?
>
> I suggest for once we should capture the exsiting function in reversedb.
>
> 1) Generation of OJB repository xml
> 2) Generation of Java source files
>
> I think a desirable feature is to also
>
> 3) generate xmi files. It opens up the opportunity that handy xml tools
can
> be used to generate various artifact based on a common schema dtd.
>
> In term of programming, I guess we should try to achieve these goals:
>
> 4) try to reuse existing OJB codebaase ( e.g. if we try to read in a
> repository.xml in the mapping tool in order to make change to it, can we
> re-use the code in OJB which is responsible to parse the file?)
>
> 5) try to reuse the apache commons. It is very sad that apache commons is
> not up yet. But the last time I visited they have already a alpha versin
of
> schema objects, which represent tables, columns , primary keys etc. There
> are also an array of utitliy which help to, for example, manipulate an
> object names. I guess we should make advantage of this to a maximum
extents.
>
> 6a) seperation of gui and the underlying functionality. It allows an
> opportunties of using some functionality via a command line wrapper.
>
> 6b) And such seperation/design should be friendly to plug-in writers.
>
> Currently i am studying the reversedb2 in order to make it work. My goal
is
> try to deliver  something works asap. Since I have worked with reversedb
> before so I hope this experience helps me to develop the reversedb2. (Of
> course anyone's participation/input is welcome)
>
> I would suggest to Mauricio to spend a considerable amount of time to
design
> and plan the structure of the application. Reason: it is a small
application
> and if code are too tightly coupled, it would mean it is hard for people
to
> work on the piece concurrently and hence limit the evolution of the
> application. It would be nice if you post your design first for comment
then
> we can shift into a higher gear to development.
>
> I seems to have talked so much about the obvious. :-) The above is really
> just my wish list.
>
>
> Regards,
>
>
> Anthony
>
>
>
> -----Original Message-----
> From: Florian Bruckner [mailto:bfl@florianbruckner.com]
> Sent: Monday, April 14, 2003 3:44 PM
> To: OJB Developers List
> Subject: AW: mapping workbench
>
>
> Hi Mauricio,
>
> > 1 If it someone has a list of features and the priority of each.
>
> Not really, there were some discussions which functionality should go into
> such a tool, but there has never been a vote on a feature list.
>
> > 2 If the is reusable code in the package org.apache.ojb.tools.
>
> There is. Take a look at org.apache.ojb.tools.reversedb. This package
> contains a simple reverse engineering tool which I wrote to make myself
> familiar with the metadata interface of JDBC and how it works with various
> drivers. While this tool is very limited by its design (or lets say
> non-design), the package org.apache.ojb.tools.reversedb2 contains a rough
> design/prototype for a tool that should be easier to use and more flexible
> when it comes to enhancing it.
>
> There were also approaches to extend already existing tools (I forgot
which
> one), but I didn't follow that development and I do not know the state of
> the project.
>
> > 3 If there are documents not listed in the web site that are helpful.
>
> Not that I know of.
>
> > 4 Someone has something to say ;)
>
> :-)
>
> regards,
>
> Florian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>

Mime
View raw message