Date: Wed, 31 Aug 2005 01:27:47 -0600 From: Greg Lewis <glewis@eyesbeyond.com> To: Vizion <vizion@vizion.occoxmail.com> Cc: Herve Quiroz <hq@freebsd.org>, freebsd-eclipse@freebsd.org Subject: Re: How should eclipse be organized in the ports tree? Message-ID: <20050831072747.GC72699@misty.eyesbeyond.com> In-Reply-To: <200508301149.28769.vizion@vizion.occoxmail.com> References: <200508301019.28780.vizion@vizion.occoxmail.com> <200508301149.28769.vizion@vizion.occoxmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David, On Tue, Aug 30, 2005 at 11:49:28AM -0700, Vizion wrote: > 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. I wholeheartedly support the notion of greater eclipse support in the ports tree. I'm even happy to commit additional eclipse support as time permits. However, this is my last e-mail about this subject for the forseeable future as, to be blunt, e-mails on this subject don't seem to be productive. I'd much rather spend my time releasing patchset 2 of 1.5.0, but, since I would like to see Eclipse support get better I thought I'd try and offer some constructive criticism of your proposals. However, it seems to be falling on deaf ears, so I'm going to be as frank as I can in this e-mail. 1. You keep claiming that your proposal of adding an extra directory level to the ports tree, ports/eclipse/plugins/ has no impact. It does. As I've noted before, this has been discussed previously on freebsd-ports and there are currently _technical reasons_ why it won't work. I'm not going to look up all the references, please see the archives for those, but here is one from last October: http://lists.freebsd.org/pipermail/freebsd-ports/2004-October/017195.html 2. You clearly don't understand virtual categories. When I suggested one for eclipse you alternatively dismissed it or attacked me about it rather than either reading the Porters Handbook or admitting you didn't know what a virtual category was and asking about it. Please take the time to at least get familiar with things like this. 3. For some reason when Herve and I talk about the 20 or so Eclipse plugins that are _actually in the ports tree right now_, you take immediate offense and insist that there are 300+ Eclipse plugins. Yes there are many, many Eclipse plugins. But we're not talking about that, we're talking about how many are actually in the tree right now, and that is what people are going to see when you propose a big reorganisation (which you are, see point 1). Also, please don't insult our intelligence by insisting that the fairies will magically commit all 300+ plugins as ports overnight if we would only rearrange the ports tree how you think we need to. 4. You're proposing a radical departure for the ports tree. There are _no other applications_ which have their own non-virtual category. The bigger the change you propose, the more compelling and weighty your reasoning must be for it to be accepted. I would suggest that "Its got a lot of plugins that fall into different categories" isn't going to cut it. No, its not my call to make, I'm merely suggesting that I don't believe that people will find your current reasoning compelling enough. If I'm wrong, great, go ahead. If I'm not then perhaps you may want to spend some time coming up with answers to questions like "Perl has 1700+ modules already in the ports tree and it doesn't have its own non-virtual category, why should eclipse have one?". Maybe thats as simple as giving some reasons why that comparison is invalid, but whatever the case I'm merely suggesting you might want to give your argument some thought. 5. Please don't claim that you can't start working on improving Eclipse support because you have to fight a huge political battle at the same time. This isn't a political discussion and never has been. You've put forward a proposal, you must be willing to clarify or modify it when people raise technical and resource concerns regarding it. When you either dismiss these concerns or answer them with clearly incorrect technical data while crying political martydom all it does is piss people off. Finally, its great that you want to improve Eclipse support. I wish you success with that endeavour if you choose to pursue it and hopefully I can be of some assistance. Its not easy building a community within the FreeBSD community, so best of luck. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050831072747.GC72699>