Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
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) [edit] 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) [edit] 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) [edit] 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.
