Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of mdiggory@gmail.com designates
 64.233.170.198 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=WYhv2HDKQWrGrKAOrwvjvQ4E+Lgkj8Hf3fM6Ua3Fn99uLA2gvwQZdWpuNlOeq05bjoZIFL4++WhHTwlBaNGkpJKfiN6cRvAVY3SMpWRmjNFv2gvznlSrg61AW5/tr420HNgroAffmrT8y034/3gJYZef8katcxHiohARjOqih/Q=
Message-ID: <4277D7C9.1010604@gmail.com>
Date: Tue, 03 May 2005 15:58:01 -0400
From: Mark Diggory <mdiggory@gmail.com>
Reply-To: mdiggory@apache.org
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: general@incubator.apache.org
Subject: Re: Proposal for a centralized Eclipse update manager site for Apache
 projects/software
References: 
 <OF9ED6D8FE.63ABB59D-ON85256FF6.005529FB-85256FF6.0056CCA4@ca.ibm.com>
In-Reply-To: 
 <OF9ED6D8FE.63ABB59D-ON85256FF6.005529FB-85256FF6.0056CCA4@ca.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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