A Java Packaging Wishlist

Paul Cager · External Since: Nov 30, 2006 Posts: 123

Late-night, random thoughts about what would be useful for us Debian
Java packagers. Any comments?

dh_installjars
==============

A new debhelper command:

* Installs Jars into usr/share/java directory, adding correct
version number suffix (as parsed from the changelog).

* Adds required symlink.

* Arguments specify required Jars (with or without the version
number suffix), or directories that will be scanned for Jars.

* Can read a "jars" file to get the list of jars (in the same
way dh_installdocs reads "docs").

If people think this is useful I might email Joey Hess to see if he
would be likely to accept a patch.

Cdbs Enhancements
=================

* /usr/share/cdbs/1/rules/debhelper.mk to add call to
dh_installjars.

* Amend ant.mk / ant-vars.mk to install Javadocs in the correct
place (dependent on setting a new DEB_ANT_xx variable).

dh_make enhancements
====================

* When invoking dh_make (with cdbs option) in a directory with a
build.xml, pkg-java "standard" rules/control files are created,
including a separate "-doc" package etc.

* When invoked with a pom.xml a pkg-java standard package is created,
and the pom is parsed to fill out skeleton entries in control,
copyright etc:

- authors
- licenses
- download location / svn repos
- dependencies

--
To UNSUBSCRIBE, email to debian-java-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Arnaud Vandyck · External Since: Nov 14, 2006 Posts: 44

Excellent proposal!

On 5/22/07, Paul Cager <paul-debian DeleteThis @home.paulcager.org> wrote:
> Late-night, random thoughts about what would be useful for us Debian
> Java packagers. Any comments?
>
> dh_installjars
> ==============
>
> A new debhelper command:
>
> * Installs Jars into usr/share/java directory, adding correct
> version number suffix (as parsed from the changelog).
>
> * Adds required symlink.
>
> * Arguments specify required Jars (with or without the version
> number suffix), or directories that will be scanned for Jars.
>
> * Can read a "jars" file to get the list of jars (in the same
> way dh_installdocs reads "docs").
>
> If people think this is useful I might email Joey Hess to see if he
> would be likely to accept a patch.
>
>
> Cdbs Enhancements
> =================
>
> * /usr/share/cdbs/1/rules/debhelper.mk to add call to
> dh_installjars.
>
> * Amend ant.mk / ant-vars.mk to install Javadocs in the correct
> place (dependent on setting a new DEB_ANT_xx variable).
>
> dh_make enhancements
> ====================
>
> * When invoking dh_make (with cdbs option) in a directory with a
> build.xml, pkg-java "standard" rules/control files are created,
> including a separate "-doc" package etc.
>
> * When invoked with a pom.xml a pkg-java standard package is created,
> and the pom is parsed to fill out skeleton entries in control,
> copyright etc:
>
> - authors
> - licenses
> - download location / svn repos
> - dependencies
>
>
> --
> To UNSUBSCRIBE, email to debian-java-REQUEST DeleteThis @lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org
>
>

--
Arnaud Vandyck

--
To UNSUBSCRIBE, email to debian-java-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

manfred · External Since: Feb 26, 2007 Posts: 21

I will some more:

- Support Maven builds and be able to read dependencies from the maven
pom.xml file and translate them to the debian control file entries for
dependencies and run dependencies.

- have a sort of meta information for provides for the major versions
of the JDK/JRE e.g. requires/provides java5-runtime, java6-runtime,
java7-runtime, java5-developmentkit and so on

- have a meta information appservers e.g. requires/provides javaee5-appserver

potentially this could all be based on the JSR numbers where the
different implementing packages include a provides -
jsrxxx-implementation

manfred

Quoting Arnaud Vandyck <avdyk RemoveThis @debian.org>:

