Community
Participate
Working Groups
The installer should support headless unattended mode. The headless installer should accept parameters for: 1) Bundle Pool Location 2) Installation location 3) Product to install 4) Product version 5) Streams that should be added. 6) Option to bootstrap the application if already installed. For variables the default or by the setup files configured values should be used. All licences should be automatically accepted.
New Gerrit change created: https://git.eclipse.org/r/66353
Moving all unresolved bugzillas to 1.4.0...
I assume the devs are pretty busy with EclipseCon and that this might have to wait after the event, considering that there's a substantial amount of code in the patch.
Yes, it's a large patch, and at a glance, I'm not sure it's taking the best design approach. I'm sure long term that many more features will be desired, i.e., anything I can change manually in the UI someone somewhere will want to do in a headless way, e.g., setting any and all the variables. A different approach might be to design a model that describes such automated steps. For example, some people have asked for a mechanism whereby they can drag and drop a "setup description" and that will make the selections of product version and streams for the user automatically. Will someone be attending the conference with whom we can discuss short term goals and a long term strategy? I'm concerned that we need to invest a significant amount of time reviewing, a significant amount of time considering the long term implications, and a significant amount of time in the long term maintaining, supporting, documenting, and enhancing the contribution.
> Will someone be attending the conference with whom we can discuss short term > goals and a long term strategy? Yes I'm sorry for not replying earlier but I think you met with M-A Laperle at post-conference. > I'm concerned that we need to invest a significant amount of time reviewing, > a significant amount of time considering the long term implications, and a > significant amount of time in the long term maintaining, supporting, > documenting, and enhancing the contribution. Yes I agree it's a big patch, and that even myself doesn't quite perfectly understand the use case at the moment (Mikael could further explain on this) but from what I understand, it was really needed in their team and it seems that one of the Ericsson team is really using the headless mode right now (probably inside scripts that also setup other non-eclipse environment stuff).
The scope is larger than our team, we will have a bit less than 1000 developers using the CLI installer. The usecase for us is to deploy Eclipse with an exact set of features/plugins and with certain prefererences set to all our developers. We depend on a lot of environment variables and special setup scripts so the user have to launch the installer from command line after running a script that setups the environment properly. Surely we could launch the standard oomph installer pointing at the correct setup files but we want to provide our users with a fully managed installation that doesnt require user interaction.
Moving all unresolved bugs to version 1.5.0.
Status update? We could really use this funtionality.
(In reply to Tim Orling from comment #8) > Status update? We could really use this funtionality. Sorry, but my comments in https://bugs.eclipse.org/bugs/show_bug.cgi?id=487626#c4 are still the status.
Ed, this model that you describe in #4, is this the now implemented Configurations model, or do I mix something up here?
Yes, the configuration model helps to automate pretty much everything that needs to be specified to run the engine headlessly. There are already system properties for settings things like the pool location (or not to use one at all), and the preferred JRE to use, so at this point I imagine a headless application would only need to specify a configuration and could take advantage of the existing system properties so that everything that's done manually in the UI can be done automatically from that basis.
Hi, is there still any chance to get this?
(In reply to Moritz Aleithe from comment #12) > Hi, is there still any chance to get this? I'm not sure when I find time to implement this. Maybe when I'm back in March and there are no other pressing things that need my attention. Of course with funding it would have been done long ago...
Only thing i could fund you is my time ;) maybe i try to hack it in myself
I am just starting to read the Oomph code, but is or is it not all the needed configuration stored in the .setup file? I guess not, because then it should be relatively easy to just start oomph headlessly at the point after the wizard is finished and read a given .setup file instead. What is missing?
(In reply to Vlad Dumitrescu from comment #15) > I am just starting to read the Oomph code, but is or is it not all the > needed configuration stored in the .setup file? I guess not, because then it > should be relatively easy to just start oomph headlessly at the point after > the wizard is finished and read a given .setup file instead. What is missing? Pretty much what Mikael wrote. The setup file offers things that can be installed, the parameters would have to decide what to install
I don't think there's much missing. A Configuration could be used to specify which product version and which if any streams to include, and it can include variable tasks to define any variable values that would normally be prompted on the Variables page. So a complete Configuration could be synthesized to provide any necessary parameters.
Thanks, I will look at it. BTW, is it possible to just do the product setup? I am in an environment with a central shared installation.
Yes, a Configuration contains an Installation and a Workspace, but the Workspace is optional so you can use just an Installation with a Product Version reference along with any variables needed to specify exact where to install it.
Created a different version of the installer with this patch applied, see more https://github.com/a-langer/eclipse-oomph-console
New Gerrit change created: https://git.eclipse.org/r/c/oomph/org.eclipse.oomph/+/66353
