Date: Tue, 30 Aug 2005 17:26:40 +0200 From: Herve Quiroz <hq@freebsd.org> To: Vizion <vizion@vizion.occoxmail.com> Cc: freebsd-java@freebsd.org Subject: Re: Eclipse as part of the ports/java tree? [Was freebsd eclipse plugins & mailing list] Message-ID: <20050830152640.GA88612@arabica.esil.univ-mrs.fr> In-Reply-To: <200508261720.38517.vizion@vizion.occoxmail.com> References: <200508251303.59453.vizion@vizion.occoxmail.com> <200508261100.47550.vizion@vizion.occoxmail.com> <20050826203737.GA58620@misty.eyesbeyond.com> <200508261720.38517.vizion@vizion.occoxmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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...
On Fri, Aug 26, 2005 at 05:20:38PM -0700, Vizion wrote:
> >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
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
Maint: janos.mohacsi@bsd.hu
Index: hungarian textproc
B-deps:
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 bsd.port.mk, let's take another
look at jdictionary:
$ ls /usr/ports/textproc/jdictionary/*.plugin
Makefile.plugin
pkg-plist.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, bsd.port.mk already contains more than 5000 lines of quite
complex logic. You may indeed advocate for some bsd.eclipse.mk (and no,
Eclipse logic will probably never hit bsd.java.mk 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).
> 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!
[...]
> Why go suboptimal?
[...]
> 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 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.
[...]
> 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
Even if it may seem like political battles to outsiders, FreeBSD is IMHO
more a matter of discussing things so that we take into account enough
required (or foreplanned) features and end up implementing a somewhat
flexible framework.
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.
Let's rather discuss the real motive here: improve Eclipse plugin
support in the ports tree. 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. :-)
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.
That said, I don't mind contributing to your efforts if you need some
advices or patch reviews. OTOH I won't be subscribed to freebsd-eclipse
to please CC me if you wish me to help you.
Now, because the 'java' category issue is quite often raised from the
grave, I am starting to think we should indeed get rid of the category
once and for all. I'll post on this topic in a separate message though.
Herve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050830152640.GA88612>