Community
Participate
Working Groups
Build Identifier: I20110613-1736 Currently, XtextProjectHelper has one static method #hasNature(IProject) which hard-codes dependency on 'org.eclipse.xtext.ui.shared.xtextNature'. Making this method non-static and injecting XtextProjectHelper would allow to 'override' this dependency and use other natures as 'a flag' for Xtext infrastructure. This may be interesting for extenders who may prefer to have their own natures for their project types. Reproducible: Always
Please note that the helper is used by shared component thus cannot be exchanged easily.
Thanks for the reply, Sebastian! Yes, I should clarify this a bit. The use case I have in mind is that a vendor may prefer to contribute and use their own 'shared' component (instead of 'o.e.xtext.ui.shared'). For example, they may want to completely control the build infrastructure (i.e. project natures and builders) for their specific project types, but would like to reuse some of the Xtext components in a very custom way (e.g. use a subclass of XtextBuilder with a very special ToBeBuiltComputer). Also they may prefer not to have some of the 'global' extensions made by 'o.e.xtext.ui.shared' (actions, decorators, etc.) In other words, they would like to fully control all the Xtext 'shared' aspects in their product, thus using Xtext more as a 'library' of highly reusable components than as a 'finished' infrastructure (if I may put it so). As far as I can see Xtext allows to do it (perhaps with minor modifications, such as this one). Does it make sense?
Yes, it does make sense. How about having your own set of shared bundles reusing the code from the Xtext bundles. This would at least prevent conflicts with other Xtext-based languages. I can understand that you want to have every little UI contribution under control in a product, I'm just a bit anxious about people modifying what is meant to be shared by many different parties. Changing XtextProjectHelper to be non-static seems to be straight forward.
Sven, I can fully understand your concern. I would like to find as clean solution as possible here. Of course, I'm not talking about any modification of shared Xtext bundles (i.e. forking), if that is what you meant. One of the problems is that 'o.e.xtext.ui.shared' bundle, in addition to providing 'shared' singletons, also contributes some extensions which indeed may seem a little intrusive in a product. Maybe a separation of 'SharedStateModule' from the 'global' contributions could provide a cleaner solution? I mean that the contributions would be made by another Xtext bundle, not by 'o.e.xtext.ui.shared'. Wouldn't it be a more flexible design? I will greatly appreciate your considerations.
