Home » Eclipse Projects » Oomph » Loading Eclipse plugins right from the Workspace(When the Project repo provides application specific Eclipse extensions)
Loading Eclipse plugins right from the Workspace [message #1857882] |
Fri, 03 March 2023 13:04 |
Michael Haubenwallner Messages: 4 Registered: March 2023 |
Junior Member |
|
|
Dear Eclipse Oomph developers!
Right within our quite huge mono-repo application, we also maintain some Eclipse plugins, which are tightly coupled with the application code.
Besides some sophisticated Views and Editors, this also includes some Xtext DSLs with code generators, where the generated code has to match the application source code.
Some of these DSL content is interpreted not only within the running Eclipse at development time, but also within the application itself at runtime.
After all, "DomainSpecificLanguage" actually means "ApplicationSpecificLanguage" here, and there would be no point in maintaining their Eclipse plugins as separate projects.
Because of this tight coupling, we have a hard time distributing these Eclipse plugins in sync with the application source code - which is what I really would like to improve.
Note that we use Genuitec SDC as the Eclipse IDE distribution mechanism right now - without any sign of Oomph anywhere (yet?).
To start with, the overall idea now is to load the application specific Eclipse plugins right from the Workspace, where the Eclipse plugins' source code resides within the application's Git repo.
Consequently, upon some Git operation touching these Eclipse plugins' source code, the running Eclipse plugins should be reloaded as well.
What I have learned/accepted already:
- Despite propably supported by OSGi/Equinox, replacing running Eclipse plugins without restarting Eclipse is unlikely to work in a stable manner:
It should be acceptable to perform an Eclipse restart upon changes to Eclipse plugins found in the Workspace.
- Before restarting, automagically recompile Eclipse plugins after some Git operation is unlikely to work at all (different Target Platform, Project selection, etc.):
It should be acceptable to add ("ship") the binaries for those Eclipse plugins as part of the very same Git commit together with the code changes.
Thoughts so far?
What I have tried already:
For some very small Eclipse plugin project on Github, I have added this project's resulting p2 site to that very Git repo, in order to have some test situation for loading Eclipse plugins right from the Workspace.
Then, I have managed to create an Oomph Project Setup file, containing some P2 Director task loading that Eclipse plugins, with "Merge Disabled=true" to allow for disabling during early P2 tasks.
If curious, I can provide the weblink to that setup file for use with current Oomph-Installer - I'm just not allowed to add weblinks in my first forum post.
However, I haven't found yet how to declare that this one P2 Director task should run _after_ the Git Clone task or even after the Projects Import task has run.
Nevertheless, manually disabling this task during project setup, and manually "Perform Setup Tasks..." again afterwards does the trick here, to get the idea of what I'm after.
Anyway, this looks so promising already, even if I'm really new to Oomph!
However, migrating all our current SDC based setup to pure Oomph would be a lot of work.
Instead, to start with, my next idea was to engage the Oomph P2 Director Task only, in order to perform the Eclipse setup using Workspace content.
But then I failed to find the correct Oomph API to use.
For the moment, I have tried to use the org.eclipse.equinox.internal.p2.director.app.DirectorApplication instead right from within the running Eclipse:
While this seems to work - at least on Linux, I really would appreciate the additional features seen with Oomph P2 Director Task, like performing the Eclipse restart for example.
Whatever thoughts, they're welcome!
Thanks a lot!
Michael
|
|
| | | | |
Goto Forum:
Current Time: Sat Dec 07 15:18:38 GMT 2024
Powered by FUDForum. Page generated in 0.03192 seconds
|