[Stefan Baramov]

Hello MyEclipse Team:

I have just discovered today, that MyEclipse 2.6.3 comes with a modified version of these plugins:

org.eclipse.debug.core
org.eclipse.debug.ui
org.eclipse.jdt.debug
org.eclipse.jdt.debug.ui

Your version if 2.5.1 and the official is 2.1.1 or .2.1.2. So, your plugins will overload the original Eclipse Plugin.

First, I believe that forking the code of Eclipse is not a bright idea but of course this is my opinion. The CPL license does allow that, so this is okay.

Second, This cause certain inconvenience to me being a plug-in developer. In particular, took me about an hour and half to figure out why the eclipse source code does not match the stack trace. (I am debuging my own debugger 🙂 )

So, in this sence, I have a few questions:

1. Are you plaing to merge your changes with the main Eclipse branch?

2. Is your source code available and if so under what license?

Thanks,
Stefan

[Scott Anderson]

Stefan,

We had to make a few changes to those plugins in order to support source-level JSP debugging. We worked very hard to avoid modifying the Eclipse source, but it was impossible. We finally decided that the feature was too important to leave out so we went ahead with our mods.

Sorry for the confusion this caused you. Since MyEclipse is really for J2EE development, not for the use of plugin developers, we really hadn’t thought it would be an issue. Actually, I would have this same problem, since we also do a lot of J2EE consulting, so I just have two Eclipse installations, one with MyEclipse in it and one without. I think the same approach would probably avoid confusion on your side too. Just a thought. To avoid the problem going forward, we’re working with the Eclipse team to get similar modifications into the Eclipse 3.0 codebase, so it’s a very shortterm thing.

–Scott
MyEclipse Support

[Stefan Baramov]

Excellent!
This is what I wanted to hear. Adding those changes in the main 3.0 trunk is the right thing to do. And of course I agree that JSP debuging is major feature.

As of my problem, I solved in a very simple way. I changed my target environment. My target envirnonment used to be the same as my development environment. And that caused the comflict with the MyEclipse plugins. Now, my target environment is a completely standalone with no other plugins than the bare Eclipse Platform 2.1.1 and my own. This is excellent because it will allow me to upgrade to 3.0 and keep my target to be 2.1.1 or 2.1.2.

Thanks for the prompt reply.
– Stefan

P.S. And by the way, it may be helpful if you guys release the source code of your stuff. This will allow people like me to look at your stuff and provide better feedback. Just a thought. Oh … and I know that most your plugins are open source anyway 🙂

[Scott Anderson]

Stefan,

As of my problem, I solved in a very simple way. …. Now, my target environment is a completely standalone with no other plugins than the bare Eclipse Platform 2.1.1

That’s really the best way to develop plugins. It’s what we do also so that we can be sure that we don’t introduce some unforseen interaction with the additional plugins we may have installed in our development environments. Launching with just the platform only takes care of this nicely. That Eclipse PDE is really great.

Oh … and I know that most your plugins are open source anyway 🙂

Actually, that’s an apparently common misconception. It’s actually only about 30% integrated open source, currently. The largest piece of which is the XDoclet support that Hans Docktor originally wrote for JBoss IDE. All the core J2EE stuff (application server connectors, deployers, JSP editor / debugging), etc is all unique content. It’s really easy to tell what we get from open source, since we certainly don’t try to hide it, by looking at the number of plugins that don’t begin with com.genuitec.* or de.bb.*. You’ll quickly be able to tell what percentage is derived from open source. Naturally, the percentage will change over time but that’s basically where we are now. 🙂

–Scott
MyEclipse Support

[Author]

Posts