Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] oomph "bug" in EPP

Eike,

FWIW, I really do like all the automated preference configuration while smoketesting builds what seems like 1000's of times.  I'm sure we'll work out the proper default behavior in SR1.
A few weeks ago I started noticing all my bootstrap tasks were magically done for me, before realizing it was the Oomph recorder.  


Thanks - Chuck

Senior Architect,
WebSphere Developer Tools, Eclipse WTP PMC Lead
IBM Software Lab - Research Triangle Park, NC




From:        Eike Stepper <stepper@xxxxxxxxxx>
To:        Eclipse Packaging Project <epp-dev@xxxxxxxxxxx>
Date:        06/19/2015 12:54 PM
Subject:        Re: [epp-dev] oomph "bug" in EPP
Sent by:        epp-dev-bounces@xxxxxxxxxxx




Am 19.06.2015 um 17:52 schrieb Markus Knauer:
> Thanks, Max, for bringing this forward as requested!
>
> I'd like to get more feedback from the other package maintainers whether you see this as a problem in your package,
> and I hope to get feedback from the Oomph team.
I'm not sure what kind of feedback is expected from us. I know it doesn't make a difference for you but this is not a
bug in Oomph; it works as designed.

Oomph provides a very powerful and flexible task execution engine, which is able to install IDEs (during the "bootstrap"
trigger) and update them later (during the "startup" trigger). The automatic task execution at startup time is
configurable per workspace via the Oomph | Setup preferences.

In addition to (i.e. on top of) this engine Oomph provides a preference recorder that automatically creates
PreferenceTasks for the preferences that are changed in the preference dialog. Once these PreferenceTasks are recorded,
they get executed by the underlying setup engine at startup time (unless that is turned off as explained above). Turning
off the recorder is not expected to disable already recorded preference tasks (or any other tasks).

That said, we agree that these XML blob-like preferences can become problematic because our PreferenceTasks can not
change (merge) their contents selectively. We plan to come up with an enhanced infrastructure around the preference
recorder that accounts for this challenge (and some other challenges such as the introduction of a machine scope in
addition to the user scope). But of course that is all post-Mars music.

>
> Technically this means we would need to add another entry to the plugin_customizations.ini  of each package that
> changes the default setting of the Oomph preference recorder from 'on' to 'off'. The content of the packages would be
> the same, the same parts of Oomph would be included and could be enabled at any time, but only through a manual change
> by the user. This change already found its way to the Java EE package this week. Based on this change we would have to
> rebuild the packages and go through another cycle with tests and votings.
Yes, that's what I thought would happen when this issue was brought up first. But apparently I was wrong ;-)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev




Back to the top