From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20110106/001987.html | 73 +++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110106/001987.html (limited to 'zarb-ml/mageia-dev/20110106/001987.html') diff --git a/zarb-ml/mageia-dev/20110106/001987.html b/zarb-ml/mageia-dev/20110106/001987.html new file mode 100644 index 000000000..a006d9ab2 --- /dev/null +++ b/zarb-ml/mageia-dev/20110106/001987.html @@ -0,0 +1,73 @@ + + + + [Mageia-dev] Adding Java-Policy + + + + + + + + + +

[Mageia-dev] Adding Java-Policy

+ Frank Griffin + ftg at roadrunner.com +
+ Thu Jan 6 22:33:28 CET 2011 +

+
+ +
Michael Scherer wrote:
+> Why include gcj in fact ?
+>
+>   
+I wondered about this when I took a look at some Java packages (e.g.
+maven) to see how easy they would be to upgrade.  A huge amount of
+complexity was introduced by the desire of the existing RPMs to produce
+a gcj version of the tool involved.
+
+I can certainly see the appeal of gcj as "compiled java" for some target
+audiences even if most of us developers can't afford not to be
+developing and testing with more mainstream JDKs, but it's not clear to
+me that gcj needs to be a part of the install for every Java-based tool. 
+
+I'm not that familiar with gcj, but I wonder if there couldn't be
+separate packages which recompile individual tools under it where
+appropriate in some automated fashion rather than forcing every Java
+tool packager to do this.
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1