Ok - it's been a week with no major grousing about the contribution
framework (we'll still of course accept comments from the larger
Incubator and ASF community and react accordingly), but lets get
started in deciding next steps. We're still debating issues around
the mail list policy (which has grown to code repository policy over
on the Incubator list, but lets not let that stop us from moving
forward for now.) I'm not sure we're done, but getting actual use
cases to handle will help us iron out the process and policy. At all
times we should be as conservative as possible, but lets get going.
The following are how I think things break down, I'd like to renew a
call for contributions in the following areas (and any not mentioned) :
VM and Parts
------------
I think (and others think) we have at least a two-phased approach to
what we'll do with VM and related for the project :
1) Near term : Purpose is to have a basis for working on the
modularity while having working code. We should solicit one or more
contributions in both C/C++ and Java to let people work on what they
want and be understanding that in all probability, it will be a
prototype. I personally would like to see us get a donation of
- JikesRVM and related projects
- an existing non-java VM, like Jam or others.
- anything Dan Lydick may want to throw our way, as it may be easier
to grok for us newbies and refactor as our modularity story develops
In each case, we could either accept a community moving over here, or
accept a copyright license in order to limit the risk to an existing
community. (For example, the research people that depend on JikesRVM
may not wish to have their work disrupted, but if things take off for
our JikesRVM "branch", then they may migrate over here. Same with
the JamVM community, if they were to grant us a copy to start working
from...)
2) Long Term : Our ultimate long-term goal is a platform competitive
with the commercial offerings. I suspect we won't be able to evolve
what we have from "Near Term" above, but rather will use Near Term to
decide on our architecture, and take a fresh run using pieces from
Near Term. Maybe not, of course, but we should understand this a
very possible path.
Tooling
-------
We need all the standard tooling (e.g. compiler). Mark sent out a
nice list that I think we should just boil down and get to work on
using/adopting. See his post from July 22, but I summarize here :
- compiler: Several candidates. (jikes, ecj, gcj)
- javadoc replacement.
- browser plug-in.
- jar replacement.
- javah replacement.
- native2ascii replacement.
- javap replacement.
- serialver replacement.
- rmic and rmiregistry
Class Library
-------------
There are a few aspects to this.
First, we have two approaches to class library / VM interface, and
with a VM contribution, it would be nice to try both. Tim and Graeme
have discussed how J9 does it, and we have a decent understanding of
how GNU Classpath does it. If we had a VM - even a simple one - we
could start toying with the two. That would require at least a toy
classlib here to use the IBM/J9 approach, and hopefully we could
derive an interface to standardize on.
Second, the modularity issues (JSR-277, OSGi) are important topics
right now. An OSGi implementation may/is/will be incubating at the
Apache Incubator, and the ASF is going to participate in JSR-277,
mixing several interest groups, such as ourselves and Apache Maven.
Anyone interested in thinking and working on that is invited to do so
here.
What else? Thoughts?
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
