1 |
(The following is shamelessly yanked from the blog post I just made) |
2 |
|
3 |
As has been previously announced, we are officially part of Google's |
4 |
Summer of Code. I've decided to step up to be a mentor, and in |
5 |
particular, to mentor projects related to Java on Linux. |
6 |
|
7 |
A few ideas follow. The 1a and 1b are listed already on our SoC page to |
8 |
an extent, but the idea is elaborated further here. If you plan on |
9 |
proposing one of these ideas, I really would expect you to even further |
10 |
elaborate. |
11 |
|
12 |
*1a)* |
13 |
/Summary:/ |
14 |
|
15 |
Build most of our Java packages with free (libre) virtual machines and |
16 |
free implementations of public APIs. |
17 |
|
18 |
/Background:/ |
19 |
|
20 |
Currently, we really only support using a proprietary virtual machine |
21 |
(ie sun, blackdown, ibm, etc), because packages are likely to fail for |
22 |
various reason with the open ones. |
23 |
|
24 |
For many open apis, such as javamail, java activation framework, etc, we |
25 |
have binary packages of Sun's proprietary implementations. In a number |
26 |
of cases, there are open implementations. However, our packages compile |
27 |
against and run using the proprietary implementations. |
28 |
|
29 |
For reasons why one would want to be using Free Java, see the article on |
30 |
the Java trap <http://www.gnu.org/philosophy/java-trap.html>. |
31 |
|
32 |
As for a practical reason, use of proprietary packages from Sun and IBM |
33 |
can annoying for the end user, because in both cases, it requires |
34 |
placing a fetch restriction on the distfiles. To the end user, this |
35 |
means that an emerge gets halted until they agree to a license, and |
36 |
download the files. |
37 |
|
38 |
/Goals:/ |
39 |
|
40 |
* Build/run all/most packages using free virtual machines |
41 |
* Build/run all/most packages against free implementations of public |
42 |
APIs |
43 |
* Might want to target specific big name packages, like eclipse, |
44 |
azureus, tomcat. |
45 |
* Be able to select between different implementations of the same apis |
46 |
|
47 |
/Tasks:/ |
48 |
|
49 |
* Work with upstream of packages that use propertary classes from |
50 |
the virtual machine (ie com.sun.*, sun.*) |
51 |
* Work with upstream of virtual machines and packages when packages |
52 |
don't compile or run with using free java |
53 |
* Find and package open implementations of public APIs |
54 |
|
55 |
/Hurdles:/ |
56 |
|
57 |
* Lots of Java packages (300+). It is unknown how many will need to |
58 |
be patched. |
59 |
* Upstream might not care about free java |
60 |
* Might not be open implementations of all APIs |
61 |
|
62 |
*1b)* |
63 |
|
64 |
/Summary:/ |
65 |
Native compiling with gcj |
66 |
|
67 |
/Background:/ |
68 |
|
69 |
GNU Compiler for Java (gcj) allows for compiling Java code to native |
70 |
machine code, as opposed to Java bytecode. Fedora/Redhat has done this |
71 |
to an extent for some time. It'd be great to be able to do this under |
72 |
Gentoo as well. |
73 |
|
74 |
/Tasks:/ |
75 |
|
76 |
* Create a 'JDK' which uses gcj as a backend. In this case, JDK |
77 |
really means providing a javac, javadoc, jar, etc |
78 |
* Have a way of keeping track of native bytecode |
79 |
* Integrate methods for native compiling into the current build |
80 |
system for building Java packages on Gentoo (ie eclasses) |
81 |
* Target native compilation of high profile applications, ie azreus, |
82 |
eclipse, freemind |
83 |
|
84 |
*2a)* |
85 |
|
86 |
/Summary:/ |
87 |
|
88 |
Build maven <http://maven.apache.org> entirely from source. |
89 |
|
90 |
/Background:/ |
91 |
|
92 |
We currently only provide binary packages of maven, due to the fact that |
93 |
it is a bootstrapping nightmare because of the monolithic nature of the |
94 |
build process. The build system, at its basic level, does the following: |
95 |
|
96 |
* Build the 'core' maven functionailty using ant |
97 |
* Build the 'core' maven functionality using maven |
98 |
* Build all the plugins using maven |
99 |
|
100 |
The problem with building all the plugins at once is that there are a |
101 |
ton of plugins, with many, many dependencies. Because of these |
102 |
dependencies, it would make it impractical to have a monolithic package, |
103 |
which would be used to build other packages. |
104 |
|
105 |
/Goals:/ |
106 |
|
107 |
* Have modular packages for maven |
108 |
* Have one package per plugin |
109 |
* Have a 'core' maven package |
110 |
* Have a 'minimal' maven package, which is core + minimal packages |
111 |
for compiling, javadocs, and jarring |
112 |
* Have a 'full' maven package which is all the plugins |
113 |
* Would need to work out a way to make the build much more modular |
114 |
|
115 |
*2b)* |
116 |
|
117 |
/Summary/ |
118 |
Build packages using maven |
119 |
|
120 |
/Background/ |
121 |
Many packages, particular Apache projects, have been switching over |
122 |
|
123 |
The main issue is getting jars from a maven repository. The normal |
124 |
behavior of maven is to download dependencies from a maven mirror. First |
125 |
of all, things at build time should not be using the network. Secondly, |
126 |
dependencies should be provided by jars from packages that have |
127 |
previously been emerged. |
128 |
|
129 |
Another issue is that maven 2 repositories contain metadata |
130 |
(specifically, pom.xml files) about the packages contained within. This |
131 |
is normally fetched from the repository, but since we don't want to be |
132 |
pulling from there, the question remains open as to where the metadata |
133 |
is gotten from and how its stored on the system. |
134 |
|
135 |
/Goals:/ |
136 |
|
137 |
* Have a system to have maven use jars that we have built through |
138 |
portage |
139 |
* Update packages to use maven when possible. These should have fine |
140 |
grain control to the plugins that are available at build time. |
141 |
Packages should depend on the minimal install, and whatever extra |
142 |
plugins they might need, and only those should be available at |
143 |
build time. |
144 |
|
145 |
/Possible solutions for dealing with maven repositories:/ |
146 |
A) Create a maven-repository like structure, and have it populated with |
147 |
jars from the system |
148 |
B) maven (2.0 at least) has a mechanism for providing alternative ways |
149 |
of fetching dependencies. We could then create an alternative way that's |
150 |
backed by portage. |
151 |
C) Find a way to tell maven not to fetch dependencies, and hope that |
152 |
there are the appropriate classes available on the classpath |
153 |
-- |
154 |
gentoo-java@g.o mailing list |