Community
Participate
Working Groups
Latest PDE code from head. 1. Create a new RCP mail template project (com.example.xyz) 2. Create a new fragment project (com.example.fragment) whose host is com.example.xyz 3. Go to the Dependencies tab of com.example.xyz and make it unresolved by specifying the bundle version of org.eclipse.ui to 6.0 If the fragment contained code, it would have had compiler errors at this point, since the fragment just lost connectivity with the host. Therefore, it is important for the manifest.mf for the fragment to flag the Fragment-Host header to indicate that the host is unresolved.
"the fragment just lost connectivity with the host" I think this is a problem. I create a plug-in that depends on the rcp mail plug-in, the plug-in has a class that references class from rcp mail plug-in. Then I change dependency of rcp on eclipse.ui to version 6.0, which makes the rcp mail unresolved. Neither rcp mail plug-in, nor a plug-in that depends on it have compile errors. There is a single error marker in rcp manifest at eclipse.ui require bundle line. This is a very good aid to fix the problem (there is no recursiveness that would show errors on otherwise correct imports in the second plug-in. If the same is repeated using fragment for which host is the rcp plug-in, instead of plug-in depending on rcp plug-in, it produces completely different results. Fragment has compile errors. Why does it, if plug-in did not? Flagging fragment manifest with errors will be confusing noise, as they are not real problems. If we change validator to flag errors in fragment manifest, it will be very inconsistent special case. Validator does not check if anything is resolved so far. Finding the problem in the rcp plug-in will be much harder to the user, with bogus errors instead of the single one in the rcp plugin. Can you consider fixing fragments that they behave similarly to plug-ins, which plug-in dependency container stays populated during development.
start at bug 97010 comment 9 to see why the behavior is different for fragments vs. plugins
I find good reasons why plug-ins get special treatment by, but found no valid reasons why fragmetns do not, and they have to "have thousands of compiler errors". You say: "For fragments, PDE can't be as lenient of course, since the call to getHost() will return null by the state and we therefore leave it at that." I don't know why it can't and the getHost() returns not null.
Created attachment 22385 [details] 98402 o.e.pde.core patch.txt Consider this patch, it adds the same special treatment to fragments as plug-ins have. Would it work? Seems to work for me, but I have never touched classpath containter code before, so am not sure about effects of it.
Keep in mind that although we are lenient with plugins, there are red X on the manifest.mf to indicate that there is something wrong. Actually technically we are as lenient with fragments as we are with plugins because if the fragment declared its own dependencies, we still add them to the fragment's classpath. It's only the host and whatever comes through the host that does not make it on the classpath. I think that's reasonable behavior because it's the state that determines what fragment binds to what host and we should not make the decision ourselves nor speculate. I'm a huge fan of leniency, but this patch is so lenient that it actually becomes a disservice since at development time there will be absolutely no signs (no compiler errors, no errors on the manifest.mf) that anything is wrong and people will be in for a shock when they run. We have had at least one instance where the fact that an unresolved fragment had Java compiler errors is what tipped the user off that there is something wrong in the manifest.mf. In that case, the platform-filter header was incorrect and would have broken the build if it went unnoticed. Of course, if the fragment contained no Java code, then the problem would have gone unnoticed too. That is why I was suggesting that some indicator on the manifest.mf is warranted.
> Keep in mind that although we are lenient with plugins, there are red X on > the manifest.mf to indicate that there is something wrong. There is no red X on the plugin depending on unresolved plug-in, exactly as there a no red X on the fragment depending on uresolved plug-in. > Actually technically we are as lenient with fragments as we are with plugins > because if the fragment declared its own dependencies, we still add them to > the fragment's classpath. I view host for a fragment equivalent to a dependent plug-in for a plugin, with that difference that plug-in reexports "everyting" to its fragment. > It's only the host and whatever comes through the host that does not make it >on the classpath A lot. > I think that's reasonable behavior because it's the state > that determines what fragment binds to what host and we should not make the > decision ourselves nor speculate. A "judgment call" has been made alredy. We try to be better then the state at resolving dependent plug-ins at development time. I still don't understand why this does not apply to fragment host. > I'm a huge fan of leniency, but this patch is so lenient that it actually > becomes a disservice since at development time there will be absolutely no > signs (no compiler errors, no errors on the manifest.mf) that anything is > wrong and people will be in for a shock when they run. As is the case for a plug-ins depending on another that has unsatisfied dependency. > Of course, if the fragment contained no Java code, then the problem would > have gone unnoticed too. That is why I was suggesting that some indicator on > the manifest.mf is warranted Manifest builder is triggered by Java builder. If fragment has no Java code, a change in manifest.mf or resolution of some plug-in will not cause a fragment manifest.mf to be build. The error will not appear. If it appears for some reason, and the plugin gets resolved, we have a worse problem, because the errror will not go away by itself. Fragment will need to be touched or full build will need to be performed. Until we rethink how manifest builder works, we should not add any error to fragment that is dependent on whether something is resolved in the state. If viewed as safe, I am for considering the patch from comment #4. If not than I am for not changing anything in this area for 3.1.
done. if a fragment has an unresolved or missing host, we flag it with an accurate message so that users are not mystified why the classpath is incomplete.
