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.

Thanks,

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
[EMAIL PROTECTED]



J Aaron Farr <[EMAIL PROTECTED]>

05/03/2005 04:34 PM

Please respond to
repository

To
[EMAIL PROTECTED]
cc
Subject
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 general@incubator.apache.org
> 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.

Jeffrey,

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.

jaaron

Reply via email to