From owner-freebsd-java@FreeBSD.ORG Sun Oct 23 17:56:11 2005 Return-Path: X-Original-To: freebsd-java@freebsd.org Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73C3816A41F; Sun, 23 Oct 2005 17:56:11 +0000 (GMT) (envelope-from brucem@mail.cruzio.com) Received: from cruzio.com (dsl3-63-249-85-132.cruzio.com [63.249.85.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06EC643D45; Sun, 23 Oct 2005 17:56:10 +0000 (GMT) (envelope-from brucem@mail.cruzio.com) Received: from mail.cruzio.com (localhost [127.0.0.1]) by cruzio.com (8.12.10/8.12.10) with ESMTP id j9NHwBx3000364; Sun, 23 Oct 2005 10:58:11 -0700 (PDT) (envelope-from brucem@mail.cruzio.com) Received: (from brucem@localhost) by mail.cruzio.com (8.12.10/8.12.10/Submit) id j9NHwBTp000363; Sun, 23 Oct 2005 10:58:11 -0700 (PDT) (envelope-from brucem) Date: Sun, 23 Oct 2005 10:58:11 -0700 (PDT) From: "Bruce R. Montague" Message-Id: <200510231758.j9NHwBTp000363@mail.cruzio.com> To: freebsd-java@freebsd.org Cc: freebsd-ports@freebsd.org Subject: Re: [SUGGEST] Reform eclipse and eclipse related ports X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2005 17:56:11 -0000 Hi, re large IDE-like things (Eclipse, Emacs) and the ports tree... FreeBSD's source-centric ports tree is probably FreeBSD's second-best feature (after the source-centric system). Over time (decades) the ports tree might come to be one of the world's great repositories, or at least repository "index" (isn't it already? ;). It should make no bones about this. Two trends relating to the ports tree (an opinion): * Any really succesful large application, over time (again, decades) becomes it's own interpretter- language-IDE-environemnt. Past a certain point, these things often never go away, they just grow. In addition to things like Emacs, Eclipse, and even X (hey, what about the Java Netbeans environment users?) there are a number of application-oriented systems: OpenOffice, R, Octave, Grass, maxima, etc.. R (open source version of S stat-pack), Octave (open source Matlab), grass (open source GIS), maxima (open source, well, Macsyma). These things, like Eclipse, can accumulate all sorts of related shims, addons, and extensions. Some of these are really popular, world-class, in their category (R), some are relatively new, but potentially popular (grass), and some are almost moribund old classics, maybe starting to make a come-back (maxima). None of these will ever "take over the world", because they are special-purpose. But they can be expected to grow and will often motiviate use of FreeBSD in classic scientific workstation environments; FreeBSD should strive to be a preferred platform for those who want to run these environments, in particular those who want to easily track the latest releases, run these sorts of things simultaneously, and access the source. * I'm not so sure about framework-centric progamming taking over the world, but other languages besides C (or at least those supported by the gcc backend) are finally(?) becoming somewhat common on Unix systems, perhaps because computers are now so fast that interpretters are attractive. If a language is succesful, of course, over time a lot of other files in the ports tree will become dependent on it. (Even if framework-centric systems dont turn out to be a silver bullet, they likely will continue to grow like everything else.) The "Ports in virtual categories" section of the ports tree currently contains mostly categories for desktops or programming languages. How hard would it be to support 2 levels of "virtual categories", in some cases? Can this already be done? Then one could add a "Java" virtual category and under it create "Eclipse" and "Netbeans" categories (or whatever, just for illustration). Anything in the ports tree that grew to a certain size, in terms of the number of other ports that were directly related to it or dependent on it (or likely to be accessed and installed by someone using it), would be considered for inclusion somewhere in the virtual ports tree, where it could all be viewed as "one big ball of stuff". - bruce