Bugzilla – Full Text Bug Listing
| Summary: | [plan] Update Execution Environment profile format to include custom jdt settings | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Chris Aniszczyk <caniszczyk> | ||||||||||||||||
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> | ||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||
| Severity: | enhancement | ||||||||||||||||||
| Priority: | P4 | CC: | aniefer, darin.eclipse, jeffmcaffer, tjwatson | ||||||||||||||||
| Version: | unspecified | Keywords: | plan | ||||||||||||||||
| Target Milestone: | 3.5 M3 | ||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| Bug Depends on: | |||||||||||||||||||
| Bug Blocks: | 238802 | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Chris Aniszczyk
For the VMProfile service, I'd envision a simple interface with possibly one method, getURL which points to the location where the profile exists on disks. The service would also contain the service properties that correspond to what's located inside the profile file (ie., org.osgi.framework.system.packages, etc...). Does this sound reasonable Tom? Or should we offer more here for people? For hooking this up in Equinox, it looks like SystemBundleActivator is the right place, registering the various profiles. The next question is... where in the framework should we setup a ServiceTracker... Framework.loadVMProfile() ? (In reply to comment #1) > For the VMProfile service, I'd envision a simple interface with possibly one > method, getURL which points to the location where the profile exists on disks. Disk? I would prefer not to give access to the raw content directly. Just let implementors get the data how every they want. > The service would also contain the service properties that correspond to what's > located inside the profile file (ie., org.osgi.framework.system.packages, > etc...). This should be good enough > > Does this sound reasonable Tom? Or should we offer more here for people? It would be helpful to specify some property values as String[] instead of one big long ',' comma separate list. I think the following properties should be specified org.osgi.framework.executionenvironment - (String[]) list of supported excecution environments org.osgi.framework.system.packages - (String[]) list of (non-java.*) packages included in the VM name - (String) the primary execution environment name (e.g. a VM profile for 1.5 would be J2SE-1.5) > > For hooking this up in Equinox, it looks like SystemBundleActivator is the > right place, registering the various profiles. The next question is... where in > the framework should we setup a ServiceTracker... Framework.loadVMProfile() ? > Problem is we need this information way too low in the Framework launch. It needs to be read and used just to create the SystemBundle. I don't really see how the Framework will be able to use profile services registered by normal bundles. By the time they get to register their services it is way too late. The framework certainly can expose its built-in profiles with services, but I don't see how the framework could use other profiles. We should consider how framework fragments could contribute to the built-in profiles discovered by the framework. I am also concerned about performance. I suspect that this useful service will be used quite infrequently and only for some very specific profiles. So loading all the data all the time and creating all the services seems wasteful. Rather than having people grovel arond through service properties and csv strings, why not have a Profile service that has IProfile getProfile(String name) Then people can be isolated from the details of how we implement that service. we dcan use registration, whiteboard with DS, extensions, .. all of the above, ... Side note, what happens in the case of multple conflicting profile definitions? (In reply to comment #3) > I am also concerned about performance. I suspect that this useful service will > be used quite infrequently and only for some very specific profiles. So loading > all the data all the time and creating all the services seems wasteful. > > Rather than having people grovel arond through service properties and csv > strings, why not have a Profile service that has > IProfile getProfile(String name) > Then people can be isolated from the details of how we implement that service. > we dcan use registration, whiteboard with DS, extensions, .. all of the above, > ... > > Side note, what happens in the case of multple conflicting profile definitions? > I like this idea. We should investigate for 3.5. Created attachment 113375 [details]
org.eclipse.osgi.patch
Here is a patch to get people started at least with thinking about the problem.
Here are some issues we need to think about:
1) how do we treat the default profiles that come with the framework? That is, what would happen if someone attempted to "unregister" a default profile? Do we allow people to modify these a bit to help with the old age problem of a profile not having a package that is actually in their VM, but not specified in the default profile?
2) how are profiles added? fragment to the system bundle? if you register one dynamically, what does that mean?
The PDE team has cycles this week to help tackle this problem which will enable other teams to use this service.
Tom, what are your thoughts on the Equinox side of accomplishing this?
Created attachment 113820 [details]
org.eclipse.osgi.patch
A work in progress.
Tom and I talked today and he just wanted a snapshot of what I was doing.
Created attachment 113821 [details]
org.eclipse.osgi.patch
Ok, weird, Mylyn didn't fully commit the patch for me so I'm going to do it manually.
So here is the idea so far:
1) have an ExecutionEnvironmentService that has a way to get all the profiles or just a specific profile
2) profiles can only be discovered via a fragment to the systembundle
I also started crafting some very basic tests which we will need to expand upon once we agree with a direction.
We can talk about this on the Equinox call tomorrow. Tom had a thought of possibly tossing the ExecutionEnvironmentService and just moving the hooks into EnvironmentInfo. Created attachment 113875 [details]
org.eclipse.osgi patch
Thanks Chris. You need to move over to the RT repo at /cvsroot/rt !! :)
Here is an updated patch. I changed the following:
- Moved the creation of the service into SystemBundle.
- Lazily discover the profiles instead of doing at startup.
- Kept the *.profile files in their current location in org.eclipse.osgi. Others depend on these resources. We cannot move them without having some migration path (hopefully using the new service).
- Still search the profiles/ directory to find profiles from fragments.
- Changed the ExecutionEnvironment interface to return simple Strings for system packages and supported environments. What will clients use these values for? My thought is that they would use them to set the platform properties on the resolver State object. In this case the State object is expecting a single string with comma separated values.
There is still significant work to allow execution enviroments from fragments to be used as the running execution environment for the framework. The framework currently loads the vm profile too early before the fragments are available. The code to load the running vm profile needs to be changed to use the algorithm of the ExecutionEnvironmentServiceImpl. There are some issues that need to be solved to do this.
1) At runtime we know the name of the profile we want to load (through system properties). We do not want to do an exhaustive search to find the entry because this is pretty expensive.
2) The profile needs to be loaded before we create the system State and add the system bundle. Otherwise we need to update the properties of the system State with the new system packages and then refresh the system bundle which will restart the framework. There is a chicken/egg problem here. We may have to force a framework restart if we install and resolve a new framework extension that provides a profile which we want to run with.
Well crap, it would be nice to have some indication in HEAD in the old location. Like deleting everything and leaving a README.txt or just deleting everything. (In reply to comment #9) > Thanks Chris. You need to move over to the RT repo at /cvsroot/rt !! :) Good to know. I sent an email to equinox-dev about having things in HEAD deleted in the old repo. > Here is an updated patch. I changed the following: > > - Moved the creation of the service into SystemBundle. > - Lazily discover the profiles instead of doing at startup. > - Kept the *.profile files in their current location in org.eclipse.osgi. > Others depend on these resources. We cannot move them without having some > migration path (hopefully using the new service). > - Still search the profiles/ directory to find profiles from fragments. Are we in agreement that this is a fair thing to do? *.profile files in a profiles directory? > - Changed the ExecutionEnvironment interface to return simple Strings for > system packages and supported environments. What will clients use these values > for? My thought is that they would use them to set the platform properties on > the resolver State object. In this case the State object is expecting a single > string with comma separated values. From an API POV, this makes sense. However, when tooling comes into question, we will mostly like want an array of strings as we will end up doing the chopping up into an array. I can live without this. > There is still significant work to allow execution enviroments from fragments > to be used as the running execution environment for the framework. The > framework currently loads the vm profile too early before the fragments are > available. The code to load the running vm profile needs to be changed to use > the algorithm of the ExecutionEnvironmentServiceImpl. There are some issues > that need to be solved to do this. > > 1) At runtime we know the name of the profile we want to load (through system > properties). We do not want to do an exhaustive search to find the entry > because this is pretty expensive. > 2) The profile needs to be loaded before we create the system State and add the > system bundle. Otherwise we need to update the properties of the system State > with the new system packages and then refresh the system bundle which will > restart the framework. There is a chicken/egg problem here. We may have to > force a framework restart if we install and resolve a new framework extension > that provides a profile which we want to run with. I will have to defer to you on this part. It's a bootstrap problem... the only way I can see us getting around this is having a profile location specified via some system property that we would search at the right time and not depend on anything in fragments. We had a discussion about this service at the equinox call today. The general consensus is that this service does not belong in the Framework. - There are other bits of information about a VM that is needed in other scenarios. For example, the jni library, the executables, the boot classpath and source and other things available from the *.ee files. These are things a framework service cannot provide. - P2 has vm IUs it uses to manage the vm information. They have additional needs beyond the system packages and supported execution environments. - The service itself will not be used by the Framework. Discovering a profile will must be done before the service is available. We should firm up the story around launching with a custom profile. The osgi.profile configuration property should be useful for doing this. - The implementation can easily be done in another bundle which discovers the *.profile files from org.eclipse.osgi. If P2 finds a need for the *.profiles then perhaps the implementation can go in one of the core p2 bundles. Otherwise it feels like something that should be defined by JDT and used by PDE. That likely does not help PDE-Build since it does not depend on JDT. Another option is to define an extension point (not in the Framework) that simply allows you to specify a resource for a profile. Then the framework can profide extensions for each profile it contains and framework fragments could also define profiles (but we still have boot strap issues for the framework to use them). I've done some deeper investigation with some of the PDE Build issues, so here is the story I've come up with so far. We have a bit of disconnect between tooling needs and runtime needs. PDE UI will obtain its list of execution environments from JDT which grabs it from the 'org.eclipse.jdt.launching.executionEnvironments' extension point. PDE Build grabs things from org.eclipse.osgi and has some source/target compiler settings mappings in data/env.properties... ie., ... CDC-1.0/Foundation-1.0.javacSource=1.3 CDC-1.0/Foundation-1.0.javacTarget=1.1 ... The tooling supports this scenario well to an extent. However, how do you support building a state using this information? The runtime doesn't have this information, so for example, when you go to export something, you will get info about a missing execution environment. PDE Build also needs to be aware of the compiler settings. Created attachment 114032 [details]
org.eclipse.osgi.patch
Thoughts about putting javac source/target information within the .profile files?
That way, PDE Build doesn't have to maintain it's mappings and may JDT can take advantage of this information too.
Tom, will you add constants for the javacSource and javacTarget keys? (similar to Constants.FRAMEWORK_SYSTEMPACKAGES?) There are four settings that are important for compiler compliance settings: * .class file compatability * source compatability * whether to allow the 'assert' identifier * whether to allow the 'enum' identifier The default settings for these options is well described by code in JavaCore.setComplianceOptions(String compliance, Map options) Talking with Tom, we propose the following keys in the profile properties file - and corresponding constants in the org.eclipse.osgi.service.environment.Constants class. * org.eclipse.osgi.java.javacTarget * org.eclipse.osgi.java.javacSource * org.eclipse.osgi.java.identifier.assert * org.eclipse.osgi.java.identifier.enum Values for the first 2 options would be string like 1.4, 1.5, etc. Values for identifier optoins would be "error", "warn", "ignore" (although I'm not sure if command line compilers allow 3 levels of reporting - or if they just allow for error/ignore). Darin, as part of this bug we should eliminate PDE's copy of ExecutionEnvironmentAnalyzer: org.eclipse.pde.internal.core.ExecutionEnvironmentAnalyzer Looking at JavaCore I think we should reuse the key values defined there: org.eclipse.jdt.core.compiler.source org.eclipse.jdt.core.compiler.codegen.targetPlatform org.eclipse.jdt.core.compiler.problem.assertIdentifier org.eclipse.jdt.core.compiler.problem.enumIdentifier org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode I would prefer not to have to define duplicate constants in org.eclipse.osgi. Darin do you agree or do you think we must have new constants in org.eclipse.osgi? We should also use the following constant from JDT: org.eclipse.jdt.core.compiler.compliance I prefer to use the jdt constant keys in case jdt invents new compiler options for later VMs, then the profiles for the new VMs can include the new keys without us having to create new constants in org.eclipse.osgi. Should we consider supporting the key java.class.version? (In reply to comment #18) > Darin do you agree or do you think we must have new constants in > org.eclipse.osgi? The problem I see is that pde.build does not pre-req JCore, so it won't be able to reference the constants from JCore. (In reply to comment #19) > We should also use the following constant from JDT: > org.eclipse.jdt.core.compiler.compliance The "compliance" preference appears to be a convenience - i.e. a way to group the other 5 settings. We could infer the 5 settings from the compliance, or infer compliance if the settings are default settings - but I'm not surewe should have both since they may not be in synch? (In reply to comment #22) > (In reply to comment #19) > > We should also use the following constant from JDT: > > org.eclipse.jdt.core.compiler.compliance > > The "compliance" preference appears to be a convenience - i.e. a way to group > the other 5 settings. We could infer the 5 settings from the compliance, or > infer compliance if the settings are default settings - but I'm not surewe > should have both since they may not be in synch? > I agree, we should not have both. I think we should not infer the other 5 settings. This way we can allow for maximum flexibility. (In reply to comment #21) > The problem I see is that pde.build does not pre-req JCore, so it won't be able > to reference the constants from JCore. > Andrew, what are you thoughts here? I am reluctant to copy all the key/value constants and associated javadoc from jdt to the Framework in order to avoid PDE-Build from having to deal with no constants available to it. Created attachment 114352 [details]
profiles using jdt keys
Here is an update profiles patch that uses the jdt keys.
Speaking with the Java compiler folks, it appears we do need to specify compiler compliance level in addition to other options. The reason is that the compliance level reflects the JDK level... For example, if Sun were to fix a compiler bug in Java 7 (but not in earlier releases), then there is different compiler behavior when invoking javac from Java 7 vs an earlier version. Targe level, source level, etc., does not completely specify all that is needed for the Eclipse Java compiler - it needs to know what the baseline compliance (JDK level) is, to be consistent with the industry standard. So, this is required by the Eclipse Java compiler to get correct behavior. With that said, I'm not sure how it is specified on the command line. (In reply to comment #25) > With that said, I'm not sure how it is specified on the command line. Jerome tells me ecj accepts this as "-1.5", etc. Not sure PDE build can tell which compiler adapter is being used. Build does not currently support setting compliance levels. But it can be done through custom scripts (http://aniefer.blogspot.com/2008/09/custom-compiler-arguments-in-pdebuild.html) Arguments can be associated with specific compiler adapters. Created attachment 114810 [details]
profiles using jdt keys
This patch adds org.eclipse.jdt.core.compiler.compliance key to the profiles.
Updated EE Profiles have been including the jdt settings for each profile. Turns out that we have no need for specifying the java.class.version property. I have removed the property from the profiles. |