Thanks for everyone's input on this. To clarify, it is the second set of dependencies that I am interested in. After reading up on many of the advises posted here, I agree that there's no need for another repository. The question now becomes whether ASF should host these plugin distributions, and if so, what the structure would be. Jaaron, may I ask what are your concerns with ASF hosting these plugin distributions? As suggested by Mark earlier, the goal here is not to require all projects to provide such plugin distribution. It remains a project decision to provide this or not. But it would be nice to see the projects that are already being used in Eclipse to take the lead on this. Btw, is there any rules that govern what a project can drop or not drop into the respository?


Jeffrey Liu


05/04/2005 10:16 AM

Please respond to

Re: Proposal for a centralized Eclipse update manager site for Apache projects/software

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.


Reply via email to