Yes, you're right. Which environment should I use during development time in order to avoid this kind of mistakes ?
OSGi provides you with the necessary foundation jars. Look at the download page for the spec (requires registration but it's not that bad :-). Subsequently, you can use their jars as the bootclasspath for compilation. Note that eclipse allows to choose profiles as of 3.2 - one is called OSGi-minimum1.1, I'd go with that one for working on the core (assuming I'd work with eclipse >= 3.2). Unfortunately, that doesn't work for me because on my Mac it claims that Hashmap doesn't implement Dictionary and Thread.setDaemon() doesn't exist (I assume that I'm to stupid to set it up correctly :-) If nothing else, just make sure what you do works on jdk1.3 - that should be good enough.
In R4, 3.9.1, p.62, first paragraph : [...] Operator should set the appropriate system property [..] For example, if the operating system returns version 2.4.2-kwt, the Operator should set the system property org.osgi.framework.os.version to 2.4.2.
Hm, without digging deeper (due to time constraints), doesn't that imply that an external Operator is supposed to configure the org.osgi.framework.os.version property correctly? Why would you want to do it inside the framework then? I must be missing something...
Regards, -- </arnaud>
regards, Karl -- Karl Pauls [EMAIL PROTECTED]
