Eclipse as part of the ports/java tree? [Was freebsd eclipse

Eclipse as part of the ports/java tree? [Was freebsd eclipse

Post by glewi » Sun, 28 Aug 2005 05:38:07

n Fri, Aug 26, 2005 at 11:00:47AM -0700, Vizion wrote:

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

"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. 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.

I'm not sure how thats an argument for creating a non-virtual eclipse
category. Would you care to explain?

I think you'll see multiple objections actually :)


Ok, so there are a significant minority of plugins that may not go into
devel, how is this a problem?

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.

See my previous comment. This is what virtual categories are for.

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?

Vapourware is never a good argument for anything.

I disagree. We need no changes to accomodate eclipse -- its currently
accomodated, albeit in a suboptimal fashion. 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. I believe
that course of action would be more than sufficient.

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. The reality is that
we're talking about eclipse and about 20 plugin ports, out of a total of
13,000+ ports. 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. Please, by all means, build
up that level of interest. 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.

Greg Lewis Email : XXXX@XXXXX.COM
Eyes Beyond Web :
Information Technology FreeBSD : XXXX@XXXXX.COM
XXXX@XXXXX.COM mailing list
To unsubscribe, send any mail to " XXXX@XXXXX.COM "

Eclipse as part of the ports/java tree? [Was freebsd eclipse

Post by vizio » Sun, 28 Aug 2005 09:24:53

n 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]:

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 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

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.

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

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.

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
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 tr

Eclipse as part of the ports/java tree? [Was freebsd eclipse

Post by hq » Thu, 01 Sep 2005 00:26:56


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:

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.

I suggest that we identify the features needed in the ports system to
improve the support of Eclipse plugins so that we may improve the ports
sytem rather than just make an exception of Eclipse.

Actually, this is the way it works for all plugins-type ports in the
tree: each plugin is a new port and, as a port, it gets a list of
categories, the first one being its main category. Hence it may happen
that the plugins are scattered amongst different directories. And I
can't see why this is a problem.

Take as an example the textproc/jdictionary port. There are many plugins
that are each located in a language-specific category. Now you may think
that it is troublesome to have them scattered but if all you really need
is to be able to find all plugins that are available for jdictionary,
then you are indeed provided with enough support in the ports tree:

$ /usr/ports/Tools/scripts/portsearch -n jdictionary


Port: hu-jdictionary-eng-hun-expr-1.4_2
Path: /usr/ports/hungarian/jdictionary-eng-hun-expr
Info: JDictionary plugin: English-Hungarian expression dictionary
Index: hungarian textproc
R-deps: XFree86-libraries-4.5.0 expat-1.95.8_3 fontconfig-2.2.3,1 freetype2-
2.1.10_1 javavmwrapper-2.0_5 jdictionary-1.8_2 jdk-1.4.2p7_1
pkgconfig-0.17.2 urwfonts-1.0


Now, regarding the fact that all plugins would share the same code and
thus need to have specific support in, let's take another
look at jdictionary:

$ ls /usr/ports/textproc/jdictionary/*.plugin


Hence each plugin is quite short. For instance,
/usr/ports/hungarian/jdictionary-eng-hun/Makefile just contains a few
lines and inherits most of its logic from Makefile.plugin:

MASTERDIR= ${.CURDIR}/../../textproc/jdictionary

.include "${MASTERDIR}/Makefile.plugin"

Moreover, already contains more than 5000 lines of quite
complex logic. You may indeed advocate for some (and no,
Eclipse logic will probably never hit as far as I am
concerned) but I can't see the point when you can just have some
Makefile.plugin in /usr/ports/java/eclipse.

I admit I am not using Eclipse myself (using rather vi, Maven, Ant and
even some Makefiles) so I didn't feel too concerned about the effort in
the first place. Moreover, I was too busy with other stuff to get
involved in the process earlier. If I am to throw out my two cents on
the freebsd-eclipse effort, I would say that you just lost even more
commiters for the Eclipse cause. I, for instance, will probably never
have a chance to work on the Eclipse framework now that there is a
specific mailing list (that I obviously won't subscribe to).




Eclipse as part of the ports/java tree? [Was freebsd eclipse

Post by vizio » Thu, 01 Sep 2005 02:14:46

n 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]:

I have replied to part of your contribution immediately - which seems to me to
hold the nub of the issue. As you seem unwilling to discuss the issues on
freebsd-eclipse I have responded here and posted the text on freebsd-eclipse.

I am replying to part of your response because I think you have a great
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).

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.

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.

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

Eclipse as part of the ports/java tree? [Was freebsd eclipse

Post by vizio » Thu, 01 Sep 2005 03:52:05

n 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]:

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

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

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

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

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

there is no reasomn why this hierarchy should not be:

I see practicle reasons for keep all eclipseplugins in a single directory


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.
XXXX@XXXXX.COM mailing list
To unsubscribe, send any mail to " XXXX@XXXXX.COM "

Eclipse as part of the ports/java tree? [Was freebsd eclipse

Post by linimo » Thu, 01 Sep 2005 06:23:55

This is a complete oversimplification of the situation.

There are some hard-coded assumptions in the ports tree -- one of which is
that there are two levels, categories and ports -- and these assumptions
are mirrored in the repositories of tens of thousands if not hundreds of
thousands of users, and thousands of lines of shell scripts and database
programs that create the binary packages and monitor the results of those
build processes.

So when you suggest that the only way that Eclipse can be supported is
to have a multilevel ports tree -- as you are seeming to -- you are clearly
totally misunderestimating the amount of effort involved.

In your most recent email I think you are finally getting a lot closer to
what I consider 'real' problem. IMHO the interesting problems you want to
solve are the 'search' and 'browse' problems. Directory names controlled
by CVS structures in an unbranched tree, which are then mirrored all around
the world, are really poor paradigms for these problems. Herve has
suggested some better tools for these which are better ways to think
about these problems and you should look at those. We certainly need more.

The meta-plugin idea is also worth considering.

But restructuring the entire tree, even to add a few hundred ports, is
simply not feasible with the level of volunteer effort we have and the
number of people that depend on the current structure worldwide.

XXXX@XXXXX.COM mailing list
To unsubscribe, send any mail to " XXXX@XXXXX.COM "