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

[Sean Flanigan]

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