Trying to locate an unresolved plug-in dependency can be strenuous and time-consuming. Almost every plug-in depends on a bunch of other plug-ins, and those plug-ins, in turn, may depend on many more. This article shows you how to resolve plug-in dependencies more quickly by automating their discovery.
Plug-in’s that depend on other plug-in’s has to be the worst thing coming out of the Eclipse camp so far.
I thought the whole point of using plug-in’s was to put specific functionality in them that directly extend the program they are made for without relying on anything other than the core program.
If you let plug-in’s rely on plug-in’s that can rely on other plug-in’s you end up with a big unmaintainable mess.
Another nail in the Eclipse coffin.
So you think any Linux distribution is a big mess? Packages in Linux are exactly like Eclipse plugin’s, they all depend on each other.. It’s called modular design..
So… Did you just say that GNU/Linux is a dependency hell?
Isn’t this exactly what people like you complain about when it comes to Windows?
With a modular design you would be able to remove or add stuff one by one without getting lots of unneeded extras to go with it. Extras that might pose a security problem at the worst.
I find it difficult to comprehend your reasoning that dependency hell implies modular design.
The dependency problem is not huge, only a handful of plugins rely on other plugins.
The main dependency problems usually root into different GEF and Webtoolkit vertsions used by extended plugins.
It currently is not possible to mix Exadel with MyEclipse due to such problems, but that one is pretty much the only realy dependency problem I am aware of, because both plugins rely heavily on WTP and other plugins.
The dependency problem usually is even less worse than in Windows the dll dependency problem or in Unix the library version dependcy problem, because usually a plugin shuts itself off if it cannot find or install the correct dependeny jars.
will have to happen, eventually, if java is used in very complex multi-platform, multi-language applications (like it is in eclipse, where you have both native (DSO) and java components). Don’t worry, that problem has been mostly solved for C & C++, so it will be eventually solved for Java as well.
My current guesstimate is that it will be addressed in the Java 7 JSRs by JSR 277. So far, the OSGi platform, used by eclipse for that purpose, seems to be going in the right direction, and attacking the right problems.
For another attempt to make Java components more manageable in complex deployment scenarios, see maven’s idea of POMs, used to explicitely label dependencies, and online repositories.
Both Richard & Jason are on the JSR 277, btw. That’s the only interesting JSR to watch atm, afaict.
For the wrong way to go about it, see the current method of the JCP to whack any possible JAR right into J2SE, that some vendor in the EC might find useful. That does not scale that well in the long run, as J2SE shows.
For how it’s done right with traditional languages, see DSOs and Debian’s apt. Also see .net assemblies, some of the idea there are pretty nice.
Many Java developers are currently apparently solving problems that can be solved with the “lets whack together semi-random binary blobs into one big binary blob and ship that” mindset, where C developers used to be stuck in the 80s. That does not mean that the increasing complexity of problems they are trying to solve with Java will not lead them to disover better ways of handling the increasing complexity of their open source dependencies.
Statically linking in Motif is soo last century, after all
cheers,
dalibor topic
is a viable approach given the current java infrastructure. The reason for this is that everything
has to be loaded by a classloader anyway.
That way you can whack mutliple libs redundandly into a single war, and all you sacrifice is some ram, because the class loader treates them independendly anyway, but not too much because not the entire lib is loaded, just the classes really used.
I am not sure whether eclipse does similar class loader handling, but I think the main problem arises from plugins which do not integrated the needed dependency classes themselves but rely on some dependency plugins within the plugin infrastructure (which normally is only a handful anyway)
c mhnlv bbg, h ,x v n, v mj , c