> Excellent proposal!
>
> On 5/22/07, Paul Cager <paul-debian RemoveThis @home.paulcager.org> wrote:
>> Late-night, random thoughts about what would be useful for us Debian
>> Java packagers. Any comments?
>>
>> dh_installjars
>> ==============
>>
>> A new debhelper command:
>>
>> * Installs Jars into usr/share/java directory, adding correct
>> version number suffix (as parsed from the changelog).
>>
>> * Adds required symlink.
>>
>> * Arguments specify required Jars (with or without the version
>> number suffix), or directories that will be scanned for Jars.
>>
>> * Can read a "jars" file to get the list of jars (in the same
>> way dh_installdocs reads "docs").
>>
>> If people think this is useful I might email Joey Hess to see if he
>> would be likely to accept a patch.
>>
>>
>> Cdbs Enhancements
>> =================
>>
>> * /usr/share/cdbs/1/rules/debhelper.mk to add call to
>> dh_installjars.
>>
>> * Amend ant.mk / ant-vars.mk to install Javadocs in the correct
>> place (dependent on setting a new DEB_ANT_xx variable).
>>
>> dh_make enhancements
>> ====================
>>
>> * When invoking dh_make (with cdbs option) in a directory with a
>> build.xml, pkg-java "standard" rules/control files are created,
>> including a separate "-doc" package etc.
>>
>> * When invoked with a pom.xml a pkg-java standard package is created,
>> and the pom is parsed to fill out skeleton entries in control,
>> copyright etc:
>>
>> - authors
>> - licenses
>> - download location / svn repos
>> - dependencies
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-java-REQUEST RemoveThis @lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmaster RemoveThis @lists.debian.org
>>
>>
>
>
> --
> Arnaud Vandyck
>
>
> --
> To UNSUBSCRIBE, email to debian-java-REQUEST RemoveThis @lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Arnaud Vandyck · External Since: Oct 30, 2006 Posts: 66

On 5/22/07, manfred DeleteThis @mosabuam.com <manfred DeleteThis @mosabuam.com> wrote:
> I will some more:
>
> - Support Maven builds and be able to read dependencies from the maven
> pom.xml file and translate them to the debian control file entries for
> dependencies and run dependencies.

We must first have maven in main!.. That's not so easy Wink

--
Arnaud Vandyck

--
To UNSUBSCRIBE, email to debian-java-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

manfred · External Since: Feb 26, 2007 Posts: 21

Quoting Arnaud Vandyck <avandyck RemoveThis @gmail.com>:

> On 5/22/07, manfred RemoveThis @mosabuam.com <manfred RemoveThis @mosabuam.com> wrote:
>> I will some more:
>>
>> - Support Maven builds and be able to read dependencies from the maven
>> pom.xml file and translate them to the debian control file entries for
>> dependencies and run dependencies.
>
> We must first have maven in main!.. That's not so easy Wink

I know. But work is being done on that. We might as well plan towards
harnessing the power we gain as soon as it is in and we are able to
use it.

In the meantime Michael Koch provides a binary maven package that can
be used for developing these features.

manfred

--
To UNSUBSCRIBE, email to debian-java-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Arnaud Vandyck · External Since: Oct 30, 2006 Posts: 66

On 5/22/07, manfred.RemoveThis@mosabuam.com <manfred.RemoveThis@mosabuam.com> wrote:
> Quoting Arnaud Vandyck <avandyck.RemoveThis@gmail.com>:
> > On 5/22/07, manfred.RemoveThis@mosabuam.com <manfred.RemoveThis@mosabuam.com> wrote:
> >> - Support Maven builds
> > We must first have maven in main!.. That's not so easy Wink

> I know. But work is being done on that. We might as well plan towards
> harnessing the power we gain as soon as it is in and we are able to
> use it.

You are right...

> In the meantime Michael Koch provides a binary maven package that can
> be used for developing these features.

His work couldn't be used for that at the moment because the maven
binary package will never reach 'main' as is. And we can't relay on
contrib or non-free package to build all our packages.

Anyway, it's a cool idea.

--
Arnaud Vandyck

--
To UNSUBSCRIBE, email to debian-java-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Paul Cager · External Since: Nov 30, 2006 Posts: 123

manfred RemoveThis @mosabuam.com wrote:
> I will some more:
>
> - Support Maven builds and be able to read dependencies from the maven
> pom.xml file and translate them to the debian control file entries for
> dependencies and run dependencies.

The maven pom certainly contains lots of the information you need to
create a Debian package - dependencies, authors, licenses etc.

By the way, I wasn't quite sure how you were suggesting this information
should be used:

- at package *creation* time (i.e. when you first create the
debian/rules, debian/copyright files etc, possibly using dh_make)

- at package *build* time (e.g. when you run debuild).

