Hi Mark, Thanks for the clarification. If I understand it correctly, this means potentially I can put plugin distributions into this repository, host a site.xml file somewhere and point to these plugin distributions? Also, this is probably a dumb question, but I'll ask anyways. Who is responsible for putting these release distributions into this repository? Individual projects? Is this done automatically (each build/release)?
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] Mark Diggory <[EMAIL PROTECTED]> 05/03/2005 03:58 PM Please respond to general To [email protected] cc Subject Re: Proposal for a centralized Eclipse update manager site for Apache projects/software Slow down, to clarify, the repository is not just for "Jar's", it is for any release distributions. An Eclipse plugin for, lets say, Ant, would be a distributable, just like any other binary or src distribution in the repository. In Eclipse, a plugin archive is "poorly" prefixed with the extension "jar", it is really a zip archive containing everything for that plugin (from what I understand, this will change in the future and it will truly be a jar, but that is an aside). The repository can hold these files and referencing them using a site.xml could happen from just about anywhere else (such as the project website). -Mark Diggory Jeffrey Liu wrote: >Hi Dion, > >Thanks for your response. The existing repository won't work. Unlike a >Java application, putting JARs on the classpath is not sufficient to make >Eclipse aware of these libraries. Eclipse needs to work with something >known as an Eclipse plug-in, which is really the JARs themselves plus a >couple XML configuration files. So, in order to make use of the Eclipse >update manager, we need to bundle the JARs, the XML configuration files >and other files such as license/readme/etc together in the form of an >Eclipse plug-in. > >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] > > > > >Dion Gillard <[EMAIL PROTECTED]> >05/03/2005 10:33 AM >Please respond to >general > > >To >[email protected] >cc > >Subject >Re: Proposal for a centralized Eclipse update manager site for Apache >projects/software > > > > > > >Is there a reason we can't reuse the existing repository at >http://www.apache.org/dist/java-repository/ ? > >In your example, Eclipse could be configured to check >http://www.apache.org/dist/java-repository/axis/jars/ for an update? > >On 5/3/05, Jeffrey Liu <[EMAIL PROTECTED]> wrote: > > >>Hi, >> >>I want to propose a centralized Eclipse update manager site for Apache >>projects/software. This may not be the correct place to ask this, but I >>can find a better place to do it, so I decided to start here. If this is >>not the right place, can somebody point me to the correct location? >>Thanks! Reason I propose an Eclipse update manager site for Apache >>projects/software is because Eclipse projects such as the Web Tools >>Platform (WTP) project often reuses software that are provided by >> >> >Apache, > > >>for example, Axis, Tomcat, Derby, etc... Often times, these Apache >>software are not redistributed by the Eclipse projects, but instead, >> >> >they > > >>are listed as prerequisites. This means, end users must first download >> >> >the > > >>Eclipse project and all the Apache software prereq by the project, and >>configure these software in the Eclipse project before they can get >>started. This is error prone and hampers the out-of-the-box experience. >>Imagine the following scenario: >> >>A user downloads WTP. Unzip it and starts it up. S/he wants to create an >>Axis Web service. S/he launches the wizard that creates a Web service, >> >> >but > > >>finds out s/he needs Tomcat and Axis. So s/he opens up her Web browser, >>goes to the Apache Web site and looks for the download page for Tomcat >> >> >and > > >>Axis. S/he downloads and unzips Tomcat and Axis to the file system. Goes >>back to WTP and manually configures Tomcat and Axis into her workspace. >>S/he launches the wizard again and move on. >> >>This is easier than said. If there's an Eclipse update manager site for >>Apache software, then when the user finds out s/he needs Tomcat and >> >> >Axis, > > >>all s/he needs to do now is launch the Eclipse update manager (URL to >> >> >the > > >>Apache update site will be preloaded), select Tomcat and Axis and click >>Finish. The Eclipse update manager will download, install and configure >>Tomcat and Axis automatically. This is much better than asking the user >> >> >to > > >>download and configure things manually. Also, this Eclipse update >> >> >manager > > >>site is very useful when new versions of a Apache software is available. >>For example: >> >>Say Eclipse WTP 1.0 ships with Axis 1.2 support. If later on, Axis >>releases a critical fix for Axis 1.2's WSDL2Java emitter, then without >> >> >an > > >>update site, we'll need to do one of the following... >> >>1. Rebuild WTP 1.0 with the Axis fix >>2. Ask users to manually update WTP >>3. Wait for the next version of WTP. >> >>None of the above sound attractive. If there's an Eclipse update manager >>site setup for Apache, then end users can search and install new updates >>automatically by making just a few clicks. I believe this advances the >>integration between open source software that are provided in different >>domains (Apache, Eclipse, etc). I think this can benefit the open source >>community and can grow the open source ecosystem. >> >>Do I need to propose a new Apache project for something like this? >>Suggestions/comments are welcomed. >> >>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] >> >> >> >> > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
