I suggest we get the first release out and include the jar in the release. I agree with David that this may take away a lot of the issues of user and developer convenience. If it doesn't, we should revisit.
Chad On 4/10/09 9:13 PM, "David Reiss" <[email protected]> wrote: > Why do you object so strongly to having binaries in the source tree? - It bloats the size of the repository, making checkouts slower. - The source is not available for users to inspect. - It requires that the Thrift developers keep the jar up to date, weigh the benefits and drawbacks of upgrading, etc. These are just the ones I have thought of off the top of my head. I suppose it is the same reason we don't include boost, libevent, or even a JDK. > It's not going to suck up that much size, The log4j jar is 50% the size of a tar.gz of the Thrift source. > and it greatly simplifies things. apt-get install liblog4j1.2-java problem solved. > For casual developers or users, I am less opposed to putting the jar in the release tarballs or instant releases. (I hope you saw my other reply. Sorry the thread got forked. Users should probably be using these instead of svn. > or those who don't use the > java libraries, it'll mean "make check" actually passes simply. I can extend ax_javac_and_java.m4 to be able to check for a specific class. We can just disable java if log4j isn't available. > An alternative would be to use maven to fulfill the dependencies, I think we should start buy updating this page <http://wiki.apache.org/thrift/ThriftRequirements> so that users will at least know how to build Thrift if they do not have Maven. > but > I don't really have any personal experience with that. If someone > wanted to contribute to that approach, I'd be pretty pumped. +1. There was an issue about this filed by someone who presumably knows what they are doing. Maybe we should follow up with him. --David
