I echo David's sentiments on this. I'd be interested to know what is in the eclipse metadata you want to attach to the various artifacts in the repository, and whether any of it coincides with existing metadata formats in use here, such as the following for parts of jakarta commons:
http://www.apache.org/dist/java-repository/commons-logging/poms/commons-logging-1.0.4.pom http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-commons.xml I don't think this is a question of a new repository, but rather what we can do to the existing one to better support what you are trying to achieve. On a side note, there is another Maven repository outside of Apache that automatically collects all of the ASF data as well as some other open source projects and manually requested inclusions at http://repo1.maven.org/maven/ Cheers, Brett On 5/4/05, David Jencks <[EMAIL PROTECTED]> wrote: > 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. > > thanks > 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. > > > > 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 > > > >
