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