Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

On http://jakarta.apache.org/commons/fileupload/ version 1.1.1 of
commons-fileupload is available. An ebuild is currently only available for
version 1.0. Version 1.1 is available for half a year but no ebuild has been
made for it.

Initial ebuild here:
https://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/dev-java/commons-fileupload

This does not work yet because we don't have portlet-api packaged. 

Created an attachment (id=97433) [details]
commons-fileupload-1.1.1.ebuild

Has dependency to dev-java/portletapi-1.0 which is not in portage and might
even change name or version in future.

Created an attachment (id=97434) [details]
commons-fileupload-1.1.1-gentoo.patch

The most up-to-date ebuild can be found here:
http://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/dev-java/commons-fileupload/

Added to portage. Thanks for contributing!

One thing to watch out for: make sure you run 'repoman full' in the directory
of the ebuild. This does some things like checking the sanity in the depends.
In particular, your ebuild for portletapi didn't have keywords for ppc and
ppc64, but this ebuild did, and commons-io was missing ppc64 keywords.

Please don't blame me because I'm reopening this bug. But I don't want to open
an new bug for the following issue:

commons-fileupload-1.1.1 depends on commons-io-1.1 but you added the dependency

=dev-java/commons-io-1*

If you download the source tar.gz from commons-fileupload you can see this
dependency in the project.xml file for Maven line 165. So I think the
dependency should be something like:

>=dev-java/commons-io-1.1

Unfortunately portage doesn't support depending on a specific SLOT (used for
compatible versions of the package) so here I used the dependancy
=dev-java/commons-io-1* to make the package depend on version 1.x which is in
SLOT="1". This is safer than depending on >=dev-java/commons-io-1.1 which could
cause problems when commons-io-2.0 arises which may (or may not) have
incompatible API.

So, you are correct, but because portage doesn't support depending on a
specific SLOT, I used that dependancy.

Created an attachment (id=99316) [details]
patch for commons-fileupload-1.1.1 (in tree)

So you were right with the dependency and my solution doesn't work.
commons-fileupload-1.1.1 doesn't compile with commons-io-1.0. Here is a patch
that solves it. Thanks.

Fixed, thanks. Hopefully we will have bug 150368 solved before some new slot of
commons-io hits the tree :) Thanks for giving me an example for that bug.