Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Peter Firmstone]

Hi Philip,

The most recent modular build attempt is here:

http://svn.apache.org/viewvc/river/jtsk/modules/

Cheers,

Peter.

On 7/3/2020 2:19 PM, Phillip Rhodes wrote:

Aaah, I may not be using the latest code then. For me, the maven build
is failing right now due to missing dependencies on classes from the
river-policy module, and that module doesn't even have a pom.xml in
it.

Which branch is everybody working on? And is work still going on
through the svn repo at the moment? I haven't had time to catch up on
all the email threads... I saw some reference to switching to Git ( a
move I endorse) but I am not sure if it's time to switch yet.  Any
insight would be much appreciated.


Phil

Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Phillip Rhodes]

Aaah, I may not be using the latest code then. For me, the maven build
is failing right now due to missing dependencies on classes from the
river-policy module, and that module doesn't even have a pom.xml in
it.

Which branch is everybody working on? And is work still going on
through the svn repo at the moment? I haven't had time to catch up on
all the email threads... I saw some reference to switching to Git ( a
move I endorse) but I am not sure if it's time to switch yet.  Any
insight would be much appreciated.


Phil

Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Peter Firmstone]

Hi Phil,

It's great to have your help. :)

The maven build structure is almost complete, there are some junit tests 
that need to be moved over to their relevant modules from the old ant 
build.  After that there will be some minor implementation dependencies 
between the modules that need to be broken, as well as some issues with 
the pom files themselves.  I believe that the gradle build will utilise 
the same module layout, so any work getting a maven build working will 
not go to waste.


It's not at a stage where it builds yet, there is some work remaining.   
It's probably best to stick with Java 8, as there will be some 
additional problems building later Java versions.


Cheers,

Peter.


On 7/2/2020 12:10 PM, Phillip Rhodes wrote:

A Gradle build would be nice. I'm willing to invest some time trying
to help make it happen if need be. But I am curious.., it looks like
someone started a Maven build a while back.. From what I can see it
seems to maybe be incomplete, or just bit-rotted. But depending on the
details of the state of that work, would there be any reason to prefer
sticking with maven? (FSM help me, I can't believe I just said that in
a public forum).

I'm not the biggest Maven fan in the world, so I only raise this issue
from the "can we use existing work instead of starting from scratch"
perspective.


Phil

Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Dan Rollo]

Phil,

If nothing else comes of this, I want to thank you for the phrase "FSM help 
me”. I had to look it up, and had a huge grin reading the wikipedia page I 
found. Wow!

Any way, I think Peter’s work includes much of the conversion to a build using 
maven modules. I am not maven averse, but neither am I gradle negative. My 
enthusiasm for the maven build is based on a hope it would lead to clearer 
delineation of  components (some of which share the same source code, but 
produce separate jars with some of the same class files as needed). I’d be 
happy to lend a hand with any maven issue that pops up, but would not lambast a 
gradle approach.

Dan


> Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for 
> River
>   12518 by: Phillip Rhodes
> 
> Administrivia:
> 
> -
> To post to the list, e-mail: dev@river.apache.org
> To unsubscribe, e-mail: dev-digest-unsubscr...@river.apache.org
> For additional commands, e-mail: dev-digest-h...@river.apache.org
> 
> --
> 
> 
> From: Phillip Rhodes 
> Subject: Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss 
> attic for River
> Date: July 1, 2020 at 10:10:29 PM EDT
> To: dev@river.apache.org
> Cc: Michael Sobolewski , dennis.re...@gmail.com
> 
> 
> A Gradle build would be nice. I'm willing to invest some time trying
> to help make it happen if need be. But I am curious.., it looks like
> someone started a Maven build a while back.. From what I can see it
> seems to maybe be incomplete, or just bit-rotted. But depending on the
> details of the state of that work, would there be any reason to prefer
> sticking with maven? (FSM help me, I can't believe I just said that in
> a public forum).
> 
> I'm not the biggest Maven fan in the world, so I only raise this issue
> from the "can we use existing work instead of starting from scratch"
> perspective.
> 
> 
> Phil
> 
> 
> 

Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Phillip Rhodes]

A Gradle build would be nice. I'm willing to invest some time trying
to help make it happen if need be. But I am curious.., it looks like
someone started a Maven build a while back.. From what I can see it
seems to maybe be incomplete, or just bit-rotted. But depending on the
details of the state of that work, would there be any reason to prefer
sticking with maven? (FSM help me, I can't believe I just said that in
a public forum).

I'm not the biggest Maven fan in the world, so I only raise this issue
from the "can we use existing work instead of starting from scratch"
perspective.


Phil

Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Peter Firmstone]

Excellent, thanks Mike,

Good to have you with us.

Cheers,

Peter.

On 5/28/2020 12:40 AM, Michael Sobolewski wrote:

Hi Peter,

