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 <[email protected]> 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 <[email protected]>
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<[email protected]>
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
