After reading some of the discussion I'm still left with the impression that what you are proposing is very similar to maven's dependency management with the addition of some client side gui fluff. I repeat my request that you explain how it differs and why it should be supported on apache space. There may be very good reasons, but so far I can't tell what they are from your description.

As someone else pointed out, the repository can be used to distribute just about any kind of artifact. Exactly what do you want different from what the repository already offers? So far from your description I would guess, knowing nothing about eclipse, that what you are asking for is that all apache projects provide an eclipse plugin distribution version that is stored in the repository. Aside from the eclipse client side fluff, what do you want?

I also suggest that changing the versions of dependencies declared by a project without rebuilding it may not be something that it is advisable to support too heavily.

david jencks

On May 3, 2005, at 2:48 PM, Jeffrey Liu wrote:

Hi Jaaron,

Thanks for your inputs. The short answer to your question is, I'm not looking for full-fledged plugins that support the toolings around ASF projects. Developing a Tomcat plugin (like the one used in the Eclipse help's system) would be out of the scope of what I'm proposing here. You are right, what I'm proposing is simply a new mechanism (an update site) to distribute outputs (jars, etc...) from ASF projects. I do want to point out that such distribution mechanism is not limited to projects that fills Eclipse dependencies, it can also be applied to full-fledged plugins. For example, if one day, the Tomcat project decides to roll its own version of the Eclipse plugins. These plugins can be made available on the same update site. It's just that the development of this plugin will remind in the Tomcat project. This new update site that I'm proposing is an alternative, hopefully better (in the eyes of Apache/Eclipse users), way of distributing ASF projects.

I believe this new distribution mechanism will help both Eclipse plugin developers and end users. For example, in WTP, there's a Web app called the Web Services Explorer which allows you to query business/services/etc from an UDDI registery. This Web app uses Apache Axis as the underlying SOAP engine. As a developer, I would like the ability to update the underlying Axis engine without having to rebuild WTP. Reason is simple, if Axis releases a fix, without the support of an update manager site, there's no easy way to get this fix into the current version of WTP. I (and end users) will have to wait for the next release of WTP in order to pick up this fix. Since Axis and WTP run on different schedules, it would be a nightmare to manage what fix gets into what release..... For end users, this update site can improve usability as well. I'll reuse the example from the original post. Picture that a end user is trying to generate a Web service using WTP. The user finds out that s/he does not have Axis and Tomcat downloaded. So the user download them manually and configure them into the Eclipse workspace. Configure in this case requires the user to launch the preference page and point WTP to the location of Axis and Tomcat. New users will not know where to configure Axis and Tomcat unless s/he reads some documentation. Wouldn't it be nice if the WTP wizards detect that the user does not have Axis and Tomcat install, so it pops up a dialog telling the user what's going on, shows the license agreements to the user and install the Axis and Tomcat plugins automatically? Btw, another reason why WTP is not redistributing any ASF projects directly is because there are too many of them. Imagine WTP ships with Tomcat 3.2, 4.1, 5.0, 5.5... the download size would be huge and users do not want that. It's better to install things on the fly when it's needed. That's why I think end users will benefit from this update site as well.


 Jeffrey Liu
 IBM Rational Software - Performance Analyst
 IBM Toronto Lab.
 8200 Warden Ave. Markham, Ontario, L6G 1C7
 Internal mail: D3/R8V/8200/MKM (D3-268)
 T/L: 969 3531
 Tel: (905) 413 3531
 Fax: (905) 413 4920


05/03/2005 04:34 PM

Please respond to



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

Hello all.

 I'm also copying over this reply I made from [EMAIL PROTECTED]

On 5/3/05, Jeffrey Liu <[EMAIL PROTECTED]> wrote:
> Hi,
> This message was originally posted to the
> mailing list. Someone pointed out that such discussion should be carried out
> here instead. So I'm re-posting the original message here. Here it goes:
> I want to propose a centralized Eclipse update manager site for Apache
> projects/software.


 In thinking about your proposal more I've got a few questions:

 Are you looking for plugins that simply fulfill Eclipse project
 dependencies or full-fledged plugins that would, for example, allow
 you to launch Axis or Tomcat from within Eclipse?  If it's resolving
 dependencies, then I don't see how a plugin wrapper around the jars
 would do this without some Eclipse code to integrate into the
 development environment (WTP,PDE,JDT).  AFAIK providing just a plugin
 wrapper would only be useful for other plugin developers, not for a
 'end-user' developer who would happen to be using the WTP.

 Plugins which extend the IDE to use ASF projects such as a Struts or
 Tomcat plugin are already available via various third parties.  Are
 you suggesting the ASF should provide its own Eclipse plugins with
 similar functionality?

 The Eclipse project itself provides some ASF related plugins, most
 notably the Tomcat plugin used for Eclipse's help system.  Is this the
 sort of plugin you are looking for?  Likewise, Eclipse has started the
 new Lepido project for a Cocoon development environment.  Seeing that
 Eclipse already hosts ASF related plugins, is there any reason for the
 ASF to host a similar update site?

I can see some advantage to providing ASF releases in plugin form but only
for plugin developers, not for most Eclipse end users.


Reply via email to