Date: Fri, 26 Aug 2005 17:20:38 -0700 From: Vizion <vizion@vizion.occoxmail.com> To: freebsd-java@freebsd.org Subject: Re: Eclipse as part of the ports/java tree? [Was freebsd eclipse plugins & mailing list] Message-ID: <200508261720.38517.vizion@vizion.occoxmail.com> In-Reply-To: <20050826203737.GA58620@misty.eyesbeyond.com> References: <200508251303.59453.vizion@vizion.occoxmail.com> <200508261100.47550.vizion@vizion.occoxmail.com> <20050826203737.GA58620@misty.eyesbeyond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 26 August 2005 13:37, the author Greg Lewis contributed to the dialogue on- Re: Eclipse as part of the ports/java tree? [Was freebsd eclipse plugins & mailing list]: >On Fri, Aug 26, 2005 at 11:00:47AM -0700, Vizion wrote: >> I am inclined to agree that eclipse does not "belong" in ports/java. >> Neither does iit belong in "devel" or "languages". > >I think you mean "lang" for the latter category, correct? It certainly >doesn't belong there since its not a programming language. It does seem >to very much belong in devel though, at least based on the Eclipse web >site. > >Here is the first sentence I read on http://www.eclipse.org: > >"Eclipse is an open source community whose projects are focused on > providing an extensible development platform and application frameworks > for building software." > >Sounds like a perfect fit for the devel category. While your observation is correct I believe your deduction misses the significance of eclipse because you are confusing two things. 1. The actual development of the eclipse IDE and application frameworks which is essentially part of the eclipse.org strategic and development plan. 2. The client rich applications and client rich tools which have been built by the eclipse community using the eclipse framework. You mention the first category to support of your argument but that argument ignores the far greater impact that the second category. The development of eclipse tools and client rich applications is not the focus of my proposals. That role properly lies within the eclipse community. I would argue that we need to concentrate on the second category which offers major benefits for the freebsd community. We need to do that by facilititating access by the freebsd community to the client rich applications and client rich tools which have been produced by the eclipse community. >Whether each individual >plugin should be in devel is a separate discussion. For example, >phpeclipse probably does belong there, eclipse-viplugin probably belongs >in editors. There is a conceptual flaw in this perception. A plugin is not an editor. The phpeclipse plugin enables eclipss to be far more than an editor -- By using phpeclipse plugin eclipse becomes a complete development and testing environment for all the tools used by a developer using php. However even this view provides a simplistic notion about the role of eclipse and encourages me to further disagreement with your conclusions. While some plugins have very specific naming and appear to be strongly focused (e.g. phpeclipse) the real power of eclipse comes from the ability to combine the use of multiple plugins and perspectives which then become highly flexible tools and provide the tools for generating and operating client rich applications. > >> In view of the huge number of eclipse plugins and, nore importantly, the >> mushrooming significance of eclipse, to everyone including the freebsd >> community, I would like to suggest we have /ports/eclipse. Here are my >> basic reasons: >> >> 1. The huge range of significant plugins (392 last count) which are >> dependent upon the the eclipse IDE. In my view, and for the good of the >> platform, we need to make these available to freebsd users in a form that >> fits into the freebsd ports collection. > >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 > >> If that means changes to the ports collection schema I see no objection. >> The long term interest of the platform is much more significant thn the >> current ports collection schema. > >I think you'll see multiple objections actually :) Well so be it -- but as I said before we are in a new era and I believe freebsd needs more of the motto "If the traditional hat does not fit then don't wear it" :-) let us take pride in designing one that does. > >> Here are the major categories and the number of plugins within each >> category: > >[snip] > >Ok, so there are a significant minority of plugins that may not go into >devel, how is this a problem? Not true. The current and rapid growth in the eclipse world lies in the vastly increasing number of rich client applications under development that will quickly dwarf the total number of plugins that appear to be development focussed. The problem of rapid development is that as the IDE versions change I foresee the need to label the plugins so it is easy to identify their interactions with different IDE versions. This will be much easier to manage and archive if all the plugins are in one location in the ports tree rather than scattered throughout the whole ports collection. The other thing is that a common make file could probably be used for the selection and installation of plugins by the user. > >> 2. That in line with current development and application thinking the >> implications and practice of the eclipse EDI framework cuts right across >> the current heirarchical divisions of the freebsd port tree which was >> itself created when the application and development environment was >> founded on an entirely different set of system and application >> constraints. > >Your initial point here would suggest that creating a virtual "eclipse" >category should be considered. This is something that has been done >before, so it wouldn't be outside of the status quo. > >> 3. We are living in a different era and the traditional divisions do not >> apply to the eclipse framework. Can we not, as a platform, welcome that >> change by making appropriate changes to our ports schema? > >See my previous comment. This is what virtual categories are for. It seems from what you are saying that the term virtual categories refers to the way in which the data is stored on the server. It is how the files are presented to the community that matters. > >> 4. As you can see by examining Eclipse and by careful study of eclipse and >> eclipse related websites it is not just an EDI it is also a multi >> application framework so it does not "belong" in anything other than its >> own place in the ports tree. > >I don't quite follow the logic I'm sorry. Development environments belong >in the "devel" category. Multi-application frameworks belong in the >"devel" category. How does something which is both not belong there? see my earlier comment -- As a development tool it is a development environment, as a framework under development it belongs under devel HOWEVER this is not the focus. The value to the freebsd community is to harness the tools which have been developed by the eclipse community and rich client applications (which certainly do not belong in devel) and, as an important aside, its use as a freebsd development framework. However because of the way in which eclipse IDE and tools integrate they all belong together (rich client application plugins can be dependent upon development tools and vice versa!!) > >> 5. I can see great potential for a number of freebsd specific eclipse >> plugins (including a combined freebsd system management and help tool >> providing an integrated and automated sysadmin functionalities). > >Vapourware is never a good argument for anything. The Vaporware to which I am referring are applications we do not currently have on the freebsd platform but are being developed for other platforms. If we are not careful freebsd will become no more nor less than a linux emulation machine! > >> 6. If we do not grasp the opportunity we now have to make the changes >> needed to accomodate eclipse and any similar generic combined >> Application/EDI frameworks then freebsd will suffer. It will certainly not >> be harmed by taking the steps necessary to incorporate into its ports >> collection. > >I disagree. We need no changes to accomodate eclipse -- its currently >accomodated, albeit in a suboptimal fashion. Why go suboptimal? >I have suggested it be moved >to a more appropriate category and conceded there _may_ (I'm not yet >convinced) be a case for creating a virtual category for it. If that means producing the kind of structure indicated above then we have no disagreement :-) >I believe >that course of action would be more than sufficient. > >> 7. There are substantial advantages when managing an eclipse development >> environment on the freebsd platform to having the plugins installed from >> the ports tree rather than via individual user accounts which could lead >> to individual team members loading different versions of plugins into >> their own user workspace. We need to have the plugins organized in the >> ports tree. That means 392 plugins - There can be no doubt that eclipse >> needs its own place in the freebsd ports hierarchy as well as its own >> mailing list for the good of the freebsd community. The combination of >> these two initiatives may attract new devotees to freebsd and cannot do us >> any harm. I do not believe we will act responsibly by leaving things as >> they are or failing to grasp the new opportunities. > >Here is the problem. The figure of 392 plugins and the unspecified harm >that will befall FreeBSD if we don't do something for eclipse is being >used to propose a reorganisation of the ports tree. A tool is a tool -- freebsd is not a religion but a set of tools. We do not need sacred relics but the flexibility to change. If the freebsd structure is so rigid that establishing an /ports/eclipse/ hierarchy is complicated then we need to use our flexible minds to design a more flexible solution. >The reality is that >we're talking about eclipse and about 20 plugin ports, Not true--- You cut out the list of plugins from my previous posting - you will see there are currently 392 plugins all of which can be ported. There are about three times that number under development. The largest proportion are rich client client applications. Category (number of plugins) Application Management (8) Application Server (9) Code Management (20) Database (24) Deployment (5) Documentation (8) Editor (30) Entertainment (6) Graphics (3) IDE (21) J2EE Development Platform (15) J2ME (4) Languages (19) Modeling (14) Network (4) Other (14) Profiling (7) Rich Client Applications (7) SCM (2) Source Code Analyzer (16) Team Development (20) Testing (23) Tools (57) UI (14) UML (11) Web (21) Web Services (10) XML (10) We are currently talking about 392 ports: in 20 categories here they are again >I'm sorry, but the reality of the level of interest in >eclipse amongst the FreeBSD community doesn't seem to match with the >magnitude of the change you are suggesting. You know the change has no real magnitude. The only magnitude I see is a reluctance to change. >Please, by all means, build >up that level of interest. The interest is going to other platforms because people in the freebsd community do not have the support from the eclipse community. The eclipse community is therefore enlarging the linux base. We need to turn that around and focus on the future not the past. >Get some people together like the Gnome and >KDE groups. Get some more plugins submitted as PRs and get them committed. >Then when you've got some runs on the board start proposing eclipse as a >virtual category. I am not going to put in that kind of effort and simultaneously fight a political battle to enable people to simply access the results. If freebsd is satisfied with doing it in a "suboptimal fashion" then why should I or anyone else bother? If the structure is not there to support it and neither will anyone else. If the eclipse hierarchy was organized the way I suggest then the all the plugins could be very quickly incorporated into the port tree 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508261720.38517.vizion>