Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OASP regeneration from entity causes duplicated UC interface extension in component facade #58

Closed
hohwille opened this issue Nov 7, 2014 · 2 comments

Comments

@hohwille
Copy link
Member

hohwille commented Nov 7, 2014

When I choose an Entity in OASP and regenerate Implementation then the component facade (e.g. TableManagement) gets merged and the extends statements to the usecase interfaces get duplicated causing a compile error.

Before:

public interface Tablemanagement extends UcFindTable, UcManageTable {

After:

public interface Tablemanagement extends UcFindTable, UcManageTable, UcFindTable, UcManageTable {

template: DataManagement.ftl

@hohwille hohwille added the bug label Nov 7, 2014
@hohwille
Copy link
Member Author

hohwille commented Nov 7, 2014

I think this was working before and appears like a regression bug of java merge strategy.

@maybeec
Copy link
Member

maybeec commented Nov 10, 2014

The problem was because of wrong imports of the usecases within the DataManagment.ftl template. Thus the merger compared e.g. two classes of UcManagTable:

Base: io.oasp.gastronomy.restaurant.tablemanagement.logic.api.usecase.UcFindTable
Patch: io.oasp.gastronomy.restaurant.tablemanagement.logic.base.UcFindTable

Due to organize imports the first will be corrected after initial generation of such a dependency. The next time the merger will compare the patch and the base, which will now declare two different imports.

_Open discussion:_

  1. You might argue that this it is a bug as it should be possible to inherit both classes. I would see that as minor improvement as it can be also argued to be a bad design and to occurr with a low probability. :) So costs vs. benefits currently would go for deferring this.
  2. Second thing to be mentioned is, that the import declarations might be seen as not necessary. This is true as far as all dependencies--your generated code depends on--exist before generating the new contents. Otherwise, I observed that "organize imports" is not able to resolve dependencies between newly generated Java classes. Maybe because of a missing compile step between generation and calling "organize imports". If we can manage to get this working, this might help us a lot during maintaining the templates over time, but this will need further investigation. I would go for a new issue (Enable organize imports for dependencies between generated contents #59) about that.

@maybeec maybeec closed this as completed Nov 10, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants