Home » Forums » Ant4Eclipse User Forum » PDE

Problem with the generation of the config.ini File

April 20, 2010 by gesobak
Posted in

Hi,
I looked at the generation of the config.ini in the M3 release. I still see there problems and think the report 175 was closed to early.

Problems/Questions:
- The generated config.ini is one line with no CR/LF at all. Probably "
" are missing at each echo line.
- There is a bug in the "osgi.bundles" line:
"org.eclipse.osgi@start" needs to be replaced with "org.eclipse.osgi@-1:start"
Then the product starts fine.
- Not all plugins needed to actually start my product are listed at the "osgi.bundles" line.
Is this intended. Eclipse adds all necessary plugins.

Thanks for your work and best regards,
Georg.

‹ Thanks! - And: mkdir output directory Missing Feature ›

Hi Georg, I've changed the

Submitted by costamojan on Wed, 04/28/2010 - 22:11.

Hi Georg,

I've changed the logic as followed:

1. Collect the bundles declared in 'osgi.bundles' for any given target platform.

2. If the entry 'osgi.bundles' refers to the simple configurator collect the bundles declared in 'bundles.info'. At the moment the path to the 'bundles.info' is hardcoded since it would require to provide url resolvers otherwise and there's probably no need for any other pathes anyway.

3. When no bundle could be loaded the default ones will be used (they're just some sort of guess). I'm thinking of removing them as that might be confusing for some people if part of a platform won't be loaded because of these hardcoded bundles.

4. The bundles of the product configuration file will be added.

Since it's currently a bit late and because of the lack of a test case I haven't tested it (at least not the task but of course some internal code that has been implemented).
So if you're giving it a try let me know what came out.

Best regards

Daniel Kasmeroglu

Here's a link where you can

Submitted by costamojan on Mon, 04/26/2010 - 17:58.

Here's a link where you can find some information regarding the config.ini :

http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.pde.doc.user...

Anyway: Feel free to enlighten me.

Best regards

Daniel Kasmeroglu

Hi, - The generated

Submitted by costamojan on Tue, 04/20/2010 - 21:41.

Hi,

- The generated config.ini is one line with no CR/LF at all. Probably "
" are missing at each echo line.

You were right. I fixed that.

- There is a bug in the "osgi.bundles" line: "org.eclipse.osgi@start" needs to be replaced with "org.eclipse.osgi@-1:start"
Then the product starts fine.

The value -1 has no meaning according to the definition.

- Not all plugins needed to actually start my product are listed at the "osgi.bundles" line.
Is this intended. Eclipse adds all necessary plugins.

The bundles that are being declared for the start are not managed within the product configuration file. They're derived from the target platform locations. I've currently enhanced the task, so it calculates the bundle list from these locations (still using the previously hardcoded bundles as a fallback solution).

As we don't have a complex product build for the test I can't verify whether this is working or not (the build itself has been implemented for a product which did provide it's own config.ini so this functionality wasn't really needed before). So I suggest that you could help us a little while using the latest build which could be taken from here:

http://hudson.nilshartmann.net/job/ant4eclipse/

Obviously I will enhance our test suite to run product based tests using a more complete product (I've also got a candidate for this) but that depends on how often we've got spare time for this.

I'm hoping for an answer of your build.

Best regards

Daniel Kasmeroglu

Even if the -1 has no

Submitted by gesobak on Thu, 04/22/2010 - 12:49.

Even if the -1 has no meaning, my example works with this setting (strange). Any other value or omitting the start value will fail to start my app with an exception:

!SESSION 2010-04-22 13:22:02.159 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.6.0_18
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Command-line arguments:  -os win32 -ws win32 -arch x86
 
!ENTRY org.eclipse.osgi 4 0 2010-04-22 13:22:02.549
!MESSAGE Startup error
!STACK 1
java.lang.IllegalArgumentException: The System Bundle's start level can not be modified.
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.setBundleStartLevel(StartLevelManager.java:371)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.installBundles(EclipseStarter.java:1060)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.loadBasicBundles(EclipseStarter.java:631)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:301)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:175)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1311)

Omitting "org.eclipse.osgi@start" from the config.ini works as well.
Any clue?
I figured out the -1 from the bundles.info info file eclipse generates during product export:
...
org.eclipse.osgi,3.5.2.R35x_v20100126,plugins/org.eclipse.osgi_3.5.2.R35x_v20100126.jar,-1,true
...

The app I have right now is not complex at all either (This might change.). I'll do my best to help. I installed the latest build (1801) and gave it a try with my feature based RCP example. Unfortunately the start failed with an exception:

!SESSION 2010-04-22 13:35:58.711 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.6.0_18
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Command-line arguments:  -os win32 -ws win32 -arch x86
 
!ENTRY org.eclipse.osgi 4 0 2010-04-22 13:35:59.133
!MESSAGE Application error
!STACK 1
java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:74)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1311)

Content of config.ini:

# Product Runtime Configuration File
eclipse.application=de.soffel.hellorcp.application
osgi.bundles.defaultStartLevel=4
eclipse.product=de.soffel.hellorcp.hellorcp
osgi.splashPath=platform:/base/plugins/org.eclipse.platform
osgi.bundles=reference:file:org.eclipse.equinox.simpleconfigurator_1.0.101.R35x_v20090807-1100.jar@1:start

Eclipse product export delivers instead:

#Product Runtime Configuration File
eclipse.application=de.soffel.hellorcp.application
osgi.bundles.defaultStartLevel=4
eclipse.product=de.soffel.hellorcp.hellorcp
osgi.splashPath=platform:/base/plugins/de.soffel.hellorcp
osgi.bundles=org.eclipse.equinox.simpleconfigurator@1:start
org.eclipse.equinox.simpleconfigurator.configUrl=file:org.eclipse.equinox.simpleconfigurator/bundles.info

See the differences at "osgi.splashPath", "osgi.bundles" and "org.eclipse.equinox.simpleconfigurator.configUrl"

In addition eclipse generates the bundles.info file:

#version=1
com.ibm.icu,4.0.1.v20090822,plugins/com.ibm.icu_4.0.1.v20090822.jar,4,false
de.soffel.hellorcp,1.0.0,plugins/de.soffel.hellorcp_1.0.0.jar,4,false
org.eclipse.core.commands,3.5.0.I20090525-2000,plugins/org.eclipse.core.commands_3.5.0.I20090525-2000.jar,4,false
org.eclipse.core.contenttype,3.4.1.R35x_v20090826-0451,plugins/org.eclipse.core.contenttype_3.4.1.R35x_v20090826-0451.jar,4,false
org.eclipse.core.databinding,1.2.0.M20090819-0800,plugins/org.eclipse.core.databinding_1.2.0.M20090819-0800.jar,4,false
org.eclipse.core.databinding.beans,1.2.0.I20090525-2000,plugins/org.eclipse.core.databinding.beans_1.2.0.I20090525-2000.jar,4,false
org.eclipse.core.databinding.observable,1.2.0.M20090902-0800,plugins/org.eclipse.core.databinding.observable_1.2.0.M20090902-0800.jar,4,false
org.eclipse.core.databinding.property,1.2.0.M20090819-0800,plugins/org.eclipse.core.databinding.property_1.2.0.M20090819-0800.jar,4,false
org.eclipse.core.expressions,3.4.101.R35x_v20100209,plugins/org.eclipse.core.expressions_3.4.101.R35x_v20100209.jar,4,false
org.eclipse.core.jobs,3.4.100.v20090429-1800,plugins/org.eclipse.core.jobs_3.4.100.v20090429-1800.jar,4,false
org.eclipse.core.runtime,3.5.0.v20090525,plugins/org.eclipse.core.runtime_3.5.0.v20090525.jar,4,true
org.eclipse.core.runtime.compatibility.auth,3.2.100.v20090413,plugins/org.eclipse.core.runtime.compatibility.auth_3.2.100.v20090413.jar,4,false
org.eclipse.equinox.app,1.2.1.R35x_v20091203,plugins/org.eclipse.equinox.app_1.2.1.R35x_v20091203.jar,4,false
org.eclipse.equinox.common,3.5.1.R35x_v20090807-1100,plugins/org.eclipse.equinox.common_3.5.1.R35x_v20090807-1100.jar,2,true
org.eclipse.equinox.ds,1.1.1.R35x_v20090806,plugins/org.eclipse.equinox.ds_1.1.1.R35x_v20090806.jar,1,true
org.eclipse.equinox.launcher,1.0.201.R35x_v20090715,plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar,4,false
org.eclipse.equinox.launcher.win32.win32.x86,1.0.200.v20090519,plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519,4,false
org.eclipse.equinox.preferences,3.2.301.R35x_v20091117,plugins/org.eclipse.equinox.preferences_3.2.301.R35x_v20091117.jar,4,false
org.eclipse.equinox.registry,3.4.100.v20090520-1800,plugins/org.eclipse.equinox.registry_3.4.100.v20090520-1800.jar,4,false
org.eclipse.equinox.simpleconfigurator,1.0.101.R35x_v20090807-1100,plugins/org.eclipse.equinox.simpleconfigurator_1.0.101.R35x_v20090807-1100.jar,1,true
org.eclipse.equinox.util,1.0.100.v20090520-1800,plugins/org.eclipse.equinox.util_1.0.100.v20090520-1800.jar,4,false
org.eclipse.help,3.4.1.v20090805_35x,plugins/org.eclipse.help_3.4.1.v20090805_35x.jar,4,false
org.eclipse.jface,3.5.2.M20100120-0800,plugins/org.eclipse.jface_3.5.2.M20100120-0800.jar,4,false
org.eclipse.jface.databinding,1.3.1.M20090826-0800,plugins/org.eclipse.jface.databinding_1.3.1.M20090826-0800.jar,4,false
org.eclipse.osgi,3.5.2.R35x_v20100126,plugins/org.eclipse.osgi_3.5.2.R35x_v20100126.jar,-1,true
org.eclipse.osgi.services,3.2.0.v20090520-1800,plugins/org.eclipse.osgi.services_3.2.0.v20090520-1800.jar,4,false
org.eclipse.rcp,3.5.0.v201002111343,plugins/org.eclipse.rcp_3.5.0.v201002111343.jar,4,false
org.eclipse.swt,3.5.2.v3557f,plugins/org.eclipse.swt_3.5.2.v3557f.jar,4,false
org.eclipse.swt.win32.win32.x86,3.5.2.v3557f,plugins/org.eclipse.swt.win32.win32.x86_3.5.2.v3557f.jar,4,false
org.eclipse.ui,3.5.2.M20100120-0800,plugins/org.eclipse.ui_3.5.2.M20100120-0800.jar,4,false
org.eclipse.ui.workbench,3.5.2.M20100113-0800,plugins/org.eclipse.ui.workbench_3.5.2.M20100113-0800.jar,4,false
org.eclipse.update.configurator,3.3.0.v20090312,plugins/org.eclipse.update.configurator_3.3.0.v20090312.jar,3,true

