- This topic has 3 replies, 2 voices, and was last updated 17 years, 3 months ago by
.
-
Posts
-
Many of the plugins provided by MyEclipse depend upon various open source projects and libraries. Unfortunately, this causes MyEclipse to be bloated; each plugin depends on particular versions of these libraries, and MyEclipse doesn’t touch what each plugin provides. For example, both the Hibernate and Spring plugins in 5.1.1GA use versions 2.7.5H3 of Antlr, and the Hibernate plugin depends on another version too. There are 9 versions of commons-digester in the plugin directory.
Could Genuitec create library plugins that contain these jar files or related groups of jar files? Suppose someone created a plugin named org.myeclipse.antlr.2.7.5H3. Then the Hibernate and Spring plugins could depend on the antlr plugin, and some space would be saved. It would be a good way to integrate ANTLR documentation; one would have an antlr feature containing a library plugin and a doc plugin.
Furthermore, could Genuitec see whether all the plugins would work with only one version of antlr (or commons-lang, or jaxb-impl)? I doubt that we need three different betas of Jaxen in the system.
I don’t suggest that anything be broken, but I’d like to see MyEclipse be more efficient.
Eric,
I could not agree with you more about reducing bloat caused by the various libraries. We have some ideas to greatly reduce the product footprint in the near future. The solution we are considering will make it possible for users to install/uninstall/update the library sets. As for reducing redundant jars between frameworks that is much harder problem to tackle. Sharing jars between frameworks would put MyEclipse on a large maintenance path to keep up with changing frameworks, not to mention liability for potential problems that may arise. The Eclipse organization has had this problem (e.g., there were 8 versions of apache xerces in the codebase at one time) and is working to consolidate common libraries between plugins. We are monitoring that project as well as pursuing a library management strategy that I referred to earlier. Thanks for you comments.
Regards,
How often does upgrading a library break a module?
It seems to me that MyEclipse could do well for itself if it could create binary, source, and documentation plugins for the popular Java libraries; people writing RCP projects would love to have canned features for their tools. Perhaps the latest OSGi initiatives will encourage developers to vend libraries so they can just be dropped into Eclipse, but I’m not holding my breath.
Here’s a case in point. I’ve just installed 6.0M1, and I’m working on a demo project using the Rome RSS library. That library requires JDOM 1.0, which I downloaded. I decided to check if MyEclipse had it, though, and it does seven times, five with a _1.0 suffix.
Instead of adding yet another jar to my project, I’d like to add one of the existing copies in, perhaps by extending a variable location on the Libraries tab of the project’s Java Build Path page. However, none of the variables points to a parent directory. So, I would have to point to the jar file myself, and accept the probability that an update to MyEclipse will break it.
I also noticed that the JSTL 1.1 jar files and some of the Struts 1.3 jar files do not come with Javadoc attachments, while the struts-* files do. I suggest that every open-source jar file used by MyEclipse have Javadoc and Source attachments designated for them. I would even prefer that the Javadoc and source be bundled with MyEclipse. Of course, I can modify things by hand, but it just seems like the right thing to do.
