10:04 a.m.
On 07/07/09 17:32, 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.
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.
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.
> 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 ?
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.
> 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.
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.
> 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...
Well, it is in the name of the manifest property...
> 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.
Great.
> 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 ;)
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