Short term plan forward... (proposal)

[Jim Hurley <Ji...@Sun.COM>]

Hi all-

Just wanted to propose a short term conceptual plan
forward for Apache River, and see if we're in sync.

Once we get the source accepted and contributed
to the project (hopefully this week!)...  I'd like to propose
that we immediately start working on a release (v0.1).  This will
not only help us understand the paces of getting a release
out through Apache, but also provide a release to the Community
from Apache.  To focus on getting a release out, the initial work
would be targeted at integration stuff (for example, getting Service UI
integrated) and some documentation rather than on very many
bug fixes or rfes.

Once we accomplish that, we can turn our focus towards another
near term release (v0.2) which could include additional bug fixes
and smaller rfes as well as any cleanup we learn from getting
the v0.1 release out. This would not only provide an added value
release out to the Community, but also give us further experience
and additional momentum of an active project moving forward.

At that point, I think we'd be seasoned enough to focus on a
release with some 'meat to it' ;-)  (some of the more major bug
fixes/rfes that have been discussed).

Running in parallel to this development focus, I think there
should be some longer range project discussions (what kind
of releases do we eventually want to do in the project, what
are we trying to accomplish (iterating on the core infrastructure
or branching out into other areas), etc).

There it is (again - high level, just to see if we agree on an
overall direction).  Please share your thoughts.

thanks -Jim

ps.  On a specific item - not sure where a package name
        (to org.apache) change would fit in this proposal.  Maybe
        release v0.2 or after?

Re: Short term plan forward... (proposal)

[Mark Brouwer <ma...@cheiron.org>]

Mark Brouwer wrote:

> [1] I have a slight concerns and that is the participation of all the
> committers we have. From the list of Sun committers I only see you and
                                                                  ^^^
                                                                  Jim

Sorry Nigel/Jim for mixing both of you up, It was kind of late last
night ;-)
-- 
Mark

Re: Short term plan forward... (proposal)

[Mark Brouwer <ma...@cheiron.org>]

Nigel Daley wrote:
> 
> On May 21, 2007, at 3:39 PM, Mark Brouwer wrote:
>
>> I find v0.1 not ambitious enough. I think it is important to do some
>> bug-fixes and RFEs that have been completed and lingering around for a
>> very long time in some peoples workspaces. Just to release so most
>> people can sit on the sideline watching v0.1 being released is not that
>> interesting to me (I also want to get rid of a lot of fixes and small
>> RFEs I've been carrying for too long).
> 
> I think we should start small so we can work through all the other 
> issues of getting a first release out the door.  For instance, the bug 
> fixes you and others want to commit, do they need unit tests?  written 
> for which harness/framework?  who's going to run them?  do the bug fixes 
> need code review?  from who?  following what guidelines?  who's going to 
> run all the other tests?  under which configurations?

Although I understand your concerns Nigel. I think the questions/issues
with regard to testing and reviewing are something we have to solve
anyway and I like to solve them in a way while as much people are
actually affected by them. If you want to circumvent touching this
subject for v0.1 it will be likely (in exaggeration mode) one man (you?)
setting up the test, somebody else running the tests without
modifications. We modify the build files for integrating ServiceUI and
we start building deliverables for which we will start a vote for
getting it released.

> IMO, if release 0.1 goes smoothly, then a more ambitious 0.2 could 
> follow on very quickly.

I doubt the real added value for .1 as I'm really afraid most people
stand watching at the sideline [1] for that release while most important
stuff has to be sorted out for .2 anyway.

I'll leave it to this as I think there are more important things to
argue about in the future ;-)

[1] I have a slight concerns and that is the participation of all the
committers we have. From the list of Sun committers I only see you and
Bob to be really active while most others are more on the background. I
think starting with touching more bugfixes and RFEs (for which they
historically have been code-owners) will encourage their participation
and see their individual identity show through.
-- 
Mark

