java/44041: Generate bsd.java.mk from an XML file

[Greg Lewis]

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 at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org