Comment 1 Dani Megert 2005-03-28 12:03:49 EST

This is already on my not yet published M7 draft plan.

Comment 2 Dani Megert 2005-03-28 12:34:45 EST

*** Bug 89236 has been marked as a duplicate of this bug. ***

Comment 3 Dani Megert 2005-03-29 05:56:44 EST

This includes the adoption in the Java editor (see bug 89236).

Comment 4 Rafael Chaves 2005-03-29 17:00:25 EST

I thought I would mention: the usage of the extensions/filenames attributes in
the editor markup must be completely dropped as well.

Comment 5 Dani Megert 2005-03-29 17:07:25 EST

You mean if we use the corresponding content-type we have to drop the
extension/filename? This is OK. You do not refer to the extension points that we
provide, right?

Comment 6 Rafael Chaves 2005-03-29 17:13:45 EST

That is what I meant (extensions to the editor ext. point only). Extension point
providers are expected to provide both content type and legacy association
mechanisms. Extension providers that migrate to the new markup should drop the
old one (instead of using both mechanisms). This is not news, just wanted to be
explicit about that.

Comment 7 Rafael Chaves 2005-03-29 17:20:12 EST

I opened bug 89426 so the Java class file viewer can also be bound to a content
type.

Comment 8 Rafael Chaves 2005-05-18 11:09:08 EDT

What I say in comment 6 may be affected by the resolution of bug 91966.

Comment 9 Dani Megert 2005-05-18 11:54:23 EDT

The addition will look like this:

   <contentTypeBinding
      contentTypeId="type1"
      contentTypeId="type2"
      ...
   /> 

Comment 10 Dani Megert 2005-05-22 17:23:26 EDT

Fixed in HEAD.
Removed 'filenames' and 'extensions' attributes as told in bug 91966 comment 10.

Comment 11 Dani Megert 2005-05-25 18:12:05 EDT

.

Comment 12 Dani Megert 2005-05-30 06:07:13 EDT

start verifying

Comment 13 Dani Megert 2005-05-30 06:08:22 EDT

Verified in 3.1 RC1:
- plug-in xml associates text, Java and class files via content type
- text, Java and class file editor are correctly opened