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

[Max Rydahl Andersen]

> 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. 
No, but it is the most critical one right now to get the plugins to load 
consistently for the user. The second one is to get version boundaries 
on our dependencies.
> 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.)
Yes, but that is what shared development means ;) Similar thing would 
happen if we used ant or maven to build things - and no it wouldn't get 
clobbered, svn update would just merge it and when you commit you review 
your changes first, right ?
> 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.
Well I think Eclipse is really bad at this scenario - they should have 
named settings that could be saved in a project and then others can 
refer to them IMO.
> 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() {}
> };
>
>
> 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.
hmm - don't tell me this now ;) How can they be so....wrong...
> 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.
Yes, I'll look into this.
> PS I'm changing my JBT workspace settings to use 1.5 compliance now! 
You should use Java 5 to compile with anyway to be sure users can run 
our stuff on the supported VM for EAP ;)

/max