Bug#432350: ITP: libicu4j-java -- Library for unicode support and internalisation (fwd)

[Andreas Tille]

Pantelis, I hope you don't mind if I foreward your PM to the list.
Everybody is invited to join this effort.  Hopefully it is not me alone
who is interested in working on this.

Kind regards

        Andreas.

-- 
http://fam-tille.de

---------- Forwarded message ----------
Date: Mon, 15 Dec 2008 16:30:54 +0200
From: Pantelis Koukousoulas <pktoss at gmail.com>
To: Andreas Tille <tillea at rki.de>
Subject: Re: Bug#432350: ITP: libicu4j-java -- Library for unicode support and
     internalisation (fwd)

> As I said I would like to support this process as best as I can. If
> it comes to sophisticated Java issues I can not help - but polishing
> a nearly finished package is no problem.

Well, there are quite a few "small packaging jobs" that need to be
done as you see and
these require practically no java experience. Luckily for us, fedora
has done most of the
"hard work" and we mainly need to "steal" the right bits and adapt
them to debian.

> So the package was uploaded right now but needs some time for ftpmaster
>processing because it was the first Debian upload.

This is not a problem since it doesn't block the development :)

>
>> FWIW, I might have some insight as to why the icu4j and jsch packages
>> were inside the eclipse package before.
>>
>> The issue seems to be that OSGi (the runtime environment eclipse is
>> based on) places some requirements on the java packages'  Manifest.MF
>> file [ .... ]
>> (See: http://fedoraproject.org/wiki/Features/Eclipse34)
>
> I have no deeper insight into this and just trusted the changelog
> entry
>
>    * Builds Eclipse-compatible version of jar.
>
> Looking twice at the things I commited I see that the diff contains
> files outside the debian directory which are touched.  I like to put
> this into patches using quilt to make sure the package can build from
> SVN + uspstream source (which currently is not the case because
> pluginBuild.xml is missing in the source and build.xml was touched).
> I will apply this using quilt to make sure any other maintainer of the
> team is able to build the package smoothly.
>
> If the changes you are mentioning for Manifest.MF should be also
> applied in a patch just tell me what changes are needed.

Well, we can reuse the Fedora patches to a large extent. The link
I 've sent you (http://fedoraproject.org/wiki/Features/Eclipse34) has
a table with the packages (dependencies) they had to change
and what they did.

The fedora patches are in a CVS repo:

cvs -d :pserver:anonymous at cvs.fedoraproject.org:/cvs/pkgs co devel

(Note that this is pretty big and you might want to checkout  specific
packages instead:
e.g.,
cvs -d :pserver:anonymous at fedoraproject.org:/cvs/pkgs co devel/jsch

or get a .tgz with everything
http://cvs.fedoraproject.org/webfiles/devel.tgz
)

> You mean namely the jsch package?  Anybody has some preliminary package
> to test?
>

Well, according the link above, quite a few packages had to be touched
or at least reviewed:

jsch, icu4j, jetty, liblucene2-java etc

The changes for each package are trivial though, pretty much just
small additions/modifications
(like the Manifest.MF) to non-java files.

The jsch package version already in debian seems ok, so you can start
from that and maybe add one
or more patches from Fedora.

You are welcome to ask any questions if I 'm not explaining things
well enough btw, both via email
and on #debian-java (I 'm pktoss)

Cheers,
Pantelis