If a eant build needs to fetch files, it will fail behind proxy. There is no way to tell add -Dhttp.proxyHost=... -Dhttp.proxyPort=... to the ant command line, since ANT_OPTS is unset. antflags in /usr/portage/eclass/java-utils-2.eclass cannot be changed from outside. example: try emerge =dev-java/itext-2.0.0 behind proxy.
(In reply to comment #0) > If a eant build needs to fetch files, it will fail behind proxy. > There is no way to tell add -Dhttp.proxyHost=... -Dhttp.proxyPort=... to the > ant command line, since ANT_OPTS is unset. antflags in > /usr/portage/eclass/java-utils-2.eclass cannot be changed from outside. > > example: try emerge =dev-java/itext-2.0.0 behind proxy. > Usually if something needs to fetch something from the internet during eant, it's a bug and you should file bug requests to stop the package in question from doing that.
I moved 2.0.0 back to ~arch because it seems it was by mistake put straight to stable keywords. 1.4.8 does not have this downloading problem.
Packaged downloaded deps, and updated itext-2.0.x to use the system installed versions. Bumped ebuild to latest version at same time. Closing bug since it it's been resolved.
Now it compiles and installs (version 2.0.1) but still spends some time, till timeout, trying to fetch 2 files during doc creation [javadoc] javadoc: warning - Error fetching URL: http://java.sun.com/j2se/1.3/docs/api/package-list [javadoc] javadoc: warning - Error fetching URL: http://www.bouncycastle.org/docs/docs1.4/package-list
Fixed in CVS. Maybe we could strip <link> elements from <javadoc> by rewriting?
Well links in docs aren't a bad thing. Question is why is ant trying to resolve the links instead of just adding them to file. Makes no sense why it needs to resolve or hit said links. Which is what seems to be the real problem. Not the links existence.
(In reply to comment #6) > Well links in docs aren't a bad thing. Question is why is ant trying to resolve > the links instead of just adding them to file. Makes no sense why it needs to > resolve or hit said links. Which is what seems to be the real problem. Not the > links existence. > Probably worth taking upstream. It's most likely not ant resolving them but the javadoc code itself so we should be asking Sun engineers.
Great so we will get an answer in a few years :)
(In reply to comment #8) > Great so we will get an answer in a few years :) > Yeah so open a new one if you want to track that issue. itext is fixed and well.
Well commenting out and removing the links from said docs is not what I would consider fixed. More like a band aid to resolve current problem. But now links are missing from docs. Which is kinda moot, but a deviation from upstream. I thought our course of action per discussion on IRC was to download and use the itext provided java docs? Which I started to do a rev bump on but was short on time. Removing those links basically breaks all references from iText's javadocs to other javadocs. Not sure if that matters at all, but removing them does have an effect on the resulting docs. Thus my re-opening bug till a proper fix or solution is in place.
(In reply to comment #6) > Well links in docs aren't a bad thing. Question is why is ant trying to resolve > the links instead of just adding them to file. Makes no sense why it needs to > resolve or hit said links. Which is what seems to be the real problem. Not the > links existence. It's simple (I think, I haven't researched it though :) feel free to). Links are optional parameters to javadoc, telling it that it can look for the apidocs of external libraries (java packages) there. But you give it only bunch of links, you don't tell it what link is for what packages. See, here are the links I patched out of build.xml: - <link href="http://java.sun.com/j2se/1.3/docs/api/" />^M - <link href="http://www.bouncycastle.org/docs/docs1.4/" />^M No sign of what link is for what packages. So javadoc is trying to fetch package-list at that URLs to determine the packages. Not sure if one can override this fetch by giving the package list explicitly, but it would be clumsy for sure. (In reply to comment #10) > I thought our course of action per discussion on IRC was to download and use > the itext provided java docs? Which I started to do a rev bump on but was short > on time. Blah, use provided java docs just for this? Nonsense. > Removing those links basically breaks all references from iText's javadocs to > other javadocs. Not sure if that matters at all, but removing them does have an > effect on the resulting docs. Thus my re-opening bug till a proper fix or > solution is in place. So what, some external links (half of them go to obsolete 1.3 JDK javadocs) are missing in our install. Big deal. And it's only because upstream cared to add them to build.xml. Most others don't. Not systematic at all. I think the only pretty solution would be to point the links to the installed javadocs of the said external packages, instead of to the online javadocs. Bug 145750 is about that.
(In reply to comment #11) > Blah, use provided java docs just for this? Nonsense. Ok no worries. Forgot you weren't around for that discussion was just me and Betelgeuse. No worries, we won't use the premade docs. But then again I am not sure there is any benefit to us compiling/making javadocs. Or using pre-built javadocs if they are available. > So what, some external links (half of them go to obsolete 1.3 JDK javadocs) are > missing in our install. Good point :) > Big deal. And it's only because upstream cared to add them to build.xml. Assumed they did such for a reason. > Most others don't. Not systematic at all. I think the only > pretty solution would be to point the links to the installed javadocs of the > said external packages instead of to the online javadocs. Bug 145750 is about > that. Yes :) but that would likely be contingent on doc USE flag being set or not with installed external packages.
