Before the conversation continues on a little, I think we need to clarify how things work in Eclipse.
First off, there are two types of dependencies in Eclipse. One is the traditional IDE project dependency. For example, let's say I'm developing a Struts application. I'll need the Struts jars and a couple Jakarta Commons jars and whatnot in my classpath. From what I understand of Jeffrey's proposal, it isn't going to handle these sort of dependencies at all. Instead, if you wanted to use the ASF's java-repository, you would end up using Maven and either run "maven eclipse" to configure the dependencies or use one of the couple Eclipse plugins for Maven such as Mevenide to do essentially the same thing. Point is, these are not the dependencies you are looking for. Move along... :-) The second type of dependency is internal to Eclipse. They are inter-plugin dependencies. For example, suppose I have an Eclipse plugin that uses Derby as an embedded database. I can either include the derby jars in my own plugin, or I can wrap the Derby jars into a second plugin and then make my plugin dependent on the Derby plugin. If I choose this split route, then if there is some bug fix update to Derby then the users of my plugin don't have to wait to get the bug fix until I release an update to my plugin. Instead, they can directly (even automatically) update their Derby plugin independently. As David pointed out much earlier in this thread, there is a bit of a risk when users start updating these dependencies on their own, but Eclipse provides a versioning mechanism for plugin which can mitigate this concern. As a plugin developer, if I know these ASF Eclipse plugin wrapped releases exist, then I can use them instead of directly including them in my own plugin. To truly take advantage of them, I might have to include some code in my plugin, but no special Eclipse code would be required in the ASF plugin. If I'm reading Jeffrey's proposal correctly, it's this second set of dependencies he is interested in. Accomplishing this would still require some work by a release manager to properly wrap up the jars along with the Eclipse plugin metadata. However, most of the work would be done my other plugin developers who were interested in taking advantage of these ASF plugins. I'm not certain that having the ASF host these plugins is really the right approach, but at least we should be clear that the proposal is not about IDE project dependencies. -- jaaron
