Best tooling to replace Texo [message #1854413] |
Wed, 17 August 2022 15:32  |
Eclipse User |
|
|
|
Hi,
I use Texo for quite some time to generate JPA classes for UML class models.
It works very well, but unfortunately seems not to be maintained anymore. For example, it can not be installed in recent Eclipse editions, so it requires an old Eclipse install to get it up-and-running. This clumsy, and a pity, because Texo is an excellent tool.
A small product survey by me revealed not an equivalent (commercial) product with similar functionality as Texo. Most products do not include a graphical editor, generate poor code (e.g. bidirectional relationships are not supported), offer only limited control of the code generation process and/or do not allow to add code to the generated code (that will not be overwritten during the next generation process).
Tools I looked at are Jeddict, StarUML/Rebel and JPA-Buddy, but none of them satisfied my requirements completely:
- graphical editor for the class modelling
- full support of JPA 2.1
- generation of high quality code, e.g. correct and safe management of bidirectional relationships
- fine grained control of the generation process
- generation of Jackson annotations, e.g. @JsonSubtype, etc. (nice to have)
My questions:
- are there suggestions for suitable tooling (commercial software is acceptable for us, as long as it fits the requirements)
- did someone manage to build Texo recently? I have checked out the source code, but the build system (buckminster) is unfamiliar to me and seems also to be end-of-live.
Thanks for your answers.
-- Jaap
|
|
|
|
|
|
|
Re: Best tooling to replace Texo [message #1856665 is a reply to message #1854413] |
Wed, 21 December 2022 11:58  |
Eclipse User |
|
|
|
I'll tell you my sad story.
I too needed some way of persisting EMF models into RDBMS. For me, annotations were not suitable because EMF is generated. I did wind up using JPA/XML, which substitutes for annotations and can be maintained separately. It is therefore immune to re-generation. The problem with the JPA/XML approach is that there is an utter dearth of documentation. Lots of docs for annotations but not for XML. popular vs not-so-popular
The upshot is that I was pulled off the task because it was taking too long. I was having to read the JPA/XML schemas in order to figure things out. I was making progress, but it was indeed slow.
It all makes me wonder if one could read the model and generate the JPA/XML Nice project for a rainy day or a sleepless night.
I have found persisting EMF into a big table (using AssociativeArray) to be far more attractive and works as well as a RDBMS.
|
|
|
Powered by
FUDForum. Page generated in 0.57951 seconds