On 07/07/09 09:16, Max Rydahl Andersen wrote: As I was trying to say in IRC, I don't think Bundle-RequiredExecutionEnvironment covers everything that we would want to be consistent between developers. Workspace settings do cover them, but there aren't any good ways of sharing/enforcing the settings. (It's possible to export workspace settings to a file, but how often should developers import them? And are they disallowed from changing *anything*? If they do change something, just for themselves, the next import will clobber their personal settings.) Unfortunately, there aren't any perfect solutions for this yet, but I think .settings files are pretty much the only usable option for now. And in a way, it makes sense for a plugin to be self-contained with its own settings, rather than being dependent on the IDE environment. In fact, I just did a quick test: In org.eclipse.bpel.apache.ode.deploy.model, which has Bundle-RequiredExecutionEnvironment: J2SE-1.5 I added some code to the default package: class MyIterator implements java.util.Iterator { @Override public boolean hasNext() { return false; } @Override public Object next() { return null;} @Override public void remove() {} }; Using Java 1.5 compiler compliance, that should not compile, since @Override is not allowed for implementations of interface methods. However, it is compiling for me, since my workspace preferences use 1.6. Only by changing my workspace preferences to 1.5, or by enabling project-specific settings (.settings directory), will the IDE use 1.5 compliance. It looks like Bundle-RequiredExecutionEnvironment really only controls the runtime requirements (as the name implies), not the compiler settings. You can tick a box when enabling project-specific settings to get the compiler settings from the Build Path/BREE, but this choice gets recorded in, you guessed it, .settings. Making sure every new project gets its .settings added will be a bit of a pain (eased by a Hudson script task?), but it should be easier than keeping workspace settings synchronized. Regards Sean PS I'm changing my JBT workspace settings to use 1.5 compliance now! -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat

On 07/07/09 17:32, Max Rydahl Andersen wrote: I'm not arguing against BREE, I'm all for specifying those things properly. But I don't think .settings affects the good things manifests can do. Huh? Maybe we are talking about two different things, because I don't understand how you can svn update/merge workspace settings. I'm not talking about files which are versioned/committed. Are you? I was talking about the preferences inside Eclipse being clobbered by *incoming* changes when importing an updated preference dump. Unless you're suggesting that everyone export workspace settings to a versioned file, and let svn merge changes into that. Hmm, interesting, but you'd have to remember to export your settings after every Preferences change, or the clobbering problem is back. And you'd have to remember to import every time the file got svn updated. It's much easier/safer with .settings files because Eclipse always keeps the file up to date with what the IDE compiler is using. So, a bit like the .settings directory, but with an option to override it per-user? Or something else, like inheritance of settings between projects? That would certainly be useful. I'm beginning to understand why Maven-based projects don't believe in versioning IDE files, but insist on generating them from the pom (which does allow inheritance). It's a shame Maven and PDE Builder don't get along. Well, it is in the name of the manifest property... Great. Yes, I only just realized that I was on a different VM from everyone else. But as I understand it, nothing in .settings affects real Hudson/PDEBuilder builds (and what the users get), only compilation in the local IDE. But there was a danger that I could introduce a 1.6-ism which would break the build. I think PDEBuilder just gets all its compiler settings from build.properties, ignoring .settings. -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat

On 07/07/09 20:10, Max Rydahl Andersen wrote: Oh, that's what you meant. That does sound like a nice option: inheriting workspace settings from a specified project. But in practice, I wouldn't like projects to depend on this, since the workspace settings are basically global variables. Inheriting settings between projects seems safer. Having both options would be great. It's always been a little too easy to make environment-dependent projects in Eclipse, which is probably why there are projects which disallow .project/.classpath files (and not just Maven projects). I thought plugin-based projects were supposed to improve on that, but they don't seem to be there yet. But what would programming be, if we didn't have the option of shooting ourselves in the foot? Sounds fun. For some value of fun. True. But that would violate the foot-shooting principle. ;-) More consistency would be nice. -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat