harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: [general] JPackage - new opportunity for Harmony?
Date Thu, 15 Nov 2007 20:35:37 GMT
Alexey Petrenko wrote:
> 2007/11/15, Mark Hindess <mark.hindess@googlemail.com>:
>> On 14 November 2007 at 19:57, "Alexey Petrenko"
>> <alexey.a.petrenko@gmail.com> wrote:
>>> One of the Tomcat developers has pointed me to JPackage project[1].
>>> This project is distributing a rather big number of Java based
>>> projects for Linux in common way.  It also distributes JDKs. Now they
>>> have only Sun JDK in their list.
>>> I think it would be good for Harmony to try to participate in this
>>> project.
>>> I've wrote a letter to JPackage discussion list and has received few
>>> favorable responses.
>> Excellent.
>>> So we probably should create JPackage compatible rpm of Harmony and
>>> suggest it for inclusion.
>>> The good thing that we can demonstrate all the benefits of Harmony's
>>> modularity by creating a set of rpms and let the user choose which
>>> parts of Harmony he really needs.
>>> Not so good thing is that we need significant changes to Harmony's
>>> build system to be fully compatible with building Harmony from source
>>> RPM. Which is probably not a requirement for JPackage but a good form
>>> for Linux community.
>> I assume you mean the requirements not to include external
>> libraries/jars?  I've been thinking about this problem a little and am
>> keen to move things forward.
> Yes, exactly. And we also need to remove build of dependencies from
> DRLVM build for example.

+1 here

APR, log4cxx are provided by many distros already. This, however, is not 
true for windows.

>> I added the hy.local.zlib option to remove one such issue but there
>> are many more in terms of jars/libs/fonts/etc that still need to be
>> addressed.  I don't really like the hy.local.zlib option and think that
>> really we need to (re)design the way we handle dependencies consistently
>> across classlib/jdktools/drlvm with support for local/ system and
>> remote/downloaded dependencies.  (The recent icu issue is a good example
>> of the problems that should be avoided by having an accurate, implicit,
>> consistent dependency implementation.)
>>> However we can start from simple binary rpm based on Harmony M3 for
>>> example.
>>> Thoughts? Objections?
>> I don't really use rpm-based distros but I have in the past and a
>> reasonable knowledge of spec files.  I'm happy to help.
> Great!. I think we should start from simple binary RPM based on M3 build.
> SY, Alexey


View raw message