Community
Participate
Working Groups
When using the new Feature wizard to create a feature.xml, the second page lets you select plugins to prepopulate the feature with. If a platform specific fragment is selected, the wizard should probably automatically set os/ws/arch values for that fragment. If the os/ws/arch are not specified in the feature.xml, export can fail when a platform specific fragment does not resolve because it is for a different platform.
Oh ya, we have a feature wizard :)
Bugday, you said bugday ? Mine ! :) Should we add the same mechanism in the Feature editor ? ATM, when a fragment is added to a feature, OS/WS/NL/Arch values aren't automatically set...
Sure, it would be nice to be consistent. I think Andrew would be pleased along with the other feature authors out there. We really didn't invest much time in the feature editor in 3.4 due to the unknowns surrounding p2.
This bug might be deceptively hard. I realize now that this basically will require looking at the fragment's Eclipse-PlatformFilter (an LDAP filter) and trying to deduce ws/os/arch(/nl) from that. Alternatively, look at FeatureGenerator.createFeature from pde.build, this is deducing ws/os/arch using a set of known configurations, a resolved state and help from BundleHelper.createFilter
(In reply to comment #4) > This bug might be deceptively hard. I realize now that this basically will > require looking at the fragment's Eclipse-PlatformFilter (an LDAP filter) and > trying to deduce ws/os/arch(/nl) from that. I've just noticed that too...! I'll have a look at what has been done in PDE build, thanks for your tips :)
If os/ws/arch values can't be generated satisfactorily, one possibility would be warning for plugins that have a platform filter but no os/ws/arch.
i probably won't have time enough to look at this bug at the moment :-s
That's fine! Thanks for all your contributions!
Well, after some reflexion, I think it's a bit difficult to implement a better solution than the alternative described by Andrew in comment #6 ... Indeed, what one would expect if the plugin or fragment filter has been set to something like (&(os=win32) (!(nl=fr))) Should the feature declare an environment filter with all locales except the "fr" one? I would say the answer is no. The same kind of problem occurs when the "|" operator is used, it's virtually impossible to generate the right os/ws/arch/nl values... In fact, I'm afraid what I don't understand very well is why the "supported environment filter" has been split into 4 different fields and doesn't re-use the LDAP syntax...
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.
