search

viatra / EMF-IncQuery

This repository is only kept for historic reasons. All development happens on eclipse.org
http://eclipse.org/viatra
13 stars 4 forks source link

Generator fragments should refer to IncQuery project by bundle ID #145

Closed istvanrath closed 12 years ago

istvanrath commented 12 years ago

I've noticed that the databinding generator generates a *.databinding/META-INF/MANIFEST.MF dependency to the original IncQuery project by the IncQuery project's name rather than its bundle ID. In special cases, where the project name is different from the bundle ID, this will lead to compile errors in the generated code.

The same issue applies to every generator fragment.

szabta89 commented 12 years ago

Maybe @ujhelyiz would have a suggestion here, because I do not think the solution is within the scope of the databinding generator project.

ujhelyiz commented 12 years ago

As the projects are not created by the fragments, @szabta89 is right that this is outside the databinding generator fragments jurisdiction. For the same reason, the issue is general for all generator fragments.

On the other hand, currently the tooling does not allow to create such projects automatically - you can achieve this by renaming your projects while not renaming its bundle id that is not recommended at all for other reasons. In other words, while you are right that the bundle id is a better candidate, I'd like to work on prohibiting the reaching of this state.

ujhelyiz commented 12 years ago

A fix added to master. However, a problem still persists: if I change the symbolic name of an IncQuery project (irrelevant whether the project name is synchronized to that or not), the builder forgets the old derived projects (e.g. validation project), and starts new ones.

@CMark, @istvanrath The question is, how should we handle this? Should we say, it is not supported to rename projects? Should we strive for a rename refactoring for all projects together? Or should we persist the old project name during building (e.g. in the would-be Generator model of #17 )?

These are the basic strategies I see, but there might be other possibilities.

istvanrath commented 12 years ago

I think the remaining issue (renaming projects causing problems) is of rather low importance, since the error can be noticed by the user easily, as - if I understand correctly - orphaned .validation etc. projects will be identified by a compile error (unresolved dependency). So I'm closing this issue.