Hi Rafal:
On Apr 10, 2014, at 2:15 PM, Rafał Krupiński <[email protected]> wrote: > > I think you missed the point. > Could be. I guess the question is, what are you wanting to contribute? If you’re going to debug or modify current code, then yes, the build system is an obstacle that you need to overcome. In which case, maybe changing parts of it could be a great first contribution. I’m just saying that’s going to be a pretty big job, no matter who does it. And it’s going to be a contentious subject (as it always has been in the past), because every developer has their favourite build system. On the other hand, if you’re looking at contributing something that will end up being in a different jar file (like I think you mentioned downloadable URLStream handlers), then ignore the current build system and create a new module with whatever build system and integration tests you like. We’ll create a new git repository for it, and release it as a separate module that a River user could add to their class path. It’s still a part of the River project, and users of River will greatly appreciate it. > I'm already a user, and I'm perfectly happy with the current build > system. In fact I couldn't care less about the build system. > Provided I remain a user. > > But becoming a contributor, or even a committer is entirely another > matter. I don't understand the project structure and I don't want to > touch those ant scripts, especially classanddepjar task, with a stick, > let alone modify it. > Don’t get me wrong - I’m not defending the current project structure. I completely agree that I don’t want to touch the existing scripts either. But that doesn’t have to get in the way of contributing. If you’re adding new features, you don’t have to plug into the existing project. Cheers, Greg Trasuk