I am still interested. Dennis worked with me on the SORCER/Rio 
integration for a couple years at AFRL/WPAFB. He helped us to 
integrate all projects at the Multidisciplinary Science and Technology 
Center with git/gradle uniform build automation, distributions and 
testing. I do not see another better alternative for River than 
git/gradle.


If Dennis needs my help I am available.

Regards
Mike

On May 27, 2020, at 3:33 AM, Peter Firmstone 
mailto:peter.firmst...@zeus.net.au>> wrote:


Thanks Dan,

Hi Dennis,

I recall Michael from Sorcer Soft (cc'd) also showed interest in a 
Gradle build.


The modular build is here:
https://svn.apache.org/viewvc/river/jtsk/modules/
svn checkout http://svn.apache.org/repos/asf/river/jtsk/modules

Do you still have svn access?   It's a development build, I think 
people would be pleased to see some development action.


The qa test suite is currently an ant build.

Regards,

Peter.


On 5/27/2020 3:40 AM, Dan Rollo wrote:

Regarding a gradle build:
I’m not against a gradle build, but I’m by no means a gradle expert.

For the initial modular build, I think the “opinionated” nature of maven is 
helpful in providing some guard rails, but that could just be a function of me 
having more familiarity with maven.

Dan

Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Peter Firmstone]

River's still using SVN.  Feel free to bring that up for discussion or a 
vote if you like, I don't think there will be any resistance to change.



On 5/27/2020 11:01 PM, Dennis Reedy wrote:

Peter,

I’ll try checking that out. One thing, I had thought River switched to 
git? Or is River still using subversion?


Dennis

On May 27, 2020, at 4:33 AM, Peter Firmstone 
 wrote:




Thanks Dan,

Hi Dennis,

I recall Michael from Sorcer Soft (cc'd) also showed interest in a 
Gradle build.


The modular build is here:
https://svn.apache.org/viewvc/river/jtsk/modules/
svn checkout http://svn.apache.org/repos/asf/river/jtsk/modules

Do you still have svn access?   It's a development build, I think 
people would be pleased to see some development action.


The qa test suite is currently an ant build.

Regards,

Peter.


On 5/27/2020 3:40 AM, Dan Rollo wrote:

Regarding a gradle build:
I’m not against a gradle build, but I’m by no means a gradle expert.

For the initial modular build, I think the “opinionated” nature of maven is 
helpful in providing some guard rails, but that could just be a function of me 
having more familiarity with maven.

Dan

Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Michael Sobolewski]

Hi Peter,

I am still interested. Dennis worked with me on the SORCER/Rio integration for 
a couple years at AFRL/WPAFB. He helped us to integrate all projects at the 
Multidisciplinary Science and Technology Center with git/gradle uniform build 
automation, distributions and testing. I do not see another better alternative 
for River than git/gradle. 

If Dennis needs my help I am available.

Regards
Mike

> On May 27, 2020, at 3:33 AM, Peter Firmstone  
> wrote:
> 
> Thanks Dan,
> 
> Hi Dennis, 
> 
> I recall Michael from Sorcer Soft (cc'd) also showed interest in a Gradle 
> build. 
> 
> The modular build is here:
> https://svn.apache.org/viewvc/river/jtsk/modules/ 
> 
> svn checkout http://svn.apache.org/repos/asf/river/jtsk/modules
> 
> Do you still have svn access?   It's a development build, I think people 
> would be pleased to see some development action.
> 
> The qa test suite is currently an ant build.
> 
> Regards,
> 
> Peter.
> 
> 
> On 5/27/2020 3:40 AM, Dan Rollo wrote:
>> Regarding a gradle build: 
>> I’m not against a gradle build, but I’m by no means a gradle expert.
>> 
>> For the initial modular build, I think the “opinionated” nature of maven is 
>> helpful in providing some guard rails, but that could just be a function of 
>> me having more familiarity with maven.
>> 
>> Dan
>> 

Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Dennis Reedy]

Peter,

Can/should we work off of this repository as well?
https://github.com/apache/river

Dennis

On Wed, May 27, 2020 at 9:01 AM Dennis Reedy  wrote:

> Peter,
>
> I’ll try checking that out. One thing, I had thought River switched to
> git? Or is River still using subversion?
>
> Dennis
>
> On May 27, 2020, at 4:33 AM, Peter Firmstone 
> wrote:
>
> 
>
> Thanks Dan,
>
> Hi Dennis,
>
> I recall Michael from Sorcer Soft (cc'd) also showed interest in a Gradle
> build.
> The modular build is here:
> https://svn.apache.org/viewvc/river/jtsk/modules/
> svn checkout http://svn.apache.org/repos/asf/river/jtsk/modules
>
> Do you still have svn access?   It's a development build, I think people
> would be pleased to see some development action.
>
> The qa test suite is currently an ant build.
> Regards,
>
> Peter.
>
>
> On 5/27/2020 3:40 AM, Dan Rollo wrote:
>
> Regarding a gradle build:
> I’m not against a gradle build, but I’m by no means a gradle expert.
>
> For the initial modular build, I think the “opinionated” nature of maven is 
> helpful in providing some guard rails, but that could just be a function of 
> me having more familiarity with maven.
>
> Dan
>
>
>

Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Dennis Reedy]

