Dnia 2014-04-12, sob o godzinie 20:15 -0500, Gregg Wonderly pisze: > There are very few things about River’s “jars” that are cast in stone.
Everything is cast in stone for me until I can understand the project structure. Part of the problem is that whole River *source* comes in one big bucket of spaghetti. It's difficult to see where the classes go without checking build.xml. Then we have the classenddepjar: one class goes to multiple jars and might end up in classloaders with different classpaths. It's hard to maintain its configuration, actually it has to be "tuned" to achieve desired result. How do I know I don't get CNFE on some untested path in production? These problems don't exist in todays projects. Without source structure reflecting modules and clear dependencies it's really hard to see the big picture. I can't see the boundaries of the modules, nor how do they interact without first reading all of it. > I know that it is “work” to create a build system if you need something > different than what something comes distributed with. But, that’s the > question here. If the build system is keeping people from contributing, then > why isn’t there a “github” distribution of the appropriate tooling that > everyone can try and see how much better it is? Every build based on Ant is custom while the majority of projects built with Maven is purely standard. > I am one of those developers who will only waste/spend so much time > fighting with something before I either throw it away, or roll my own > so that I know what is going on and don’t waste my time with lack of > transparency that keeps me from understanding how my software is > actually working. It may be good for you, but what happens with potential contributors, if only the author can understand it? Regards Rafał
