Hi Rafal: Some commentary below…
Greg. On Apr 10, 2014, at 5:17 AM, Rafał Krupiński <rafal.krupin...@sorcersoft.com> wrote: > Dnia 2014-04-09, śro o godzinie 23:33 -0400, Greg Trasuk pisze: >> Hi all: > > Hi Greg, > > Now I feel bad for not contributing my extensions to River, that I have > implemented for SORCER (nb open source on github). > https://github.com/sorcersoft/sorcer > We have our own ServiceStarter, historically based on River's and I > think I could contribute some patches based on that.. What kind of changes did you make to ServiceStarter? > I also have some preliminary work on downloadable URLStreamHandlers, and > I'd be happy to contribute it to River once it's done. > Patches welcome! And new committers needed. > The only problem is, I don't know anything about River's build process, > ant scripts, classanddepjar tuning and @Betas. It would be much easier > for me to contribute if River was mavenized. There was a discussion on > that, but it's dead now and I don't see that materializing into code > (maybe I don't know where to look). > Let’s talk about the build system. It was originally based on Make, then ported to Ant, and we’ve talked in the past about switching to Maven. Grails has also been suggested. People have commented that the build system and the source code structure is difficult to understand, and prevents them from participating in the development. I understand that, but I also think that when we start to talk about changing the build system, there’s a couple of incorrect assumptions at work. First, we need to realize that the build system is there to produce artifacts. In the case of the current releases, these artifacts are, in fact, published to Maven Central. So although River isn’t built using Maven, it is certainly compatible with Maven. A downstream project can use any build system that can access Maven Central’s repository. That at least covers Grails, Ivy, and Maven, and probably others. Second, at the current time, River releases one source package that includes everything that River delivers, and so right now, everything River releases is built using the archaic (but working!) River build system. But there’s no requirement that we only have one product! So, if someone wanted to contribute something else to River, they’re free to build that module using whatever build system they want to use. The River Container used Maven. Your improved ServiceStarter, if you contributed it, could use Maven. Had Rio been contributed, it could have used Grails or whatever. What I’m saying is that if we’re adding functionality, there’s no reason to limit ourselves to the current build system. Now, if you’re altering existing code, as Peter has been doing in qa_refactor, you’re kind of stuck. However, if somebody wanted to create a JMM-safe implementation of Reggie, for instance, they could certainly pull out the Reggie code and mavenize it on its own. Reggie (just as an example) is published to Maven Central as it’s own set of artifacts. > Maybe the problem is that I wait for others to do the work instead of > doing it? Shall I start a new github project for mavenized river and > initiate the migration? > There’s another fallacy here, that we can’t use git, so additional projects need github. In fact, ASF now has git repositories available (I understand that github has some other features that people find useful. In fact, ASF is working on tighter integration, so for instance, we’ll soon be able to accept pull requests directly). We certainly could setup a git repository (as in fact I did for River Container), and in fact it’s automatically mirrored to github. It doesn’t have to be all-or-nothing. Having said that, I wouldn’t jump in and “Mavenize River”. Why would we need to take on such a huge job, if the current build system works (ugly though it is)? Rather, I’d suggest that we think about having another River deliverable to include a new unit of functionality. > Regards > Rafał >