Re: Short term plan forward... (proposal)

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Nigel Daley wrote:
> 
> On May 21, 2007, at 3:39 PM, Mark Brouwer wrote:
> 
>> Jim Hurley wrote:
>>> Hi all-
>>> Just wanted to propose a short term conceptual plan
>>> forward for Apache River, and see if we're in sync.
>>
>> Thanks for starting this Jim. Below some of my initial thoughts on your
>> ideas.
>>
>>> Once we get the source accepted and contributed
>>> to the project (hopefully this week!)...  I'd like to propose
>>> that we immediately start working on a release (v0.1).  This will
>>> not only help us understand the paces of getting a release
>>> out through Apache, but also provide a release to the Community
>>> from Apache.  To focus on getting a release out, the initial work
>>> would be targeted at integration stuff (for example, getting Service UI
>>> integrated) and some documentation rather than on very many
>>> bug fixes or rfes.
>>> Once we accomplish that, we can turn our focus towards another
>>> near term release (v0.2) which could include additional bug fixes
>>> and smaller rfes as well as any cleanup we learn from getting
>>> the v0.1 release out. This would not only provide an added value
>>> release out to the Community, but also give us further experience
>>> and additional momentum of an active project moving forward.
> 
> +1 to Jim's suggestions
> 
>> I find v0.1 not ambitious enough. I think it is important to do some
>> bug-fixes and RFEs that have been completed and lingering around for a
>> very long time in some peoples workspaces. Just to release so most
>> people can sit on the sideline watching v0.1 being released is not that
>> interesting to me (I also want to get rid of a lot of fixes and small
>> RFEs I've been carrying for too long).
> 
> I think we should start small so we can work through all the other
> issues of getting a first release out the door.  For instance, the bug
> fixes you and others want to commit, do they need unit tests?  written
> for which harness/framework?  who's going to run them?  do the bug fixes
> need code review?  from who?  following what guidelines?  who's going to
> run all the other tests?  under which configurations?
> 

+1

> IMO, if release 0.1 goes smoothly, then a more ambitious 0.2 could
> follow on very quickly.
> 
> Cheers,
> Nige
> 
> 
> 

Re: Short term plan forward... (proposal)

[Nigel Daley <nd...@mac.com>]

On May 21, 2007, at 3:39 PM, Mark Brouwer wrote:

> Jim Hurley wrote:
>> Hi all-
>> Just wanted to propose a short term conceptual plan
>> forward for Apache River, and see if we're in sync.
>
> Thanks for starting this Jim. Below some of my initial thoughts on  
> your
> ideas.
>
>> Once we get the source accepted and contributed
>> to the project (hopefully this week!)...  I'd like to propose
>> that we immediately start working on a release (v0.1).  This will
>> not only help us understand the paces of getting a release
>> out through Apache, but also provide a release to the Community
>> from Apache.  To focus on getting a release out, the initial work
>> would be targeted at integration stuff (for example, getting  
>> Service UI
>> integrated) and some documentation rather than on very many
>> bug fixes or rfes.
>> Once we accomplish that, we can turn our focus towards another
>> near term release (v0.2) which could include additional bug fixes
>> and smaller rfes as well as any cleanup we learn from getting
>> the v0.1 release out. This would not only provide an added value
>> release out to the Community, but also give us further experience
>> and additional momentum of an active project moving forward.

+1 to Jim's suggestions

> I find v0.1 not ambitious enough. I think it is important to do some
> bug-fixes and RFEs that have been completed and lingering around for a
> very long time in some peoples workspaces. Just to release so most
> people can sit on the sideline watching v0.1 being released is not  
> that
> interesting to me (I also want to get rid of a lot of fixes and small
> RFEs I've been carrying for too long).

I think we should start small so we can work through all the other  
issues of getting a first release out the door.  For instance, the  
bug fixes you and others want to commit, do they need unit tests?   
written for which harness/framework?  who's going to run them?  do  
the bug fixes need code review?  from who?  following what  
guidelines?  who's going to run all the other tests?  under which  
configurations?

IMO, if release 0.1 goes smoothly, then a more ambitious 0.2 could  
follow on very quickly.

Cheers,
Nige

Re: Short term plan forward... (proposal)

[Craig L Russell <Cr...@Sun.COM>]

Hi,

I'm not a stakeholder, but would like to second the concept that the  
earlier you have something that the rest of the world can see, the  
better. Even something that you know will change radically is  
something that others can start to look at, comment on, and suggest  
changes in.

So I'd say it's worthwhile putting together a 0.1 release. The  
process of cutting a release should provide a good opportunity for  
community building.

Craig

On May 22, 2007, at 6:11 AM, Rick Moynihan wrote:

> Vinod Johnson - Sun Microsystems wrote:
>> Part of what is in play here is how much more time and effort (I  
>> would imagine the effort part would me more process oriented  
>> rather than technical) it would take to do a 0.1 vs a 0.2. If the  
>> answer is 'not that much more' then there seems to be little to be  
>> gained from splitting the two. If it is 'reasonably more' then I  
>> think there is value in having a binary distribution as an initial  
>> artifact for people to be able to download and touch and feel.  
>> This value judgment, of course, comes with the assumption (perhaps  
>> misguided) that the slant initially is towards showing people that  
>> we have a binary that works rather than the magnitude of active  
>> ongoing work.
>> My 2c.
>
> Perhaps this sounds odd, and maybe it is, but if River were to get  
> an early release out, even one that I don't use.  At least I'd have  
> something which is River and is open to change.  Right now it feels  
> like much of River is opaque and within Sun.  The sooner there is a  
> release, the sooner River will feel like a project.
>
> I think there is a lot of value in seeing a 0.1 release (unless of  
> course 0.2 won't be significantly longer), even if everyone knows  
> 0.2/0.5/... is going to change everything.  The value here is in  
> having something which people can call River.  Then River will  
> become something concrete and open to suggestions and critique.
>
> This said, perhaps the code drop is enough, but I'd rather not have  
> to track changes and discussions at that level of granularity right  
> now.
>
> In many ways I think my feelings follow Mike Herrick's.  I have a  
> lot of hope for River, and I hope my comments don't come across as  
> being too critical.  I'm convinced that Jini's move to Apache is  
> the right thing, it's just frustrating that it's taking so long.
>
> -- 
> Rick Moynihan
> Software Engineer
> Calico Jack LTD
> http://www.calicojack.co.uk/

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: Short term plan forward... (proposal)

[Rick Moynihan <ri...@calicojack.co.uk>]

Vinod Johnson - Sun Microsystems wrote:
> 
> Part of what is in play here is how much more time and effort (I would 
> imagine the effort part would me more process oriented rather than 
> technical) it would take to do a 0.1 vs a 0.2. If the answer is 'not 
> that much more' then there seems to be little to be gained from 
> splitting the two. If it is 'reasonably more' then I think there is 
> value in having a binary distribution as an initial artifact for people 
> to be able to download and touch and feel. This value judgment, of 
> course, comes with the assumption (perhaps misguided) that the slant 
> initially is towards showing people that we have a binary that works 
> rather than the magnitude of active ongoing work.
> 
> My 2c.

Perhaps this sounds odd, and maybe it is, but if River were to get an 
early release out, even one that I don't use.  At least I'd have 
something which is River and is open to change.  Right now it feels like 
much of River is opaque and within Sun.  The sooner there is a release, 
the sooner River will feel like a project.

I think there is a lot of value in seeing a 0.1 release (unless of 
course 0.2 won't be significantly longer), even if everyone knows 
0.2/0.5/... is going to change everything.  The value here is in having 
something which people can call River.  Then River will become something 
concrete and open to suggestions and critique.

This said, perhaps the code drop is enough, but I'd rather not have to 
track changes and discussions at that level of granularity right now.

In many ways I think my feelings follow Mike Herrick's.  I have a lot of 
hope for River, and I hope my comments don't come across as being too 
critical.  I'm convinced that Jini's move to Apache is the right thing, 
it's just frustrating that it's taking so long.

-- 
Rick Moynihan
Software Engineer
Calico Jack LTD
http://www.calicojack.co.uk/

Re: Short term plan forward... (proposal)

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 5/23/07, Mark Brouwer <ma...@cheiron.org> wrote:
> I believe the questions of Bob are still unanswered so probably it is
> best to have people who want to have a release out of the door ASAP
> provide an answer for them and make a task of the things to be done for
> the first release and then have a vote about it.

Exactly. There's nothing stopping people from making a release as soon
as the code has landed in svn. Unlike code changes, a release can't be
vetoed on technical grounds. The only things you need for a release
are that you meet the Apache legal and branding policies and that you
have at least three PMC members voting +1 on the release. A release
can also be prepared in parallel with other development work.

> I don't know whether a vote is normal in this case but no doubt our mentors
> or somebody more acquainted with the process here will help us out with that.

The only required vote is on accepting a release candidate. The
typical process is for someone to step up as the release manager and
propose a release plan that outlines what needs to be done for the
release. The release plan is a good opportunity to discuss and build
consensus, but there's no need to formally vote on it.

BR,

Jukka Zitting

Re: Short term plan forward... (proposal)

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Mark Brouwer wrote:
> Hi Dan,
> 
> Dan Creswell wrote:
> 
>> I can imagine that a release with some bug fixes mightn't get too much
>> contention but would take longer as we thrash around unit tests etc
>> (which I think are essential).
> 
> Setting things up will take its time, such as getting the JIRA issues
> in, test environment, etc., etc. During that process it is my opinion
> other tasks can be done in parallel.
> 
> Although my opinion is a minority in this case, which is fine, but still
> even Jim's proposal leaves some room for solving issues so I'm going to
> enter the twilight zone and want a bit more done than what people can
> download and is already available since October 2005.
> 
> I think the process of picking issues, doing code review and working
> together is something we should 'train' even for the first release. It
> won't be hard to pick already a few simple issues for which there are
> currently no direct tests, or you won't/can't write unit tests and that
> are normally just done by code review. Such as there are:
> 
> RIVER-5, RIVER-7, RIVER-8, RIVER-9, RIVER-18, RIVER-24, RIVER-25 (I
> expect some people to differ from opinion whether these are trivial but

Precisely and given our record on differing opinions and making forward
progress I really don't want to see us holding up a release for this.

> that is OK). There would have been more although they are related to
> files that contain larger fixes as well. The issues are already listed,
> the fixes are already in the field, so I really can't see the problem of
> a bit of exercise on the code and us working together.
> 
>> If we get into RFE's, from my own past discussions in this area, I know
>> I'm going to have a lot of things to say and a lot of stuff to
>> challenge/thrash out.  Basically my view is that will delay the first
>> release far too long.
> 
> I agree, but I expect each of us can make a judgment about when it is an
> opportune moment to make these public (rather sooner than later I would
> say) and for which phase to schedule it for discussion and
> incorporation. And misjudgments are a good way to learn to work in this
> project, so a few of them are even necessary I guess :-)
>

Necessary but not necessarily necessary now.

> My problem so far is that getting a release out of the door as a sign of
> life seems to be the most important aspect instead of us (all) working

Getting a release done is working together is it not?

And if getting a release out the door ensures we actually have people
waiting around for the next release as opposed to clearing off to do
something more interesting that would seem worthwhile.

I've said this before, we can all sit here and play around writing Jini
stuff that we think is cool and playing with it in our own little
sandpits and that might indeed build a developer community.

The question is will that build a developer community that has something
interesting to offer the world at large or will it be a community that
is insular and has no relationship with that larger world?  Will it lead
to something of value to those beyond the developer community or just
those within?

I would venture to suggest that we've already done the insular
development community and we know where that leads to.  Surely it's time
for something different?

> together. To me the release represents a gesture to the world of our
> good intentions (which can be important although I'm not so very
> sensitive to that) but has no advantage over October 2005 (legally it
> is even an incubator release) while at the same time it is putting some
> people in the wait mode and that I have a 'slight problem' with.
>

I accept the release has no advantage to you but there's some evidence
that it's valuable in some fashion to our user community.

> I believe the questions of Bob are still unanswered so probably it is
> best to have people who want to have a release out of the door ASAP
> provide an answer for them and make a task of the things to be done for
> the first release and then have a vote about it. I don't know whether a
> vote is normal in this case but no doubt our mentors or somebody more
> acquainted with the process here will help us out with that.
> 
> I hope my language is not too harsh. I'm Dutch so that means I've been
> brought up in a consensus society where people
> go-with-the-flow-although-screaming-and-kicking so probably I support
> what the majority ends up with if they let me do 3 issues ;-).

Your language is direct and that's fine.

Dan.

Re: Short term plan forward... (proposal)

[Mark Brouwer <ma...@cheiron.org>]

Hi Dan,

Dan Creswell wrote:

> I can imagine that a release with some bug fixes mightn't get too much
> contention but would take longer as we thrash around unit tests etc
> (which I think are essential).

Setting things up will take its time, such as getting the JIRA issues
in, test environment, etc., etc. During that process it is my opinion
other tasks can be done in parallel.

Although my opinion is a minority in this case, which is fine, but still
even Jim's proposal leaves some room for solving issues so I'm going to
enter the twilight zone and want a bit more done than what people can
download and is already available since October 2005.

I think the process of picking issues, doing code review and working
together is something we should 'train' even for the first release. It
won't be hard to pick already a few simple issues for which there are
currently no direct tests, or you won't/can't write unit tests and that
are normally just done by code review. Such as there are:

RIVER-5, RIVER-7, RIVER-8, RIVER-9, RIVER-18, RIVER-24, RIVER-25 (I
expect some people to differ from opinion whether these are trivial but
that is OK). There would have been more although they are related to
files that contain larger fixes as well. The issues are already listed,
the fixes are already in the field, so I really can't see the problem of
a bit of exercise on the code and us working together.

> If we get into RFE's, from my own past discussions in this area, I know
> I'm going to have a lot of things to say and a lot of stuff to
> challenge/thrash out.  Basically my view is that will delay the first
> release far too long.

I agree, but I expect each of us can make a judgment about when it is an
opportune moment to make these public (rather sooner than later I would
say) and for which phase to schedule it for discussion and
incorporation. And misjudgments are a good way to learn to work in this
project, so a few of them are even necessary I guess :-)

My problem so far is that getting a release out of the door as a sign of
life seems to be the most important aspect instead of us (all) working
together. To me the release represents a gesture to the world of our
good intentions (which can be important although I'm not so very
sensitive to that) but has no advantage over October 2005 (legally it
is even an incubator release) while at the same time it is putting some
people in the wait mode and that I have a 'slight problem' with.

I believe the questions of Bob are still unanswered so probably it is
best to have people who want to have a release out of the door ASAP
provide an answer for them and make a task of the things to be done for
the first release and then have a vote about it. I don't know whether a
vote is normal in this case but no doubt our mentors or somebody more
acquainted with the process here will help us out with that.

I hope my language is not too harsh. I'm Dutch so that means I've been
brought up in a consensus society where people
go-with-the-flow-although-screaming-and-kicking so probably I support
what the majority ends up with if they let me do 3 issues ;-).
-- 
Mark

