When upgrading from our product from 3.3 to 3.6.1 (finally got the green light from managers after some fights),
I've run into a this regression..
basically Compare framework does not seem to work with non-textual/non-steam input any more, ContentMergeViewers are not created as they should.

Added several comments to clarify -> got no response yet. - am unsure if some is looking it at all. Is there a better place to push this forward (mailing list, another forum, IRC, raise another bug, tagging, etc...)?

Is there a way that this patch be included 3.6.2 (out soon as I understand).
No pressure:) but ... I would much prefer to upgrade to an official Eclipse version than having to build a custom patch.

Il 01/02/2011 03:16, Gergely Nagy ha scritto:
> Added several comments to clarify -> got no response yet. - am unsure if
> some is looking it at all. Is there a better place to push this forward
> (mailing list, another forum, IRC, raise another bug, tagging, etc...)?

I think the best is to keep on posting comments on that bug until
someone replies...

On 2/1/2011 5:08 PM, Mauro Molinari wrote:
> Il 01/02/2011 03:16, Gergely Nagy ha scritto:
>> Added several comments to clarify -> got no response yet. - am unsure if
>> some is looking it at all. Is there a better place to push this forward
>> (mailing list, another forum, IRC, raise another bug, tagging, etc...)?
>
> I think the best is to keep on posting comments on that bug until
> someone replies...
>
> Good luck!
> Mauro.
Yep, you can ping on the bug once a week. Someone will respond..

The only thing is I'd really like this to happen within 3.6.2, otherwise I'd have to either build my own patched org.eclipse.compare bundle, or wait at least another year (actually this is not really an option).

Is there a clean way to deploy patches with these 1-line kind of fixes into my app? I understand fragments might work but that's not a reliable way.
Should I just import it into Eclipse, add fix, change version (qualifier?) rebuild, export plugin from Eclipse, and replace old jar in the app with the new one?

On 2/1/2011 7:04 PM, Gergely Nagy wrote:
> Thanks for the replies hint - I'll try that :)
>
>
> The only thing is I'd really like this to happen within 3.6.2, otherwise
> I'd have to either build my own patched org.eclipse.compare bundle, or
> wait at least another year (actually this is not really an option).
The next release - 3.7 - will happen in June, so the wait is not a year :)

> Should I just import it into Eclipse, add fix, change version
> (qualifier?) rebuild, export plugin from Eclipse, and replace old jar in
> the app with the new one?
Sure you can do this, but note that if you change the version you also
have to fiddle with p2 to get it to work. But if you keep the same
version and then replace the old jar, then things should work just fine.

On 2/1/2011 7:04 PM, Gergely Nagy wrote:
> wait at least another year (actually this is not really an option).
The next release - 3.7 - will happen in June, so the wait is not a year
.

Ok, well as an ISV I prefer to wait for SR1-2 to get less bugs to hack around

Quote:

> Should I just import it into Eclipse, add fix, change version
> (qualifier?) rebuild, export plugin from Eclipse, and replace old jar in
> the app with the new one?
Sure you can do this, but note that if you change the version you also
have to fiddle with p2 to get it to work. But if you keep the same
version and then replace the old jar, then things should work just fine.

Good point, although I managed to avoid the P2 minefield so far. Just overwriting existing jar with no version change sounds dirty and dangerous too.
Any guidelines, best practices for patch versioning?
Thanks.

On 2/2/2011 3:01 AM, Gergely Nagy wrote:
> Quote:
>> > Should I just import it into Eclipse, add fix, change version
>> > (qualifier?) rebuild, export plugin from Eclipse, and replace old
>> jar in
>> > the app with the new one?
>> Sure you can do this, but note that if you change the version you also
>> have to fiddle with p2 to get it to work. But if you keep the same
>> version and then replace the old jar, then things should work just fine.
>
> Good point, although I managed to avoid the P2 minefield so far. Just
> overwriting existing jar with no version change sounds dirty and
> dangerous too.
> Any guidelines, best practices for patch versioning?
> Thanks.
The right way is to go via p2 - the export wizard also lets you install
into the host eclipse (though I have not tried this option to install a
plugin into another eclipse installation).

Overwriting the existing jar is just a quick and dirty way, but not
dangerous ;-)

On 01.02.2011 22:31, Gergely Nagy wrote:
> Deepak Azad wrote on Tue, 01 February 2011 09:50
>> On 2/1/2011 7:04 PM, Gergely Nagy wrote:
>> > wait at least another year (actually this is not really an option).
>> The next release - 3.7 - will happen in June, so the wait is not a
>> year :)
>> .
>
> Ok, well as an ISV I prefer to wait for SR1-2 to get less bugs to hack
> around
>
> Quote:
>> > Should I just import it into Eclipse, add fix, change version
>> > (qualifier?) rebuild, export plugin from Eclipse, and replace old
>> jar in
>> > the app with the new one?
>> Sure you can do this, but note that if you change the version you
>> also have to fiddle with p2 to get it to work. But if you keep the
>> same version and then replace the old jar, then things should work
>> just fine.
>
> Good point, although I managed to avoid the P2 minefield so far. Just
> overwriting existing jar with no version change sounds dirty and
> dangerous too.
> Any guidelines, best practices for patch versioning?
See http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse. pde.doc.user/guide/tools/project_wizards/new_feature_patch.h tm