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:33:33 GMT
Mark Hindess wrote:
> 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.
> 
> 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.)

I've argued with Geir since the beginning that I'd like to see Harmony 
using dependencies from the installed distros as must as it is possible 
while Geir insisted that we link statically when we can. Things played 
in the favor of my POV a bit when it appeared that on x86_64 linking 
statically with jpeg, png and lcms simply doesn't work as these packages 
built statically by distros are not built as relocatable code, and we 
don't want to distribute our own versions of jpeg, png and lcms binaries.

Geir however has got a point since only a binary JRE is certified as a 
Java(TM). For example Sun distributes its JRE with the above libraries 
linked statically.

The list of Harmony dependencies goes much farther than just graphical 
libraries. And handling them should be more flexible than it is done 
currently. Why do you not like hy.local.zlib? Something like that I've 
been thinking about, making more packages to be taken from local 
installation to allow tighter integration with packages that distros create.

>> 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.
> 
> Regards,
>  Mark.
> 
> 
> 


-- 
Gregory


Mime
View raw message