Community
Participate
Working Groups
Build ID: 3.4.0 I20080617-2000 Steps To Reproduce: Pre-req: Add custom execution environment: 1. Windows->Preferences->Java->Instaled JREs. 2. Add->Execution Environment Description-> Next. 3. Specify valid ee file. (File includes: -Dee.language.level=1.5 entry) ->Finish. pre-req: Create new plug-in project. 1. File->New->Plug-in project. 2. Specify name click Next. 3. In the "Plug-in content" page of the new project wizard make sure new Execution Environmet is selected in "Execution Environment" field. Click Finish. Problem: Attempt to export project as a "Deployable plug-in" 1. Hightlight project, Right-click, Export->Plug-in Development->Deployable plug-ins and fragments. Click Next. 2. Check project, specify destination. Click Finish. 3. Problem reported: "Problems during export Bundle u_1.0.0 failed to resolve.: Missing Constraint: Bundle-RequiredExecutionEnvironment: desktopEE-6.5" Other problem: Cannot build Update Site project's feature, if it contains a plug-in project targeting custom Execution Environment. 1. Create new feature project. 2. Add plugin project from above to the newly created feature. 3. Create new Update Site project, add newly created feature. 4. Open Site.xml in Site manifest editor, and choose to build the feature. Error reported: "Problems during export Bundle u_0.0.0 failed to resolve.: Missing Constraint: Bundle-RequiredExecutionEnvironment: desktopEE-6.5" More information:
This is related to bug 236296, and might be a duplicate.
Would it be possible to fix this in 3.4.1 ?
Although there is an obvious common denominator between this issue and bug 236296 (requiredExecutionEnvironment entry set to a custom EE). I think they might require separate fixes. I found that PDE is terminating these operations because the bundle state includes ResolverError.MISSING_EXECUTION_ENVIRONMENT errors. That error shouldn't occur since the custome EE is valid. One more note, the ResolverError.MISSING_EXECUTION_ENVIRONMENT error seems to stem from the fact that org.osgi.framework.executionenvironment in the osgi state file (.metadata\.plugins\org.eclipse.pde.core\New_configueeerationd\org.eclipse.osgi\.state.8) doesn't include the custom EE. Why doesn't that state file include the new EE?
Andrew, where does PDE build get it's EE's from? Does it use OSGi profiles? Are they hardcoded? PDE build is headless, so I'm assuming it won't konw about contributed EEs (via the jdt extension point).
CC'ing Tom - looks like the ResolverError.MISSING_EXECUTION_ENVIRONMENT is coming from the OSGi layer. Is there any extensibility in OSGi to accept custom execution environment definitions? We support extesnsibility at the JDT layer, but lower layers do not know about this.
(In reply to comment #4) > Andrew, where does PDE build get it's EE's from? Does it use OSGi profiles? Are > they hardcoded? PDE build is headless, so I'm assuming it won't konw about > contributed EEs (via the jdt extension point). > Looking at the class /org.eclipse.pde.build/src/org/eclipse/pde/internal/build/site/PDEState.java it looks like it uses the "profile.list" file contained in org.eclipse.osgi as the list of EEs that are supported. I don't see any place where user defined EEs can be used. (In reply to comment #5) > CC'ing Tom - looks like the ResolverError.MISSING_EXECUTION_ENVIRONMENT is > coming from the OSGi layer. Is there any extensibility in OSGi to accept custom > execution environment definitions? > > We support extesnsibility at the JDT layer, but lower layers do not know about > this. > The resolver State supports EEs which are specified in platform properties that are set using the org.eclipse.osgi.service.resolver.State.setPlatformProperties(Dictionary[]) method. (In reply to comment #2) > Would it be possible to fix this in 3.4.1 ? > Is this a regression or an enhancement request? AFAIK PDE-Build has never supported custom EEs. We typically do not do enhancements in point releases.
Moving to UI since they are building the state for export, I raised bug 239843 for build. This is an enhancement. Tom is correct, PDE/Build reads the profile.list and the *.profile files from the OSGi bundle. See PDEState.resolveState to see how we add profiles to the state. If custom EE's are being added via .ee files, then the information normally in the .profile file is also required, specifically the org.osgi.framework.system.packages and org.osgi.framework.executionenvironment properties. Either the .ee file will need to define these, or define a property indicating the .profile file to use. Additionally, PDE/Build reads an org.eclipse.pde.build/data/env.properties file which specifies source/target levels corresponding to each EE. In case of a custom EE, these source/target levels will need to be provided. UI is already giving us the bootclasspath for each EE, and I assume there would be no change here for custom EEs.
This looks like an enhancement request to me for people wanting to use their own profiles. Tom, is it time that we just have a central place for this stuff? I believe the SDK has 3 places that we are defining various profiles for things (p2, security, etc...)
(In reply to comment #8) > This looks like an enhancement request to me for people wanting to use their > own profiles. > > Tom, is it time that we just have a central place for this stuff? I believe the > SDK has 3 places that we are defining various profiles for things (p2, > security, etc...) > Yes I do but I'm not sure where you would define these. We have some standard ones included in org.eclipse.osgi, it seems like we just need another "central" mechanism where additional ones can be added (perhaps fragments to system.bundle?)
(In reply to comment #9) > Yes I do but I'm not sure where you would define these. We have some standard > ones included in org.eclipse.osgi, it seems like we just need another "central" > mechanism where additional ones can be added (perhaps fragments to > system.bundle?) I opened bug 240724 to explore this topic more. It would be nice to do for 3.5 as this is pain point when it comes to keeping those bits in sync...
This may also relate to some of the work I'm experimenting with in bug 240724
*** Bug 198928 has been marked as a duplicate of this bug. ***
Created attachment 117147 [details] patch Builds on the new infrastructure from JDT. Retrieves environments and compliance settings dynamically. Needs some more testing.
Tom, I noticed that some OSGi profiles specify an addition compiler setting for "org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode". Should PDE just blindly set all "org.eclipse.jdt.core.compiler.*" settings specified? (I thought we originally agreed on 5 compliance settings). However, just using any settings present would make things pretty flexible/extensible.
(In reply to comment #14) > Tom, I noticed that some OSGi profiles specify an addition compiler setting for > "org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode". Should PDE just > blindly set all "org.eclipse.jdt.core.compiler.*" settings specified? (I > thought we originally agreed on 5 compliance settings). However, just using any > settings present would make things pretty flexible/extensible. > I think using any org.eclipse.jdt.core.compiler.* settings present is the way to go. I got my settings from the method org.eclipse.jdt.core.JavaCore.setComplianceOptions(String, Map). I think this provides us with the flexibility necessary if jdt adds a new option.
Created attachment 117237 [details] patch This patch uses compilance settings from assocaited execution environment when setting compiler options for projects. Still need to address calling out to PDE build with custom EE's.
Cool, it's nice to see the code simplified ;) Darin, do we get burned if we are pointing to an older target?
(In reply to comment #17) > Cool, it's nice to see the code simplified ;) > Darin, do we get burned if we are pointing to an older target? You mean if there is no EE specified? (I have to do more testing for that case).
Created attachment 117260 [details] updated patch Setup export script generation with custom EE's.
Created attachment 117348 [details] patch Updated patch and added tests.
As expected, when running the new tests against the old code base, the only failure is the testCustomEnvironment(). This validates compliance/classpath settings are the same w.r.t to non-custom EE's. I've tested exporting manually, but have not added a test yet. My question is around ant script generation from the export wizard. It seems that the ant script should set "extra EE locations", but I'm not sure how this should be done, since the location of the 'extra' profile files is generated in the PDE metadata area, which does not make the script very re-useable.
Generated build.xml's were not meant to be generally reusable. However, in the particular case of EE's, you we only need the ee profiles at generation time. Once the scripts are created, all that is need is for the appropriate ee-named properties specifying the bootclasspaths to be set.
Created attachment 117364 [details] patch OK, so we don't need to modify the generated ant script. Added 2 export tests to ensure the code path of exporting with a custom environment is used and succeeds.
OK, this patch is ready for review/application by Chris and/or Curtis. I ran the tests on XP and Ubuntu - all are green.
Thanks Darin. > 20091107
*** Bug 170518 has been marked as a duplicate of this bug. ***
