www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Aaron Farr <jaaronf...@gmail.com>
Subject Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Date Wed, 04 May 2005 14:16:12 GMT
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.


View raw message