Re: Short term plan forward... (proposal)

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Vinod Johnson - Sun Microsystems wrote:
> 
>>
>> I find v0.1 not ambitious enough. I think it is important to do some
>> bug-fixes and RFEs that have been completed and lingering around for a
>> very long time in some peoples workspaces. Just to release so most
>> people can sit on the sideline watching v0.1 being released is not that
>> interesting to me (I also want to get rid of a lot of fixes and small
>> RFEs I've been carrying for too long). Therefore I'm inclined to merge
>> the goals for v0.1 and v0.2 as most of it likely represents completed
>> work. Based on what is in Bugtraq, has been added to River and is
>> completed in the Sun internal version control system we can make a
>> selection of what to put into that first release. Whether there is still
>> a need for a release between the first release and the 'meat to it'
>> release I find hard to say at this point.
>>
> Part of what is in play here is how much more time and effort (I would
> imagine the effort part would me more process oriented rather than
> technical) it would take to do a 0.1 vs a 0.2. If the answer is 'not
> that much more' then there seems to be little to be gained from
> splitting the two. If it is 'reasonably more' then I think there is
> value in having a binary distribution as an initial artifact for people
> to be able to download and touch and feel. This value judgment, of
> course, comes with the assumption (perhaps misguided) that the slant
> initially is towards showing people that we have a binary that works
> rather than the magnitude of active ongoing work.
> 
> My 2c.

I can imagine that a release with some bug fixes mightn't get too much
contention but would take longer as we thrash around unit tests etc
(which I think are essential).

If we get into RFE's, from my own past discussions in this area, I know
I'm going to have a lot of things to say and a lot of stuff to
challenge/thrash out.  Basically my view is that will delay the first
release far too long.

Dan.

Re: Short term plan forward... (proposal)

[Vinod Johnson - Sun Microsystems <Th...@Sun.COM>]

>
> I find v0.1 not ambitious enough. I think it is important to do some
> bug-fixes and RFEs that have been completed and lingering around for a
> very long time in some peoples workspaces. Just to release so most
> people can sit on the sideline watching v0.1 being released is not that
> interesting to me (I also want to get rid of a lot of fixes and small
> RFEs I've been carrying for too long). Therefore I'm inclined to merge
> the goals for v0.1 and v0.2 as most of it likely represents completed
> work. Based on what is in Bugtraq, has been added to River and is
> completed in the Sun internal version control system we can make a
> selection of what to put into that first release. Whether there is still
> a need for a release between the first release and the 'meat to it'
> release I find hard to say at this point.
>
Part of what is in play here is how much more time and effort (I would 
imagine the effort part would me more process oriented rather than 
technical) it would take to do a 0.1 vs a 0.2. If the answer is 'not 
that much more' then there seems to be little to be gained from 
splitting the two. If it is 'reasonably more' then I think there is 
value in having a binary distribution as an initial artifact for people 
to be able to download and touch and feel. This value judgment, of 
course, comes with the assumption (perhaps misguided) that the slant 
initially is towards showing people that we have a binary that works 
rather than the magnitude of active ongoing work.

My 2c.
-- 
- vinod

Re: Short term plan forward... (proposal)

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Sean Landis wrote:
> Mark had asked me to start a new thread, but since you asked, Bob...
> 
> Yes, essentially generifying would be it. We should not to have to
> cast Object instances these days. There appear to be some places where
> direct generifying might not work w/o significant change, but I
> haven't done a full analysis.
> 
> There's an adoption aspect to this, at least where I work. The local
> culture is zealous about type safety and generally looks down upon
> open source that hasn't yet moved to 1.5.
> 
> I confess that I am a bit taken aback now by open source software that
> hasn't taken advantage of 1.5 features. I can't know for sure, but I
> suspect it is one more barrier for some people.
> 

It might well be a barrier but I'm aware of a number of substantial
jini-users (and potential ones) that aren't on 1.5 in production as yet.

Who should we favour?

> Sean
> 
> On 5/22/07, Bob Scheifler <Bo...@sun.com> wrote:
>> Sean Landis wrote:
>> > Moving the interfaces. utilities, and services to 1.5 is very
>> > important to me
>>
>> Do you mean generifying the public APIs, or something else?
>>
>> - Bob
>>
> 

Re: Short term plan forward... (proposal)

[Sean Landis <se...@gmail.com>]

Yeah, sad, but OTOH, at least someone has gone through it. That's promising.

Sean

On 5/22/07, Bob Scheifler <Bo...@sun.com> wrote:
> Sean Landis wrote:
> > There appear to be some places where
> > direct generifying might not work w/o significant change, but I
> > haven't done a full analysis.
>
> FWIW, 3 years ago (how sad is that) I went through the exercise for
> all of the public net.jini APIs, including getting a compilable
> starter kit (but didn't bother to eliminate all compiler warnings
> resulting from not generifying internal code).
>
> - Bob
>

Re: Short term plan forward... (proposal)

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> I assume your generification was done in a compatible way, i.e. code
> compiled against the pre-generified net.jini APIs will continue to work
> assuming they were deployed on J2SE 5 or higher.

The intent was to be binary compatible.

> Did you also investigate the usage of typed collections for method
> signatures that have arrays as argument and return value and the
> var-args construct.

I didn't look hard at adding new methods or constructors.  I did go
through and find places where parameterization couldn't be done
because of arrays but would have been possible with collections.
Varargs on existing methods yes.  I also didn't look at supporting new
language features in ConfigurationFile.

> Do you envision deprecation of the latter

Nope.

> adding the equivalent using typed collections.

Perhaps.

> If we are going to generify I
> think we shouldn't do it only half

As long as generics are only a compile-time thing, it will never feel
complete. ;-)

- Bob

Re: Short term plan forward... (proposal)

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Sean Landis wrote:
>> There appear to be some places where
>> direct generifying might not work w/o significant change, but I
>> haven't done a full analysis.
> 
> FWIW, 3 years ago (how sad is that) I went through the exercise for

I assumed you've got over it by now :-P

> all of the public net.jini APIs, including getting a compilable
> starter kit (but didn't bother to eliminate all compiler warnings
> resulting from not generifying internal code).

I assume your generification was done in a compatible way, i.e. code
compiled against the pre-generified net.jini APIs will continue to work
assuming they were deployed on J2SE 5 or higher.

Did you also investigate the usage of typed collections for method
signatures that have arrays as argument and return value and the
var-args construct. Do you envision deprecation of the latter and adding
the equivalent using typed collections. If we are going to generify I
think we shouldn't do it only half, but I also release that once you
start deprecating why not roll other insight into the API as well at the
same time. Suddenly it might turn out that a lot of the current API is
subject to change. I have a nagging feeling [1] that starting with
generification of the API is like throwing away a snowflake on the top
of mountain with the net result the village in the valley is hit by an
avalanche.

FYI, it is already quite a while since the discussion of Java 5 popped
up and at this point I'm fine with moving to Java 5 but not for the
first 1 or 2 releases. This is something I would like to see done when
other major chunks of work are being accomplished.

[1] if one wonder why I have this nagging feeling, I do have version 1.0
of the JSC API for over 2 years in my workspace and that takes advantage
of generics as well and other J2SE 5.0 API. While it started out as
generification in a compatible way it resulted in a mixture of typed
collections and typed arrays. It didn't feel right and given the size of
the installed base I decided to make things consistent, but while no
longer backwards compatible I also decided to clean up some other parts.
End of the story ... it became something different, although similar. It
is not rocket science for people to migrate from 0.1 to 1.0 and I still
think what I'm doing is the right thing, but still it is a barrier.

In general my experience with generifying public APIs and internals are
mixed, so far I didn't catch any bugs, code density was not achieved
(contrary), not all casts went away and I can recall a few moments when
somebody threw a bucket of water over my head as smoke was coming out of
my ears. I'm proud of having survived the exercise, but creating type
safe APIs was sometimes nearing rocket science at least for me (I was
very glad with Bracha's tutorial).
-- 
Mark

Re: Short term plan forward... (proposal)

[Bob Scheifler <Bo...@Sun.COM>]

Sean Landis wrote:
> There appear to be some places where
> direct generifying might not work w/o significant change, but I
> haven't done a full analysis.

FWIW, 3 years ago (how sad is that) I went through the exercise for
all of the public net.jini APIs, including getting a compilable
starter kit (but didn't bother to eliminate all compiler warnings
resulting from not generifying internal code).

- Bob

Re: Short term plan forward... (proposal)

[Sean Landis <se...@gmail.com>]

Mark had asked me to start a new thread, but since you asked, Bob...

Yes, essentially generifying would be it. We should not to have to
cast Object instances these days. There appear to be some places where
direct generifying might not work w/o significant change, but I
haven't done a full analysis.

There's an adoption aspect to this, at least where I work. The local
culture is zealous about type safety and generally looks down upon
open source that hasn't yet moved to 1.5.

I confess that I am a bit taken aback now by open source software that
hasn't taken advantage of 1.5 features. I can't know for sure, but I
suspect it is one more barrier for some people.

Sean

On 5/22/07, Bob Scheifler <Bo...@sun.com> wrote:
> Sean Landis wrote:
> > Moving the interfaces. utilities, and services to 1.5 is very
> > important to me
>
> Do you mean generifying the public APIs, or something else?
>
> - Bob
>

Re: Short term plan forward... (proposal)

[Bob Scheifler <Bo...@Sun.COM>]

Sean Landis wrote:
> Moving the interfaces. utilities, and services to 1.5 is very
> important to me

Do you mean generifying the public APIs, or something else?

- Bob

Re: Short term plan forward... (proposal)

[Mark Brouwer <ma...@cheiron.org>]

Sean Landis wrote:
> I think a quick release (as a sign of life) might be a good idea. If a
> few bug fixes can be integrated in a short time frame that would be
> great. By quick release, I think less than a month after the code is
> available to the committers.
> 
> I confess I haven't looked at the bug reports so I am not going to
> comment on which should be in, but if fixes are already available for
> some as Mark says, then they seem like good candidates.
> 
> Moving the interfaces. utilities, and services to 1.5 is very
> important to me and I'd like to see that on the roadmap in the not too
> distant future. At some point, it would then make sense to integrate
> some of the 1.5 features internally but, again, I'd leave that to
> people more involved in the code than I.
> 
> Not being a committer, I hope my input is not offensive to those who
> are investing their personal time.

Not at all, it was a very polite response!

As you indicate 'moving interfaces, utilities and service to 1.5 is
very important to you' would you care to explain why. Probably for
clarity it is better to start that discussion in a new thread I guess.
-- 
Mark

Re: Short term plan forward... (proposal)

[Sean Landis <se...@gmail.com>]

Hi Dan,

On 5/23/07, Dan Creswell <da...@dcrdev.demon.co.uk> wrote:
> Sean Landis wrote:
> > I think a quick release (as a sign of life) might be a good idea. If a
> > few bug fixes can be integrated in a short time frame that would be
> > great. By quick release, I think less than a month after the code is
> > available to the committers.
> >
>
> And if it's more than a month?  Are you then thinking "to hell with it,
> might as well add some other stuff as well if it takes that long"?

No the opposite. If it's more than a month, scale down. I personally
would also be happy with the idea of a baseline River release that's
essentially the current release. I was trying to find a medium ground
by supporting moderate work if it was quick.

> > I confess I haven't looked at the bug reports so I am not going to
> > comment on which should be in, but if fixes are already available for
> > some as Mark says, then they seem like good candidates.
> >
> > Moving the interfaces. utilities, and services to 1.5 is very
> > important to me and I'd like to see that on the roadmap in the not too
>
> Why is it important to you?

See my response to Bob who asked the same question.

> > distant future. At some point, it would then make sense to integrate
> > some of the 1.5 features internally but, again, I'd leave that to
> > people more involved in the code than I.
> >
> > Not being a committer, I hope my input is not offensive to those who
> > are investing their personal time.
> >
>
> It isn't and if it is, I'm sure you'll be told :)
>
> > Regards,
> > Sean

Re: Short term plan forward... (proposal)

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Sean Landis wrote:
> I think a quick release (as a sign of life) might be a good idea. If a
> few bug fixes can be integrated in a short time frame that would be
> great. By quick release, I think less than a month after the code is
> available to the committers.
> 

And if it's more than a month?  Are you then thinking "to hell with it,
might as well add some other stuff as well if it takes that long"?

> I confess I haven't looked at the bug reports so I am not going to
> comment on which should be in, but if fixes are already available for
> some as Mark says, then they seem like good candidates.
> 
> Moving the interfaces. utilities, and services to 1.5 is very
> important to me and I'd like to see that on the roadmap in the not too

Why is it important to you?

> distant future. At some point, it would then make sense to integrate
> some of the 1.5 features internally but, again, I'd leave that to
> people more involved in the code than I.
> 
> Not being a committer, I hope my input is not offensive to those who
> are investing their personal time.
> 

It isn't and if it is, I'm sure you'll be told :)

> Regards,
> Sean
> 

Re: Short term plan forward... (proposal)

[Sean Landis <se...@gmail.com>]

I think a quick release (as a sign of life) might be a good idea. If a
few bug fixes can be integrated in a short time frame that would be
great. By quick release, I think less than a month after the code is
available to the committers.

I confess I haven't looked at the bug reports so I am not going to
comment on which should be in, but if fixes are already available for
some as Mark says, then they seem like good candidates.

Moving the interfaces. utilities, and services to 1.5 is very
important to me and I'd like to see that on the roadmap in the not too
distant future. At some point, it would then make sense to integrate
some of the 1.5 features internally but, again, I'd leave that to
people more involved in the code than I.

Not being a committer, I hope my input is not offensive to those who
are investing their personal time.

Regards,
Sean

Re: Short term plan forward... (proposal)

[Calum Shaw-Mackay <ca...@gmail.com>]

> > Outside of getting something called River released and getting the
> > standard processes going, I'm interested in seeing a simplification of
> > Jini/JavaSpaces. 1. Someone else mentioned this, but forget the
> > installer, just unzip / untar (take a look at Tangosol or GridGain - it
> > is dirt simple) Yes on Maven, Ivy, etc.
> > 2. Configuration - simplify it into a property file or at least provide
> > that as the default (again Tangolos/GridGain are different, but they are
> > simple to set up)
>
> Properties?  Why not some XML?  More importantly, why do you consider
> this simpler?  And do you mean you want everything configured in that
> single file or just some set of core things?  And what are the core things?

In all honesty, I like the way Configuration Files work and actually
want them to be more expressive, even perhaps go so far as to use some
form of Scripting engine to allow this - especially if we have the
abilitiy to make configurations dynamic and use events to signla when
these configurations have changed thus reducing the need to restart
services to apply configuration changes

> In addition I have another sampler question for you:
>
> What about convention over configuration?


Okay I'm going to chip in here on the c-over-c debate, and as it's
very based on JSE 5, it may be of relevance. When I was developing
Glyph the issues of converntion over configuration were very quickly
made apparent to me as Glyph does a lot of code generation. So many of
the glyph utilities make reasonable assumptions about package
suffixes, class names and the like - however these are generated by
apt to these conventions and where it makes practical sense it pushes
these conventions into configuration files such that they may be
configured differently at deployment-time. What I'm realising as I'm
working on Glyph, specifically the new leasing and landlord stuff, is
that preferring one or the other is a bad road to go down. Conventions
rely to much on foresight and at the extreme are, in a sense, a way of
hard coding, whilst too much configuration, lends itself to a system
that is way too dumb to work out how things are set out, and/or
provides a system where the administrator has to configure absolutely
everything. Convention is really a configuration pattern, and can be
used to great effect as long as your able to tailor that convention
through configurations. So really you need a symbiotic relationship
between convention and configuration, not one over the other.

Sorry just from my experience

You can now be returrned to your regular programme

Cheers

--Calum

Re: Short term plan forward... (proposal)

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Herrick, Mike wrote:
> Hi Dan,
> 
> I'm in the position of evaluating introducing new (to us) technology. In
> order to introduce it, I want to see signs of health. I can only assume
> that you are in this position as well in your new job. The roadmap is

So we should clarify that one.  No, that's not my position as:

(1)	Jini is not a core feature of Betfair, distributed systems are.
i.e.  Technology is not the issue, design and architecture are and we
don't necessarily use Jini for implementation.

(2)	I'm seen by many as "Mr Jini" and have previously maintained patched
starter kits for various people.  A number of people treat me as their
first stop for Jini support and some are even expecting me to go fork
JSTK and do something independent of River.  In fact some have even
encouraged me to fork.

I suspect my position then is best termed "unique".  I sometimes play
"customer" and sometimes "developer" and sometimes "committer" whichever
I think is useful for enlarging the community of users of Jini
(enlarging the developer community for me is a response to a larger more
vibrant user community).

> just a logical starting point. It seems to be if not thee - one of the
> first things people check when looking at an open source up start.

And what are the other heartbeats as we're on the subject?

> Perhaps I am harping on that too much so I'll stop. But look at the
> state of it right now:
> http://incubator.apache.org/river/roadmap.html This sends a message to
> people (I think).
> 
> And it isn't necessarily fair, but I think that something like
> Jini/JavaSpaces has an even tougher road ahead of it because it has been
> around for 10 years. It isn't some brand new project. People expect more

I'm less worried about that.  There are a number of similar opensource
efforts in the universe that had similar issues of adoption and making
it to mainstream.

> perhaps because they are used to (I presume) Sun Marketing etc. And
> sadly, Jini/JavaSpaces didn't ever "make it" into the mainstream
> (compared to J2EE) so it has a certain perception amongst people outside
> of the community. You know this better than anyone. When the project has
> been around for 5 months and these things still are not in place I
> wonder and grow concerned. Perhaps others won't. My point is don't make
> it easy for them to ignore/write off Jini/JavaSpaces.
>

Well that's a discussion for beer time - it's way too large and messy to
do here.

> I think that I am the minority here in that I represent potential growth
> of the Jini/JavaSpaces community. I am just trying to give you my
> perspective. I assume that I represent part of the whole point of
> bringing Jini/JavaSpaces to Apache - to grow the community?
> 
> I harp on the Roadmap, but I'm really talking about everything. The
> quickest way to show life IMHO is to get a couple things on the roadmap
> and get those .1, .2 releases done (maybe that is the only thing on the
> roadmap for now).
> 
> Outside of getting something called River released and getting the
> standard processes going, I'm interested in seeing a simplification of
> Jini/JavaSpaces. 1. Someone else mentioned this, but forget the
> installer, just unzip / untar (take a look at Tangosol or GridGain - it
> is dirt simple) Yes on Maven, Ivy, etc.
> 2. Configuration - simplify it into a property file or at least provide
> that as the default (again Tangolos/GridGain are different, but they are
> simple to set up)

Properties?  Why not some XML?  More importantly, why do you consider
this simpler?  And do you mean you want everything configured in that
single file or just some set of core things?  And what are the core things?

In addition I have another sampler question for you:

What about convention over configuration?

> 3. Logging - get rid of sys.out, use log4j (I vaguely remember that
> somewhere)
>

Hmmm, where have you seen sys.out?  Or do you mean don't use JDK logging
use log4j?

> Anyway, I want this to be successful and will help where I can. 
> 
> Cheers,
> 
> Mike 
> 

Many thanks for taking time,

Dan.

> -----Original Message-----
> From: Dan Creswell [mailto:dan@dcrdev.demon.co.uk] 
> Sent: Wednesday, May 23, 2007 3:14 AM
> To: river-dev@incubator.apache.org
> Subject: Re: Short term plan forward... (proposal)
> 
> Hi Mike,
> 
> I'm happy for you to wade in - more external feedback the better.
> 
> My current concern is that at the moment you seem to be saying not much
> more than "Bad River, do stuff, be there".
> 
> Is that actually all you want or are there specific things you expect
> from River?  Those things mightn't be roadmap stuff, they might be
> something else.  In fact, there's a question - why do you want a
> roadmap?  What does that mean to you?  Is it some kind of symbol of
> longevity or maybe a hint of some planning/forethought that makes you
> feel comfortable or something else?
> 
> Dan.
> 
> Herrick, Mike wrote:
>> Mark,
>>
>> I will try to be more constructive in my criticism in the future. 
>> River so far has just been confusing to watch. As someone new to the 
>> community, this is discouraging.
>>
>> I did mention the same criticism you can find on my blog months ago on
> 
>> this list (was more positive then). We just hit a point in our project
> 
>> where the future looked too bleak that we didn't feel like we could 
>> continue to invest in this technology. I now have a little hope, but 
>> we will only pick things back up once it is clear that River is on a 
>> good track.
>>
>> I don't have a vote, but I like Jim Hurley's suggestion for a plan.
>> Those are nice baby steps that will get things going. Any of the 
>> follow on stuff can just be .4, .5. .6 or whatever.
>>
>> In terms of what I can do to help - I can do some grunt work of some 
>> sort to start. If you have an idea let me know, otherwise I'll keep an
> 
>> eye out.
>>
>> Mike
>>
>> -----Original Message-----
>> From: Mark Brouwer [mailto:mark.brouwer@cheiron.org]
>> Sent: Tuesday, May 22, 2007 12:31 AM
>> To: river-dev@incubator.apache.org
>> Subject: Re: Short term plan forward... (proposal)
>>
>> Herrick, Mike wrote:
>>> Whatever is done, get it on the roadmap. Get a 12 month roadmap. 
>>> Start
>>> acting like a project that has a chance at making it as a poddling.
>> Hello Mike,
>>
>> It is hard not to miss the criticism here and in the blogosphere with 
>> regard to Jini and the Apache River project. Therefore I do have a 
>> remark (I just picked your posting so don't take it too personally).
>>
>> "And so, my fellow Apache River friends, ask not what the project can 
>> do for you; ask what you can do for the project."
>>
>> I say this as although it is indeed unfortunate to realize how long it
> 
>> took for the code to arrive, sometimes I also have the feeling some 
>> people think we are here to fulfill their wishes for which they even 
>> have a hard time to make them public.
>>
>> I have no problem with criticism as it is often a healthy way to get 
>> you out of your comfort zone, at the same time I also think there is a
> 
>> limit to it. This project will only become a success and graduate if 
>> we are able to collect new committers who want to backup their wishes 
>> with effort. I realize for a large part that will depend on our 
>> guidance/openness and atmosphere we create here, but equally important
> 
>> are the ideas and will to contribute by those prospects.
>>
>> Asking for a roadmap is logical and fine, but so is suggesting ideas 
>> for that roadmap as it might well turn out that if nobody comes up 
>> with ideas and did some thinking how that fits in with the current 
>> investments/installed base it might well turn out that it ain't the 
>> Big-Bang some of you might be hoping for, while at the same time 
>> significant work is performed that is only perceived by others as 
>> 'maintenance'.
>>
>> This posting is not intended to shut people up, the contrary, but I 
>> hope we can get a collaborative atmosphere here even while at some 
>> moment you want to put the other in the drying machine because of 
>> his/her opinion
>> ;-)
>> --
>> Mark
>>
> 

Re: Short term plan forward... (proposal)

[Holger Hoffstaette <ho...@wizards.de>]

Calum,

apologies for not responding earlier.

On Wed, 23 May 2007 17:49:44 +0100, Calum Shaw-Mackay wrote:

>> (svn co, mvn install) or unzip, run. Anything else is "not good enough".
>> Make it easy to develop (in an IDE), easy to build and easy to test!
> 
> How does the following sit with you......

I should have clarified - I was talking mainly about easy development of
River itself, not client apps (yet). In fact with Spring's javaspaces
module that issue is mostly moot (IMHO). I'm still a Jini/JavaSpaces
newbie but have been using the module to rewrite the JavaSpaces connector
for Mule (http://mule.mulesource.org) against GigaSpaces as reference
implementation while still retaining full vendor independence, and so far
that has turned out to be very easy because of the dramatically simplified
lookup procedure. My first trial - similar to your client below - took not
much more code but did not require custom annotations or other assorted
trickery.

> package glyph.test.simple;
> 
> import java.rmi.RemoteException;
> 
> import net.jini.core.lease.Lease;
> import net.jini.core.transaction.TransactionException; import
> net.jini.lookup.entry.Name;
> import net.jini.space.JavaSpace05;
> 
> import org.jini.glyph.Client;
> 
> public class TestClient {
> 	@Client
> 	public void writeMyEntry(JavaSpace05 myspace){
> 		try {
> 			Name ne = new Name("Joe Bloggs");
> 			myspace.write(ne, null, Lease.FOREVER);
> 		} catch (RemoteException e) {
> 			// TODO Auto-generated catch block
> 			e.printStackTrace();
> 		} catch (TransactionException e) {
> 			// TODO Auto-generated catch block
> 			e.printStackTrace();
> 		}
> 		}
> 	}
> }
> This is all you need to be a client to a JavaSpace and write an
> entry....This is on the issue of making the IDE do the hardwork, or having
> the compiler do the hardwork so you dont have to...

I think I understand what this code and the annotation does, but at least
to me this looks like a perfect example for how and why not to use
annotations. :-)

regards
Holger

Re: Short term plan forward... (proposal)

[Calum Shaw-Mackay <ca...@gmail.com>]

> (svn co, mvn install) or unzip, run. Anything else is "not good enough".
> Make it easy to develop (in an IDE), easy to build and easy to test!

How does the following sit with you......


package glyph.test.simple;

import java.rmi.RemoteException;

import net.jini.core.lease.Lease;
import net.jini.core.transaction.TransactionException;
import net.jini.lookup.entry.Name;
import net.jini.space.JavaSpace05;

import org.jini.glyph.Client;

public class TestClient {
	@Client
	public void writeMyEntry(JavaSpace05 myspace){
		try {
			Name ne = new Name("Joe Bloggs");
			myspace.write(ne, null, Lease.FOREVER);
		} catch (RemoteException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (TransactionException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}
}

This is all you need to be a client to a JavaSpace and write an
entry....This is on the issue of making the IDE do the hardwork, or
having the compiler do the hardwork so you dont have to...


--Calum

RE: Short term plan forward... (proposal)

[Holger Hoffstaette <ho...@wizards.de>]

Lurker alert ;)

On Wed, 23 May 2007 08:34:33 -0400, Herrick, Mike wrote:

> I think that I am the minority here in that I represent potential growth
> of the Jini/JavaSpaces community. I am just trying to give you my

No, not at all. I've been lurking from day one and share exactly the same
concerns.

> Outside of getting something called River released and getting the
> standard processes going, I'm interested in seeing a simplification of
> Jini/JavaSpaces. 1. Someone else mentioned this, but forget the installer,
> just unzip / untar (take a look at Tangosol or GridGain - it is dirt
> simple) Yes on Maven, Ivy, etc. 2. Configuration - simplify it into a
> property file or at least provide that as the default (again
> Tangolos/GridGain are different, but they are simple to set up)
> 3. Logging - get rid of sys.out, use log4j (I vaguely remember that
> somewhere)

Amen to all of that! (-log4j directly, +slf4j for clogging compatibility)

(svn co, mvn install) or unzip, run. Anything else is "not good enough".
Make it easy to develop (in an IDE), easy to build and easy to test!

Holger

RE: Short term plan forward... (proposal)

["Herrick, Mike" <Mi...@LibertyMutual.com>]

Hi Dan,

I'm in the position of evaluating introducing new (to us) technology. In
order to introduce it, I want to see signs of health. I can only assume
that you are in this position as well in your new job. The roadmap is
just a logical starting point. It seems to be if not thee - one of the
first things people check when looking at an open source up start.
Perhaps I am harping on that too much so I'll stop. But look at the
state of it right now:
http://incubator.apache.org/river/roadmap.html This sends a message to
people (I think).

And it isn't necessarily fair, but I think that something like
Jini/JavaSpaces has an even tougher road ahead of it because it has been
around for 10 years. It isn't some brand new project. People expect more
perhaps because they are used to (I presume) Sun Marketing etc. And
sadly, Jini/JavaSpaces didn't ever "make it" into the mainstream
(compared to J2EE) so it has a certain perception amongst people outside
of the community. You know this better than anyone. When the project has
been around for 5 months and these things still are not in place I
wonder and grow concerned. Perhaps others won't. My point is don't make
it easy for them to ignore/write off Jini/JavaSpaces.

I think that I am the minority here in that I represent potential growth
of the Jini/JavaSpaces community. I am just trying to give you my
perspective. I assume that I represent part of the whole point of
bringing Jini/JavaSpaces to Apache - to grow the community?

I harp on the Roadmap, but I'm really talking about everything. The
quickest way to show life IMHO is to get a couple things on the roadmap
and get those .1, .2 releases done (maybe that is the only thing on the
roadmap for now).

Outside of getting something called River released and getting the
standard processes going, I'm interested in seeing a simplification of
Jini/JavaSpaces. 1. Someone else mentioned this, but forget the
installer, just unzip / untar (take a look at Tangosol or GridGain - it
is dirt simple) Yes on Maven, Ivy, etc.
2. Configuration - simplify it into a property file or at least provide
that as the default (again Tangolos/GridGain are different, but they are
simple to set up)
3. Logging - get rid of sys.out, use log4j (I vaguely remember that
somewhere)

Anyway, I want this to be successful and will help where I can. 

Cheers,

Mike 

-----Original Message-----
From: Dan Creswell [mailto:dan@dcrdev.demon.co.uk] 
Sent: Wednesday, May 23, 2007 3:14 AM
To: river-dev@incubator.apache.org
Subject: Re: Short term plan forward... (proposal)

Hi Mike,

I'm happy for you to wade in - more external feedback the better.

My current concern is that at the moment you seem to be saying not much
more than "Bad River, do stuff, be there".

Is that actually all you want or are there specific things you expect
from River?  Those things mightn't be roadmap stuff, they might be
something else.  In fact, there's a question - why do you want a
roadmap?  What does that mean to you?  Is it some kind of symbol of
longevity or maybe a hint of some planning/forethought that makes you
feel comfortable or something else?

Dan.

Herrick, Mike wrote:
> Mark,
> 
> I will try to be more constructive in my criticism in the future. 
> River so far has just been confusing to watch. As someone new to the 
> community, this is discouraging.
> 
> I did mention the same criticism you can find on my blog months ago on

> this list (was more positive then). We just hit a point in our project

> where the future looked too bleak that we didn't feel like we could 
> continue to invest in this technology. I now have a little hope, but 
> we will only pick things back up once it is clear that River is on a 
> good track.
> 
> I don't have a vote, but I like Jim Hurley's suggestion for a plan.
> Those are nice baby steps that will get things going. Any of the 
> follow on stuff can just be .4, .5. .6 or whatever.
> 
> In terms of what I can do to help - I can do some grunt work of some 
> sort to start. If you have an idea let me know, otherwise I'll keep an

> eye out.
> 
> Mike
> 
> -----Original Message-----
> From: Mark Brouwer [mailto:mark.brouwer@cheiron.org]
> Sent: Tuesday, May 22, 2007 12:31 AM
> To: river-dev@incubator.apache.org
> Subject: Re: Short term plan forward... (proposal)
> 
> Herrick, Mike wrote:
>> Whatever is done, get it on the roadmap. Get a 12 month roadmap. 
>> Start
> 
>> acting like a project that has a chance at making it as a poddling.
> 
> Hello Mike,
> 
> It is hard not to miss the criticism here and in the blogosphere with 
> regard to Jini and the Apache River project. Therefore I do have a 
> remark (I just picked your posting so don't take it too personally).
> 
> "And so, my fellow Apache River friends, ask not what the project can 
> do for you; ask what you can do for the project."
> 
> I say this as although it is indeed unfortunate to realize how long it

> took for the code to arrive, sometimes I also have the feeling some 
> people think we are here to fulfill their wishes for which they even 
> have a hard time to make them public.
> 
> I have no problem with criticism as it is often a healthy way to get 
> you out of your comfort zone, at the same time I also think there is a

> limit to it. This project will only become a success and graduate if 
> we are able to collect new committers who want to backup their wishes 
> with effort. I realize for a large part that will depend on our 
> guidance/openness and atmosphere we create here, but equally important

> are the ideas and will to contribute by those prospects.
> 
> Asking for a roadmap is logical and fine, but so is suggesting ideas 
> for that roadmap as it might well turn out that if nobody comes up 
> with ideas and did some thinking how that fits in with the current 
> investments/installed base it might well turn out that it ain't the 
> Big-Bang some of you might be hoping for, while at the same time 
> significant work is performed that is only perceived by others as 
> 'maintenance'.
> 
> This posting is not intended to shut people up, the contrary, but I 
> hope we can get a collaborative atmosphere here even while at some 
> moment you want to put the other in the drying machine because of 
> his/her opinion
> ;-)
> --
> Mark
> 

Re: Short term plan forward... (proposal)

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Hi Mike,

I'm happy for you to wade in - more external feedback the better.

My current concern is that at the moment you seem to be saying not much
more than "Bad River, do stuff, be there".

Is that actually all you want or are there specific things you expect
from River?  Those things mightn't be roadmap stuff, they might be
something else.  In fact, there's a question - why do you want a
roadmap?  What does that mean to you?  Is it some kind of symbol of
longevity or maybe a hint of some planning/forethought that makes you
feel comfortable or something else?

Dan.

Herrick, Mike wrote:
> Mark,
> 
> I will try to be more constructive in my criticism in the future. River
> so far has just been confusing to watch. As someone new to the
> community, this is discouraging.
> 
> I did mention the same criticism you can find on my blog months ago on
> this list (was more positive then). We just hit a point in our project
> where the future looked too bleak that we didn't feel like we could
> continue to invest in this technology. I now have a little hope, but we
> will only pick things back up once it is clear that River is on a good
> track.
> 
> I don't have a vote, but I like Jim Hurley's suggestion for a plan.
> Those are nice baby steps that will get things going. Any of the follow
> on stuff can just be .4, .5. .6 or whatever.
> 
> In terms of what I can do to help - I can do some grunt work of some
> sort to start. If you have an idea let me know, otherwise I'll keep an
> eye out.
> 
> Mike
> 
> -----Original Message-----
> From: Mark Brouwer [mailto:mark.brouwer@cheiron.org] 
> Sent: Tuesday, May 22, 2007 12:31 AM
> To: river-dev@incubator.apache.org
> Subject: Re: Short term plan forward... (proposal)
> 
> Herrick, Mike wrote:
>> Whatever is done, get it on the roadmap. Get a 12 month roadmap. Start
> 
>> acting like a project that has a chance at making it as a poddling.
> 
> Hello Mike,
> 
> It is hard not to miss the criticism here and in the blogosphere with
> regard to Jini and the Apache River project. Therefore I do have a
> remark (I just picked your posting so don't take it too personally).
> 
> "And so, my fellow Apache River friends, ask not what the project can do
> for you; ask what you can do for the project."
> 
> I say this as although it is indeed unfortunate to realize how long it
> took for the code to arrive, sometimes I also have the feeling some
> people think we are here to fulfill their wishes for which they even
> have a hard time to make them public.
> 
> I have no problem with criticism as it is often a healthy way to get you
> out of your comfort zone, at the same time I also think there is a limit
> to it. This project will only become a success and graduate if we are
> able to collect new committers who want to backup their wishes with
> effort. I realize for a large part that will depend on our
> guidance/openness and atmosphere we create here, but equally important
> are the ideas and will to contribute by those prospects.
> 
> Asking for a roadmap is logical and fine, but so is suggesting ideas for
> that roadmap as it might well turn out that if nobody comes up with
> ideas and did some thinking how that fits in with the current
> investments/installed base it might well turn out that it ain't the
> Big-Bang some of you might be hoping for, while at the same time
> significant work is performed that is only perceived by others as
> 'maintenance'.
> 
> This posting is not intended to shut people up, the contrary, but I hope
> we can get a collaborative atmosphere here even while at some moment you
> want to put the other in the drying machine because of his/her opinion
> ;-)
> --
> Mark
> 

RE: Short term plan forward... (proposal)

["Herrick, Mike" <Mi...@LibertyMutual.com>]

Mark,

I will try to be more constructive in my criticism in the future. River
so far has just been confusing to watch. As someone new to the
community, this is discouraging.

I did mention the same criticism you can find on my blog months ago on
this list (was more positive then). We just hit a point in our project
where the future looked too bleak that we didn't feel like we could
continue to invest in this technology. I now have a little hope, but we
will only pick things back up once it is clear that River is on a good
track.

I don't have a vote, but I like Jim Hurley's suggestion for a plan.
Those are nice baby steps that will get things going. Any of the follow
on stuff can just be .4, .5. .6 or whatever.

In terms of what I can do to help - I can do some grunt work of some
sort to start. If you have an idea let me know, otherwise I'll keep an
eye out.

Mike

-----Original Message-----
From: Mark Brouwer [mailto:mark.brouwer@cheiron.org] 
Sent: Tuesday, May 22, 2007 12:31 AM
To: river-dev@incubator.apache.org
Subject: Re: Short term plan forward... (proposal)

Herrick, Mike wrote:
> Whatever is done, get it on the roadmap. Get a 12 month roadmap. Start

> acting like a project that has a chance at making it as a poddling.

Hello Mike,

It is hard not to miss the criticism here and in the blogosphere with
regard to Jini and the Apache River project. Therefore I do have a
remark (I just picked your posting so don't take it too personally).

"And so, my fellow Apache River friends, ask not what the project can do
for you; ask what you can do for the project."

I say this as although it is indeed unfortunate to realize how long it
took for the code to arrive, sometimes I also have the feeling some
people think we are here to fulfill their wishes for which they even
have a hard time to make them public.

I have no problem with criticism as it is often a healthy way to get you
out of your comfort zone, at the same time I also think there is a limit
to it. This project will only become a success and graduate if we are
able to collect new committers who want to backup their wishes with
effort. I realize for a large part that will depend on our
guidance/openness and atmosphere we create here, but equally important
are the ideas and will to contribute by those prospects.

Asking for a roadmap is logical and fine, but so is suggesting ideas for
that roadmap as it might well turn out that if nobody comes up with
ideas and did some thinking how that fits in with the current
investments/installed base it might well turn out that it ain't the
Big-Bang some of you might be hoping for, while at the same time
significant work is performed that is only perceived by others as
'maintenance'.

This posting is not intended to shut people up, the contrary, but I hope
we can get a collaborative atmosphere here even while at some moment you
want to put the other in the drying machine because of his/her opinion
;-)
--
Mark

Re: Short term plan forward... (proposal)

[Mark Brouwer <ma...@cheiron.org>]

Herrick, Mike wrote:
> Whatever is done, get it on the roadmap. Get a 12 month roadmap. Start
> acting like a project that has a chance at making it as a poddling.

Hello Mike,

It is hard not to miss the criticism here and in the blogosphere with
regard to Jini and the Apache River project. Therefore I do have a
remark (I just picked your posting so don't take it too personally).

"And so, my fellow Apache River friends, ask not what the project can do
for you; ask what you can do for the project."

I say this as although it is indeed unfortunate to realize how long
it took for the code to arrive, sometimes I also have the feeling some
people think we are here to fulfill their wishes for which they even
have a hard time to make them public.

I have no problem with criticism as it is often a healthy way to get you
out of your comfort zone, at the same time I also think there is a limit
to it. This project will only become a success and graduate if we are
able to collect new committers who want to backup their wishes with
effort. I realize for a large part that will depend on our
guidance/openness and atmosphere we create here, but equally important
are the ideas and will to contribute by those prospects.

Asking for a roadmap is logical and fine, but so is suggesting ideas for
that roadmap as it might well turn out that if nobody comes up with
ideas and did some thinking how that fits in with the current
investments/installed base it might well turn out that it ain't the
Big-Bang some of you might be hoping for, while at the same time
significant work is performed that is only perceived by others as
'maintenance'.

This posting is not intended to shut people up, the contrary, but I hope
we can get a collaborative atmosphere here even while at some moment you
want to put the other in the drying machine because of his/her opinion ;-)
-- 
Mark

Re: Short term plan forward... (proposal)

[Jim Hurley <Ji...@Sun.COM>]

On May 21, 2007, at 10:09 PM, Herrick, Mike wrote:
> :
> Get the code and if you don't this week, can you please explain why
> specifically? For those of us not in the inner circle Apache River  
> seems
> to be going nowhere. I'm sure there are good reasons, but you have  
> been
> saying for 2 months that you are going to have the code "any day now".

Sorry for the delay.  There's a lot of source here (and docs, build  
stuff,
etc).  Running scripts (and correcting problems) to update the headers
and such has taken some time. Also wanted to be sure we included
everything.  Thanks to Frank Barnaby for his work on this.

We are going to get the starter kit contribution bundle attached today.
:-)

