Eclipse as part of the ports/java tree? [Was freebsd eclipse
plugins & mailing list]
vizion at vizion.occoxmail.com
Sat Aug 27 00:24:37 GMT 2005
On Friday 26 August 2005 13:37, the author Greg Lewis contributed to the
Re: Eclipse as part of the ports/java tree? [Was freebsd eclipse plugins &
>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
>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
>Whether each individual
>plugin should be in devel is a separate discussion. For example,
>phpeclipse probably does belong there, eclipse-viplugin probably belongs
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:
Scattering eclipse modules and plugins over the whole of the ports tree would,
I believe, be both counterintuitive, counterproductive and
>> 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
>Ok, so there are a significant minority of plugins that may not go into
>devel, how is this a problem?
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
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
>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
client application plugins can be dependent upon development tools and vice
>> 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
>> 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
>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
>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,
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
Category (number of plugins)
Application Management (8)
Application Server (9)
Code Management (20)
J2EE Development Platform (15)
Rich Client Applications (7)
Source Code Analyzer (16)
Team Development (20)
Web Services (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
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
If the eclipse hierarchy was organized the way I suggest then the all the
plugins could be very quickly incorporated into the port tree
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.
More information about the freebsd-java