Date: Sun, 10 Mar 2002 15:58:33 +0800 From: Yong-Jhen Hong <winard@ms11.url.com.tw> To: ports@FreeBSD.org Subject: abount bsd.java.mk Message-ID: <20020310075833.GA8812@winax.home>
next in thread | raw e-mail | index | archive | help
--GRPZ8SYKNexpdSJ7
Content-Type: multipart/mixed; boundary="Qxx1br4bt0+wmkIi"
Content-Disposition: inline
--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hello!
It's nice to see the Ernst's working on bsd.java.mk, I think it is a
very need for serious Java developers and system administrators. I want
to make some comment about it.
I'm just making a Apache XML Cocoon2 port, wondering why that is so
uneasy to make such a Java-based port unlike a C/C++ version. To me
there are several reasons: a JDK contains many things (virtual machine,
bytecode compiler, javadoc, javah, jar, rmi*, sources and several class
libraries), a port needs to figure out which part it depends on to
build, install, or run; second, there is no common agreement on how
should a class library, a piece of javadocs, and any other documents,
property files, be installed, which makes it hard for installing and
checking which is already existing on the system.
=46rom my point of view, Java class libraries is best used like shared
libraries, and keeped in uncompressed form under a common directory, for
example, ${PREFIX}/lib/java. This approach makes it easier to check if
a library API exists, and possibly we can have such checking rule in a
port Makefile:
CLASS_DEPENDS=3D \
org.apache.xerces.parsers.DOMParser:${PORTSDIR}/textproc/xerces-j
and such installation macros:
do-install:
${INSTALL_JAR} ${INSTALL_WRKSRC}/build/batik-libs.jar
or
do-install:
${INSTALL_CLASSES} ${INSTALL_WRKSRC}/build/classes
The drawback is a common API might be implemented by several packages,
an experienced administrator may want to use different implementations
for different applications. And if a package implement several APIs, for
example Xalan implement XSLT in DOM2, SAX2, and TrAX, then a after-
installed pacakge would override a before-installed because of the lack
of some API implementations in the before-installed package. This can be
solved by dividing such port into sub ports and a meta port, which needs
much cares. But it even make it a much easier life for developers, for
they don't need to maintain a long list of class paths.
Javadocs is the same. I think it can be maintained like GNU Info
documents, which means we have just one ${PREFIX}/javadoc, and a javadoc
instruction is activated during installtion to merge package API
docments into the common javadoc tree. All other documents can be
installed following the current convention in ${PREFIX}/share/doc.
Even JDK can be installed in such way (in ${PREFIX}/bin, lib/java,
share, man, javadoc), the problem is still on how to handle different
implementations. For class libraries, a possible solution is a
specialized configurable class loader, but which is not the port system
can handle.
Yong-Jhen Hong
<mailto:winard@ms11.url.com.tw/>
--Qxx1br4bt0+wmkIi
Content-Type: application/pgp-keys
Content-Description: PGP =?big5?B?xl+wzSAweEIzRkZBNUI5oUM=?=
Content-Disposition: attachment
Content-Transfer-Encoding: quoted-printable
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
mQGiBDw12agRBACCXCcQe/FIy15HO9bI77ICKwEqpcQAmkUFWB3lGztMvmCCKB4b
mZf8XGGvLmR3OwnPOxkiPZ4gYckWmTyBUh4QNThyVCzrzrazeKj31yoNZf41fZYR
yrQebzoJExT26vtKaOuZS4VUK+rHQUW6bwALUss9VSlE3o+ppAADcFM+2wCgzONY
/bLyjpWzRifye/seyHcEOYED/RxW6J6OCZH8av46G+Fg8em3Hybc9GzAHzOIBJ5C
lcom/7RodHg0e7Cfa6zHHi+6JFafSTegJcfXg0zejlFgbfNb5cAlPfiCaDYuKOZc
NF91Uxf+ShD3TMFbTGqdhwMlwvRO5yYwTbBR6mmv5TxdYc6g4XXz9lutJx7CqpZl
sofuA/oDoG86S74GAzywlmysJmCxPrtdtHLsqNZe5YV1DFIy07f9KL8FDIBYuh2D
lDLT7GFAIuybmIdoHT6NmgflERohRexBa6pO4K2I5jcBSY0jl5iteV3GGtAc9OCQ
3m9bkdgM9nOr4dMsVZZIby/DHTplwHOiHHd1fuFpPu+bnZLVWrQnWW9uZy1KaGVu
IEhvbmcgPHdpbmFyZEBtczExLnVybC5jb20udHc+iFcEExECABcFAjw12agFCwcK
AwQDFQMCAxYCAQIXgAAKCRAxzMHys/+luRv1AJ9b3UwA7sW0GC/Kw7RsjcPf4a8K
uQCeJLo9bXv6FGY4P7XnhnuSwqvL6R65Ag0EPDXarhAIAPcyL4yfWxlCY+qtGIe8
X5GKOpbhKEJRHq0K8ciZfuemYsgxyBcauSeur42MZ+EoQx5I0B5L/nqmSmQq//d2
tcVMs8kn//mG7fmonUfL8/LmnAX2sh8X0HfvZ08AKHSrX8oBMKHUDnEY3jvC27e4
2/evd6O+Fi1YXj0lWp+3yAt5Q3gkOEglsGgshE8fVekh7NOSwAQUbCv/STIwQPSL
zcdQ4+UYxQK9YaSqRsz5GcRP5j/Dh+ec33yZFPrjUiJLsXieR0gDIxlbNbdHmlEi
zMs7poh4hrDQR0br/4eG4fDSxVUnyWhSL1uNiGX1D8z7cQ+/1FPBt/SJK1xlBzDK
rO8ABAsIAJz//I8vIKOZPMGd5o5rT8Ms0s/PlkRUnrAeivSaYOef1hZazVSS0TH9
3FXTguUQDGkT3tVZZf9dMqFtvDnB41JJEGbqdqwjdoAvVq2SXhXcv3Sctvd4aEWb
FHPd97fMjdOFtd/lboZGLM+klCwDciGbgQ8u/Zaco5veyhIZSOgxDe6qqa+hj0x8
OjhrjXBkxHkhJ2OmIdvRs0Xj9Kc9B4hR/7mGeUNgo5l8EVQCymCyRu5OOGiaL/pn
x66Zfdly6t1S3VNn/Og0YtLkIMD6juPcSSvZsgFpVqu0slQ9KdTPckZSSRWlaIJa
QvgKAVQDuwSGvyuBoiu2ueBJGNLTnNSIRgQYEQIABgUCPDXargAKCRAxzMHys/+l
ucnnAKCjpMaxsS/G7xwY4Bbq43D87b7JDgCffAhOytGyjenMdJMfEzpgZhJDtwQ=3D
=3DJGJX
-----END PGP PUBLIC KEY BLOCK-----
--Qxx1br4bt0+wmkIi--
--GRPZ8SYKNexpdSJ7
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8ixIoMczB8rP/pbkRAjkCAJ9i/4TSNC+lX0ObC8+1XvrVgvp23ACgwhnf
Vd8Tg6xwgSXFBuXkBtYBrFI=
=oQ7O
-----END PGP SIGNATURE-----
--GRPZ8SYKNexpdSJ7--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020310075833.GA8812>