Peter,

I’ll try checking that out. One thing, I had thought River switched to git? Or 
is River still using subversion?

Dennis

> On May 27, 2020, at 4:33 AM, Peter Firmstone  
> wrote:
> 
> 
> Thanks Dan,
> 
> Hi Dennis, 
> 
> I recall Michael from Sorcer Soft (cc'd) also showed interest in a Gradle 
> build. 
> 
> The modular build is here:
> https://svn.apache.org/viewvc/river/jtsk/modules/
> svn checkout http://svn.apache.org/repos/asf/river/jtsk/modules
> 
> Do you still have svn access?   It's a development build, I think people 
> would be pleased to see some development action.
> 
> The qa test suite is currently an ant build.
> 
> Regards,
> 
> Peter.
> 
> 
>> On 5/27/2020 3:40 AM, Dan Rollo wrote:
>> Regarding a gradle build: 
>> I’m not against a gradle build, but I’m by no means a gradle expert.
>> 
>> For the initial modular build, I think the “opinionated” nature of maven is 
>> helpful in providing some guard rails, but that could just be a function of 
>> me having more familiarity with maven.
>> 
>> Dan
>> 

Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Peter Firmstone]

Thanks Dan,

Hi Dennis,

I recall Michael from Sorcer Soft (cc'd) also showed interest in a 
Gradle build.


The modular build is here:
https://svn.apache.org/viewvc/river/jtsk/modules/
svn checkout http://svn.apache.org/repos/asf/river/jtsk/modules

Do you still have svn access?   It's a development build, I think people 
would be pleased to see some development action.


The qa test suite is currently an ant build.

Regards,

Peter.


On 5/27/2020 3:40 AM, Dan Rollo wrote:

Regarding a gradle build:
I’m not against a gradle build, but I’m by no means a gradle expert.

For the initial modular build, I think the “opinionated” nature of maven is 
helpful in providing some guard rails, but that could just be a function of me 
having more familiarity with maven.

Dan

Re: Board feedback - Request discuss attic for River

[Dan Rollo]

Regarding a gradle build: 
I’m not against a gradle build, but I’m by no means a gradle expert.

For the initial modular build, I think the “opinionated” nature of maven is 
helpful in providing some guard rails, but that could just be a function of me 
having more familiarity with maven.

Dan

Re: Board feedback - Request discuss attic for River

[Peter Firmstone]

Hi Dennis,

Replies inline below.

On 5/22/2020 2:56 PM, Dennis Reedy wrote:

Hi Peter,

Some quick late night thoughts ...

- Time depending, helping a Gradle build for River is something that I'd
be glad to participate in. I think one of the biggest challenges will be
getting the testing framework working, or choosing a modern equivalent.

I would definitely appreciate your participation :)

- As it relates to combining Rio and River, I'd vote no. River has
enough complexities/challenges, no reason to muddy the waters even more
with Rio. Perhaps looking at how to create River components within a Spring
Boot app might be more attractive, and open the an entire open source
eco-system.

Ok, interested to hear your thoughts on that, I'm not a spring boot dev.

- I have not seen the tide turning for dynamic code, my experience has
been the opposite.
Due to complexity no doubt and additional testing requirements.   I was 
in my own bubble, thinking about how the complexities of dynamic code 
can be made simpler and how this might affect it's adoption in the future.

- Something else to consider is to look at the level of effort for
moving River to a more current Java version though, at least Java 8 if not
11.
JGDMS is Java 8 source and tested on Java 11, actually it has some minor 
changes to support Java 11 specifically, but I can't remember them off 
hand.  So if this code is brought in after the modular build we'll pick 
up these changes.


Regards

Dennis

On Fri, May 22, 2020 at 12:07 AM Peter Firmstone <
peter.firmst...@zeus.net.au> wrote:


Hi Dennis,

Good to hear from you.

The truth is, I'm no build expert, Dan is much more capable than I am,
so I'm waiting to hear Dan's opinion on Gradle, it certainly looks good.

Would you be interested in helping to create a Gradle build?

Something else I've been thinking about is you once proposed to
integrate Rio with River, by the time I saw the proposal it had
unfortunately already been shot down.   I was wondering if you were
still interested in doing that?If so, what do others on the list
think about it?

I think these are good suggestions, but we'll need some help with
presentation and communication.   I'm low level infrastructure focused,
not so much at the application level.

River's potential future strong points with IPv6 will be secure end to
end dynamic discovery.   The tide seems to be turning for dynamic code,
which was both a strength and an Achilles heel, is now looking a lot
less like an Achillies heel and more like a strength again as originally
envisioned.  Unfortunately today Android and Apple iOS and not really
supportable as Jini clients, so I have doubts about consumer IOT, I
think we might be better suited to industrial IoT, time will tell.   We
will have the only pure Java Object based remote invocation framework
that can integrate properly with OSGi, when support for it is added.   I
think we've had much longer to understand problems with distributed
computing and are overcoming them now.