I think using the information at package *creation* time is a good idea;
I listed a few ideas in my original email. The automatic tools would
create a skeleton packaging which could be amended by the packager.

But I'm not so sure about dynamically generating dependency information
at package build time. Did you see the discussion earlier this month
about "java dependency substvars"?

Regards,
Paul

--
To UNSUBSCRIBE, email to debian-java-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Manfred Moser · External Since: Mar 04, 2007 Posts: 9

On Tuesday May 22 2007, Arnaud Vandyck wrote:
> > In the meantime Michael Koch provides a binary maven package that
> > can be used for developing these features.
>
> His work couldn't be used for that at the moment because the maven
> binary package will never reach 'main' as is. And we can't relay on
> contrib or non-free package to build all our packages.
>
> Anyway, it's a cool idea.

Assuming that his binary package runs maven as distributed by upstream
and the final debin package will do so as well, which was discussed
as an aim at an earlier stage here as far as I understand it would
actually be feasible to use the binary package for developing these
processes now.

Anyway.. just an idea. Integrating maven will include lots of other
tasks like a debian build system private repository and so on.

manfred
--
Manfred Moser
http://www.mosabuam.com
skype: mosabua
http://www.linkedin.com/in/manfredmoser

--
To UNSUBSCRIBE, email to debian-java-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Manfred Moser · External Since: Mar 04, 2007 Posts: 9

On Tuesday May 22 2007, Paul Cager wrote:
> manfred.DeleteThis@mosabuam.com wrote:
> > I will some more:
> >
> > - Support Maven builds and be able to read dependencies from the
> > maven pom.xml file and translate them to the debian control file
> > entries for dependencies and run dependencies.
>
> The maven pom certainly contains lots of the information you need
> to create a Debian package - dependencies, authors, licenses etc.
>
> By the way, I wasn't quite sure how you were suggesting this
> information should be used:
>
> - at package *creation* time (i.e. when you first create the
> debian/rules, debian/copyright files etc, possibly using dh_make)
>
> - at package *build* time (e.g. when you run debuild).
>
> I think using the information at package *creation* time is a good
> idea; I listed a few ideas in my original email. The automatic
> tools would create a skeleton packaging which could be amended by
> the packager.

That was mostly what I was thinking of. Potentially it could also be
run on updates from upstream. That might be a bit harder. In an ideal
world a java developer that has no idea about packaging could use
some sort of maven plugin that actually uses all this and creates a
debian package... that might be a hard level to get to though.

> But I'm not so sure about dynamically generating dependency
> information at package build time. Did you see the discussion
> earlier this month about "java dependency substvars"?

I missed that discussion. I do assume that with some sort of lookup
list of "debian" approved/included dependencies even that might be
possible. Certainly something to be considered as a second step once
the creation time works Wink

--
Manfred Moser
http://www.mosabuam.com
skype: mosabua
http://www.linkedin.com/in/manfredmoser

--
To UNSUBSCRIBE, email to debian-java-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Trygve_Laugstøl · External Since: Mar 05, 2007 Posts: 8

Arnaud Vandyck wrote:
> On 5/22/07, manfred RemoveThis @mosabuam.com <manfred RemoveThis @mosabuam.com> wrote:
>> I will some more:
>>
>> - Support Maven builds and be able to read dependencies from the maven
>> pom.xml file and translate them to the debian control file entries for
>> dependencies and run dependencies.
>
> We must first have maven in main!.. That's not so easy Wink

Why do you need Maven in main first? There shouldn't be any issues using
Maven's metadata to generate the control file nor generating a build.xml
file.

--
Trygve

--
To UNSUBSCRIBE, email to debian-java-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Arnaud Vandyck · External Since: Nov 14, 2006 Posts: 44

On 5/23/07, Trygve Laugstøl <trygvis.RemoveThis@apache.org> wrote:
> Arnaud Vandyck wrote:
[...]
> > We must first have maven in main!.. That's not so easy Wink

> Why do you need Maven in main first? There shouldn't be any issues using
> Maven's metadata to generate the control file nor generating a build.xml
> file.

If we wanna use maven to build, we need maven in main. If we want to
extract metadata, we just need an xslt or some
perl/python/java/whatever xml parser.

--
Arnaud Vandyck

Trygve_Laugstøl · External Since: Mar 05, 2007 Posts: 8

