Created attachment 146522 [details] apache-poi.diff textproc/apache-poi is marked as broken, for it downloads some files through building process. fix this problem by downloading necessary files as distfile. Fix: here is a patch:
no testlogs required, should be testable by committer.
Created attachment 146615 [details] Update apache-poi to version 3.10.1 I (independently) also fixed apache-poi by setting MANUAL_PACKAGE_BUILD. The original patch in this PR is probably better for cluster builds, but mine is easier to maintain. Most importantly though, I updated it to version 3.10.1 as there are serious vulnerabilities in the original version: "The Apache POI team is pleased to announce the release of 3.10.1. This release is a bugfix release to fix two security issues with OOXML (CVE-2014-3529 and CVE-2014-3574), relating to external entity expansion and so-called XML bombs in OOXML documents. ..." Both patches add staging support,
Pedro, I don't really like this MANUAL_PACKAGE solution. turutani solved the problem already, can't you update your 3.10.1 patch to solve it the same way? And we need to be fast, the port is due to be removed in 8 days.
(In reply to John Marino from comment #3) > Pedro, I don't really like this MANUAL_PACKAGE solution. turutani solved > the problem already, can't you update your 3.10.1 patch to solve it the same > way? > I tried this but it doesn't work too well (will update it soon). Actually I used turutani's patch and then updated the package to version 3.10.1. > And we need to be fast, the port is due to be removed in 8 days. As I said, the package is not easy to maintain. I prefer the MANUAL_PACKAGE solution until a better solution is found for ports using Maven to build.
IFAIK, there are several ports that use maven that have worked around this issue without crippling the port with MANUAL_PACKAGE_BUILD. I don't think you need to re-invent the wheel here.
obviously the issue here is that I can't test this port in poudriere, which I would really like to do.
Created attachment 147529 [details] Attempt to prefetch the Maven files This patch attempts to apply turutani-san's patch approach. It still misses to fetch a couple of files but I am short on time today. Perhaps we could use the MANUAL_PACKAGE approach for now and leave the pre-fetching as a WIP for later? This port is required for Apache OFBiz and it would be a shame to lose it or start from scratch.
Created attachment 147534 [details] Pre-fetching the Maven files Update: I found time and I finished prefetching the missing files. Mileage may vary though, no guarantees, slippery when wet, etc...
(In reply to John Marino from comment #5) > IFAIK, there are several ports that use maven that have worked around this > issue without crippling the port with MANUAL_PACKAGE_BUILD. I don't think > you need to re-invent the wheel here. For the record ... The problem is much bigger than just fetching files for an individual port and remains unsolved: Maven pretends to solve basically the same issues as the ports tree but we can't really treat it as a ports tree within each port. We should at least share a distdir for all files originating at Maven to avoid carrying multiple copies of the same tarballs in each port distdir. It is also somewhat crazy that we can't reuse our native ports instead of maven dependencies, but the problem is rather complex to solve and I don't really have a solution.
How about install pre-compiled binary?
Pedro, is distinfo complete? > portlint WARN: Makefile: USE_ANT is intended only for ports that build with Ant. It is recommended not to override the default 'do-build:' target when defining USE_ANT FATAL: /usr/home/marino/svnhub/freebsd-ports/textproc/apache-poi/distinfo: has no SIZE record for apache-poi/xmlbeans-2.6.0.jar. FATAL: /usr/home/marino/svnhub/freebsd-ports/textproc/apache-poi/distinfo: no checksum record for apache-poi/xmlbeans-2.6.0.jar. WARN: /usr/home/marino/svnhub/freebsd-ports/textproc/apache-poi/distinfo: no checksum records for all supported algorithms (SHA256) for apache-poi/xmlbeans-2.6.0.jar. 2 fatal errors and 2 warnings found. It seems that xmlbeans entry is missing?
(In reply to Vanilla I. Shu from comment #10) > How about install pre-compiled binary? I hate to admit it, since I thought it was preferable to rebuild such things, but for this port it is a good idea.
(In reply to Pedro F. Giffuni from comment #12) > (In reply to Vanilla I. Shu from comment #10) > > How about install pre-compiled binary? > > I hate to admit it, since I thought it was preferable to rebuild such > things, but for this port it is a good idea. So DragonFly users don't need / don't want this port?
(In reply to John Marino from comment #13) > (In reply to Pedro F. Giffuni from comment #12) > > (In reply to Vanilla I. Shu from comment #10) > > > How about install pre-compiled binary? > > > > I hate to admit it, since I thought it was preferable to rebuild such > > things, but for this port it is a good idea. > > So DragonFly users don't need / don't want this port? I don't understand why not: Java bytecode is very portable and we have many other ports (beanshell, for example) that don't bother with sources.
Created attachment 147650 [details] Update: Pre-fetching the Maven files Update with missing checksum: sorry for the delay but I had to figure out how to trick the ports tree about the new pkg version.
Created attachment 147653 [details] install pre-compiled binary version. install pre-compiled binary version.
(In reply to Vanilla I. Shu from comment #16) > Created attachment 147653 [details] > install pre-compiled binary version. > Looks good to me, and it's much easier to maintain. Thanks!
A commit references this bug: Author: marino Date: Thu Sep 25 11:23:45 UTC 2014 New revision: 369238 URL: http://svnweb.freebsd.org/changeset/ports/369238 Log: Unbreak textproc/apache-poi to save the port from deletion PR: 193142 1st Proposal: turutani (kyoto) 2nd Proposal: pfg@ winner: vanilla@ In the final iteration, the Maven infrastructure was removed in favor of a precompiled binary which provides the bonus of a simpler makefile in additional to being poudriere-compatible. Changes: head/textproc/apache-poi/Makefile head/textproc/apache-poi/distinfo
Thanks, everyone, for all the contributions!
(In reply to John Marino from comment #19) > Thanks, everyone, for all the contributions! Yeah thanks thanks for the patience !! BTW, this also saves databases/jasperreports from deprecation.
(In reply to Pedro F. Giffuni from comment #20) > BTW, this also saves databases/jasperreports from deprecation. Only if jasperreports has no separate issues, which I'm not positive is the case. Somebody should take the initiative to built jasperreports in poudriere and see if that's successful. Also, it would be interesting to know if jasperreports is at the latest version or conversely is several versions behind. If the latter, and nobody has bothered to maintain it, it might still be worth removing. In other words, I didn't remove the expiration flag from jasperreports simply because apache-poi is fixed. It needs a separate review IMO.