From owner-freebsd-java@FreeBSD.ORG Thu May 1 08:53:55 2003 Return-Path: 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 8A80C37B401; Thu, 1 May 2003 08:53:55 -0700 (PDT) Received: from mgr3.xmission.com (mgr3.xmission.com [198.60.22.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C58743FB1; Thu, 1 May 2003 08:53:54 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) Received: from mail by mgr3.xmission.com with spam-scanned (Exim 3.35 #1) id 19BGNc-0002sw-03; Thu, 01 May 2003 09:53:52 -0600 Received: from [207.135.128.145] (helo=misty.eyesbeyond.com) by mgr3.xmission.com with esmtp (Exim 3.35 #1) id 19BGNZ-0002qw-03; Thu, 01 May 2003 09:53:50 -0600 Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.12.9/8.12.9) with ESMTP id h41FwDQf082847; Thu, 1 May 2003 09:58:14 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.12.9/8.12.9/Submit) id h41FwBNC082846; Thu, 1 May 2003 09:58:11 -0600 (MDT) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Thu, 1 May 2003 09:58:11 -0600 From: Greg Lewis To: Ernst de Haan Message-ID: <20030501155811.GA78184@misty.eyesbeyond.com> References: <200210140852.g9E8qfbH050638@zaphod.euronet.nl> <20030501000903.Q41591@puget.esil.univ-mrs.fr> <200305010918.56072.znerd@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305010918.56072.znerd@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=-3.8 required=8.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MUTT,X_AUTH_WARNING version=2.43 X-Spam-Level: cc: Greg Lewis cc: Herve Quiroz cc: freebsd-java@FreeBSD.ORG Subject: Re: java/44041: Generate bsd.java.mk from an XML file X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:53:55 -0000 On Thu, May 01, 2003 at 09:18:56AM +0200, Ernst de Haan wrote: > Hi Herve, > > > I was in the mood for some XSLT coding so I decided to take care of this > > one hour ago. So far, I've finished everything up to step 3 (included) > > but I will need to get some sleep sooner or later ;) > > > > So I was wondering if you still need this XML->bsd.java.mk tool... and if > > you (or anybody else) had already done something about it. > > Haven't done anything about it yet. And I personally think it's a very good > idea. This way we only have to maintain a bsd.java.xml file. > > Greg, what do you think of this? Well, without having seen Herve's XSLT, I think the best way of explaining things is to describe what I would like to see ultimately happen with bsd.java.mk. Maybe some of this is due to not fully understanding the file, but here goes. At the moment if I specify USE_JAVA=1.X+ then bsd.java.mk seems to hardwire not only the order in which it tries versions (e.g. 1.4, 1.3, 1.2) but the order in which ports of those versions are tried. I believe I'm supposed to at least be able to override the first choice with JAVA_PORT, but this doesn't seem to be working, e.g.: env JAVA_PORT=java/jdk13 make ... ===> jmp-0.28 depends on file: /usr/local/jdk1.4.1/bin/java - found Maybe I'm doing this incorrectly? Anyway, the net result is that currently the set up seems to be pretty inflexible for the user. As a user I want to be able to specify both the order in which JDK versions are tried, and the order of the ports to try for each version. This actually is a real problem, just ask Kris Kennaway who recently asked me about this when the openoffice package build on bento ended up requiring about 5 JDKs to be installed. I also want to be able to specify these orders simply, with an environment or make variable setting. In addition to this, as the number of JDK versions increases, it could well be that a port depends on an API which has been removed (not just deprecated) from the most recent version. As a port maintainer, it may make sense for me to be able to do something like: USE_JAVA=1.1,1.2,1.3 This is somewhat separate though. To try and bring this back to the topic at hand, if I make the necessary changes to bsd.java.mk to support the flexibility I'm talking about, its not clear to me that it will be easy to generate bsd.java.mk from an XML file, or that it will even be more maintainable to do so. In some ways it seems all that this does is move the maintenance from bsd.java.mk itself to the XML file. What might be more helpful is to try and remove this maintenance altogether and possibly generate an included section of bsd.java.mk straight from the ports themselves using a script of some sort. E.g. you would run the script on the ports tree and it would generate a list of existing JDKs and their default order and place that information in an appropriate format in a file called bsd.java.order.mk which would be included in bsd.java.mk. Finally, I'd like for ports to be able to rely on a JRE (if thats all they need) instead of or as well as a JDK. We haven't got many JRE ports in the tree yet (only 1 in fact), but this may make sense as the JDK packages continue to get larger and larger. I think this is because most people working on the ports are also developers and need the full JDK. However, for many applications all that is needed is the JRE, which may save a user some time and effort. I should hasten to add that this is intended to be constructive thoughts on a possible direction for java ports in general. I also have some other less relevant issues (for instance, I don't like the way /usr/local seems to be getting more and more cluttered with ports that just install themselves in a subdirectory there, and some of the java ports are the worst offenders, mine included). But none of it is intended to take away from the great work Ernst and others (including Herve) have done in this area. Anyway, enough already, this email is far longer than I intended, but hopefully there is something useful in it :). -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org