Hi Milos, I agree, sharing plugins is nice because you can decrease the file size. Another drawback of having multiple private copies of the same jar is that you may run into class loading issues. In Eclipse, each plugin has its own class loader. And the same fully qualified class loaded by different class loaders are the considered different, therefore, you may run into collisions.
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] Milos Kleint <[EMAIL PROTECTED]> 05/03/2005 12:54 PM Please respond to general To [email protected] cc Subject Re: Proposal for a centralized Eclipse update manager site for Apache projects/software if I want to use commons-logging as a Netbeans module/Eclipse plugin (meaning my own module/plugin references commons-logging codebase), then I need to bundle it myself a either part of my plugin or as a separate one. Having it as separate plugin has the advantage that multiple plugins can reuse the same classes just by declaring a dependency on the commons-logging plugin, whereas when I cobundle it as part of my plugin it's not reusable by others. actually maven should be able to generate eclipse plugin/netbeans module binaries for any given project. (the maven plugins for that are stored at mevenide.codehaus.org) Regards Milos kleint On 5/3/05, David Jencks <[EMAIL PROTECTED]> wrote: > I'm not really familiar with eclipse. Could you please explain what > advantages your proposal has over building your project with maven? > From your description I would guess that using maven as your build > system provides all the features you want with more automation. > > many thanks, > david jencks > > On May 2, 2005, at 1:00 PM, Jeffrey Liu 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
