Date: Tue, 30 Aug 2005 10:19:27 -0700 From: Vizion <vizion@vizion.occoxmail.com> To: freebsd-eclipse@freebsd.org Cc: Greg Lewis <glewis@eyesbeyond.com>, Herve Quiroz <hq@freebsd.org>, David Wolfskill <david@catwhisker.org> Subject: How should eclipse be organized in the ports tree? Message-ID: <200508301019.28780.vizion@vizion.occoxmail.com>
next in thread | raw e-mail | index | archive | help
On Tuesday 30 August 2005 08:26, the author Herve Quiroz contributed to the dialogue on- Re: Eclipse as part of the ports/java tree? [Was freebsd eclipse plugins & mailing list]: This is my reaction to part of Herv's original contribution (I will post the rest later) to a debate about how eclipse plugins would be best organized in the freebsd ports tree. I have no fixed ideas about this but am aware there are now almost 300 plugins which, I believe, should be in our ports tree. The question is how to organize them. ------------------------------------------ Herv has said he will not subscribe to freebsd-eclipse so I am copying this here. >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... <snip> I am replying to part of your response because I think you have a great musunderstanding. >I don't think you will get much attention from other commiters if you >introduce things as "the one true approach" compared to the "suboptimal >fashion" that is, by your word, the current state of the ports system. > Please do NOT put words the words of others in my mouth. "suboptimal" was not my description but a description given by Greg to the current state of affairs. I happen to agree with him but it is a committer who believes that to be the case. So please do not cast me in the role of an outsider decrying the work of vituous committers. I very much appreciate what you guys do which is done very well (even if I do hold to the view that the freebsd policies (which determine what should be done) are fast becoming out of date and in consequence freebsd is in danger of losing its pre-eminent place to linux. To my mind that would be a great loss). >Let's rather discuss the real motive here: improve Eclipse plugin >support in the ports tree. It is not justabout improving the support it is about improving convenience and accessibility. Perhaps it could be solved by writing an eclipse plugin for freebsd users which accessed the freebsd ports tree and pulled the plugins directly from the tree and installed them? In that way the freebsd ports tree would then have only to store the plugins themselves. This might be the way to go. In fact taking it one stage further such a plugin would mean that eclipse could be used to develop a global freebsd port access and installation tool. Now that is something worth thinking about! My general question is would there be real benefits from seperating the data storage and its internal structures (the ports tree itself), from the gui (which could use metadata to present information in the form required by the user about the data and assist the end user to select manage, select, upfate and install ports) and processes which implement user instructions. I sometimes wonder the excellent ports tree system appears, by comparison with some recent approaches, not to have benefited from an access makeover. However good the product I wonder whether we need to give more consideration to useability. An all bells and whistles web/database driven front end interface which enables the end user to organize information about the content is an ideal dream. Getting someone to give the time to do the work would be the challenge. >Again, it has nothing to do with the >greatness of Eclipse nor the personal feelings of commiters towards >Eclipse. In the later case, I would probably already have done some "cvs >remove" on /usr/ports/java/eclipse a long time ago. :-) Perhaps freebsd committers have had too much on their plate to be other than reactive. Certainly we are behind the curve on this one by comparison with Linux and that is worrying. Especially as the eclipse team only took the initiative to work with linux and ignored freebsd. That is starting to change thanks to the efforts of a few freebsd eclipse users and committers. > >Together with the freebsd-java community we have been working on >refactoring the Java subsystem for years so that it would provide *us* >the support *we* needed (that is, not only to attract more developpers >to FreeBSD from Linux). It took quite some time and some lengthy >dicsussions to get our bsd.java.mk subsystem added to the tree and we >are speaking of more than 300 Java ports here. So unless we manage to >use a similar apporach for Eclipse as for jdictionary, you will probably >end up battling a long time, advocating for a rework of the whole ports >tree when 20 plugins ports are indeed concerned. I do not know where you get the idea of 20 plugin ports from. There are currently twenty categories of eclipse plugins and 291 plugins. The estimate is that will be around 600 plugins within a year from now. Are you not sure that the scale of takeup, the volume of development in eclipse (and possibly its significance), and its potential to contribute to the advancement of freebsd has been underestimated within the freebsd "meritocracy". Will you please refrain from suggesting that I am advocating a rework of the ports tree? I have no way of knowing if or why any reworking is needed. It seems to me that that is matter for those who control the ports tree to decide. I fo not know how it works. My concern is to ensure that freebsd benefits from developments in the wider community and builds upon is assets. This discussion has taken me froma position of believing that freebsd has the tools we need to one where I have started to worry whether our assets (including the ports tree) have been engineered in a that has made data so inextricably interwoven with process that resource adaptability is now severely compromised. Fo you not agree that worry is reinforced when members of the committer community argue against such the simple concept I have proposed to deal with almost 300 eclipse plugins on the grounds that it implies a reworking of the ports tree? To be fair Greg has suggested that my proposal could be adopted by using what he labelled as a "virtual" solution that has been used elsewhere. From the way he put it forward I drew the implication that there would be a knee jerk reaction against the idea. I am now faced with the question is the ports tree as inflexible as some people suggest or are some members of our meritocracy more inflexible than the freebsd assets? -- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508301019.28780.vizion>