Arnaud Vandyck wrote:
> On 5/23/07, Trygve Laugstøl <trygvis.DeleteThis@apache.org> wrote:
>> Arnaud Vandyck wrote:
> [...]
>> > We must first have maven in main!.. That's not so easy Wink

>> Why do you need Maven in main first? There shouldn't be any issues using
>> Maven's metadata to generate the control file nor generating a build.xml
>> file.
>
> If we wanna use maven to build, we need maven in main. If we want to
> extract metadata, we just need an xslt or some
> perl/python/java/whatever xml parser.

No you don't. I meant that you can use Maven to generate the files and
include in debian/. That way you can leverage the project's meta-data
and start working on integration Maven into the build process until it
is properly into main and those files can be generated build-time.

--
Trygve

--
To UNSUBSCRIBE, email to debian-java-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Arnaud Vandyck · External Since: Oct 30, 2006 Posts: 66

On 5/26/07, Trygve Laugstøl <trygvis.RemoveThis@apache.org> wrote:
> Arnaud Vandyck wrote:
> > If we wanna use maven to build, we need maven in main. If we want to
> > extract metadata, we just need an xslt or some
> > perl/python/java/whatever xml parser.
>
> No you don't. I meant that you can use Maven to generate the files and
> include in debian/. That way you can leverage the project's meta-data
> and start working on integration Maven into the build process until it
> is properly into main and those files can be generated build-time.

I don't like the idea of generating those files at build time. But
maybe I don't understand what you mean.

Anyway, tools used to generate and build debian package are in main so
if we want to include maven calls in those scripts, we need maven to
be in main.

--
Arnaud Vandyck

Manfred Moser · External Since: Mar 04, 2007 Posts: 9

On Saturday May 26 2007, Arnaud Vandyck wrote:
> On 5/26/07, Trygve Laugstøl <trygvis.TakeThisOut@apache.org> wrote:
> > Arnaud Vandyck wrote:
> > > If we wanna use maven to build, we need maven in main. If we
> > > want to extract metadata, we just need an xslt or some
> > > perl/python/java/whatever xml parser.
> >
> > No you don't. I meant that you can use Maven to generate the
> > files and include in debian/. That way you can leverage the
> > project's meta-data and start working on integration Maven into
> > the build process until it is properly into main and those files
> > can be generated build-time.
>
> I don't like the idea of generating those files at build time. But
> maybe I don't understand what you mean.

Sorry to be unclear. I meant at the time when you are first assembling
the package from the upstream source. The information in the pom can
be used to derive a lot of data in the debian control files.

In addition when another version is available from upstream the pom
content can be verified back into the control files to do amendments.
That wont be fully automatic of course.

manfred

--
Manfred Moser
http://www.mosabuam.com
skype: mosabua
http://www.linkedin.com/in/manfredmoser

Trygve_Laugstøl · External Since: Mar 05, 2007 Posts: 8

Arnaud Vandyck wrote:
> On 5/26/07, Trygve Laugstøl <trygvis DeleteThis @apache.org> wrote:
>> Arnaud Vandyck wrote:
>> > If we wanna use maven to build, we need maven in main. If we want to
>> > extract metadata, we just need an xslt or some
>> > perl/python/java/whatever xml parser.
>>
>> No you don't. I meant that you can use Maven to generate the files and
>> include in debian/. That way you can leverage the project's meta-data
>> and start working on integration Maven into the build process until it
>> is properly into main and those files can be generated build-time.
>
> I don't like the idea of generating those files at build time. But
> maybe I don't understand what you mean.

I think you understood me correctly. There is nothing wrong with
generated files, there are already lots of them begin built on every
..deb build. I know it's not ideal to check in generated files, but given
the benefit it shouldn't be a big problem.

I made a Maven 2 plugin for this over *3* years ago [1], but still
no-one has been able to leverage any of the metadata in Maven.

> Anyway, tools used to generate and build debian package are in main so
> if we want to include maven calls in those scripts, we need maven to
> be in main.

Yes, do be a integral part of the build cycle it has to be. But it does
not have to be there to be able to leverage a lot of the information
that is inside every Maven-based project.

[1]: Probably even earlier than that, but that was when the repository
was initialized: http://fisheye.codehaus.org/changelog/mojo?cs=5

--
Trygve

--
To UNSUBSCRIBE, email to debian-java-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org