Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » Best tooling to replace Texo
Best tooling to replace Texo [message #1854413] Wed, 17 August 2022 19:32 Go to next message
Mr Cur is currently offline Mr CurFriend
Messages: 35
Registered: September 2014
Member
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 #1854419 is a reply to message #1854413] Thu, 18 August 2022 06:47 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

I'm sorry that I cannot help with Texo specifically; whenever I have tried to improve my knowledge, I somehow concluded that Texo wasn't relevant for me.

Buckminster is indeed very end of life. Maven-based Tycho is the almost universally adopted replacement. It has distinct differences and is on balance distinctly better but the transition is painful.

However most Eclipse projects have a local build that just happens magically as the JDT builder and possibly other builders do their work. You are able to launch a nested Eclipse and use your build without ever touching Buckminster or Tycho or Maven or Gradle or ...

To allow other users, or yourself in the outer Eclipse to use your semi-interactive build you just need to export the plugins, and then import them again. I regret that it is many years since I did this so I cannot offer precise guidance, but you can probably manage without a Buckminster replacement. There is a File->Export facility. Slightly more advanced, but still simple is to add a feature and build an Update Site. Texo surely provides features so you just need to define the Update Site. Texo is so old that the Update Site may already be there from pre-Buckminster days.

You will of course have to invoke test suites manually and may need to do a little repair to accommodate the mandatory Java 11 for modern Eclipse IDE work.

Regards

Ed Willink

[Updated on: Thu, 18 August 2022 06:49]

Report message to a moderator

Re: Best tooling to replace Texo [message #1854422 is a reply to message #1854419] Thu, 18 August 2022 07:46 Go to previous messageGo to next message
Mr Cur is currently offline Mr CurFriend
Messages: 35
Registered: September 2014
Member
Hi Ed,

Many thanks for you detailled guidance. It is certainly an option to see if we can solve the problems ourselves. I am familiar with Java development, but as it come to Eclipse only from a user perspective. But I will give it a try.

Best,
-- Jaap
Re: Best tooling to replace Texo [message #1854425 is a reply to message #1854422] Thu, 18 August 2022 09:26 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
Yes, this project is in a state were it should be archived. If you'd like to keep it alive as a committer, I can try to help with that. It will be a significant investment of time. In the not-too-distant future, it will need to be migrated to Github. It will also need new builds based on Tycho...

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Best tooling to replace Texo [message #1854445 is a reply to message #1854425] Thu, 18 August 2022 19:33 Go to previous messageGo to next message
Mr Cur is currently offline Mr CurFriend
Messages: 35
Registered: September 2014
Member
I had a look this night. My findings are that the code is too old. It would nbe a lot of work. Moreover, the documentation for a developer is very limited. For us, it is perhaps quicker to write a JPA ourselves, since we don't a lot of functionality that is also in Texo.
Re: Best tooling to replace Texo [message #1856665 is a reply to message #1854413] Wed, 21 December 2022 16:58 Go to previous message
Geoffry Roberts is currently offline Geoffry RobertsFriend
Messages: 7
Registered: December 2022
Junior Member
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.
Previous Topic:Linking an actor to a use case
Next Topic:How to display a reference
Goto Forum:
  


Current Time: Wed Apr 24 22:14:03 GMT 2024

Powered by FUDForum. Page generated in 0.03237 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top