Assuming folks have a chance to check it out over the next few days,
I'd like to start an acceptance vote on it early next week.

To be able to get the starter kit source into the project without
further delay, I'm separating the contribution and vote on QATests
from the starter kit.

thanks -Jim

RE: Short term plan forward... (proposal)

["Herrick, Mike" <Mi...@LibertyMutual.com>]

Whatever is done, get it on the roadmap. Get a 12 month roadmap. Start
acting like a project that has a chance at making it as a poddling.

Get the code and if you don't this week, can you please explain why
specifically? For those of us not in the inner circle Apache River seems
to be going nowhere. I'm sure there are good reasons, but you have been
saying for 2 months that you are going to have the code "any day now". 

It is encouraging to see some life here.

We did a POC of Jini/JavaSpaces and love the tech, but put adoption
(further work) on hold because River looked dead (and thus we figured
that was the end of Jini/JavaSpaces).

Not trying to be harsh, but as someone new to Jini/JavaSpaces (who loves
the tech) it has been very disappointing to watch River so far.

Just get the roadmap and hit a few singles. I liked the .1 release idea.

I guess it depends if River is maintenance for Jini/JavaSpaces or if you
want to grow the community. If it is the later, hit some singles and get
some credibility and then swing for the fences.

Mike 

-----Original Message-----
From: Calum Shaw-Mackay [mailto:calum.shawmackay@gmail.com] 
Sent: Monday, May 21, 2007 4:03 PM
To: river-dev@incubator.apache.org
Subject: Re: Short term plan forward... (proposal)