That is how far I got right now. Tell me if you want me to test something.

Best regards,
Georg.

Further remarks

Submitted by gesobak on Thu, 04/22/2010 - 15:35.

Further remarks ...

Concerning the -1: In eclipse this value comes directly from the launch configuration (see code below)!

What do you think about the following approach to get the config.ini content:
1. Let the developer export the launch configuration via the "Shared File" option in the "Run configurations" Dialog.
2. Let the developer specify this file as run configuration file in ant4eclipse for his project build. If the developer does not do this, go for your other approaches.
3. Fetch the content for "osgi.bundles" from the launch configuration file ("selected_target_plugins" and "selected_workspace_plugins"):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="org.eclipse.pde.ui.RuntimeWorkbench">
<booleanAttribute key="append.args" value="true"/>
<stringAttribute key="application" value="de.soffel.hellorcp.application"/>
<booleanAttribute key="askclear" value="true"/>
<booleanAttribute key="automaticAdd" value="false"/>
<booleanAttribute key="automaticValidate" value="false"/>
<stringAttribute key="bootstrap" value=""/>
<stringAttribute key="checked" value="[NONE]"/>
<booleanAttribute key="clearConfig" value="false"/>
<booleanAttribute key="clearws" value="false"/>
<booleanAttribute key="clearwslog" value="false"/>
<stringAttribute key="configLocation" value="${workspace_loc}/.metadata/.plugins/org.eclipse.pde.core/hellorcp.product"/>
<booleanAttribute key="default" value="false"/>
<booleanAttribute key="includeOptional" value="true"/>
<stringAttribute key="location" value="${workspace_loc}/../runtime-hellorcp.product"/>
<stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value="-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl}"/>
<stringAttribute key="org.eclipse.jdt.launching.SOURCE_PATH_PROVIDER" value="org.eclipse.pde.ui.workbenchClasspathProvider"/>
<stringAttribute key="pde.version" value="3.3"/>
<stringAttribute key="product" value="de.soffel.hellorcp.hellorcp"/>
<stringAttribute key="productFile" value="\de.soffel.hellorcp.build\hellorcp.product"/>
<stringAttribute key="selected_target_plugins" value="org.eclipse.equinox.util@default:default,org.eclipse.core.databinding.property@default:default,org.eclipse.core.contenttype@default:default,org.eclipse.update.configurator@3:true,org.eclipse.equinox.launcher.win32.win32.x86*1.0.200.v20090519@default:false,org.eclipse.osgi@-1:true,org.eclipse.help@default:default,org.eclipse.core.databinding.observable@default:default,org.eclipse.jface.databinding@default:default,org.eclipse.swt.win32.win32.x86*3.5.2.v3557f@default:false,org.eclipse.core.runtime@default:true,org.eclipse.core.databinding.beans@default:default,org.eclipse.core.runtime.compatibility.auth@default:default,org.eclipse.equinox.launcher.win32.win32.x86*1.0.200.v20090519@default:false,org.eclipse.core.runtime.compatibility.registry@default:false,org.eclipse.core.jobs@default:default,org.eclipse.jface@default:default,org.eclipse.ui.workbench@default:default,org.eclipse.equinox.app@default:default,org.eclipse.swt@default:default,org.eclipse.core.expressions@default:default,org.eclipse.equinox.common@2:true,org.eclipse.equinox.simpleconfigurator@1:true,org.eclipse.core.databinding@default:default,org.eclipse.ui@default:default,org.eclipse.equinox.launcher@default:default,org.eclipse.core.commands@default:default,org.eclipse.swt.win32.win32.x86*3.5.2.v3557f@default:false,org.eclipse.equinox.ds@1:true,com.ibm.icu@default:default,org.eclipse.osgi.services@default:default,org.eclipse.rcp@default:default,org.eclipse.equinox.preferences@default:default,org.eclipse.equinox.registry@default:default"/>
<stringAttribute key="selected_workspace_plugins" value="de.soffel.hellorcp@default:default"/>
<booleanAttribute key="show_selected_only" value="false"/>
<booleanAttribute key="tracing" value="false"/>
<booleanAttribute key="useDefaultConfig" value="true"/>
<booleanAttribute key="useDefaultConfigArea" value="true"/>
<booleanAttribute key="useProduct" value="true"/>
<booleanAttribute key="usefeatures" value="false"/>
</launchConfiguration>

