harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [general] JPackage - new opportunity for Harmony?
Date Thu, 15 Nov 2007 05:14:26 GMT
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.
Nice, indeed.

> > 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.)

Agree, this is a real nag. The common_resources aren't work as
intended, every module is dancing differently. BTW, the BTI solves the
same problem once again and I guess Stepan is not quite happy in that
- shouldn't there be a reusable solution?

>
> > 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.
>
>
>

Mime
View raw message