I'll reply some more later, given time to think some more...

Regards,

Peter.

On 5/22/2020 3:20 AM, Dennis Reedy wrote:

I think showing/explaing how River can fit into a larger eco-system of
existing applications would certainly help. How could River augment

Spring

Boot? What would it look like to combine River and Kafka? A discussion of
what it would mean to deploy micro-services built with RIver in the

cloud?

What are the set of problems that River solves in 2020 that are not
solvable by other technologies? Is this about IoT? If so then the project
page should reflect that.

As far as the modular build is concerned, sure it may help, but if it is
done, lets please use Gradle. A few years ago I put this example
 together, it may

help

with that.

On Thu, May 21, 2020 at 9:54 AM Bryan Thompson 

wrote:

I think engagement requires a few things.  +1 on the technical points

that

you have called out Peter. But we also need to engage developers beyond
those who are traditional users of River/Jini to foster new development
with River. Which can then lead to new development of River by a broader
base of developers.

The modular build can definitely help create opportunities for

developers

to get engaged. But having examples of what they can achieve and how

easily

using modern security and IPV6 Is important for there to be any new
developers using River.

My question would be where are we on that roadmap. I know that we have

been

making progress towards this.  When will the project reach a state

where it

will engage a new group of developers and what actions will it take to

help

make that happen beyond the technology development?

Bryan

On Thu, May 21, 2020 at 01:46 Peter Firmstone <

peter.firmst...@zeus.net.au

wrote:


Thanks Patricia,

I'm not sure we're going to see a significant number of developers
contributing in the near 

Re: Board feedback - Request discuss attic for River

[Dennis Reedy]

Hi Peter,

Some quick late night thoughts ...

   - Time depending, helping a Gradle build for River is something that I'd
   be glad to participate in. I think one of the biggest challenges will be
   getting the testing framework working, or choosing a modern equivalent.
   - As it relates to combining Rio and River, I'd vote no. River has
   enough complexities/challenges, no reason to muddy the waters even more
   with Rio. Perhaps looking at how to create River components within a Spring
   Boot app might be more attractive, and open the an entire open source
   eco-system.
   - I have not seen the tide turning for dynamic code, my experience has
   been the opposite.
   - Something else to consider is to look at the level of effort for
   moving River to a more current Java version though, at least Java 8 if not
   11.

Regards

Dennis

On Fri, May 22, 2020 at 12:07 AM Peter Firmstone <
peter.firmst...@zeus.net.au> wrote:

> Hi Dennis,
>
> Good to hear from you.
>
> The truth is, I'm no build expert, Dan is much more capable than I am,
> so I'm waiting to hear Dan's opinion on Gradle, it certainly looks good.
>
> Would you be interested in helping to create a Gradle build?
>
> Something else I've been thinking about is you once proposed to
> integrate Rio with River, by the time I saw the proposal it had
> unfortunately already been shot down.   I was wondering if you were
> still interested in doing that?If so, what do others on the list
> think about it?
>
> I think these are good suggestions, but we'll need some help with
> presentation and communication.   I'm low level infrastructure focused,
> not so much at the application level.
>
> River's potential future strong points with IPv6 will be secure end to
> end dynamic discovery.   The tide seems to be turning for dynamic code,
> which was both a strength and an Achilles heel, is now looking a lot
> less like an Achillies heel and more like a strength again as originally
> envisioned.  Unfortunately today Android and Apple iOS and not really
> supportable as Jini clients, so I have doubts about consumer IOT, I
> think we might be better suited to industrial IoT, time will tell.   We
> will have the only pure Java Object based remote invocation framework
> that can integrate properly with OSGi, when support for it is added.   I
> think we've had much longer to understand problems with distributed
> computing and are overcoming them now.
>
> I'll reply some more later, given time to think some more...
>
> Regards,
>
> Peter.
>
> On 5/22/2020 3:20 AM, Dennis Reedy wrote:
> > I think showing/explaing how River can fit into a larger eco-system of
> > existing applications would certainly help. How could River augment
> Spring
> > Boot? What would it look like to combine River and Kafka? A discussion of
> > what it would mean to deploy micro-services built with RIver in the
> cloud?
> > What are the set of problems that River solves in 2020 that are not
> > solvable by other technologies? Is this about IoT? If so then the project
> > page should reflect that.
> >
> > As far as the modular build is concerned, sure it may help, but if it is
> > done, lets please use Gradle. A few years ago I put this example
> >  together, it may
> help
> > with that.
> >
> > On Thu, May 21, 2020 at 9:54 AM Bryan Thompson 
> wrote:
> >
> >> I think engagement requires a few things.  +1 on the technical points
> that
> >> you have called out Peter. But we also need to engage developers beyond
> >> those who are traditional users of River/Jini to foster new development
> >> with River. Which can then lead to new development of River by a broader
> >> base of developers.
> >>
> >> The modular build can definitely help create opportunities for
> developers
> >> to get engaged. But having examples of what they can achieve and how
> easily
> >> using modern security and IPV6 Is important for there to be any new
> >> developers using River.
> >>
> >> My question would be where are we on that roadmap. I know that we have
> been
> >> making progress towards this.  When will the project reach a state
> where it
> >> will engage a new group of developers and what actions will it take to
> help
> >> make that happen beyond the technology development?
> >>
> >> Bryan
> >>
> >> On Thu, May 21, 2020 at 01:46 Peter Firmstone <
> peter.firmst...@zeus.net.au
> >> wrote:
> >>
> >>> Thanks Patricia,
> >>>
> >>> I'm not sure we're going to see a significant number of developers
> >>> contributing in the near future.
> >>>
> >>> Unfortunately the technical matters, which are complex and difficult
> >>> have caused a lot of argument in the past and have been the cause of a
> >>> high barrier to entry for new developers.   At least that's what I
> >>> think, feel free to provide your perspective.
> >>>
> >>> I have been working on solutions to address some of the complexity.
> >>>
> >>> I noticed that the board thought we hadn't had any 

