Community
Participate
Working Groups
Not everyone uses a proper J2SE JRE as their default JRE. These bundles will not compile on my workspace without some manual tweaking.
Created attachment 80085 [details] Patch to add EE settings in the MANIFEST.MF and .classpath files.
Just hit this today when I performed a global 'Override and Update' without thinking. Can we get this resolved?
I have released the UI portion of the patch. Moving to core for the core portion.
One second - before we do it could somebody describe the meaning of the change? - <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> + <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.4"/> I've opened a bug 218211 on PDE saying that having specific VM referenced in the classpath does not work when plugin needs to be tested in several environments (in my case, 1.4 and 1.5). If the entry like the entry above is added, then changing VM in launch configuration 1.4 to 1.5 did not have an effect for me - I had to go into project properties and manually change JRE references there. However, if no specific JRE is specified in the entry above, then changing VM in the launch configuration is sufficient to move between 1.4 and 1.5. That bug was closed as "works for me" by PDE and I did not have time to follow up on it.
(In reply to comment #4) > One second - before we do it could somebody describe the meaning of the change? > > - <classpathentry kind="con" > path="org.eclipse.jdt.launching.JRE_CONTAINER"/> > + <classpathentry kind="con" > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.4"/> The project will not compile on my workspace because my workspace's default JRE is IBM's J9 Foundation 1.0 JRE. Specifying the J2SE-1.4 will allow it to compile because JDT will then find a match for the EE in the list of JREs that I have set in the preference page.
I've reoped the bug 218211 and adding Chris to the CC list here. It does look to me that there is a bug in PDE.
(In reply to comment #6) > It does look to me that there is a bug in PDE. Do you mean that PDE is causing this project to not compile out-of-the-box in my workspace?
The correct, please update your classpath compliance settings via PDE and if you have EEs specified in the MANIFEST.MF correct, you will get a correct classpath.
Guys, don't you find it strange that you have to set classpath to <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.4"/> to have bundle compile against your default VM which happens to be Foundation 1.0 ? Chris, sorry, I don't understand what you are saying in the comment 8.
(In reply to comment #9) > Guys, don't you find it strange that you have to set classpath to > > <classpathentry kind="con" > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.4"/> > > to have bundle compile against your default VM which happens to be Foundation > 1.0 ? Maybe I worded my description incorrectly, let me try again. 1. Checkout project from CVS. 2. Project does not compile. 3. This is caused by my workspace's default JRE being F1.0, the .classpath file of the project in question is pointing to the default. 4. The project _should_ have an EE _and_ corresponding .classpath entry set to ensure that projects will "always" compile OOTB for people checking out code from CVS ("always" is in parentheses in the event that the user does not have a 'Perfect Match', in that case, that is the user's problem, not the developer's). 5. Said patch adds J2SE-1.4 to the MANIFEST.MF and .classpath file so that this project will now compile OOTB on any workspace that has an appropriate match set for J2SE-1.4. This is not a PDE problem because a) the MAINFEST.MF does not have an EE set b) the .classpath file does not have an EE set c) PDE cannot expect to magically know which EE to use d) this project was more than likely created before "widespread EE adoption", so the original creator of the project did not set an EE, heck, maybe EEs didn't even exist back then, my OSGi foo is weak
I do believe that PDE has a problem but I'll leave that for the 218211. For the specific compilation error: After I set up Foundation 1.1 j9 VM as a default and checked out the project, I received a number of compilation errors complaining about XML parser and its components not found. Which is as expected - those classes are not present on the FOundation VM. If I add 1.4 as a minimum EE to the project and use "update the classpath settings", then errors go away. (Which is strange as at this point my VM is set to Foundation 1.1 but OK, I'll leave that to PDE.) Remi, is this what the problem that you see? If it is, then we probably should: - add 1.4 and 1.0 as execution environments to manifest.mf; - Add package imports on XML parser classes Note that the dependent test.performance bundle lists 1.4 as minimum EE.
(In reply to comment #11) > If I add 1.4 as a minimum EE to the project and use "update the classpath > settings", then errors go away. > > (Which is strange as at this point my VM is set to Foundation 1.1 but OK, I'll > leave that to PDE.) > > Remi, is this what the problem that you see? Yes, that's the problem I'm describing. With regards to your PDE comment, when you say your VM is set to Foundation 1.1, you meant your workspace's default, correct? Do you not have a match for J2SE-1.4 though in that workspace? When you update the classpath settings, it will tweak the .classpath file accordingly to point to J2SE-1.4. This should trigger a rebuild and JDT will (hopefully) find an appropriate JRE and compile the project against that JRE. Hence, the errors go away because the project can be compiled against J2SE-1.4 without any problems. > If it is, then we probably should: > > - add 1.4 and 1.0 as execution environments to manifest.mf; > - Add package imports on XML parser classes I don't really have a problem with this. I will leave it to the Runtime team to decide what EE settings the project should use. All I want is for proper EEs and .classpath files to be set so that they compile for me when I check them out. If I am missing packages or don't have perfect matches, that's my problem. But if the project has no BREE and has a .classpath file pointing at the default, then it will only cause problems in the future.
Created attachment 90682 [details] Updated patch for the org.eclipse.core.tests.harness
Patch applied to CVS Head.
Added "contributed" keyword.