Just as a further note for discussion, I believe we should be engaging
the community now about the next iteration of the specs (i.e. things
like Executor extension for Javaspaces, et al, XA transaction manager,
etc) and what wants to be seen in the next iteration of the core
services (Nested Transaction Manager implementation for example), so
that from that area, things can be seen to be progressing.

Just a thought

--Calum

On 21/05/07, Mark Brouwer <ma...@cheiron.org> wrote:
> Jim Hurley wrote:
> > Hi all-
> >
> > Just wanted to propose a short term conceptual plan forward for 
> > Apache River, and see if we're in sync.
>
> Thanks for starting this Jim. Below some of my initial thoughts on 
> your ideas.
>
> > Once we get the source accepted and contributed to the project 
> > (hopefully this week!)...  I'd like to propose that we immediately 
> > start working on a release (v0.1).  This will not only help us 
> > understand the paces of getting a release out through Apache, but 
> > also provide a release to the Community from Apache.  To focus on 
> > getting a release out, the initial work would be targeted at 
> > integration stuff (for example, getting Service UI
> > integrated) and some documentation rather than on very many bug 
> > fixes or rfes.
> >
> > Once we accomplish that, we can turn our focus towards another near 
> > term release (v0.2) which could include additional bug fixes and 
> > smaller rfes as well as any cleanup we learn from getting the v0.1 
> > release out. This would not only provide an added value release out 
> > to the Community, but also give us further experience and additional