Re: Board feedback - Request discuss attic for River

[Peter Firmstone]

Hi Dennis,

Good to hear from you.

The truth is, I'm no build expert, Dan is much more capable than I am, 
so I'm waiting to hear Dan's opinion on Gradle, it certainly looks good.


Would you be interested in helping to create a Gradle build?

Something else I've been thinking about is you once proposed to 
integrate Rio with River, by the time I saw the proposal it had 
unfortunately already been shot down.   I was wondering if you were 
still interested in doing that?    If so, what do others on the list 
think about it?


I think these are good suggestions, but we'll need some help with 
presentation and communication.   I'm low level infrastructure focused, 
not so much at the application level.


River's potential future strong points with IPv6 will be secure end to 
end dynamic discovery.   The tide seems to be turning for dynamic code, 
which was both a strength and an Achilles heel, is now looking a lot 
less like an Achillies heel and more like a strength again as originally 
envisioned.  Unfortunately today Android and Apple iOS and not really 
supportable as Jini clients, so I have doubts about consumer IOT, I 
think we might be better suited to industrial IoT, time will tell.   We 
will have the only pure Java Object based remote invocation framework 
that can integrate properly with OSGi, when support for it is added.   I 
think we've had much longer to understand problems with distributed 
computing and are overcoming them now.


I'll reply some more later, given time to think some more...

Regards,

Peter.

On 5/22/2020 3:20 AM, Dennis Reedy wrote:

I think showing/explaing how River can fit into a larger eco-system of
existing applications would certainly help. How could River augment Spring
Boot? What would it look like to combine River and Kafka? A discussion of
what it would mean to deploy micro-services built with RIver in the cloud?
What are the set of problems that River solves in 2020 that are not
solvable by other technologies? Is this about IoT? If so then the project
page should reflect that.

As far as the modular build is concerned, sure it may help, but if it is
done, lets please use Gradle. A few years ago I put this example
 together, it may help
with that.

On Thu, May 21, 2020 at 9:54 AM Bryan Thompson  wrote:


I think engagement requires a few things.  +1 on the technical points that
you have called out Peter. But we also need to engage developers beyond
those who are traditional users of River/Jini to foster new development
with River. Which can then lead to new development of River by a broader
base of developers.

The modular build can definitely help create opportunities for developers
to get engaged. But having examples of what they can achieve and how easily
using modern security and IPV6 Is important for there to be any new
developers using River.

My question would be where are we on that roadmap. I know that we have been
making progress towards this.  When will the project reach a state where it
will engage a new group of developers and what actions will it take to help
make that happen beyond the technology development?

Bryan

On Thu, May 21, 2020 at 01:46 Peter Firmstone 
Thanks Patricia,

I'm not sure we're going to see a significant number of developers
contributing in the near future.

Unfortunately the technical matters, which are complex and difficult
have caused a lot of argument in the past and have been the cause of a
high barrier to entry for new developers.   At least that's what I
think, feel free to provide your perspective.

I have been working on solutions to address some of the complexity.

I noticed that the board thought we hadn't had any commits for 3+ years,
I'll be sure to add some commit statistics to the next board report.   I
counted 191 commits over the last three years, not big, but not nothing
either.

I think it's fair to say that we need Apache's infrastructure, our web
site, Jira bug reporting system, repository and mailing lists.

The old 2.2 series code suffered from fragility due to race conditions
and other bugs, understandably this made some existing developers very
fearful of change (who had probably suffered from this fragility in the
past) and the pace at which development was occurring had some
frightened, which impacted our ability to work on the code, for this
reason I don't talk too much about the code, as I fear the return of
arguments of old, you might say I'm a bit shy.   In fact I am hoping
that slowing down the pace of development as was requested has given
people time to accept and adapt to the 3.0 release series.

