QA on templates

[maybeec]

Expected behavior

The current ide setup of devon 2.4.0 delivers templates. I am importing these templates and trying to generate different java application based on different architectures (simple vs complex). It should work in any combination like

• CRUD DAO + CRUD logic (simple) + CRUD service REST
• CRUD DAO + CRUD logic (complex) + CRUD service REST
• CRUD DAO + CRUD logic (simple) + CRUD service SOAP
• CRUD DAO + CRUD logic (complex) + CRUD service SOAP
• ... etc

Please also check "nested" and spring data increments. Maybe we should cleanup here. Currently, it is not easy to understand what is meant by "nested".

Actual behavior

• The annotation @UseCase is not defined anymore. Most probably, it is removed in oasp4j? @hohwille
• In some cases, Cto methods are missing on logic layer, but they are generated and accessed through the service implementation.
• I think, I also observed, that any AbstractUseCase or some super class was not generated in some combination.

Steps to reproduce (bug) / Use Case of feature request (enhancement)

1. Generate different combinations as mentioned above. Different errors will arise.
2. Please start with a clean state all the time.

Related/Dependent Issues

Implementation Hints

Best would be, if we could provide multiple SWTBot tests, each generating one combination of increments above, which should compile out of the box. Then we could check that, by trying to find compilation errors in the error view. You might want to have a look at the latest commit on cobigen-eclipse, which introduced SWTBot code to access the error log. A prove of validity might be to assert, that there are no errors after generation and rebuild.

[jdiazgon]

In this comment, I will keep updating the errors that I find related to the generation of the different increments.

Using OASP4J archetype version 2.4.0.

Working fine

These are the increments that compile and work fine (although to compile you need Entity infrastructure and TO's increments).

• Increments CRUD DAO + CRUD logic (simple) + CRUD service REST.
• Increments CRUD DAO + CRUD logic (simple) + CRUD service SOAP.
• Increments CRUD DAO + CRUD logic (complex) + CRUD service SOAP.
• Increments CRUD DAO + CRUD logic (simple) + CRUD Nested SOAP service + CRUD Nested Rest service.

Some compilation errors

• [x] increments CRUD DAO + CRUD logic (complex) + CRUD service REST has a compilation error related to ${entityName}Cto not defining find${entityName}Cto method.
• [x] increments CRUD DAO + CRUD logic (complex) + CRUD Nested REST service + CRUD Nested SOAP service has a compilation error related to ${entityName}Cto not defining find${entityName}Cto method.
• [ ] increments CRUD SpringData logic + Entity infrastructure + TOs has multiple compilation errors related to org.springframework.data.jpa.repository.JpaRepository and Q${entityName}Entity not being found.
• [ ] increments CRUD SpringData logic (complex)+ CRUD SpringData logic has multiple compilation errors related to type mismatch errors when trying to save an entity,

[jdiazgon]

The usefulness of nested and spring data increments should be discussed. I haven't received any claim on my side related to compilation errors. This may mean that our developers just use the most common increments like CRUD DAO + CRUD logic (simple) + CRUD service REST + CRUD service SOAP + TO's + Entity infrastructure.

[github-actions[bot]]

Stale issue message