> > momentum of an active project moving forward.
>
> I find v0.1 not ambitious enough. I think it is important to do some 
> bug-fixes and RFEs that have been completed and lingering around for a

> very long time in some peoples workspaces. Just to release so most 
> people can sit on the sideline watching v0.1 being released is not 
> that interesting to me (I also want to get rid of a lot of fixes and 
> small RFEs I've been carrying for too long). Therefore I'm inclined to

> merge the goals for v0.1 and v0.2 as most of it likely represents 
> completed work. Based on what is in Bugtraq, has been added to River 
> and is completed in the Sun internal version control system we can 
> make a selection of what to put into that first release. Whether there

> is still a need for a release between the first release and the 'meat
to it'
> release I find hard to say at this point.
>
> With regard to the version numbering you used. The version numbering 
> between the Jini Specifications and the JTSK has been correlated to an

> unhealthy degree IMHO and I think starting from zero isn't the best we

> can do as likely the first releases will be something that resembles 
> the JTSK from Apache instead of from Sun. As long as we don't have a 
> clear (as perceived by our audience) separation between the specs and 
> the implementation/starter kit I would suggest starting at 2.2.
>
> The more 'meat to it' specification release could become 3.0 and 
> whatever products/deliverables we end up with could start using a 
> version number that does justice to it.
>
> > At that point, I think we'd be seasoned enough to focus on a release

> > with some 'meat to it' ;-)  (some of the more major bug fixes/rfes 
> > that have been discussed).
>
> Agreed.
>
> > Running in parallel to this development focus, I think there should 
> > be some longer range project discussions (what kind of releases do 
> > we eventually want to do in the project, what are we trying to 
> > accomplish (iterating on the core infrastructure or branching out 
> > into other areas), etc).
>
> Agreed.
>
> > ps.  On a specific item - not sure where a package name
> >        (to org.apache) change would fit in this proposal.  Maybe
> >        release v0.2 or after?
>
> As far as I'm concerned after v0.2. This won't be a trivial change and