I have been pinning my hopes on the Modular build to allow new
developers to focus on smaller components without having to understand
the whole project.

Also I think that River is constrained by the limitations of IPv4, I
mean who only codes for the intranet these days?   Once we integrate
multicast IPv6 support (I have been using this for at least 

Re: Board feedback - Request discuss attic for River

[Dennis Reedy]

I think showing/explaing how River can fit into a larger eco-system of
existing applications would certainly help. How could River augment Spring
Boot? What would it look like to combine River and Kafka? A discussion of
what it would mean to deploy micro-services built with RIver in the cloud?
What are the set of problems that River solves in 2020 that are not
solvable by other technologies? Is this about IoT? If so then the project
page should reflect that.

As far as the modular build is concerned, sure it may help, but if it is
done, lets please use Gradle. A few years ago I put this example
 together, it may help
with that.

On Thu, May 21, 2020 at 9:54 AM Bryan Thompson  wrote:

> I think engagement requires a few things.  +1 on the technical points that
> you have called out Peter. But we also need to engage developers beyond
> those who are traditional users of River/Jini to foster new development
> with River. Which can then lead to new development of River by a broader
> base of developers.
>
> The modular build can definitely help create opportunities for developers
> to get engaged. But having examples of what they can achieve and how easily
> using modern security and IPV6 Is important for there to be any new
> developers using River.
>
> My question would be where are we on that roadmap. I know that we have been
> making progress towards this.  When will the project reach a state where it
> will engage a new group of developers and what actions will it take to help
> make that happen beyond the technology development?
>
> Bryan
>
> On Thu, May 21, 2020 at 01:46 Peter Firmstone  >
> wrote:
>
> > Thanks Patricia,
> >
> > I'm not sure we're going to see a significant number of developers
> > contributing in the near future.
> >
> > Unfortunately the technical matters, which are complex and difficult
> > have caused a lot of argument in the past and have been the cause of a
> > high barrier to entry for new developers.   At least that's what I
> > think, feel free to provide your perspective.
> >
> > I have been working on solutions to address some of the complexity.
> >
> > I noticed that the board thought we hadn't had any commits for 3+ years,
> > I'll be sure to add some commit statistics to the next board report.   I
> > counted 191 commits over the last three years, not big, but not nothing
> > either.
> >
> > I think it's fair to say that we need Apache's infrastructure, our web
> > site, Jira bug reporting system, repository and mailing lists.
> >
> > The old 2.2 series code suffered from fragility due to race conditions
> > and other bugs, understandably this made some existing developers very
> > fearful of change (who had probably suffered from this fragility in the
> > past) and the pace at which development was occurring had some
> > frightened, which impacted our ability to work on the code, for this
> > reason I don't talk too much about the code, as I fear the return of
> > arguments of old, you might say I'm a bit shy.   In fact I am hoping
> > that slowing down the pace of development as was requested has given
> > people time to accept and adapt to the 3.0 release series.
> >
> > I have been pinning my hopes on the Modular build to allow new
> > developers to focus on smaller components without having to understand
> > the whole project.
> >
> > Also I think that River is constrained by the limitations of IPv4, I
> > mean who only codes for the intranet these days?   Once we integrate
> > multicast IPv6 support (I have been using this for at least two years
> > now), we can communicate easily over the internet.
> >
> > Another concern I have is security, we should have fixed security issues
> > a long time ago, however the mood of development at the time didn't
> > foster that, I think it was 2010 when I first flagged security issues
> > with Serialization.   That's another reason why I've been hesitant to
> > create bug fix releases, I don't think the code is good enough for a
> > release without addressing some significant security issues first.
> >
> > But clearly people are using the security features of River like SSL/
> > TLS, which indicates people are using River over the internet already,
> > in spite of limitations with IPv4 NAT.  I have other fixes that address
> > TLS security issues in River and bring cyphers and constraints into
> > 2020, rather than 2004 era cyphers.
> >
> > Regards,
> >
> > Peter.
> >
> > On 5/21/2020 10:54 AM, Patricia Shanahan wrote:
> > > The board tends to be more concerned about an active community than
> > > technical matters. We need to discuss whether there is a pool of
> > > potential contributors who are likely to become active.
> > >
> > > On 5/20/2020 5:51 PM, Peter Firmstone wrote:
> > >> Hello River Folk,
> > >>
> > >> I've received feedback from the Board this morning, they are
> > >> requesting that we discuss the Attic for River.
> > >>
> > >> Personally I think the project 

Re: Board feedback - Request discuss attic for River

[Bryan Thompson]

I think engagement requires a few things.  +1 on the technical points that
you have called out Peter. But we also need to engage developers beyond
those who are traditional users of River/Jini to foster new development
with River. Which can then lead to new development of River by a broader
base of developers.

The modular build can definitely help create opportunities for developers
to get engaged. But having examples of what they can achieve and how easily
using modern security and IPV6 Is important for there to be any new
developers using River.

My question would be where are we on that roadmap. I know that we have been
making progress towards this.  When will the project reach a state where it
will engage a new group of developers and what actions will it take to help
make that happen beyond the technology development?

Bryan

On Thu, May 21, 2020 at 01:46 Peter Firmstone 
wrote:

> Thanks Patricia,
>
> I'm not sure we're going to see a significant number of developers
> contributing in the near future.
>
> Unfortunately the technical matters, which are complex and difficult
> have caused a lot of argument in the past and have been the cause of a
> high barrier to entry for new developers.   At least that's what I
> think, feel free to provide your perspective.
>
> I have been working on solutions to address some of the complexity.
>
> I noticed that the board thought we hadn't had any commits for 3+ years,
> I'll be sure to add some commit statistics to the next board report.   I
> counted 191 commits over the last three years, not big, but not nothing
> either.
>
> I think it's fair to say that we need Apache's infrastructure, our web
> site, Jira bug reporting system, repository and mailing lists.
>
> The old 2.2 series code suffered from fragility due to race conditions
> and other bugs, understandably this made some existing developers very
> fearful of change (who had probably suffered from this fragility in the
> past) and the pace at which development was occurring had some
> frightened, which impacted our ability to work on the code, for this
> reason I don't talk too much about the code, as I fear the return of
> arguments of old, you might say I'm a bit shy.   In fact I am hoping
> that slowing down the pace of development as was requested has given
> people time to accept and adapt to the 3.0 release series.
>
> I have been pinning my hopes on the Modular build to allow new
> developers to focus on smaller components without having to understand
> the whole project.
>
> Also I think that River is constrained by the limitations of IPv4, I
> mean who only codes for the intranet these days?   Once we integrate
> multicast IPv6 support (I have been using this for at least two years
> now), we can communicate easily over the internet.
>
> Another concern I have is security, we should have fixed security issues
> a long time ago, however the mood of development at the time didn't
> foster that, I think it was 2010 when I first flagged security issues
> with Serialization.   That's another reason why I've been hesitant to
> create bug fix releases, I don't think the code is good enough for a
> release without addressing some significant security issues first.
>
> But clearly people are using the security features of River like SSL/
> TLS, which indicates people are using River over the internet already,
> in spite of limitations with IPv4 NAT.  I have other fixes that address
> TLS security issues in River and bring cyphers and constraints into
> 2020, rather than 2004 era cyphers.
>
> Regards,
>
> Peter.
>
> On 5/21/2020 10:54 AM, Patricia Shanahan wrote:
> > The board tends to be more concerned about an active community than
> > technical matters. We need to discuss whether there is a pool of
> > potential contributors who are likely to become active.
> >
> > On 5/20/2020 5:51 PM, Peter Firmstone wrote:
> >> Hello River Folk,
> >>
> >> I've received feedback from the Board this morning, they are
> >> requesting that we discuss the Attic for River.
> >>
> >> Personally I think the project still has a lot of potential to pick
> >> up again once the modular build is complete, and it is a useful place
> >> to send patches and discuss changes.
> >>
> >> A very important patch was sent in June last year by Shawn Ellis for
> >> Java 11.0.3 and later for services using SSL/TLS.
> >>
> >> Another important change to the JERI protocol was discussed in
> >> September last year.
> >>
> >> http://mail-archives.apache.org/mod_mbox/river-dev/201909.mbox/browser
> >>
> >> What are your thoughts?
> >>
> >> I don't think the board is asking that we send River to the attic,
> >> just that we discuss it.
> >>
> >> Regards,
> >>
> >> Peter.
> >>
>

Re: Board feedback - Request discuss attic for River

[Peter Firmstone]

Thanks Patricia,

I'm not sure we're going to see a significant number of developers 
contributing in the near future.


Unfortunately the technical matters, which are complex and difficult 
have caused a lot of argument in the past and have been the cause of a 
high barrier to entry for new developers.   At least that's what I 
think, feel free to provide your perspective.


I have been working on solutions to address some of the complexity.

I noticed that the board thought we hadn't had any commits for 3+ years, 
I'll be sure to add some commit statistics to the next board report.   I 
counted 191 commits over the last three years, not big, but not nothing 
either.


I think it's fair to say that we need Apache's infrastructure, our web 
site, Jira bug reporting system, repository and mailing lists.


The old 2.2 series code suffered from fragility due to race conditions 
and other bugs, understandably this made some existing developers very 
fearful of change (who had probably suffered from this fragility in the 
past) and the pace at which development was occurring had some 
frightened, which impacted our ability to work on the code, for this 
reason I don't talk too much about the code, as I fear the return of 
arguments of old, you might say I'm a bit shy.   In fact I am hoping 
that slowing down the pace of development as was requested has given 
people time to accept and adapt to the 3.0 release series.


I have been pinning my hopes on the Modular build to allow new 
developers to focus on smaller components without having to understand 
the whole project.


Also I think that River is constrained by the limitations of IPv4, I 
mean who only codes for the intranet these days?   Once we integrate 
multicast IPv6 support (I have been using this for at least two years 
now), we can communicate easily over the internet.


Another concern I have is security, we should have fixed security issues 
a long time ago, however the mood of development at the time didn't 
foster that, I think it was 2010 when I first flagged security issues 
with Serialization.   That's another reason why I've been hesitant to 
create bug fix releases, I don't think the code is good enough for a 
release without addressing some significant security issues first.


But clearly people are using the security features of River like SSL/ 
TLS, which indicates people are using River over the internet already, 
in spite of limitations with IPv4 NAT.  I have other fixes that address 
TLS security issues in River and bring cyphers and constraints into 
2020, rather than 2004 era cyphers.


Regards,

Peter.

On 5/21/2020 10:54 AM, Patricia Shanahan wrote:
The board tends to be more concerned about an active community than 
technical matters. We need to discuss whether there is a pool of 
potential contributors who are likely to become active.


On 5/20/2020 5:51 PM, Peter Firmstone wrote:

Hello River Folk,

I've received feedback from the Board this morning, they are 
requesting that we discuss the Attic for River.


Personally I think the project still has a lot of potential to pick 
up again once the modular build is complete, and it is a useful place 
to send patches and discuss changes.


A very important patch was sent in June last year by Shawn Ellis for 
Java 11.0.3 and later for services using SSL/TLS.


Another important change to the JERI protocol was discussed in 
September last year.


http://mail-archives.apache.org/mod_mbox/river-dev/201909.mbox/browser

What are your thoughts?

I don't think the board is asking that we send River to the attic, 
just that we discuss it.


Regards,

Peter.

Re: Board feedback - Request discuss attic for River

[Peter Firmstone]

Thanks Dan. :)

