From owner-freebsd-eclipse@FreeBSD.ORG Tue Aug 30 18:53:28 2005 Return-Path: X-Original-To: freebsd-eclipse@freebsd.org Delivered-To: freebsd-eclipse@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6C2116A41F; Tue, 30 Aug 2005 18:53:28 +0000 (GMT) (envelope-from vizion@vizion.occoxmail.com) Received: from lakecmmtao04.coxmail.com (lakecmmtao04.coxmail.com [68.99.120.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 691CB43D48; Tue, 30 Aug 2005 18:53:28 +0000 (GMT) (envelope-from vizion@vizion.occoxmail.com) Received: from dns1 ([64.58.171.82]) by lakecmmtao04.coxmail.com (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20050830185328.XANN3947.lakecmmtao04.coxmail.com@dns1>; Tue, 30 Aug 2005 14:53:28 -0400 From: Vizion To: freebsd-eclipse@freebsd.org Date: Tue, 30 Aug 2005 11:49:28 -0700 User-Agent: KMail/1.8 References: <200508301019.28780.vizion@vizion.occoxmail.com> In-Reply-To: <200508301019.28780.vizion@vizion.occoxmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508301149.28769.vizion@vizion.occoxmail.com> Cc: Greg Lewis , Herve Quiroz Subject: Re: How should eclipse be organized in the ports tree? X-BeenThere: freebsd-eclipse@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "FreeBSD users of eclipse EDI, tools, rich client apps & ports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 18:53:29 -0000 On Tuesday 30 August 2005 08:26, the author Herve Quiroz contributed to the dialogue on- Re: How should eclipse be organized in the ports tree? Here is the second part >David, > >I pretty much agree with all that Greg already said but still there are >some facts I think you should be aware of if you actually wish to >improve eclipse support in the ports tree... > >On Fri, Aug 26, 2005 at 05:20:38PM -0700, Vizion wrote: >> >I'm not sure how thats an argument for creating a non-virtual eclipse >> >category. Would you care to explain? >> >> To hell with the pedantic label -- call it what you like - virtual or >> non-virtual what matters is the reality of access and support to the >> freebsd community that comes from the way in which we organize our files >> and install the client rich applications and tools. >> >> here is what I think would work: >> ports/eclipse/eclipse.v.x.xxx >> .................../eclipse.v.x.nnn >> ports/eclipse/plugins/puginlabel1 >> ports/eclipse/plugins/pluginlabel2 >> ................................/pluginlabelN >> ports/eclipse/misc/file1 >> ports/eclipse/misc/file2 >> ............................/fileN >> >> Scattering eclipse modules and plugins over the whole of the ports tree >> would, I believe, be both counterintuitive, counterproductive and >> confusing.ports/eclipse > >No tool, whatever its "usefulness", deserves to have its own ports tree >in the ports tree. That's indeed what you suggest in your message. The >way the ports tree currently works is somewhat well defined in many >locations (the Porter's Handbook mainly) and we, as commiters, tend to >ensure that the current ports system provides enough flexibility so that >no port would need some special treatment to fit in the ports tree. Does not flexibilty mean the system being able to meet the special needs of any individual port -- rather than the port having to adapted to meet the inevitably limited preconceptions of the system at the time of its conception? If the system was flexible then there would be no problem! Let see what we need and take it from there. Eclipse is a client rich application with nearly 300 plugin modules which is likely to have over 600 plugin modules within a year. Each plugin, in combination with the core, can (and often does) combine multiple functionalities (e.g it may combine the functionalities of a database, a browser, a language development environment and a network service). Modules may be dependent upon one another. Eclipse has its own internal mechanisms for handling those interdependencies. Is not the Freebsd ports hierarchy designed, from the base up, by seperating software on the assumption that the software can be categorized by functionalities? Is not the question how do we deal with archiving ports which conceptually conflict with the assumptions behind the original design. Or to put it the other way round, my question is how can we use the existing ports hierarchy to meet the needs of the new generation of client rich applications which eclipse represents? Eclipse represents a type of software development which did not exist at the time freebsd (or the ports) were being designed. How do we store 300 -600 plugins in the short term and make them easily accessible? How do we do that in a simple way? Eclipse has an inbuilt plugin import system. If all the plugins were organized in one directory then it would be possible to build a generic system which could use eclipse to load the plugins and reduce the amount of work needed to keep the eclipse hierarchy up to date. The only thing needed to make this work would be that only eclipse plugins should reside in the directory. Hence my suggestion /usr/ports/eclipse This directory would hold the eclipse core identified by version number and possibly a freebsd specific plugin which manages the loading of all remaining eclipse plugins /usr/ports/eclipse/plugins /usr/ports/eclipse/misc there is no reasomn why this hierarchy should not be: /usr/ports/xxxx/eclipse /usr/ports/xxxx/eclipse/plugins /usr/ports/xxxx/eclipse/misc I see practicle reasons for keep all eclipseplugins in a single directory hierarchy. david -- 40 yrs navigating and computing in blue waters. English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after completing engineroom refit.