harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][pack200] new module (was: [classlib][pack200] Development has stalled :-( )
Date Wed, 10 Jan 2007 12:07:08 GMT
I think it would be helpful to keep the following two issues you have
raised quite separate.

1) Additional requirements on the Pack200 code, and
2) The working model for contributing code.

Taking them in reverse order, there have been a number of suggestions
for working 'disconnected' and contributing patches / new files from
your local repository (such as svk and git) that I hope you can figure
out a system that works for you.  It is a problem that all contributors
face, and a great topic for sharing experiences.

IMO the additional requirements on the Pack200 code seems to
unnecessarily couple implementation with packaging/deployment needs.  I
don't think making Pack200 a separate bundle will be sufficient to meet
all the requirements.  Let me try and explain why:

- dependency on Java 1.4 syntax and APIs

We can easily ensure that the Pack200 code only uses 1.4 syntax by
compiling it with the appropriate source flag.  However, we cannot
ensure it only uses 1.4 APIs since we compile Harmony against itself.
The only way to do that is to have a JSE1.4 class library around, which
means an additional Harmony dependency.

I suggest that we compile the code in a separate source folder as 1.4,
but rely upon an out of band build to check that there are no references
outside the J2SE-1.4 execution environment.

If people commit 5.0 syntax, or code that depends upon 5.0 APIs then it
is not your job to fix it -- you should yell on the dev list and have it
rolled back.

- packaging as a separate bundle

In regular OSGi you do not explicitly list java.* packages in the
Import-Package statement.  They are part of the execution environment
hosting the bundle.  However, since Harmony is modularizing the class
libraries themselves we precisely want to define the scope of the bundle
by java.* and their corresponding implementation packages.

For the Pack200 code to be a useful bundle in Harmony will require a
different Manifest to a bundle that is useful as a regular Eclipse
plug-in / Felix bundle / whatever.  Harmony's bundles cannot specify a
required execution environment.  One manifest will not do both jobs.

I suggest that there needs to be a separate project description and
Manifest for a 'regular' Pack200 bundle outside the modules source tree,
that links to the same source folder containing the same implementation
code.  Then there can be a 'Harmony view' and 'regular bundle view' of
the same code.

- NLS messages

Sure, if the code is going to be separable, then it needs a way to take
only it's own messages away.  The mechanism for loading messages is
lightweight so I suggest there is no need to re-invent that code.


So then, does this warrant a new module, and what is a module anyway?
Why is 'regex' a module, etc?

The original discovery of modules was driven by the observed coupling in
the APIs and implementation of the class library code.  We split up
groups of functionally coherent behaviour, and declared them a module.

Later we decided that we would not split along the API's SPI boundaries
too, so, for example, the LDAP and DNS providers are in the JNDI module,
and the SHA1, PKCS code are in SECURITY module etc.

I see the Pack200 being similar.  It is a provider to the ARCHIVE
module, and by the same reasoning would be part of that module.  The
additional requirements means that I'd ensure it was in a separate
source folder, and a non-Harmony module project made to deliver that
code into a regular OSGi bundle for consumption elsewhere.

Could we have made a different choice about projects?  Sure.  We could
pick finer-grained bundles and pull out all the reusable pieces and
providers into projects/bundles.  I can imagine having at least 3x as
many modules for Harmony [aside: I've always wanted separate test code
projects].

That is how we got to this set of modules and their 'semantic size'.
Could we, or should we, have done it differently?  Maybe, it has worked
well for us so far in terms of resolving multiple contributions, and
switching different implementations (was it 3 RMI's at one point?!).
But like all parents, you know that if you are asked 'why?' enough times
then the answer will eventually be 'because!' <g>.  If we want to
revisit this decision then fine, but let's do so consistently for the
whole project, and not build a patchwork architecture of different local
decisions.

I've seen good-will on both sides to try and get a workable solution.
Let's keep talking until we get a satisfactory resolution.  And in the
meantime,keep hacking on the code :-)

Regards,
Tim

Mime
View raw message