> probably something we should do while we try to get the question 
> answered about maintaining compatibility, not something for the v0.2 
> to be tackled I guess. Or in other word, if we pursue a change with 
> major impact I think it is also the best opportunity to make some 
> changes that could lead to (minor) incompatibility and that will 
> require a significant window in which to sort that out.
>
> Another thing that should be discussed is the minimum J2SE version we 
> are going to conform us to for these initial releases. For v0.1/0.2 I 
> would say we should stick to J2SE 1.4 and for the 'meat to it' release

> we should start the discussion about moving to 5.0.
> --
> Mark
>

Re: Short term plan forward... (proposal)

[Calum Shaw-Mackay <ca...@gmail.com>]

Just as a further note for discussion, I believe we should be engaging
the community now about the next iteration of the specs (i.e. things
like Executor extension for Javaspaces, et al, XA transaction manager,
etc) and what wants to be seen in the next iteration of the core
services (Nested Transaction Manager implementation for example), so
that from that area, things can be seen to be progressing.

Just a thought

--Calum

On 21/05/07, Mark Brouwer <ma...@cheiron.org> wrote:
> Jim Hurley wrote:
> > Hi all-
> >
> > Just wanted to propose a short term conceptual plan
> > forward for Apache River, and see if we're in sync.
>
> Thanks for starting this Jim. Below some of my initial thoughts on your
> ideas.
>
> > Once we get the source accepted and contributed
> > to the project (hopefully this week!)...  I'd like to propose
> > that we immediately start working on a release (v0.1).  This will
> > not only help us understand the paces of getting a release
> > out through Apache, but also provide a release to the Community
> > from Apache.  To focus on getting a release out, the initial work
> > would be targeted at integration stuff (for example, getting Service UI
> > integrated) and some documentation rather than on very many
> > bug fixes or rfes.
> >
> > Once we accomplish that, we can turn our focus towards another
> > near term release (v0.2) which could include additional bug fixes
> > and smaller rfes as well as any cleanup we learn from getting
> > the v0.1 release out. This would not only provide an added value
> > release out to the Community, but also give us further experience
> > and additional momentum of an active project moving forward.
>
> I find v0.1 not ambitious enough. I think it is important to do some
> bug-fixes and RFEs that have been completed and lingering around for a
> very long time in some peoples workspaces. Just to release so most
> people can sit on the sideline watching v0.1 being released is not that
> interesting to me (I also want to get rid of a lot of fixes and small
> RFEs I've been carrying for too long). Therefore I'm inclined to merge
> the goals for v0.1 and v0.2 as most of it likely represents completed
> work. Based on what is in Bugtraq, has been added to River and is
> completed in the Sun internal version control system we can make a
> selection of what to put into that first release. Whether there is still
> a need for a release between the first release and the 'meat to it'
> release I find hard to say at this point.
>
> With regard to the version numbering you used. The version numbering
> between the Jini Specifications and the JTSK has been correlated to an
> unhealthy degree IMHO and I think starting from zero isn't the best we
> can do as likely the first releases will be something that resembles the
> JTSK from Apache instead of from Sun. As long as we don't have a clear
> (as perceived by our audience) separation between the specs and the
> implementation/starter kit I would suggest starting at 2.2.
>
> The more 'meat to it' specification release could become 3.0 and
> whatever products/deliverables we end up with could start using a
> version number that does justice to it.
>
> > At that point, I think we'd be seasoned enough to focus on a
> > release with some 'meat to it' ;-)  (some of the more major bug
> > fixes/rfes that have been discussed).
>
> Agreed.
>
> > Running in parallel to this development focus, I think there
> > should be some longer range project discussions (what kind
> > of releases do we eventually want to do in the project, what
> > are we trying to accomplish (iterating on the core infrastructure
> > or branching out into other areas), etc).
>
> Agreed.
>
> > ps.  On a specific item - not sure where a package name
> >        (to org.apache) change would fit in this proposal.  Maybe
> >        release v0.2 or after?
>
> As far as I'm concerned after v0.2. This won't be a trivial change and
> probably something we should do while we try to get the question
> answered about maintaining compatibility, not something for the v0.2 to
> be tackled I guess. Or in other word, if we pursue a change with major
> impact I think it is also the best opportunity to make some changes that
> could lead to (minor) incompatibility and that will require a
> significant window in which to sort that out.
>
> Another thing that should be discussed is the minimum J2SE version we
> are going to conform us to for these initial releases. For v0.1/0.2 I
> would say we should stick to J2SE 1.4 and for the 'meat to it' release
> we should start the discussion about moving to 5.0.
> --
> Mark
>

Re: Short term plan forward... (proposal)

[Mark Brouwer <ma...@cheiron.org>]

Jim Hurley wrote:
> Hi all-
> 
> Just wanted to propose a short term conceptual plan
> forward for Apache River, and see if we're in sync.