Best regards,
Georg.

Basically you're idea would

Submitted by costamojan on Thu, 04/22/2010 - 17:26.

Basically you're idea would be possible. Nevertheless the launch configuration is derived from the product configuration. The question is how the calculation of the started bundles takes place.
Last but not least I need such a situation to reproduce this error first and recognize when it's finished.

Best regards

Daniel Kasmeroglu

Situation to reproduce ...

Submitted by gesobak on Thu, 04/22/2010 - 20:20.

If you mean a situation to reproduce the error I had, I think this is quite easy:
Just use a standard eclipse 3.5.5 as target plattform for a simple HelloWorld RCP app (feature based in my case). I think I can send you my simple example via mail, if you want to have it. Then I need your mail address.

The problem here is, that the standard eclipse now uses the simpleconfigurator in the "osgi.bundles" line of the config.ini file. In your code you parse this line to get a list of bundles, but they are not there. They are in the bundles.info file.

I reckon you know that, but I'm a bit confused about which error you are talking about.

Best regards,
Georg

I've sent your my email just

Submitted by costamojan on Thu, 04/22/2010 - 21:40.

I've sent your my email just in case my next solve won't fix it.

The problem here is, that the standard eclipse now uses the simpleconfigurator in the "osgi.bundles" line of the config.ini file. In your code you parse this line to get a list of bundles, but they are not there. They are in the bundles.info file.

I think we're getting closer to the bottom of the problem. The "spec" I've found about the config.ini just mentioned the behaviour of the starting bundle list. But when I'm understanding you correctly the initially started bundle "simpleconfigurator" provides some kind of shortcut functionality to load the bundles from the 'bundles.info' file. Solving this wouldn't be very complicated. Though it would be nice if you've got some doc about it. Nevertheless I'll let you know when I got another version for you to try.

Best regards

Daniel Kasmeroglu

More remarks ...

Submitted by gesobak on Fri, 04/23/2010 - 08:56.

You are right, the launch configuration is derived from the product configuration and concerning the product build, generating the config.ini from a launch configuration is wrong. I do not know, if the generation of a config.ini file from a launch configuration could be of any use.

Concerning the product build the right way to do it, is the way eclipse is doing it. Fetch the information from the product file. Get all dependent plugins/features and nested plugins/features. Doing that, respect the start level and the auto start configuration in the product file. This is in our real project a must have, because we use spring DM. There these values need to be configured, to get the thing running.

IMHO the approach you favor now, looking at the config.ini in the target platform is not optimal. You might miss some bundles from the workspace, but I'm not really sure about that (I did not check.). And the real drawback is (IMHO), if the target platform is a plain eclipse install, you pull in all eclipse bundles of this eclipse install, even if you do not need them.

These are just some thoughts concerning this topic with our requirements in mind.

Tell me your opinion. Best regards,
Georg

IMHO the approach you favor

Submitted by costamojan on Fri, 04/23/2010 - 12:06.

