Greg, I included the links to the aforementioned work to provide examples of what you might be able to do wrt examples. I was hoping you could look at what has already been done both in River and Rio, and take advantage of it. I see how you could have misunderstood my reply, and heaven forbid we get into another rat hole of maven, ant, gradle, make or whatever...
What would be great would be to figure out what examples you want to provide (a distributed calculator example is a simple one), and just do it. Its super easy to create project that can be built using Maven or Gradle (there are even project generation tools that do this for River/Rio), that is along as you adhere to some basic conventions (to which I have already mentioned). You need to also understand that conventions are never hard-and-fast, they are by definition a way in which something is usually done, it does not mean it is the only way, or "the" way, just a really good way that if followed will generally lead to an easier road to follow. I know this is a tough sell for this group, where most everybody has their way, and is unwilling to part from it, but my experience in making projects successful using River as a technology generally is based on de-mystifying it and making it straight forward. Reasonable conventions help with this. I don't know if pushing your River container approach is best for an example, but a stock River example with straight forward conventions allows developers to understand how to structure a project, how to build it, and most importantly how to test it. Without those basic fundamentals of an example it doesn't make much sense to pursue. For me, having spent years in the Maven world, and having done a huge project conversion that uses River from Ant to Gradle, Gradle would be my choice for an example. Maven is too complicated, to restrictive, and geez XML. Ughh. You can see from my earlier links that the project structure remains the same, the project automation tool changes. You get the same artifact resolution from Maven repositories, but a much much stronger, flexible project automation tool that we can do so much more with. HTH Dennis > On Jan 8, 2015, at 557PM, Greg Trasuk <tras...@stratuscom.com> wrote: > > > So, to be clear, I’m not talking about “Mavenizing” River. I’m not saying > that’s a bad idea (or gradle-izing, whatever). But let’s face it - we’ve > been talking about it for five years with no agreement and no progress. > > What we have is a build process for the River libraries in the JTSK that > works (although it needs to get updated for JDK 8) but confuses the heck out > of everyone. I think we all agree that something ought to be done, but we > it’ll be a big job. The problem is, we keep allowing that argument to block > any progress on our “getting started” experience. > > I have always been of the viewpoint that the vast majority of potential users > of River really do not need to be concerned with compiling River. They just > need the jars, and they need to know how to use them. > > So what I’m suggesting here, is a set of examples that show people how to use > River to get the services up-and-running in a fresh build tool. Which we all > know does not actually require anyone to build River, since the artifacts are > in Central. If those users become interested in hacking on the River source, > then they’re welcome to either learn how the JTSK build works, or fix it - > that’s great. But that’s not what I’m talking about with these examples. > > I’m pointing this out in the hope that we avoid falling into another round of > arguments over “modularizing” or “Mavenizing” River. > > > Cheers, > > Greg Trasuk > > > On Jan 8, 2015, at 5:31 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: > >> Greg, >> >> Here is a start to a gradle-ized version of River done 3 years ago >> http://svn.apache.org/viewvc/river/jtsk/skunk/modules/, could easily beused >> to create examples as well. >> >> And here is the maven-ized version: >> http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/modularize/ >> >> HTH >> >> Dennis >> >>> On Jan 8, 2015, at 521PM, Greg Trasuk <tras...@stratuscom.com> wrote: >>> >>> >>> Hi Dennis: >>> >>> I’m slightly allergic to hard-and-fast conventions. For example, the >>> service browser example really doesn’t fit those conventions. Also, I’m >>> reticent to suggest repackaging the infrastructure services (reggie, >>> outrigger, mahalo, etc) at this time (meaning that I personally have no >>> plans to do it). Having said that, I’m basically with you. Matter of fact >>> if you have a look at the River-Container examples over at >>> https://github.com/trasukg/river-container-examples you’ll see that’s >>> pretty much the same style. The minor difference is that I’ve used >>> ‘hello-impl’ rather than ‘hello-service’, and there’s also a ‘hello-module’ >>> that is the packaged artifact for the container. >>> >>> I believe the critical thing is to make sure that the client api is >>> separate, so that the client doesn’t accidentally know anything about the >>> implementation. All else is implementation details, though I agree that we >>> should provide a good example. >>> >>> As far as Maven/Gradle, it happens that I know Maven and not Gradle. All I >>> am trying to do is provide some easier example than just diving into the >>> JTSK source. If someone were to contribute a Gradle-based example, that’s >>> all-the-better for user choice. But I don’t think we should go around >>> telling people what build tool to use. >>> >>> Cheers, >>> >>> Greg Trasuk >>> >>> >>> On Jan 8, 2015, at 4:05 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: >>> >>>> Hi Greg, >>>> >>>> I'd like to suggest that River follow the conventions that align with >>>> whats recommended over in Rio >>>> (http://www.rio-project.org/conventions.html). This has been pretty >>>> successful using both Maven and Gradle (at this time I would go with >>>> Gradle btw). >>>> >>>> HTH >>>> >>>> Regards >>>> >>>> Dennis >>>> >>>>> On Jan 5, 2015, at 1016PM, Greg Trasuk <tras...@stratuscom.com> wrote: >>>>> >>>>> >>>>> I started working on making new demos and “getting started” stuff back >>>>> before the holidays. Here’s my thinking… >>>>> >>>>> As Patricia alludes to, it really shouldn’t be necessary to build the >>>>> River distribution in order to try out some samples and get started. >>>>> After all, the artifacts are published on Maven Central, so they can >>>>> simply be referenced in a Maven build (or Gradle, Ivy, Etc). >>>>> >>>>> Towards that end, I started building a new Mavenized ‘examples’ project, >>>>> which can be checked-out from >>>>> https://svn.apache.org/repos/asf/river/river-examples/river-examples/trunk. >>>>> >>>>> In that project, there are currently modules for the service browser jars >>>>> and a ‘home’ folder for the compiled and packaged examples. (might be >>>>> best to download it and do a ‘mvn install site’). There’s also >>>>> documentation for the examples under the main project (look at >>>>> <project-home>/target/site/index.html - this should be familiar to Maven >>>>> users). The documentation currently includes how to build and run the >>>>> service browser (although I think right now it’s incomplete on how the >>>>> configuration works - haven’t looked at it since Dec 15). >>>>> >>>>> Right now, the project has a dependency on the new ‘river-rt-tools’ >>>>> modules that I talked about back in December as well. So in order to run >>>>> the examples, you currently need to checkout >>>>> 'https://svn.apache.org/repos/asf/river/river-rt-tools/trunk' and do a >>>>> ‘mvn install’ on it, which will install the runtime tool artifacts >>>>> (start.jar) in your local Maven cache. In the end, those artifacts would >>>>> also be released and published on Maven Central, so you eventually >>>>> wouldn’t need to build the runtime tools separately. >>>>> >>>>> My plan is to add modules to the river-examples project for a >>>>> 'hello-service’ and ‘hello-client’, as well as a config for the >>>>> infrastructure services (Reggie, etc). So eventually, the “getting >>>>> started” instructions become “have a look at ‘river-examples’”, and we’d >>>>> remove the (very confusing, if you ask me) ‘examples’ folder from the >>>>> JTSK distribution. As a bonus, we can isolate new users from the >>>>> convoluted build system in River. >>>>> >>>>> If this seems like a reasonable path forward for our “getting started” >>>>> experience, perhaps you’d like to work on bringing over some of the >>>>> examples from the JTSK to the ‘river-examples’ project. That’s probably >>>>> also a good way to re-familiarize yourself with Jini. I probably won’t >>>>> have any cycles to work on it seriously for the next couple weeks, but >>>>> could cheerfully make suggestions. >>>>> >>>>> You should be able to check-out these two Maven project in the IDE of >>>>> your choice. I was using NetBeans, but AFAIK, Eclipse should be able to >>>>> use the Maven build directly. I just haven’t tried it. >>>>> >>>>> Cheers, >>>>> >>>>> Greg Trasuk. >>>>> >>>>> On Jan 5, 2015, at 6:07 PM, Patricia Shanahan <p...@acm.org> wrote: >>>>> >>>>>> I have completed buying a new home, moving into it, and selling the old >>>>>> one, followed by Christmas in England and recovery from the cold I >>>>>> caught there. That means I'm ready to get much more active in River. >>>>>> >>>>>> Last year, we got some feedback suggesting that better support for new >>>>>> users might remove a barrier to community building. My main agenda is >>>>>> community building, so I want to work on that. I am going to be a very >>>>>> naive potential user, so stand by for basic questions. >>>>>> >>>>>> I began by downloading the binary version, since in this mode I am not >>>>>> interested in being a River developer. However, when I looked at the >>>>>> "Getting Started" page, >>>>>> river.apache.org/user-guide-basic-river-services.html, it says: >>>>>> >>>>>> "The instructions assume that you're building from source as checked out >>>>>> from the SVN trunk. Currently this is necessary because the code >>>>>> snippets below use methods and classes which, at time of writing, >>>>>> haven't made it into the latest binary release yet. Having said that, >>>>>> the code you will need in the binary release isn't to far removed from >>>>>> what you'll see below, so you can progress with the binary release if >>>>>> you want to and are happy odifying the code." >>>>>> >>>>>> According to the page info, the "time of writing" was no later than >>>>>> November 23, 2013. Do I still need to do a River build before I can run >>>>>> the example? If so, why and what can I do to fix that? >>>>>> >>>>>> I have no idea whether or not I would be happy "odifying" code - maybe >>>>>> "modifying"? >>>>>> >>>>>> What is the best procedure for editing the "Getting Started" page? I >>>>>> want to make sure that any changes I make really are improvements, so I >>>>>> would like PMC review as I go along. >>>>>> >>>>>> Patricia >>>>>> >>>>>> >>>>> >>>> >>> >> >