Thanks for starting this Jim. Below some of my initial thoughts on your
ideas.

> Once we get the source accepted and contributed
> to the project (hopefully this week!)...  I'd like to propose
> that we immediately start working on a release (v0.1).  This will
> not only help us understand the paces of getting a release
> out through Apache, but also provide a release to the Community
> from Apache.  To focus on getting a release out, the initial work
> would be targeted at integration stuff (for example, getting Service UI
> integrated) and some documentation rather than on very many
> bug fixes or rfes.
> 
> Once we accomplish that, we can turn our focus towards another
> near term release (v0.2) which could include additional bug fixes
> and smaller rfes as well as any cleanup we learn from getting
> the v0.1 release out. This would not only provide an added value
> release out to the Community, but also give us further experience
> and additional momentum of an active project moving forward.

I find v0.1 not ambitious enough. I think it is important to do some
bug-fixes and RFEs that have been completed and lingering around for a
very long time in some peoples workspaces. Just to release so most
people can sit on the sideline watching v0.1 being released is not that
interesting to me (I also want to get rid of a lot of fixes and small
RFEs I've been carrying for too long). Therefore I'm inclined to merge
the goals for v0.1 and v0.2 as most of it likely represents completed
work. Based on what is in Bugtraq, has been added to River and is
completed in the Sun internal version control system we can make a
selection of what to put into that first release. Whether there is still
a need for a release between the first release and the 'meat to it'
release I find hard to say at this point.

With regard to the version numbering you used. The version numbering
between the Jini Specifications and the JTSK has been correlated to an
unhealthy degree IMHO and I think starting from zero isn't the best we
can do as likely the first releases will be something that resembles the
JTSK from Apache instead of from Sun. As long as we don't have a clear
(as perceived by our audience) separation between the specs and the
implementation/starter kit I would suggest starting at 2.2.

The more 'meat to it' specification release could become 3.0 and
whatever products/deliverables we end up with could start using a
version number that does justice to it.

> At that point, I think we'd be seasoned enough to focus on a
> release with some 'meat to it' ;-)  (some of the more major bug
> fixes/rfes that have been discussed).

Agreed.

> Running in parallel to this development focus, I think there
> should be some longer range project discussions (what kind
> of releases do we eventually want to do in the project, what
> are we trying to accomplish (iterating on the core infrastructure
> or branching out into other areas), etc).

Agreed.

> ps.  On a specific item - not sure where a package name
>        (to org.apache) change would fit in this proposal.  Maybe
>        release v0.2 or after?

As far as I'm concerned after v0.2. This won't be a trivial change and
probably something we should do while we try to get the question
answered about maintaining compatibility, not something for the v0.2 to
be tackled I guess. Or in other word, if we pursue a change with major
impact I think it is also the best opportunity to make some changes that
could lead to (minor) incompatibility and that will require a
significant window in which to sort that out.

Another thing that should be discussed is the minimum J2SE version we
are going to conform us to for these initial releases. For v0.1/0.2 I
would say we should stick to J2SE 1.4 and for the 'meat to it' release
we should start the discussion about moving to 5.0.
-- 
Mark

Re: Short term plan forward... (proposal)

["Christopher G. Stach II" <cg...@ldsys.net>]

Bob Scheifler wrote:
> Jim Hurley wrote:
>> I'd like to propose
>> that we immediately start working on a release (v0.1).
>> To focus on getting a release out, the initial work
>> would be targeted at integration stuff (for example, getting Service UI
>> integrated) and some documentation rather than on very many
>> bug fixes or rfes.
> 
> I'm OK with that if that's what people want, but it would be good
> to get a bit more clarity.  The first release would have:
>  - no code changes over the 2.1 starter kit release?
>  - lib/serviceui.jar added in as-is (not classes folded into other jars)?
>  - no installer, just a zip file distribution?
>  - no fundamental changes to the build process?
>  - just cosmetic changes to the documentation?  [what changes?]
> 
> 
> - Bob
> 

I'm definitely for fast and short releases.  Some things that should
probably be done in the first release include:

* Identifying what IS Jini and what ISN'T Jini (or, what is River)

I think that there might be a lot of confusion as to what is standard
and what isn't.  Decent examples of this pattern are JPA-Hibernate and
Jini-GigaSpaces (although the Jini isn't that visible there).  I can
imagine that beginners interested in Jini are picking up Jan Newmarch's
Jini 2.0 book and finding themselves puzzled about all of the
clarifications.  "This isn't a standard class and it can disappear at
any time." (paraphrased)  This leaves room for both a bare bones Jini
package that is concerned about backwards compatibility and a value
added set of packages where developers can run free and implement new
things (like a [what I think is an awesome idea] semi-standard
implementation of notify heartbeat.)  Jini is pretty stagnant as it is.
 There's no reason to hold it back from new Java library classes or
language features.

* Make it easily available

A lot of people use Maven, Maven 2, and Ivy.  A zip file or available
JARs should be fine.  Get it on ibiblio ASAP.  I think that anyone using
this can put it together with good documentation.  Screw installers. :)
 I know that I'd personally rather unzip something and take the parts
that I want than run someone else's version of what they think things
should look like on my computer or in my workspace.

* Good, or at least centralized, documentation

As always, the last part to happen. :)  It doesn't have to be
comprehensive, as long as people can get started.  A plain old wiki with
some common use cases should suffice.  In addition, I think that a lot
of the Jini experts are pretty quiet about design patterns, or at least
those patterns are hidden from plain view on mailing lists.  This is a
great chance for everyone to just dump their crap on a wiki and let
people piece it together over time.  At least they will know where to look.

* Great build process.

Jini has a chance to be very useful to a lot of businesses, and open
source is usually pretty tough to sell in many organizations.  Great and
easily available metrics are important.  People will probably want to
see defect analysis, metrics, unit test coverage, defect trends, MTTR,
etc.  Getting this going right away will be good to show that there's
momentum from the initial code delivery and it will help formulate a
repository structure in the early stages.

There was a more, but I was pretty tired...

-- 
Christopher G. Stach II

Re: Short term plan forward... (proposal)

[Gregg Wonderly <gr...@wonderly.org>]

Bob Scheifler wrote:
> I'm OK with that if that's what people want, but it would be good
> to get a bit more clarity.  The first release would have:
>  - no code changes over the 2.1 starter kit release?
>  - lib/serviceui.jar added in as-is (not classes folded into other jars)?
>  - no installer, just a zip file distribution?
>  - no fundamental changes to the build process?
>  - just cosmetic changes to the documentation?  [what changes?]

My view is that there are a couple of different issues here.  One is the 
management of the CVS/SVN content and the other is the creation of a release.  I 
have a couple of different desires related to these two issues.  I've talked 
about some of them, but just to reiterate:

Source code content:
o	Tabbing should be either all tabs or all spaces to make it possible
	for people to leave their IDE settings alone and get reasonably
	viewable code.  All of my source is tabs only as I've said here before.

o	There should be a base source drop that is exactly the content of the
	last Jini 2.1 content to help in generating diffs for migrating and
	commoning source bases that other developers have from the 2.1 content.

Release content:
o	A 0.1 release, I think would help the new "team" figure out what is
	needed to make that happen.  By making limited changes to the content
	from the 2.1 releases, a content audit of sorts might be possible.
	Whether this is a public release might be interesting to discuss.

o	Calling the first release 2.2 is something I agree with to better
	help people understand the evolution between Jini and the River project.

Gregg Wonderly

Re: Short term plan forward... (proposal)

[Bob Scheifler <Bo...@Sun.COM>]

Jim Hurley wrote:
> I'd like to propose
> that we immediately start working on a release (v0.1).
> To focus on getting a release out, the initial work
> would be targeted at integration stuff (for example, getting Service UI
> integrated) and some documentation rather than on very many
> bug fixes or rfes.

I'm OK with that if that's what people want, but it would be good
to get a bit more clarity.  The first release would have:
  - no code changes over the 2.1 starter kit release?
  - lib/serviceui.jar added in as-is (not classes folded into other jars)?
  - no installer, just a zip file distribution?
  - no fundamental changes to the build process?
  - just cosmetic changes to the documentation?  [what changes?]


- Bob

Re: Short term plan forward... (proposal)

[Dan Creswell <da...@dcrdev.demon.co.uk>]

That's all +1 for me Jim.

I'm very pro 0.1 release for all the reasons you mention plus I think it
helps us get back in touch with our (hopefully larger) community.

One question:  Would we tackle the "installer issue" for 0.1?

Dan.

Jim Hurley wrote:
> Hi all-
> 
> Just wanted to propose a short term conceptual plan
> forward for Apache River, and see if we're in sync.
> 
> Once we get the source accepted and contributed
> to the project (hopefully this week!)...  I'd like to propose
> that we immediately start working on a release (v0.1).  This will
> not only help us understand the paces of getting a release
> out through Apache, but also provide a release to the Community
> from Apache.  To focus on getting a release out, the initial work
> would be targeted at integration stuff (for example, getting Service UI
> integrated) and some documentation rather than on very many
> bug fixes or rfes.
> 
> Once we accomplish that, we can turn our focus towards another
> near term release (v0.2) which could include additional bug fixes
> and smaller rfes as well as any cleanup we learn from getting
> the v0.1 release out. This would not only provide an added value
> release out to the Community, but also give us further experience
> and additional momentum of an active project moving forward.
> 
> At that point, I think we'd be seasoned enough to focus on a
> release with some 'meat to it' ;-)  (some of the more major bug
> fixes/rfes that have been discussed).
> 
> Running in parallel to this development focus, I think there
> should be some longer range project discussions (what kind
> of releases do we eventually want to do in the project, what
> are we trying to accomplish (iterating on the core infrastructure
> or branching out into other areas), etc).
> 
> There it is (again - high level, just to see if we agree on an
> overall direction).  Please share your thoughts.
> 
> thanks -Jim
> 
> ps.  On a specific item - not sure where a package name
>        (to org.apache) change would fit in this proposal.  Maybe
>        release v0.2 or after?
>