incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Liu <jeff...@ca.ibm.com>
Subject Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Date Tue, 03 May 2005 22:07:15 GMT
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
jeffliu@ca.ibm.com




Mark Diggory <mdiggory@gmail.com> 
05/03/2005 03:58 PM
Please respond to
general


To
general@incubator.apache.org
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
>jeffliu@ca.ibm.com
>
>
>
>
>Dion Gillard <dion.gillard@gmail.com> 
>05/03/2005 10:33 AM
>Please respond to
>general
>
>
>To
>general@incubator.apache.org
>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 <jeffliu@ca.ibm.com> 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
>>jeffliu@ca.ibm.com
>>
>>
>> 
>>
>
>
> 
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message