[jbosstools-dev] Cleaning up manifest.mf's

[Sean Flanigan]

On 07/07/09 09:16, Max Rydahl Andersen wrote:
>> b) we should remove .settings whereever possible since with1 and 2
>> from above it should no longer be necessary to set project specific
>> compiler options; and having them overriden per project just creates
>> confusion. Removing .settings will be my next cleanup - let me know if
>> you know of a good reason for keeping any .settings files around ?
> I've removed all jdt.core prefs since they just stated "use JDK 5" which
> is redundant in eclipse 3.5.
>
> There were also a few with NLS warnings enabled - should be enabled
> globally instead of per project I believe (Sean?)
>
> The only .settings left are those with encoding settings and some
> validator setup I don't know if is needed.
>
> Could those involved in these let me know if we can delete them or not ?

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