How to modularize an Xtext-based Eclipse RCP project: separate plugins for formatter, validator, etc

[AhmedMahmoud98]

Hi Xtext team,

In my current Xtext-based Eclipse RCP project, I have a large .dsl plugin that contains all logic—grammar, formatter, validator, scoping, etc. I’d like to refactor this setup to follow a more modular architecture, where:

The .dsl plugin contains only the grammar and common runtime/shared logic.

Other concerns (like formatting, validation, etc.) are moved into separate lightweight plugins (e.g., .dsl.formatter, .dsl.validator, .dsl.generator, etc.).

The main goal is to create a lightweight executable for each individual task.

My questions:

Is this modular separation supported and recommended in Xtext?

Should each plugin have its own Guice *RuntimeModule that only binds what it needs (e.g., just the IFormatter2 in the formatter plugin)?

How should injectors be handled in this setup? Should each plugin define its own StandaloneSetup, or can they reuse the base one from the .dsl plugin with a custom module?

How can I keep the .dsl plugin decoupled from formatter/validator implementations (i.e., without it knowing about the other plugins)?

If there’s an example project that demonstrates this pattern or any guidance on best practices for structuring modular Xtext plugins, I’d greatly appreciate it.

Thanks!

[cdietrich]

i dont think this makes sense and is possible. can you elaborate why you want to do it?

[LorenzoBettini]

As @cdietrich already said, I don't think it is a good idea. Ask yourself whether you'll ever need the core module without validation. I'd suggest you not overengineer your code.

[AhmedMahmoud98]

Hi cdietrich, LorenzoBettini

The main goal is to create fast, lightweight executables for tasks like formatting, validating, sorting, ... where it should be easy to integrate into our users' CI pipelines without needing everything in one place. I want to create something similar to YAML ANTLR for example.

[LorenzoBettini]

Modularizing code doesn't necessarily make it fast (it might be the opposite).
Having "everything" in one place makes things much easier and more maintainable, not to mention much simpler.
We learned it ourselves: One single Git repository is much better than 6 separate Git repositories.

[cdietrich]

plus one on this. i dont think modulaization would give any speedup.