Re: [jbosstools-dev] Cleaning up manifest.mf's
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