IMHO the approach you favor now, looking at the config.ini in the target platform is not optimal. You might miss some bundles from the workspace, but I'm not really sure about that (I did not check.). And the real drawback is (IMHO), if the target platform is a plain eclipse install, you pull in all eclipse bundles of this eclipse install, even if you do not need them.

I wouldn't just do a plain copy of all target platform plugins. Only plugins that are part of the build product would make it into the config.ini (or bundles.info).
Regarding the config.ini from the target platform: That's the way Eclipse is doing it (at least according to the explanation I could find).

Best regards

Daniel Kasmeroglu

Regarding the config.ini from

Submitted by gesobak on Mon, 04/26/2010 - 14:39.

Regarding the config.ini from the target platform: That's the way Eclipse is doing it (at least according to the explanation I could find).

Could you please give me some link to these explanations.


I'm not an expert, but I think still the product file should be the driving information. Implementing your approach, will you respect the start level and the auto start configuration from the product file? I know you respect i.e. the launcher name.

I think it is possible to have a target platform without a config.ini. What is your approach then?

Thanks and best regards,
Georg.

but I think still the product

Submitted by costamojan on Mon, 04/26/2010 - 16:09.

but I think still the product file should be the driving information.

I don't anything different. If you have a look into the product file you won't find any information regarding the start level. The whole config.ini stuff is derived from other informations (I will give you a link when I'm at home).

Implementing your approach, will you respect the start level and the auto start configuration from the product file?

Maybe you could give me your product file which seems to contain the start level information.

I think it is possible to have a target platform without a config.ini. What is your approach then?

As there will be no bundles the config.ini would be empty.

Let me get this straight: Ant4Eclipse is an open source project. So I don't intend to catch each possible constellation. I'm only focused on things that seems worth it (at least to me). If you feel that other scenarios shall be supported, too you're free to join us.

Best regards

Daniel Kasmeroglu

Here is a product file with

Submitted by gesobak on Tue, 04/27/2010 - 08:21.

Here is a product file with information about start level and auto start:

<?xml version="1.0" encoding="UTF-8"?>
<?pde version="3.5"?>
<product name="hello rcp" uid="de.soffel.hellorcp.product" id="de.soffel.hellorcp.hellorcp" application="de.soffel.hellorcp.application" version="1.0.0" useFeatures="true" includeLaunchers="true">
   <configIni use="default">
   </configIni>
   <launcherArgs>
      <vmArgsMac>-XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts</vmArgsMac>
   </launcherArgs>
   <windowImages/>
   <launcher name="hellorcp">
      <solaris/>
      <win useIco="false">
         <bmp/>
      </win>
   </launcher>
   <vm>
   </vm>
   <plugins>
   </plugins>
   <features>
      <feature id="de.soffel.hellorcp.feature" version="1.0.0"/>
   </features>
   <configurations>
      <plugin id="de.soffel.hellorcp" autoStart="true" startLevel="6" />
   </configurations>
</product>



I was thinking about eclipse equinox as target platform, when I asked about your approach, if there is no config.ini. I thought it could be of interest or might be of some relevance.


Let me get this straight: Ant4Eclipse is an open source project. So I don't intend to catch each possible constellation. I'm only focused on things that seems worth it (at least to me). If you feel that other scenarios shall be supported, too you're free to join us.

Yes, I know that and I'm really happy with whatever you are doing for ant4eclipse. I just wanted to understand the whole problem and sort things out concerning the config.ini file stuff. If you are settled with your way implementing it, that is fine, just tell me and I will stop posting on this topic. If you have something to test, I'm looking forward to do it and give you feedback.

Thanks and best regards,
Georg.

I just wanted to understand

Submitted by costamojan on Tue, 04/27/2010 - 09:06.

I just wanted to understand the whole problem and sort things out concerning the config.ini file stuff. If you are settled with your way implementing it, that is fine, just tell me and I will stop posting on this topic. If you have something to test, I'm looking forward to do it and give you feedback.

As you did. I will check this when I've got the time for it. Do you know whether the configuration element was already available in 3.4/3.3 ? To be honest: I'm seeing this element the first time.
You don't need to stop posting. The automated generation of the config.ini is truly a feature worth the effort. But until now I just wasn't aware of these configuration element, so that helped a lot (btw. a DTD/Schema would be much nicer ;-).

Best regards

Daniel Kasmeroglu

I just checked with an

Submitted by gesobak on Wed, 04/28/2010 - 13:53.

I just checked with an eclipse 3.4. The configuration tab with start levels etc. is new in eclipse 3.5. The Help gives some new spare information on it.

Best regards,
Georg.