Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsOomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1387033/#msg_1387033
Is it possible to launch Oomph as a headless application ? If it is, which APIs allow to do that ?
Best regards,
Axel]]>Axel RICHARD2014-06-23T15:23:53-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1387037/#msg_1387037
In theory it should be possible because we've just fully separated Core and UI, but we haven't developed a headless
installer application. Hence we've never tested that it really already works. If you're interested to help that would
make a nice contribution ;-)
Am 23.06.2014 17:23, schrieb Axel RICHARD:
> Hi,
>
> Is it possible to launch Oomph as a headless application ? If it is, which APIs allow to do that ?
>
> Best regards,
> Axel]]>Eike Stepper2014-06-23T16:13:59-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1387039/#msg_1387039
It's certainly possible in principle, but we've not looked at providing
such an application. What are you hoping to achieve? (Certainly all the
things you'd normally have to specify in the installer wizard would need
to be specified as arguments to the application.)
On 23/06/2014 5:23 PM, Axel RICHARD wrote:
> Hi,
>
> Is it possible to launch Oomph as a headless application ? If it is,
> which APIs allow to do that ?
>
> Best regards,
> Axel]]>Ed Merks2014-06-23T16:18:44-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1387105/#msg_1387105
As part of EMF Compare, we want to provide a headless application in order to do merge opertions on models with (j)git. For that reason, we need a mechanism to provision a worksapce and an eclipse environment, and Oomph seems to fit this need.
Axel]]>Axel RICHARD2014-06-24T07:25:54-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1387109/#msg_1387109
I see, so it would be a headless application that includes
org.eclipse.core.resources, i.e., that includes workspace support. I see
no reason, in principle, why this wouldn't work well. Do you want to
help design such an application? Without your help, it will likely be a
few weeks before we'd have time to look at it...
On 24/06/2014 9:25 AM, Axel RICHARD wrote:
> Ed,
>
> As part of EMF Compare, we want to provide a headless application in
> order to do merge opertions on models with (j)git. For that reason, we
> need a mechanism to provision a worksapce and an eclipse environment,
> and Oomph seems to fit this need.
>
> Axel]]>Ed Merks2014-06-24T08:22:07-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1392344/#msg_1392344
With Oomph, there is bootstrap tasks and startup tasks. Once bootstrap tasks have been executed, you can launch the provisionned environment. When this environment is launched, Oomph is automatically launched to execute startup tasks (e.g. clone a repo, imports projects...).
I succeed in programmatically provision an eclipse environment with oomph.
But I don't find the code that allows to execute the startup tasks in this provisionned environment.
Am 02.07.2014 09:30, schrieb Axel RICHARD:
> Hi,
>
> With Oomph, there is bootstrap tasks and startup tasks.
Knitpicking a bit, the list of tasks that you see for the bootstrap trigger and the list of tasks you see for the
startup trigger is not necessarily disjunct; or in other words, a task can be both a bootstrap and a startup task.
> Once bootstrap tasks have been executed, you can launch the provisionned environment. When this environment is
> launched, Oomph is automatically launched to execute startup tasks (e.g. clone a repo, imports projects...).
> I succeed in programmatically provision an eclipse environment with oomph. But I don't find the code that allows to
> execute the startup tasks in this provisionned environment.
That code is in org.eclipse.oomph.setup.ui.SetupUIPlugin.performStartup().
This method should be automatically called when the org.eclipse.oomph.setup.ui plugin is started, which happens early.
So I wonder why that doesn't happen in your case.]]>Eike Stepper2014-07-02T11:25:36-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1392567/#msg_1392567
It's important to set properties in the eclipse.ini, in particular
-Doomph.setup=true
On 02/07/2014 1:25 PM, Eike Stepper wrote:
> Hi Axel,
>
> Comments below...
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
> Am 02.07.2014 09:30, schrieb Axel RICHARD:
>> Hi,
>>
>> With Oomph, there is bootstrap tasks and startup tasks.
> Knitpicking a bit, the list of tasks that you see for the bootstrap
> trigger and the list of tasks you see for the startup trigger is not
> necessarily disjunct; or in other words, a task can be both a
> bootstrap and a startup task.
>
>> Once bootstrap tasks have been executed, you can launch the
>> provisionned environment. When this environment is launched, Oomph is
>> automatically launched to execute startup tasks (e.g. clone a repo,
>> imports projects...).
>> I succeed in programmatically provision an eclipse environment with
>> oomph. But I don't find the code that allows to execute the startup
>> tasks in this provisionned environment.
> That code is in
> org.eclipse.oomph.setup.ui.SetupUIPlugin.performStartup().
>
> This method should be automatically called when the
> org.eclipse.oomph.setup.ui plugin is started, which happens early. So
> I wonder why that doesn't happen in your case.
>
>]]>Ed Merks2014-07-02T14:19:22-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1393897/#msg_1393897
Thanks for your prompt answers, still progress on executing oomph headless.
I succeed in programmatically provision an eclipse environment with oomph.
I succeed in execute my startup tasks in this provisionned environment.
Now, I don't understand why the plugin org.eclipse.oomph.setup.ui is included in the feature org.eclipse.oomph.setup-feature ?
In the perform(SetupTaskContext) method of GitCloneTaskImpl, I found this:
// Force start egit to make the clone appears in the repositories view and so projects are connected by the egit team provider.
CommonPlugin.loadClass("org.eclipse.egit.ui", "org.eclipse.egit.ui.Activator");
But, in my case, that is to say a headless context, I don't want org.eclipse.egit.ui.
Do you plan to remove org.eclipse.oomph.setup.ui from the org.eclipse.oomph.setup-feature ? Or do you know a workaround ?
Best regards,
]]>Axel RICHARD2014-07-04T12:46:21-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1394375/#msg_1394375
Comments below.
On 04/07/2014 2:46 PM, Axel RICHARD wrote:
> Hi guys,
>
> Thanks for your prompt answers, still progress on executing oomph
> headless.
> I succeed in programmatically provision an eclipse environment with
> oomph. I succeed in execute my startup tasks in this provisionned
> environment.
>
> Now, I don't understand why the plugin org.eclipse.oomph.setup.ui is
> included in the feature org.eclipse.oomph.setup-feature ?
That's maybe bogus. Please open a bugzilla and we'll review.
>
> In the perform(SetupTaskContext) method of GitCloneTaskImpl, I found
> this:
>
> // Force start egit to make the clone appears in the repositories view
> and so projects are connected by the egit team provider.
> CommonPlugin.loadClass("org.eclipse.egit.ui",
> "org.eclipse.egit.ui.Activator");
>
> But, in my case, that is to say a headless context, I don't want
> org.eclipse.egit.ui.
> Do you plan to remove org.eclipse.oomph.setup.ui from the
> org.eclipse.oomph-feature ?
I'm not sure the two things are related. Certainly we should change the
GitCloneTaskImpl so it guards the loadClass call. We only call that
because the EGit UI plugin needs to be enabled for projects to actually
be imported into the workspace and for clones to be added to the clones
view. That plugins where the auto import support comes from. Perhaps
that is a bogus aspect of EGit because, i.e., why shouldn't you be able
to auto import projects headlessly?
Or maybe we shouldn't be relying on auto import in the targlet task...
> Or do you know a workaround ?
Will you rely on projects actually ending up in the workspace?
>
> Best regards,
>]]>Ed Merks2014-07-05T06:51:48-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1395664/#msg_1395664
I try to import a simple eclipse project stored in a git repository into an eclipse luna. I import the project with Import > General > Existing Projects into Workspace (not from the Git Repositories view nor Import > Git > Projects from Git), so I didn't use EGit. As a result, the imported project is shown as connected the the repository in the Package Explorer, and the Git Repositories view of the Git Perspective displays the repository.
So I believe GitCloneTaskImpl doesn't need to load egit.ui. Just import projects, and the repositories associated to these projects will be display in the Git repostories view.
Best regards,]]>Axel RICHARD2014-07-07T08:07:35-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1413835/#msg_1413835
Some news of our need with EMF Compare. We succeed in using Oomph as a headless application, and I would thank you for this great tool you've made.
As a reminder we want to provide a headless application in order to do specific git operations (diff, merge) on models with (j)git. For that reason, we use Oomph to provision an eclipse environment.
When a user wants to compare or merge EMF models from a command line, he needs to do that in an Eclipse environment similar to the one he used to create these models. As such, the environment requires some plugins to be installed but it may also requires some preferences to be set, some perspective to be activated etc... Among these plugins, there are the mandatory ones that will be use to do the git operation.
First, Oomph provision an Eclipse with all appropriate plugins to launch the git operation. These plugins are EGit, EMF Compare and their dependencies. If the user setup model provided as parameter of the git command contains other plugins, they will be provisioned too.
For a given Oomph setup model file, the provisioning operation is executed only once. Indeed, if you launch again a git logical operation with the same Oomph setup model file, then the already provisioned Eclipse IDE corresponding to the setup model will be reused. It avoids to execute this potentially costly task each time.
Then, in this provisioned Eclipse, the list of tasks contained in the user setup model are executed.
Once all Oomph tasks executed, EMF Compare calls the logical git operation with the others parameters provided in the command line interface. Once the git logical operation has been executed, the user can see the results in his command line tool.
Here is a review of our code that use Oomph as a headless application: https://git.eclipse.org/r/#/c/30733/
If you're interested, feel free to give us your opinion about the use of Oomph in this review.
Best regards,]]>Axel RICHARD2014-08-29T14:44:42-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1417424/#msg_1417424
I've looked at that review briefly and noticed that it includes many many files. I'm sorry but it seems beyond what I
can achieve in a short time frame. If you have specific questions please don't hesitate to ask ;-)
Am 29.08.2014 um 16:44 schrieb Axel RICHARD:
> Ed, Eike,
>
> Some news of our need with EMF Compare. We succeed in using Oomph as a headless application, and I would thank you for
> this great tool you've made.
> As a reminder we want to provide a headless application in order to do specific git operations (diff, merge) on models
> with (j)git. For that reason, we use Oomph to provision an eclipse environment.
> When a user wants to compare or merge EMF models from a command line, he needs to do that in an Eclipse environment
> similar to the one he used to create these models. As such, the environment requires some plugins to be installed but
> it may also requires some preferences to be set, some perspective to be activated etc... Among these plugins, there
> are the mandatory ones that will be use to do the git operation.
> First, Oomph provision an Eclipse with all appropriate plugins to launch the git operation. These plugins are EGit,
> EMF Compare and their dependencies. If the user setup model provided as parameter of the git command contains other
> plugins, they will be provisioned too.
> For a given Oomph setup model file, the provisioning operation is executed only once. Indeed, if you launch again a
> git logical operation with the same Oomph setup model file, then the already provisioned Eclipse IDE corresponding to
> the setup model will be reused. It avoids to execute this potentially costly task each time.
> Then, in this provisioned Eclipse, the list of tasks contained in the user setup model are executed.
> Once all Oomph tasks executed, EMF Compare calls the logical git operation with the others parameters provided in the
> command line interface. Once the git logical operation has been executed, the user can see the results in his command
> line tool.
> Here is a review of our code that use Oomph as a headless application: https://git.eclipse.org/r/#/c/30733/
> If you're interested, feel free to give us your opinion about the use of Oomph in this review.
>
> Best regards,]]>Eike Stepper2014-09-05T11:53:43-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1506431/#msg_1506431
I'd like to have an headless application to start oomph against 1..n setupfiles you can configure as parameter and which setups up a new eclipse installation or updates an already existing one which can also be parameterized by a second parameter
I have searched if oomph can already be executed as headless application and found this thread. Can you please give me a hint, if you have anything concrete to use or if an bugzilla entry or something else already exists, because I could imagine to contribute such a feature.
If not already implemented, what would you expect from such an headless application?
Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.21.0:validate-version (default-validate-version) on project org.eclipse.oomph.gitbash: OSGi version 1.0.0.SNAPSHOT must have .qualifier qualifier for SNAPSHOT builds -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
Can you give me a hint what's wrong here?
Thanks in advance
Cheers
Markus]]>Markus Oley2014-12-10T21:22:20-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1506874/#msg_1506874
You'd really need to look at what the EMF compare folks have done
because we've done nothing along this line in Oomph. We've just ensured
minimal/optional dependencies allow the infrastracture to be used
headless, not designed any specific headless applications. It seems to
me one could write many different headless applications depending what
you'd like to be parameterized and what you'd like the application to do
with those parameters. One application I can imagine is something that
parameterizes all the interactions that are available in the installer
dialog...
On 10/12/2014 10:22 PM, Markus Oley wrote:
> Hi Eike and Ed,
> I'd like to have an headless application to start oomph against 1..n
> setupfiles you can configure as parameter and which setups up a new
> eclipse installation or updates an already existing one which can also
> be parameterized by a second parameter
>
> I have searched if oomph can already be executed as headless
> application and found this thread. Can you please give me a hint, if
> you have anything concrete to use or if an bugzilla entry or something
> else already exists, because I could imagine to contribute such a
> feature.
> If not already implemented, what would you expect from such an
> headless application?
> Thanks in advance
>
> Cheers
> Markus]]>Ed Merks2014-12-11T06:07:22-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1508177/#msg_1508177
thank you for you answer,
I had a look at the contribution and as I can see from my point of view the emf compare folk have implemented a headless application which has some git actions and needs oomph to setup the workspace properly. This is not exactly the thing I need, but it's a very good example, where I can see how I can implement a real headless application. Thank you.
So I want to try to implement an headless application where I can parameterize a folder where to setup the configurations and parameterize a bunch of files to get the info what I want to setup. I think this is a very general way and you do not have to add additional functionality to parameter handling if oomph actions are extended theirselfes.
I could imagine to contribute this, so can you give me a hint, if I should implement in oomph git and contribute it as pull request? Or should I go another way? I'm new in the whole process of contributing.
On 12/12/2014 8:13 AM, Markus Oley wrote:
> Hi Ed,
> thank you for you answer, I had a look at the contribution and as I
> can see from my point of view the emf compare folk have implemented a
> headless application which has some git actions and needs oomph to
> setup the workspace properly. This is not exactly the thing I need,
> but it's a very good example, where I can see how I can implement a
> real headless application. Thank you.
> So I want to try to implement an headless application where I can
> parameterize a folder where to setup the configurations and
> parameterize a bunch of files to get the info what I want to setup. I
> think this is a very general way and you do not have to add additional
> functionality to parameter handling if oomph actions are extended
> theirselfes.
I think I see what you mean. Sort of a
descriptor/template/configuration-file for what needs to be done, rather
than 50 different command line parameters.
> I could imagine to contribute this, so can you give me a hint, if I
> should implement in oomph git and contribute it as pull request?
If you provision an IDE with the Oomph.setup itself, and you choose
Gerrit for the repository URI, you will be able to commit to Gerrit
where we can do an interactive reviews; of course you'll need a Gerrit
account, but that's trivial.
> Or should I go another way? I'm new in the whole process of contributing.
That's one of the goals of Oomph: to make it easy to contribute to
projects. I.e., instead of forcing contributors to spend hours or a
full day setting up an environment, this aspect is automated so
contributors can focus on contribution, not administration.
> Thanks in advance
>
> Cheers
> Markus]]>Ed Merks2014-12-12T07:47:37-00:00Re: Oomph headless
https://www.eclipse.org/forums/index.php/mv/msg/782061/1508543/#msg_1508543
I think I see what you mean. Sort of a
descriptor/template/configuration-file for what needs to be done, rather
than 50 different command line parameters.
-> Yes, that's the point.
That's one of the goals of Oomph: to make it easy to contribute to
projects. I.e., instead of forcing contributors to spend hours or a
full day setting up an environment, this aspect is automated so
contributors can focus on contribution, not administration.
-> OK, thank you, I will give it a try and 'll be back if I have something to see.
Have a nice weekend,
Cheers
Markus]]>Markus Oley2014-12-12T13:58:05-00:00