On 5/21/2020 12:20 PM, Dan Rollo wrote:

Hi Peter,

I acknowledge the contributions are slow to come, but I agree with your 
observation that contributions are still coming. I would prefer the River 
project not be moved to the attic just yet. (“I don’t want to go on the cart. I 
feel better”….to soon? ;)

Dan


From: Peter Firmstone 
Subject: Board feedback - Request discuss attic for River
Date: May 20, 2020 at 8:51:42 PM EDT
To: dev@river.apache.org


Hello River Folk,

I've received feedback from the Board this morning, they are requesting that we 
discuss the Attic for River.

Personally I think the project still has a lot of potential to pick up again 
once the modular build is complete, and it is a useful place to send patches 
and discuss changes.

A very important patch was sent in June last year by Shawn Ellis for Java 
11.0.3 and later for services using SSL/TLS.

Another important change to the JERI protocol was discussed in September last 
year.

http://mail-archives.apache.org/mod_mbox/river-dev/201909.mbox/browser

What are your thoughts?

I don't think the board is asking that we send River to the attic, just that we 
discuss it.

Regards,

Peter.

Re: Board feedback - Request discuss attic for River

[Dan Rollo]

Hi Peter,

I acknowledge the contributions are slow to come, but I agree with your 
observation that contributions are still coming. I would prefer the River 
project not be moved to the attic just yet. (“I don’t want to go on the cart. I 
feel better”….to soon? ;)

