db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: Mapping workbench, finally
Date Tue, 22 Apr 2003 20:15:02 GMT
(sorry for reposting, somehow my message did not get delivered the first 
time...)

Hi all,

Matthias.Roth@BIT.admin.ch wrote:
> Hi Florian,
> I also think it will be a good idea to coordinate our effort, if it is
> possible.
> But we have to solve different interest conflict:
> -	forward engineering tool
> -	reverse engineering tool
> -	inside out engineering tool (mapping existing classes with existing
> tables)

I don't see this as interest conflict or concurrency. To have a complete
set of mapping tools we will need at least:

*Forward engineering*
1. Java to repository.xml and DDL (presumably XDoclet based)
2. XMI to Java and repository.xml and DDL (presumably XSL based
transformation)

*Reverse engineering*
3. reading in a DB catalog, selecting tables and generating Java code
and repository.xml (see existing reverse-Ddb tool and the existing
Eclipse plugin)

*mapping proper*
4. reading in a DB catalog, selecting tables, reading in classes from
the classpath, selecting classes to map, and performing the mapping of
classes to table and of attributes to columns.


All four scenarios should reuse as much code as possible. My initial
suggestion was to use the
org.apache.ojb.broker.metadata.DescriptorRepository the central
dataformat for all all transformations.
This would lead to the following design:
1a. Java to repository.xml (XDoclet based) and parsing the
DescriptorRepository from that file. Then there would be an additional
DescriptorRepository to DDL Generator (similar to the
RepositoryPersistor that can be used to generate a repository.xml file
from a DescriptorRepository instance).

1b. Java to DescriptorRepository transformation (not based on XDoclet,
thus some additional work required). Then again the DescriptorRepository
to DDL Generator.

2. First a XSL transformation from XMI to Java sourcecode, then same
procdure as in 1a or 1b.

3. After reading in and selecting tables a DescriptorRepository instance
is constructed from the mapping information. The RepositoryPersistor is
used to write the repository.xml file.
Java source code can be generated by XSL transformation from the
repository XML.

4. During the mapping process a DescriptorRepository instance is built
upfrom the mapping information. The RepositoryPersistor is used to write
the repository.xml file.

As you can see there is a lot of reuse possible and there are also
several thing prepared in the metadata package for a cool mapping toolkit!


> -	Stand alone tool (Swing, SWT)
> -	Eclipse Plugin based Tool
> -	Etc.
> I made an Eclipse Plugin, because I work with IBM WSAD and do not want an
> other
> tool outside the IDE.

IMO it is manadatory to reuse as much code as possible for these
implementations. We have to maintain this code for long time and
maintaining a functional change in one place is more fun than doing it
twice or thrice.

> In XP is one point: do 'only' what you know now but good and make a redesign
> if you have new requirements.  From this point of view I do not like to
> throw away anything.
> But a good idea will be to define some use cases to decide if we throw away
> anything.

IMO the requirements are quite clear and not changing every day. Making
a solid design in advance will safe us a lot of work.

> 
> A vision can be to have a tool in eclpse, for work with db and classes, as
> the Microsoft Studio offers to their clients for .net. But this means that
> we have to support more functions than it is needed to support 'only' OJB.
> In the new Plugin I have a function to get data from tables. I like also to
> have a function witch generates ActionForms for Struts, because more than 60
> % of the table will be used in the same structure in ActionForms.

Of course there will be other user who would like to see NetBeans or
JBuilder Plugins.
We should try to isolate the *functional* code in such a way that we
only have to maintain it in one place. Only the IDE interfacing code
should vary.

I'm willing to check in code to the OJB codebase to get things going.
But I could also imagine that we could "reactivate" the old
objectbridge.sf.net site to make CVS access easier for a wider range of
developers.

cheers,
Thomas


> regards 
> Matthias
> -----Original Message-----
> From: Florian Bruckner (apache.org) [mailto:florianbruckner@apache.org]
> Sent: Dienstag, 22. April 2003 16:25
> To: ojb-user@db.apache.org; OJB Developers List
> Subject: Mapping workbench, finally
> 
> 
> Hi,
> 
> I am crossposting this intentionally to users AND dev-list as I hope I can
> get some more attention for this message. This is just meant to start the
> discussion, please let us discuss these matters on the dev list.
> 
> Recently a some graphical tools popped up that all claim to solve specific
> problems concerning repository mappings. It is good to see that OJB has a
> growing user base and that there is increasing willingness to contribute to
> the success of OJB. On the other hand it makes me somewhat sad that these
> effort are all but coordinated. For example there is a plugin for eclipse
> that is based on reversedb (see below), Mathias undoubtedly put in a lot of
> effort to fix bugs and make the classes work for his purpose. But neither
> have any bugs ever been discussed on any public mailing list nor have the
> bugfixes made it back to the codebase of reversedb. The result is lost
> effort on both sides and software that is less functional than it could be.
> 
> OJB currently has (and has had for a long time now) two flavours of a
> mapping workbench. Reversedb is a simple (slow and buggy) application to
> read a database schema and generate XML and java classes. Reversedb2 is a
> rough prototype for a mapping workbench with a better design than reversedb.
> Both applications suffer from the fact that design and implementation have
> been made by a single person (me). The design is possibly even broken in a
> way that makes it impossible to implement certain requirements.
> 
> I understand that it is a problem for a lot of people to contribute to a
> piece of software where they have not been able to contribute during the
> design phase and when they think they could have done better. Let's throw
> away all we have and start over again.
> 
> This email should be seen as a call for a discussion. Let's discuss what the
> requirements to a mapping workbench are, let's discuss the goals and how
> these goals can be achieved, let's discuss who can take which role in such
> an effort, let's discuss a design and let's make the best mapping tool
> possible. And let's combine our efforts.
> 
> regards,
> 
> Florian
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 



Mime
View raw message