Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Some Infos About Oomph

Thanks for your answer, Eike.
(BTW, I don't care about a missing 'c' in my name ;)

Le 28/01/2015 10:34, Eike Stepper a écrit :
Is Oomph able to listen to "structural" IDE actions (such as addition of some new feature or setting of a global preference) and to maintain a "current" profile according to it? For example, assuming I install an IDE provisioned by Oomph, and then install e4 Tools in it; then can I export and backup a profile that automatically contains my initial IDE + the addition of e4 tools? Currently we've only implemented a recorder for the global workspace preferences. We're working on a more general framework to listen to these "structual changes" in the running IDE, generate SetupTasks from them and store them in a profile. Yatta has also already worked on a couple of these "task builders" and is involved in the effort to store these profiles at and make them available to other users.

And then can I either re-provision a new IDE or an existing one with the profile definition I exported?
Currently we always add these generated SetupTasks to the user profile and that particular profile is applied to any IDE or workspace anyways (restrictions can be specified, too). With our tree structure editors you can easily move/copy these tasks from your user profile to product or project profiles. And we'll soon start to make it easier for the user to control where these generated tasks will be stored. For example we've discussed a new "machine profile" to separate machine-specific from user-specific setup aspects.

Another question then (I'm really going deeper in my understanding of Oomph, so sorry if those question seem too basic).
The strategy of Oomph is recording a sequence of changes (preference, installation...). However, I'm wondering in the case of bootstrapping or customizing an application, whereas this sequence is actually useful. What does it provide over only polling the "current" state and recomputing the profile from scratch? Instead of recording, we can imagine an "Export profile" action that would ask p2 which IUs have been installed, export the main preferences, export the existing SCM repositories definition... Is history of installation really important, or does only the result/snapshot count?
I tend to believe that only the snapshot counts, and that instead of a recorder, a "simple" crawler would be satisfying.
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets

Back to the top