On Fri, Aug 22, 2008 at 1:33 PM, Dmitri Girski <[EMAIL PROTECTED]> wrote:
> > Dude, what's the hassle? You install a plugin for Eclipse, point the > plugin > > at the BC executable and you're off... > > I just like when everything works. It worked before, now it is broken. > And surprisingly, I am not happy with this fact, as instead of doing > what I used to do I have to find some workarounds. Nope, That's how Eclipse and Beyond Compare have always interacted, through a plugin. It's not a workaround, it's using the builtin capabilities of the platform to add functionality. The same way it's able to work with mxml and actionscript. Do you think that Eclipse comes with code-hinting for MXML? No, it's there because some bright Java programmers used the innate functionality of Eclipse to allow it to do more than the stock distribution. > All I'm saying is that you should lay the blame where it really > belongs. It's not like Adobe wrote the Compare functionality in FB3, > they're using > > So, when your car breaks, do you call directly Bosch AG and ask why > this bloody alternator stopped working? I think you would simply send > your car to the dealer you've bought the car from. :) No, but that's irrelevant as we're not talking about my Passat, we're talking about Flex Builder and Eclipse. > FB is not a just an Eclipse & Flex SDK tied up together. Look at the > Adobe bugs db - there are hundreds and hundreds of bugs just for the > Builder itself. Never said it was just the two things mashed together. I'm sure there are issues with the code from Adobe. But those are the things that deserve to be logged in the Adobe bugs db, not stuff about code they didn't write. To turn your analogy around, if I use Flex Builder to write Java code and I have an issue there, should I harangue Adobe about it? No. I should send the issue to the Java EE team at the Eclipse Foundation. -- Howard Fore, [EMAIL PROTECTED] "The universe tends toward maximum irony. Don't push it." - Jeff Atwood
