I agree, I certainly don't want (and don't want to *seem* to be someone who wants to) absorb all other projects and code. I certainly don't want to assimilate anyone into my own personal collective, I've got enough voices in my head as it is... ;-)
I had hoped that by creating the "Success Stories" page and linking to a bunch of downstream projects and by asking Gregg for links and permission to link to his projects I was avoiding coming across like that. Having said that; my continued pet peeve is that there is not enough *easy-to-get-going* stuff in the River download. The key part of that sentence is *in the River download*. There are one/two points here (http://pelegri.wordpress.com/2010/12/05/hudsons-secret-kohsuke/) that strike me as very important. They are: - Lower the Barrier of Entry - Every step that leads to participation needs to be easy In my opinion (and that's all it is) getting going with River/Jini is *not* easy. Telling new users "download River, now look for a downstream project to go and learn as well - before you can do anything with your River download" is not as easy as "download River, extend these classes, run that script, and enjoy your Hello World service". Again, my own opinion. The kind of "free stuff" I'm talking about doesn't warrant a sub-project, I don't think. Just an extra JAR and source directory in River itself. As to encouraging other down-stream projects to be come River sub-projects, I'm quite neutral about that. However, I *do* want to link to those downstream projects. I figure that once new users have outgrown the Hello World-type service I mention above, they should be directed to down-stream projects which will (I hope) be better implemented, more robust, have better documentation and have more fuller features. > Gregg and his projects are part of our community, why not contribute to > Gregg's project instead, as it appears we're trying to implement / duplicate > existing functionality. I agree, when you look into the Jini community is actually quite rich and a big and valuable part of that are Gregg's projects. The couple of *classes* that Gregg mentioned is something that I've been trying to find the time to write myself. > perhaps it is time we widen the net, and capture some common functionality > implemented in various down stream projects, this would need to be done as > a process of consultation. Is that not what I was doing? Your two statements conflict a little bit, "contribute to [down stream] projects" and "capture some common functionality [from] down stream projects". I think that for any given piece of functionality, a decision needs to be made on what the right thing to do is. And for any two different pieces of functionality, the "right thing" may well be different. I think that a basic/abstract extensible service class would be a good thing to have in the River download. Maybe I just went about it all the wrong way Maybe it was rude of me and I've put Gregg on a spot that he doesn't want to be on; in which case you have my complete and total apology. I don't really understand this para: > I understand also what it feels like when your trying to get something done > and someone throws up a roadblock or another hoop to jump through and how > difficult it has been in the past to get things done, however if done > properly it's an achievement that you'll be recognised for, rather than > resented. Have I done something that has caused resentment? I hadn't noticed, but if so I again apologise for it. I don't really see any hoops or roadblocks (other than River not being easy for new developers). I'm prepared to write these classes myself, I was just hoping not to have to. As I understand the Apache Way, if people think the work is unnecessary, but otherwise don't object, and I'm prepared to do the work, then the work will get done when I get around to it. So, no hard feelings? Cheers, Tom On Wed, Dec 8, 2010 at 11:56 AM, Peter Firmstone <j...@zeus.net.au> wrote: > We are community, we need to be careful not to Borg, but to foster. > > We can encourage important projects to become River sub projects. This will > grow our community further. > > Gregg and his projects are part of our community, why not contribute to > Gregg's project instead, as it appears we're trying to implement / duplicate > existing functionality. I think you'll find other parts of his projects are > also useful. > > When we bring code into River from subprojects we take on the responsibility > of maintaining that code, it also becomes the default implementation. We > have a responsibility to take more than our own needs into consideration. > > River is a platform and I agree we need to make it easier to deploy. A lot > of external projects do this already, perhaps we can link to these? > > I also acknowledge that fragmentation causes confusion, so perhaps it is > time we widen the net, and capture some common functionality implemented in > various down stream projects, this would need to be done as a process of > consultation. > > I understand also what it feels like when your trying to get something done > and someone throws up a roadblock or another hoop to jump through and how > difficult it has been in the past to get things done, however if done > properly it's an achievement that you'll be recognised for, rather than > resented. > > If you just want to code though, perhaps you can create a subproject, making > River easier to use and deploy for first time developers, this might also > encourage projects with competing functionality to become subproject's of > River to get more of the limelight. > > Cheers, > > Peter. > > Tom Hobbs wrote: >> >> Hi Gregg, >> >> Is any of this stuff in a public repo? You might have noticed that >> I've put a "River Success Stories" page on the site and it'd be great >> to be able to link to these projects - even the >> experimental/incomplete ones. >> >> With regards to startnow, particularly ConfigurableJiniApplication and >> PersistentJiniService, would you be willing to donate these to the >> River code base? This kind of thing is exactly what I wanted to put >> in the "extras" drirectory of River that was discussed a while back. >> >> Let me just say that I am more than very happy to direct people onto >> your implementations and towards your projects, as I hope the above >> request for the links to public repos and permission to link to them >> above shows. However I still think that it's easier and more >> intuitive to new users if they get more stuff like this along with >> their original River download. I hope that you don't think I'm trying >> to absorb all of your projects into River or divert any credit away >> from you onto this project, but just those two quick-start classes >> would be really useful for new developers using River - and a donation >> of existing code saves me the effort of re-implementing them myself! >> >> Cheers, >> >> Tom >> >> >> On Fri, Dec 3, 2010 at 10:04 PM, Gregg Wonderly <gr...@wonderly.org> >> wrote: >> >>> >>> Sam, there is not a comprehensive list anywhere, but I'll post one here >>> just >>> FYI and anyone else who might be interested. What I want to stress is >>> that >>> most of this stuff is hovering closer to "investigation" than >>> "production" >>> quality code. I'm willing to answer questions as best I can. Some of it >>> is >>> early versions of stuff which I later put into production with >>> changes/enhancements. >>> >>> gosie A Jini Based Desktop System >>> This is my serviceUI based desktop environment. >>> This application lets you use a list of hosts and URL >>> suffixes, and then does unicast to those hosts, and >>> creates a dynamic policy for all host and URL suffix >>> combinations. In my use, I rely the reef project work >>> on reggie for delayed unmarshalling as well as on the >>> fact that the hosts have services returning vhttp URLs >>> in the annotations which will download and locally cache >>> all service jars. In the deployments I use this, there >>> are 5-10 services per machine with 2-4 jars per service. >>> There are 2 or more serviceUIs per service registration. >>> This results in hundreds of UIs to select from and thus >>> I need very quick display of icons and choices. >>> >>> griddle Jini Grid tuple space >>> This is something that I put together while the >>> JavaSpaces05 discussion was happening. It has in-space >>> executor and programmble query control because the space >>> objects are separated from the keys so that the data >>> can stay marshalled and the keys can be unmarshalled >>> and compared with the "entry" matching implementation. >>> >>> jetset A Jetty service for launching servlets >>> This is a service that launches the Jetty web server >>> logman Remote logging management using a Jini enabled LogManager >>> This service is launched from the LogManager SPI in >>> the JVM. It provides remote monitoring by letting you >>> change logger settings as well as remote streaming of >>> the log output. >>> >>> reef A service lookup to reduce client memory use. >>> This is the work that I did to make Reggie return >>> marshalled match data so that you can decide when >>> to unmarshall the service and the Entry objects >>> yourself. You can thus get Name objects and other >>> data without unmarshalling the service. I also did >>> work to Jini to provide the ability to configure the >>> net.jini.loader.pref.ClassLoading class to "never prefer" >>> some classes so that things such as Name would never >>> cause the initial download that the preferred list >>> discovery causes. >>> >>> startnow A collection of Jini tools for new Users >>> This includes a ConfigurableJiniApplication and a >>> PersistentJiniService class that I use all the time >>> as foundations for all services I write. But there >>> are also all kinds of things that I dumped into >>> this project as I was experimenting with different >>> concepts about abstracting parts of Jini prior to the >>> 2.0 release with Configuration and other good things. >>> Included in this project is stuff like a configuration >>> provider/manager that I was working on. There is also >>> a DynamicPolicyProxyPreparer class that was intended >>> to allow proxyPreparation to look at the codesource >>> and assert policy around the prepared proxy. This was >>> intended to allow "users" or "deployers" to give users >>> appropropriate local policy to use for services they >>> might encounter on the network. >>> >>> whatsitdo A Jini Container system for Jini Examples >>> This project was about giving people instance access >>> to Jini as well as to example services which used Jini. >>> It provides a container GUI that you can drag "jars" into >>> and the contained services will be shown and you can then >>> launch them and use the associated serviceUIs. What is >>> interesting, to me, in this, was that I put together some >>> "hacks" on the JarFile/ZipFile mechanisms and jar: URL >>> handling in the JVM to allow recursive jar URLs to work. >>> This meant that you could put the jini jars into your >>> services jar as the complete classpath for it, and include >>> codebase jars as well, and through the magic I created, >>> everything just worked. It still works last I tried it. >>> >>> The build scripts do all the work to package thinsg, >>> and there are control points that are created in that >>> process to allow the right thing to happen. I used >>> the com.sun.jini.start stuff as the "service launching" >>> control code. >>> >>> Gregg Wonderly >>> >>> On 12/1/2010 9:25 AM, Sam Chance wrote: >>> >>>> >>>> Greg, >>>> >>>> Are your various Jini/River related projects listed on-line somewhere? >>>> >>>> Thank you! >>>> Sam >>>> >>>> On Wed, Dec 1, 2010 at 10:13 AM, Gregg Wonderly<gr...@wonderly.org> >>>> wrote: >>>> >>>> >>>>> >>>>> I have requested that jini.dev.java.net be moved and I've requested >>>>> that >>>>> my individual projects be moved. Any other projects own by others need >>>>> to >>>>> be dealt with pronto. All users should have received emails about >>>>> needed >>>>> action. >>>>> >>>>> Gregg Wonderly >>>>> >>>>> On 11/24/2010 5:19 AM, Peter Firmstone wrote: >>>>> >>>>> >>>>>> >>>>>> There are a lot of Jini Community projects on Java.net which are >>>>>> probably >>>>>> stagnant. >>>>>> >>>>>> Do we know if any of these projects will be moved? >>>>>> >>>>>> It looks like they're all going to go the way of the dinosaur unless >>>>>> we >>>>>> preserve >>>>>> their source. >>>>>> >>>>>> Looks like we've got 6 days left to copy these projects. It will be a >>>>>> significant loss if we don't. >>>>>> >>>>>> Peter. >>>>>> >>>>>> Niclas Hedhman wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> Has this been discussed?? >>>>>>> >>>>>>> <quote> >>>>>>> ACTION REQUIRED: Java.net is migrating to a new infrastructure and >>>>>>> project owners must request that projects be moved by November 30, >>>>>>> 2010. A list of projects that will be moved is here: >>>>>>> http://java.net/projects/help/pages/RequestedProjects For more >>>>>>> details >>>>>>> please see the Community Manager's blog - >>>>>>> http://www.java.net/blog/30701 >>>>>>> </quote> >>>>>>> >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> >>>>>> >>>>>> >>> >>> >> >> > >
