You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Dion Gillard <di...@gmail.com> on 2005/05/03 16:33:51 UTC
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 <je...@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
>
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Milos Kleint <mk...@gmail.com>.
it would be nice to have a similar feature for Netbeans.
Milos Kleint
On 5/3/05, Jeffrey Liu <je...@ca.ibm.com> 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 <di...@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 <je...@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
> >
> >
>
> --
> http://www.multitask.com.au/people/dion/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by "Mark R. Diggory" <md...@apache.org>.
Jeffrey,
Yes as they pointed out I'm moving our responses to the thread to the
repository group.
Each project is responsible for their repository contents. So, from this
standpoint, if you took Axis for example, the Axis group would be
responsible for managing the release of any Axis Eclipse plugin
artifacts into the repository. Now, the benefit (or burden) of this is
that Axis gets canonical control of managing the distribution of such a
plugin and can maintain authority of its release cycle. So ultimately,
you should hop onto the Axis list and start a discussion there
concerning if they are interested in maintaining the plugin.
Some important facts about the repository.
1.) The repository under www.apache.org/dist/java-repository is only for
full releases of apache projects (not nightly/integration builds).
2.) Its is not advised that you point users directly at the above url,
but go through any of the many Apache mirrors.
3.) All released artifacts should be signed by author using both PGP and
MD5 signatures.
In regards to (2), I'd be interested in seeing how the new mirrors
feature of the Eclipse update manager can handle this gracefully.
Jeffrey Liu wrote:
>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 <md...@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 <di...@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 <je...@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
>
>
>
>
>
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by Mark Diggory <md...@gmail.com>.
Jeffrey,
Yes as they pointed out I'm moving our responses to the thread to the
repository group.
Each project is responsible for their repository contents. So, from this
standpoint, if you took Axis for example, the Axis group would be
responsible for managing the release of any Axis Eclipse plugin
artifacts into the repository. Now, the benefit (or burden) of this is
that Axis gets canonical control of managing the distribution of such a
plugin and can maintain authority of its release cycle. So ultimately,
you should hop onto the Axis list and start a discussion there
concerning if they are interested in maintaining the plugin.
Some important facts about the repository.
1.) The repository under www.apache.org/dist/java-repository is only for
full releases of apache projects (not nightly/integration builds).
2.) Its is not advised that you point users directly at the above url,
but go through any of the many Apache mirrors.
3.) All released artifacts should be signed by author using both PGP and
MD5 signatures.
In regards to (2), I'd be interested in seeing how the new mirrors
feature of the Eclipse update manager can handle this gracefully.
Jeffrey Liu wrote:
>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 <md...@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 <di...@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 <je...@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
>
>
>
>
>
Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Again, please move this thread to the repository@ list. Thank you!
Erik
On May 3, 2005, at 6:07 PM, Jeffrey Liu wrote:
> 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 <md...@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 <di...@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 <je...@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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by Jeffrey Liu <je...@ca.ibm.com>.
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 <md...@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 <di...@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 <je...@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
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by Mark Diggory <md...@gmail.com>.
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 <di...@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 <je...@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
Re: Proposal for a centralized Eclipse update manager site for
Apache projects/software
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Jeffrey,
> 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.
So are you proposing a new project or some infra work to host another
repo with these jars+metadata? And then of course support/commitment of
various projects to put stuff into that repo.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal for a centralized Eclipse update manager site for Apache
projects/software
Posted by Jeffrey Liu <je...@ca.ibm.com>.
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 <di...@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 <je...@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
>
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Proposal for a centralized Eclipse update manager site for Apache projects/software
Posted by "Noel J. Bergman" <no...@devtech.com>.
Dion Gillard wrote:
> Is there a reason we can't reuse the existing repository at
> http://www.apache.org/dist/java-repository/ ?
And for further discussion, please use repository@apache.org.
--- noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org