Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
On Thu, May 21, 2015 at 6:40 PM, Yonik Seeley ysee...@gmail.com wrote: It's my opinion that it also wastes everyones time to force them to have a pristine checkout before committing I guess there are two kinds of checks which `ant precommit` tries to combine -- one is checks which influence the quality/correctness of the code which is checked in, and that's probably the vast majority. The stray files check is more of a commit helper, whose impact is limited to the developers working copy, if you violate it and miss files, it should really trigger other issues like compilation or tests in jenkins. I don't know if there are others which fall into this category. One way out may be to remove the stray files check from precommit and instead provide a different wrapper script or ant target which wraps around `svn ci`. That could interactively show unversioned files, and ask questions like do you really want to go ahead and if you say, commit it anyway. Also, have we tried pre-commit hooks before? It certainly won't do all of pre-commit but way we can move some of the svn checks like eol-style etc. there and those can be mandatory.
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
If you have a public method, that refers to a package-private class, nobody can really use that public method you exposed. There is one exception that involves subclasses (not talking about javadoc links to the declaring class now). If you have a package-private class with a public method and inherit (within the same package) to a public class then that method can be used in the public class (and you cannot reduce the visibility of that public method, it remains public). This kind of trick is used to hide scaffolding classes that are exposed from multiple points, for example java.lang.AbstractStringBuilder (pkg-private) and StringBuilder, StringBuffer. I can be a smartass here but only because I painfully and methodically debugged some quirky obfuscation errors resulting from this issue (in proguard)... Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
On Wed, May 20, 2015 at 11:38 PM, Yonik Seeley ysee...@gmail.com wrote: Seems like a bug in javadoc if it fails on valid java code with no javadoc specified on the involved classes. if you'd run ant precommit you would have gotten the same error, and (if you hadn't understood the problem) you could have asked about it before breaking the build. I normally only make sure unit tests pass. Please understand that by taking this attitude you waste everyone else's time who does want to pass ant precommit before committing, and everyone else's time to scan all these broken builds emails. If you truly refuse to pass ant precommit before committing, at least be vigilant and watch the next few builds to see if you broke them, and then fix it quickly. ant precommit is way to picky. I agree it's picky but I think that's a feature, not a bug :) It is this way so it catches common errors that unit tests don't catch: a leftover #nocommit, wrong svn props, forgot to svn add, etc. Over time we've made it more picky each time one of us falls into a trap of forgetting to do XYZ before committing. And in this case it looks like it caught something truly wrong with your change (a public API using a package-private class). Had you run it before hand and paid attention to what it said you could have fixed it... My biggest complaint is how slow it is ... I wish we could improve that. For example it will fail if one as any extra files lying around (which is normally the case for active development / debugging). Doing a clean checkout and re-applying the patch just to make ant precommit happy is too high of a hurdle. My guess is that most committers don't use it for the majority of commits. This is to try to help you remember to svn add files. Why not store such files outside of the source tree? Or maybe we can add them to svn:ignore? Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
For a long while on my local checkout, I have svn:ignore at the root level set to ‘*’. I really think we should consider committing this; I think I’ve advocated for it before. RE “precommit” being a pain — yeah but, like Mike already said, it catches problems. At least it’s faster lately than it used to be months ago. On Thu, May 21, 2015 at 5:16 AM Michael McCandless luc...@mikemccandless.com wrote: On Wed, May 20, 2015 at 11:38 PM, Yonik Seeley ysee...@gmail.com wrote: Seems like a bug in javadoc if it fails on valid java code with no javadoc specified on the involved classes. if you'd run ant precommit you would have gotten the same error, and (if you hadn't understood the problem) you could have asked about it before breaking the build. I normally only make sure unit tests pass. Please understand that by taking this attitude you waste everyone else's time who does want to pass ant precommit before committing, and everyone else's time to scan all these broken builds emails. If you truly refuse to pass ant precommit before committing, at least be vigilant and watch the next few builds to see if you broke them, and then fix it quickly. ant precommit is way to picky. I agree it's picky but I think that's a feature, not a bug :) It is this way so it catches common errors that unit tests don't catch: a leftover #nocommit, wrong svn props, forgot to svn add, etc. Over time we've made it more picky each time one of us falls into a trap of forgetting to do XYZ before committing. And in this case it looks like it caught something truly wrong with your change (a public API using a package-private class). Had you run it before hand and paid attention to what it said you could have fixed it... My biggest complaint is how slow it is ... I wish we could improve that. For example it will fail if one as any extra files lying around (which is normally the case for active development / debugging). Doing a clean checkout and re-applying the patch just to make ant precommit happy is too high of a hurdle. My guess is that most committers don't use it for the majority of commits. This is to try to help you remember to svn add files. Why not store such files outside of the source tree? Or maybe we can add them to svn:ignore? Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
On Thu, May 21, 2015 at 12:55 AM, Robert Muir rcm...@gmail.com wrote: Honestly yonik: this is an API bug. If you have a public method, that refers to a package-private class, nobody can really use that public method you exposed. It's temporary - package private stuff will migrate to public. It's not in it's final form and not meant to be a public API, but some things have to be public for internal cross-package use. My point is that javadoc shouldn't fail stuff that java is happy with. -Yonik - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
On Thu, May 21, 2015 at 8:53 AM, Yonik Seeley ysee...@gmail.com wrote: On Thu, May 21, 2015 at 12:55 AM, Robert Muir rcm...@gmail.com wrote: Honestly yonik: this is an API bug. If you have a public method, that refers to a package-private class, nobody can really use that public method you exposed. It's temporary - package private stuff will migrate to public. It's not in it's final form and not meant to be a public API, but some things have to be public for internal cross-package use. My point is that javadoc shouldn't fail stuff that java is happy with. But it is broken. The checker just tells you reality. If users click that package-private parameter link in the javadocs, they will get a 404 not found. And they wont be able to use the public method, because even though its public, it has a package-private class as parameter. The build did completely the right thing to fail here. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
Please understand that by taking this attitude you waste everyone else's time who does want to pass ant precommit before committing, and everyone else's time to scan all these broken builds emails. +1 personally ... i'm past the point of willing to overlook people who obviously break the build ... ranodmized / timing sensitive test failures are one thing -- but failure to compile, failure to pass precommit ... these are obvious mistakes that can be easily caught in advance, and create blocks preventing for other developers. that's un-fucking-acceptable. If i'm working on something, and discover that a recent commit has broken precommit, I revert. no discussion, no hesitation : It's temporary - package private stuff will migrate to public. It's : not in it's final form and not meant to be a public API, but some : things have to be public for internal cross-package use. Then commit to a branch, or keep it in a patch, or keep it in a github fork. This project has evolved to trying to have the best safe guards we can against broken code making it into the repo -- if people ignore those safe guards, they have no right to complain when the rest of us call them out on their bull shit and/or revert their commits. : My point is that javadoc shouldn't fail stuff that java is happy with. java is happy with nocommit in source files, and @author tags -- that doesn't mean we as a project are. If the most efficient way to find these types of problems is by validating the javadocs -- as opposed to spending a lot of time writting some sort of justom source code analysis -- then so be it. -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
OK Mr grumpy. It's my opinion that it also wastes everyones time to force them to have a pristine checkout before committing And I know for a *fact* that a large number of committers don't run ant precommit before every commit. If i'm working on something, and discover that a recent commit has broken precommit, I revert. no discussion, no hesitation Shrug... I've fixed a number of other peoples commits that have inadvertently broken the build. If it's an easy fix, I'll continue taking that path. Seems both easier and a bit nicer. I'll look into the precommit target to see what other targets that can be run earlier to try and catch bugs w/o forcing one to have a pristine checkout. -Yonik - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
What's the deal with this? BROKEN LINK: file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html FacetMerger.Context has no javadoc! -Yonik On Wed, May 20, 2015 at 8:39 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12585/ Java: 64bit/jdk1.8.0_60-ea-b12 -XX:-UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 60276 lines...] -documentation-lint: [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [exec] [exec] file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/SumAgg.Merger.html [exec] BROKEN LINK: file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html [exec] BROKEN LINK: file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html [exec] [exec] [exec] Broken javadocs links were found! BUILD FAILED /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:536: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:90: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build.xml:621: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build.xml:634: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:2547: exec returned: 1 Total time: 53 minutes 12 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
Seems like a bug in javadoc if it fails on valid java code with no javadoc specified on the involved classes. if you'd run ant precommit you would have gotten the same error, and (if you hadn't understood the problem) you could have asked about it before breaking the build. I normally only make sure unit tests pass. ant precommit is way to picky. For example it will fail if one as any extra files lying around (which is normally the case for active development / debugging). Doing a clean checkout and re-applying the patch just to make ant precommit happy is too high of a hurdle. My guess is that most committers don't use it for the majority of commits. -Yonik - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
On Wed, May 20, 2015 at 11:38 PM, Yonik Seeley ysee...@gmail.com wrote: Seems like a bug in javadoc if it fails on valid java code with no javadoc specified on the involved classes. Why is it a bug in javadoc? It generates plenty of javadoc for your code even if you don't specify it, like method signatures, return types, arguments. And for these links are generated... The current javadocs level is 'protected' so that class isn't included, hence the broken link. Honestly yonik: this is an API bug. If you have a public method, that refers to a package-private class, nobody can really use that public method you exposed. Try it. This is just the only way we currently have to detect API bugs like this. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
: What's the deal with this? : : BROKEN LINK: file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html : : FacetMerger.Context has no javadoc! heh ... Context is everything. the *full* error is telling you that while trying to veryfy the javadocs file SumAgg.Merger.html it found 2 broken links to FacetMerger.Context.html ... the reason the links are broken is because you have a public method (SumAgg.Merger.merge(Object, Context)) that takes as it's argument an instance of an object who's class is not public (Context is declared as a public class, but it's a static inner class of FacetMerger which is a package protected class) .. so it's impossible for the (public) javadocs of SumAgg.Merger.merge to link anywhere explaining what the hell a Context object is. if you'd run ant precommit you would have gotten the same error, and (if you hadn't understood the problem) you could have asked about it before breaking the build. : [exec] Verify... : [exec] : [exec] file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/SumAgg.Merger.html : [exec] BROKEN LINK: file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html : [exec] BROKEN LINK: file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!
The issue is the two broken links coming from SumAgg.Merger to it, thats what the output is supposed to mean: [exec] file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/SumAgg.Merger.html [exec] BROKEN LINK: file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html [exec] BROKEN LINK: file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html in this case a public method refers to a package private class. On Wed, May 20, 2015 at 9:19 PM, Yonik Seeley ysee...@gmail.com wrote: What's the deal with this? BROKEN LINK: file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html FacetMerger.Context has no javadoc! -Yonik On Wed, May 20, 2015 at 8:39 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12585/ Java: 64bit/jdk1.8.0_60-ea-b12 -XX:-UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 60276 lines...] -documentation-lint: [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [exec] [exec] file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/SumAgg.Merger.html [exec] BROKEN LINK: file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html [exec] BROKEN LINK: file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html [exec] [exec] [exec] Broken javadocs links were found! BUILD FAILED /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:536: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:90: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build.xml:621: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build.xml:634: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:2547: exec returned: 1 Total time: 53 minutes 12 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
