- This topic has 23 replies, 8 voices, and was last updated 17 years, 10 months ago by
.
-
Posts
-
I recently istalled the latest version of MyEcilpse. After that I tried to itstall the Visual Editor (VE) which failed with some confilts, I believe, with GEF libraries. If I remove MyEcilpse the VE installs and functions properly. Perhaps you are making the wrong assumbpiton that whoever uses MyEclipse (enterprise development) will not use VE (client developement). I know that you try to make it easly for the clients of MyEclipse as far as installation is concerned but and bundle the GEF and whatever else is required for its functionality with MyEclipse. Howere, I believe the correct approach would be to specify which versions of the standard components are required for MyEclipse and not bundle them or at least give an alternative package without them. I believe the conflicts will be easier to avoid this way.
In any case, please advise how to deal with this situation.
Thanks.vladchuk,
We ship the final releases of EMF/GEF and JEM all with myEclipse 4.0 for the express purpose of being compatible with VE 1.1 release, from a handful of our users that use that release they said everything works great.Can you verify that youa re using the latest stable release of VE? Unfortunately plugin version conflict is a reality with an integrated platform like Eclispe, and us not shipping compile-time and runtime dependencies for our product isn’t possible, as is the case with many other Eclipse-based products, so this is just a growing pain we all have to learn to work around, I know it can be frustrating.
vladchuk,
I’m using MyEclipse 4.0GA and VE 1.1 together and from everything I’m seeing they work great together. Are there any *other* plugins you have installed with those that might be causing this problem? Are you also trying to install the GEF libraries (that would be bad – since MyEclipse comes with that stuff)..?
I do not exclude the possibility that there might be an error in my configuration. However, when I remove MyEcilpse, install EMF, GEF, etc. and the latest version of VE it works fine. I will try again and try to gather more information.
@vladchuk wrote:
I do not exclude the possibility that there might be an error in my configuration. However, when I remove MyEcilpse, install EMF, GEF, etc. and the latest version of VE it works fine. I will try again and try to gather more information.
I would recommend creating a *brand NEW* Eclipse installation. Install MyEclipse 4GA into *that*. Start it (with a new workspace) and make sure everything appears to be working. Then install VE 1.1 into *THAT* Eclipse directory. Start MyEclipse again.
You should be fine.
Putting in and pulling out JEM/GEF and MyEclipse into the same Eclipse installation is just begging for pain and misery. You can never be sure you really removed all of one set of libraries or the other. This is one of my really big gripes about the Eclipse paradigm.
Putting in and pulling out JEM/GEF and MyEclipse into the same Eclipse installation is just begging for pain and misery.
Dave is exactly right with this statement. That is why both our automated installers and our manual install instructions will install all of our plugins and features into a separate location, *not* into the base Eclipse installation (like most other plugins) because that just creates an unmanageable mess.
However, when I remove MyEcilpse, install EMF, GEF, etc.
This is likely the problem since both MyEclipse and VE bundle the correct (and same) versions of EMF/GEF etc. Manually installing other copies yourself is not needed and is likely causing the problem you’re experiencing. If you follow Dave’s instructions, you’ll get a working installation quickly.
I installed MyEclipse4.0 when Eclipse 3.1 was installed with VE. I received the error when trying to access the JSP editor:
org.osgi.framework.BundleException: The activator org.eclipse.emf.common.CommonPlugin$Implementation for bundle org.eclipse.emf.common is invalid
That error and this forum discussion led me to reinstall Eclipse 3.1 without VE and everything now works.
Was there info somewhere for people with a similar installation as mine to reinstall 3.1 if VE and EMF was already installed? I assume if I install VE it will work with the EMF that is installed with MyEclipse. Perhaps the MyEclipse install should recognize EMF is already installed and use that?Was there info somewhere for people with a similar installation as mine to reinstall 3.1 if VE and EMF was already installed?
We mentioned the dependent library updates and why a full reinstall was necessary in this announcement for 4.0:
http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-8781.htmlI assume if I install VE it will work with the EMF that is installed with MyEclipse. Perhaps the MyEclipse install should recognize EMF is already installed and use that?
The issue isn’t that it was previously installed, but rather that is tagged as the same version but contains API changes introduced by the Eclipse team so it is incompatible. Please see the previous thread for the full explaination.
Do we have a HOWTO that tells people what exactly to do and install in what specific order to make VE work with MyEclipse?
1) Install Eclipse
2) Install MyEclipse
3) Install VE (NOT the EMF/GEF or JEM dependent libraries)Steps 2 and 3 can be interchanged. Although if you do 3 first, VE won’t work until you do 2, because MyEclipse ships the dependent libs it needs.
This is a larger problem which is going to cause pain and misery for anyone using MyEclipse with other producs (not just VE). I realise this is a Eclipse platform issue, but I’d like to discuss this further in this forum to get a set of guidelines that everyone can benefit from. For example, we have a custom plugin that requires GEF 3.1 to be installed which is also used by MyEclipse. My question is:
1) Do you modify in any way GEF, EMF and JEM plugins that you bundle and do the version numbers correspond to the current stable releases by Eclipse.org with the same version number ?If yes, then how do you propose larger organisations manage MyEclipse distribution so that it lives happily alongside other products ?
Options that I can see:1) If you bundle unchanged versions of outside dependencies then those dependecies can be provided outside of MyEclipse (eg local update site) and MyEclipse can be distributed minus those dependecies – we use local update sites so with combination with E3.1 dependency checking when using update sites MyEclipse will install fine as it would pull in the dependencies it needs (assuming correct dependecy versions were supplied) – this would eliminate plugin conflicts.
2) An installation of MyEclipse could be installed with all dependencies in a seperate directory and installed in a configuration by either the link or add extension location methods. Can’t use a local update site (or any update site) for this – not a nice way to manage MyEclipse install for multiple users.
You seem to be suggesting option 2) is the way to go – can you comment on your oposition to option 1) – why not provide a distribution with dependencies and without dependencies to suit ?
Also, the new recommended practice for distribution of Eclipse 3.1 plugins is as jars which greatly reduces the number of files – can you comment on when is MyEclipse going to adopt this ? Are there any technical issues standing in the way ?
Providing all plugins as jars would also make it much easier for your customers to set up their own update sites it then wanted to 🙂 – for the purpose of option 1) above.Regards,
Bernard Cena1) They are all straight drop ins from the eclipse.org site, we realize that with those plugins conflicts/duplicate deps are extremely likely, so we know that we can’t change them at all unless we want to have tons of broken plugins on our hands.
Fine – thanks for confirming that EMF, GEF, VE plugins are unchanged.
Can you comment on my other questions ?
Why don’t you distribute plugins as jars ?
How about providing a distribution minus dependencies ?
Comments on your plans/strategy re update sites ?Why don’t you distribute plugins as jars ?
Many of our plugins have external library dependencies and jarred plugins don’t support them. That’s why things like the Ant plugin in the core distribution aren’t shipped as jars.
How about providing a distribution minus dependencies ?
Because we’d still be required to support it and this allows one less place for problems as well as providing a one-stop-shop for installation for our users. The vast majority of our users like not having to keep up with all the various builds of all the base technolgoies and would rather we shield them from that by simply supplying “what works”.
Comments on your plans/strategy re update sites ?
No change in policy: we’ll provide an update site whenever it is technically possible to do so. For 4.0GA it simply was not for the reasons detailed here: http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-8781.html. For future updates to 4.0 we anticipate being able to provide an update site for all of them at this time.
