Community
Participate
Working Groups
When PDE Launch is used with a existing config.ini the osgi.bundles attributes and containing startlevel and autostart are ignored. e.g. config.ini containing following entries is completely ignored osgi.bundles=\ org.eclipse.equinox.simpleconfigurator@1\:start,\ org.eclipse.equinox.transforms.xslt@1\:start,\ org.eclipse.equinox.weaving.aspectj@1\:start,\ org.apache.felix.scr@2\:start,\ org.eclipse.equinox.event@3\:start,\ org.eclipse.equinox.cm@3\:start If this sequence is not considered by the pde launch o.e.equinox.transform and o.e.equinox.weaving are not started and cannot work properly. My assumption is that this behaveour exists since the removal/exchange of the o.e.update.configurator with o.e.equinox.simpleconfigurator.
New Gerrit change created: https://git.eclipse.org/r/143023
(In reply to Peter Kirschner from comment #0) > My assumption is that this behaveour exists since the removal/exchange of > the o.e.update.configurator with o.e.equinox.simpleconfigurator. So this is not a regression in 4.12?
If not a regression, we can take this up in 4.13
@Peter: please attach a small sample project to reproduce the issue.
@Vikas This is definitely a regression. Our project is not capable of updating to an Eclipse post Oxygen release. We have been using config.ini PDE launches since 8 years. It was always a smooth update. Post Oxygen the startup is not working anymore. @Julian I can provide a sample project, but this requires additional IDE tooling setup. AJDT must be addionally installed to compile the Aspects and execute them from IDE launches. Currently as a PDE user there is no way to launch bundles before the SCM is started. The transforms bundle is manipulating the plugin.xml. That must happen before any of those bundle is analyzed. So this is only guaranteed it we start it as the first bundle after the fw bundle. It behaves similar for the AspectJ bundle, which we use with runtime weaving option. So this also requires an start-up as early as possible, to get things setup and running before any of the bundles to be woven is started. I see currently no way to get the bundle startup sequence from my initial description running. Any hint how to do this without config.ini is appreciated.
(In reply to Peter Kirschner from comment #5) > I see currently no way to get the bundle startup sequence from my initial > description running. Any hint how to do this without config.ini is > appreciated. Configuring those exact start levels in the plugins tab doesn't work?
Sorry I missed out to explain that we are using feature based product launches. So there is no actual plugin tab allowing to fine tune the plugins autostart and start level.
>>This is definitely a regression. We are done with 4.12. We can put this fix in 4.13 after review. Meanwhile you can patch up this fix locally.
New Gerrit change created: https://git.eclipse.org/r/143349
Looking at the code, I can't see any regression (at least not since oxygen). LaunchConfigurationHelper::createConfigIniFile loads the osgi.bundles from the config template without touching any start levels. Only if no osgi.bundles property exists, a default is computed. Peter, please create a simple test product to reproduce it (e.g. a bundle with a logging activator, that's auto-started). Overwriting/ignoring start levels set in the plugin tab is not an option IMO, as it likely breaks existing plugin-based launch configs. I'll try to solve Bug 331595 in 4.13, I suggest you use a plugin-based launch config in the meantime.
Testcases created for default and existing/custom config.ini file. Please review proposed fix in Gerrit.
moving to M3
Why is this bug now moved to target release 4.14 M1? Bugfix patch is provided in Gerrit and review findings are all incorporated. This is definitely a regression and there is no workaround or alternative.
(In reply to Peter Kirschner from comment #13) > Why is this bug now moved to target release 4.14 M1? > Bugfix patch is provided in Gerrit and review findings are all incorporated. > This is definitely a regression and there is no workaround or alternative. Moved to Rc1
(In reply to Vikas Chandra from comment #14) > Moved to Rc1 Moving again. This is too critical for this release.
(In reply to Peter Kirschner from comment #13) > Why is this bug now moved to target release 4.14 M1? > Bugfix patch is provided in Gerrit and review findings are all incorporated. > This is definitely a regression and there is no workaround or alternative. because 1) it's a change in a critical component and we're in RC phase 2) review findings are *not* resolved 3) you still did not provide any sample project to show it's actually a regression 4) we did provide a proper solution for this issue in this release [1] [1] https://www.eclipse.org/eclipse/news/4.13/pde.php#feature-launch-startlevels
1) it's a change in a critical component and we're in RC phase - I agree on this and there is also bug introduced with the "new" fix - start levels for pre-configured bundles e.g. o.a.felix.scr cannot be changed, although the new UI suggested it. So the proposed increase of default start level and configuration is not feasible cause this "system" bundles are always on their pre-configured sl :-( 2) review findings are *not* resolved - I did create now two sample bundles and launch configurations for "all" of the launch config types known to me, to show the required usage scenario 3) you still did not provide any sample project to show it's actually a regression Sample projects are included now and configured inside launches 4) we did provide a proper solution for this issue in this release [1] The provided solutions is not supporting our scenario - we are changing the default levels and introduce two additional bundles BEFORE any Eclipse bundles. Here is a summary from my point of view based on the usage of this IDE Eclipse IDE for Eclipse Committers Version: 2019-09 M2 (4.13.0M2) Build id: 20190808-0907 and the code of master branch from 23 August. # Current status Created launch configurations/testcases for the 3 different feature/plug-ins selection types * ALL - "all workspace and enabled target plug-ins" * FEATURES - "features selected below" * PLUGINS - "plug-ins selected below only" All Launch configurations are freshly created inside the new IDE and configured to use a clear ws and config area. If feasible the 2 workspace plugins (o.e.p.t.first and o.e.p.t.second) are added. For each type testcase for the sl configurations are provided * generated default config.ini * modified generated default config.ini (modified if feasible via current sl UI) * provide/existing config.ini file Generated config.ini allows to configure sl for pre-configured bundles like * org.eclipse.equinonx.simpleconfigurator * org.apache.felix.scr BUT this is not considered see commented asserts statements in line 229-233 inside LaunchConfigIniBehaviourTests - commented and suceeding asserts provided THIS STILL REQUIRES A FIX from my point of view. # results of implementation from master on the NEW/ADDITIONAL testcases Selection Type "ALL" does not allow to provide sl configuration, hence "generated" and "modified generated" are eclipse defaults and marked as not applicable (n/a) + means test successful - means test failed Type/Cfg ALL FEATURE PLUGIN generated n/a + + mod. gen. n/a + + existing - - - # results after applying the provided patch generated n/a + + mod. gen. n/a + + existing + + +
(In reply to Peter Kirschner from comment #17) > 1) it's a change in a critical component and we're in RC phase > - I agree on this and there is also bug introduced with the "new" fix - > start levels for pre-configured bundles e.g. o.a.felix.scr cannot be > changed, although the new UI suggested it. So the proposed increase of > default start level and configuration is not feasible cause this "system" > bundles are always on their pre-configured sl :-( I can't reproduce that, the system start levels are only applied as a fallback. Please open a separate bug with a repro sample for this.
I created this bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=550433
(In reply to Peter Kirschner from comment #17) > The provided solutions is not supporting our scenario - we are changing the > default levels and introduce two additional bundles BEFORE any Eclipse > bundles. I assume you got that to work with explicit start levels configured for the system bundles. Is there still functionality missing in PDE to configure a launch config for your usecase?
We have multiple config.ini for different product variants. Currently they have one single point to maintain - the "config.ini" file. With the current UI based solution we would have to maintain an an additional PDE-Launch configuration for each of those product configuration and keep the launch.xml in sync with config.ini used later in product. This is a significant overhead just for the sake of using PDE. and there is still the option to use a config.ini file, which are doing since more than 10 years. Do you really want to break that backwards compatibility? The configuration option is there. You broke the contract. I spent a significant effort of providing a bugfix and corresponding test-cases for each scenario. Are there still review findings open? What or where is the problem in accepting the fix, which will allow us and everybody else to continue using their config.ini files?
(In reply to Peter Kirschner from comment #21) > and there is still the option to use a config.ini file, which are doing > since more than 10 years. Do you really want to break that backwards > compatibility? I'm done arguing this point. Since you still did not provide an executable repro (which some test files are not), I build one myself and run it on Neon. As expected, the start levels from the existing config.ini are ignored in favor of the ones from the GUI. Ergo not a regression! If you wan't to argue otherwise, provide a project that can be executed in different releases. > The configuration option is there. You broke the contract. The contract is clearly labeled: "Use an existing config.ini file as a template". It say's "template", not "use that file and ignore everything else". Your patch breaks that contract. > I spent a significant effort of providing a bugfix and corresponding > test-cases for each scenario. Are there still review findings open? > > What or where is the problem in accepting the fix, which will allow us and > everybody else to continue using their config.ini files? Your patch breaks the configuration options in the dialog (by design), which I've noted in my very first review comment as not viable. I could have been clearer on that point - my bad.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Created attachment 288347 [details] gerrit as patch