Dan


From: Peter Firmstone 
Subject: Board feedback - Request discuss attic for River
Date: May 20, 2020 at 8:51:42 PM EDT
To: dev@river.apache.org


Hello River Folk,

I've received feedback from the Board this morning, they are requesting that we 
discuss the Attic for River.

Personally I think the project still has a lot of potential to pick up again 
once the modular build is complete, and it is a useful place to send patches 
and discuss changes.

A very important patch was sent in June last year by Shawn Ellis for Java 
11.0.3 and later for services using SSL/TLS.

Another important change to the JERI protocol was discussed in September last 
year.

http://mail-archives.apache.org/mod_mbox/river-dev/201909.mbox/browser

What are your thoughts?

I don't think the board is asking that we send River to the attic, just that we 
discuss it.

Regards,

Peter.

Re: Board feedback - Request discuss attic for River

[Patricia Shanahan]

The board tends to be more concerned about an active community than 
technical matters. We need to discuss whether there is a pool of 
potential contributors who are likely to become active.


On 5/20/2020 5:51 PM, Peter Firmstone wrote:

Hello River Folk,

I've received feedback from the Board this morning, they are requesting 
that we discuss the Attic for River.


Personally I think the project still has a lot of potential to pick up 
again once the modular build is complete, and it is a useful place to 
send patches and discuss changes.


A very important patch was sent in June last year by Shawn Ellis for 
Java 11.0.3 and later for services using SSL/TLS.


Another important change to the JERI protocol was discussed in September 
last year.


http://mail-archives.apache.org/mod_mbox/river-dev/201909.mbox/browser

What are your thoughts?

I don't think the board is asking that we send River to the attic, just 
that we discuss it.


Regards,

Peter.