Re: Example Gradle Buuild

[Phillip Rhodes]

On Fri, Oct 9, 2020 at 12:46 PM Dennis Reedy  wrote:
>
> Hi all,
>
> Wrt to what needs to happen to move forward and merge the gradle build into 
> the official repo is fairly straight forward. We need an official Git 
> repository. Once that's done I can move what I have created here to that repo.

Sounds like moving to Git would be a significant step for us, all
around. If I can help with that initiative at all, I'm happy to throw
in and do $whatever.

> In the meantime, if anyone would like to collaborate on that repository, feel 
> free to fork, or I can always add you as a collaborator.

I'll take a look.


Phil

Re: Example Gradle Buuild

[Dennis Reedy]

Hi all,

Wrt to what needs to happen to move forward and merge the gradle build into
the official repo is fairly straight forward. We need an official Git
repository. Once that's done I can move what I have created here
 to that repo.

In the meantime, if anyone would like to collaborate on that repository,
feel free to fork, or I can always add you as a collaborator.

Regards

Dennis

On Fri, Oct 9, 2020 at 7:07 AM Peter Firmstone 
wrote:

> Hi Phil,
>
> My thoughts inline below:
>
> On 10/9/2020 9:05 AM, Phillip Rhodes wrote:
> > Two things
> >
> > 1. What needs to happen for us to move forward with merging in the
> > Gradle build to the official repo?
>
> Dennis, what are your thoughts?
>
>
> >
> > 2. Regarding the modular build in general: Not sure how much testing
> > has been done with any of the artifacts from any of these builds, so
> > what I'm doing tonight is grabbing the 3.0-SNAPSHOT artifacts from the
> > maven build, and trying to build a simple River service with them,
> > just as a quick "sanity check" that things work.
>
> No qa or jtreg tests have been run against the modular build, junit
> tests that have made the transition have, but these don't provide much
> coverage.
>
> In the original jar files, many class files were duplicated, but now
> class files are no longer duplicated and have been replaced by modular
> dependencies.There are very minimal changes to source code just to
> get it to compile.
>
> However the names of many of the original jar files are hard coded into
> the qa suite, these need to be cleaned up before the suite will run.
>
> I have done this work previously, the artifact names are variables in
> JGDMS' qa suite:
>
> https://github.com/pfirmstone/JGDMS/tree/trunk/qa
>
> We can take the structure of JGDMS' qa test suite, without changing
> River's test source code, except where absolutely necessary.  Note the
> qa suite is still an ant build, it hasn't been modularized.
>
> JGDMS is a fork of River, but there are a lot of code changes, the
> amount of change as well as the pace of change was concerning for some
> so it didn't make it into River, hence the fork, so we don't want to go
> changing River's source code unless we absolutely have to for the
> modular build.
>
> Once we have a modular build, changes can be made at the module level,
> which will be easier to review, understand and digest.
>
> >
> > If folks are still interested in moving forward with the Gradle
> > approach, I'd love to see us go ahead and get that stuff merged and
> > commit to it as The Path Forward. Thoughts?
>
> +1 Peter.
>
>
> >
> >
> > Phil
> >
> >
> > On Mon, Jul 13, 2020 at 4:55 PM Dennis Reedy 
> wrote:
> >> Hi all,
> >>
> >> I've updated the Gradle build project over here
> >> . It reflects the latest
> from
> >> the SVN version here <
> http://svn.apache.org/repos/asf/river/jtsk/modules>.
> >> If we'd like to move forward with this, I'd like to see us do that, and
> do
> >> it with the approved move to a Git repository.
> >>
> >>
> >> Regards
> >>
> >> Dennis
> >>
> >> On Sat, Jul 11, 2020 at 8:32 PM Peter Firmstone <
> peter.firmst...@zeus.net.au>
> >> wrote:
> >>
> >>> Hi Dennis,
> >>>
> >>> Yes definitely, if you're ok with that.
> >>>
> >>> The qa test suite could potentially be modularized as well, I'm
> guessing
> >>> it would be easier to run these tests with a gradle build.
> >>>
> >>> Cheers,
> >>>
> >>> Peter.
> >>>
> >>> On 7/11/2020 11:12 PM, Dennis Reedy wrote:
>  Hi Peter,
> 
>  We could just fold what you’ve done into the project. I merged the
> >>> modules for expediency. I’ll spend some time next week doing that if
> we’d
> >>> like to move it forward.
>  Regards
> 
>  Dennis
> 
> > On Jul 11, 2020, at 5:04 AM, Peter Firmstone <
> >>> peter.firmst...@zeus.net.au> wrote:
> > HI Dennis,
> >
> > Had a quick look just now, I can see why gradle is attractive.
> >
> > I'm not a big fan of the larger modules, but you have demonstrated it
> >>> can work.
> > I guess it's a trade off between maintainability and avoiding the
> need
> >>> to untangle the circular links.
> > Have you had a look at the code changes I made to remove the circular
> >>> links?
> > Cheers,
> >
> > Peter.
> >
> >> On 7/11/2020 5:50 AM, Dennis Reedy wrote:
> >> Curious as to whether anyone has looked at this.
> >>
> >> Regards
> >>
> >> Dennis
> >>
> >>> On Tue, Jul 7, 2020 at 1:30 PM Dennis Reedy <
> dennis.re...@gmail.com>
> >>> wrote:
> >>> To demonstrate how a modular Gradle build would look like, I put
> >>> together
> >>> a clone of Apache River subversion branch of
> >>> http://svn.apache.org/repos/asf/river/jtsk/modules, created as a
> Git
> >>> repository, and built with Gradle here:
> >>> https://github.com/dreedyman/apache-river.
> >>>
> >>> This is not to take 

Re: Example Gradle Buuild

[Peter Firmstone]

Hi Phil,

My thoughts inline below:

On 10/9/2020 9:05 AM, Phillip Rhodes wrote:

Two things

1. What needs to happen for us to move forward with merging in the
Gradle build to the official repo?


Dennis, what are your thoughts?




2. Regarding the modular build in general: Not sure how much testing
has been done with any of the artifacts from any of these builds, so
what I'm doing tonight is grabbing the 3.0-SNAPSHOT artifacts from the
maven build, and trying to build a simple River service with them,
just as a quick "sanity check" that things work.


No qa or jtreg tests have been run against the modular build, junit 
tests that have made the transition have, but these don't provide much 
coverage.


In the original jar files, many class files were duplicated, but now 
class files are no longer duplicated and have been replaced by modular 
dependencies.    There are very minimal changes to source code just to 
get it to compile.


However the names of many of the original jar files are hard coded into 
the qa suite, these need to be cleaned up before the suite will run.


I have done this work previously, the artifact names are variables in 
JGDMS' qa suite:


https://github.com/pfirmstone/JGDMS/tree/trunk/qa

We can take the structure of JGDMS' qa test suite, without changing 
River's test source code, except where absolutely necessary.  Note the 
qa suite is still an ant build, it hasn't been modularized.


JGDMS is a fork of River, but there are a lot of code changes, the 
amount of change as well as the pace of change was concerning for some 
so it didn't make it into River, hence the fork, so we don't want to go 
changing River's source code unless we absolutely have to for the 
modular build.


Once we have a modular build, changes can be made at the module level, 
which will be easier to review, understand and digest.




If folks are still interested in moving forward with the Gradle
approach, I'd love to see us go ahead and get that stuff merged and
commit to it as The Path Forward. Thoughts?


+1 Peter.





Phil


On Mon, Jul 13, 2020 at 4:55 PM Dennis Reedy  wrote:

Hi all,

I've updated the Gradle build project over here
. It reflects the latest from
the SVN version here .
If we'd like to move forward with this, I'd like to see us do that, and do
it with the approved move to a Git repository.


Regards

Dennis

On Sat, Jul 11, 2020 at 8:32 PM Peter Firmstone 
wrote:


Hi Dennis,

Yes definitely, if you're ok with that.

The qa test suite could potentially be modularized as well, I'm guessing
it would be easier to run these tests with a gradle build.

Cheers,

Peter.

On 7/11/2020 11:12 PM, Dennis Reedy wrote:

Hi Peter,

We could just fold what you’ve done into the project. I merged the

modules for expediency. I’ll spend some time next week doing that if we’d
like to move it forward.

Regards

Dennis


On Jul 11, 2020, at 5:04 AM, Peter Firmstone <

peter.firmst...@zeus.net.au> wrote:

HI Dennis,

Had a quick look just now, I can see why gradle is attractive.

I'm not a big fan of the larger modules, but you have demonstrated it

can work.

I guess it's a trade off between maintainability and avoiding the need

to untangle the circular links.

Have you had a look at the code changes I made to remove the circular

links?

Cheers,

Peter.


On 7/11/2020 5:50 AM, Dennis Reedy wrote:
Curious as to whether anyone has looked at this.

Regards

Dennis


On Tue, Jul 7, 2020 at 1:30 PM Dennis Reedy 

wrote:

To demonstrate how a modular Gradle build would look like, I put

together

a clone of Apache River subversion branch of
http://svn.apache.org/repos/asf/river/jtsk/modules, created as a Git
repository, and built with Gradle here:
https://github.com/dreedyman/apache-river.

This is not to take away from the Maven effort by any means, that

work was

the baseline for creating this effort last night. This is by means
complete, or an accepted way of building Apache River, but used as a

means

to demonstrate how a modular version of Apache River can be built with
Gradle.

 - Besides using Gradle, there are differences in this project's
 structure. The river-jeri, river-jrmp, river-iiop and

river-pref-loader

 modules have been merged into river-platform to avoid circular

dependencies.

 - The groovy-config module has also been enabled.
 - All OSGi configurations have not been enabled.
 - There were issues with the Velocity work, it was removed

Regards

Dennis Reedy

Re: Example Gradle Buuild

[Phillip Rhodes]

Two things

1. What needs to happen for us to move forward with merging in the
Gradle build to the official repo?

2. Regarding the modular build in general: Not sure how much testing
has been done with any of the artifacts from any of these builds, so
what I'm doing tonight is grabbing the 3.0-SNAPSHOT artifacts from the
maven build, and trying to build a simple River service with them,
just as a quick "sanity check" that things work.

If folks are still interested in moving forward with the Gradle
approach, I'd love to see us go ahead and get that stuff merged and
commit to it as The Path Forward. Thoughts?


Phil


On Mon, Jul 13, 2020 at 4:55 PM Dennis Reedy  wrote:
>
> Hi all,
>
> I've updated the Gradle build project over here
> . It reflects the latest from
> the SVN version here .
> If we'd like to move forward with this, I'd like to see us do that, and do
> it with the approved move to a Git repository.
>
>
> Regards
>
> Dennis
>
> On Sat, Jul 11, 2020 at 8:32 PM Peter Firmstone 
> wrote:
>
> > Hi Dennis,
> >
> > Yes definitely, if you're ok with that.
> >
> > The qa test suite could potentially be modularized as well, I'm guessing
> > it would be easier to run these tests with a gradle build.
> >
> > Cheers,
> >
> > Peter.
> >
> > On 7/11/2020 11:12 PM, Dennis Reedy wrote:
> > > Hi Peter,
> > >
> > > We could just fold what you’ve done into the project. I merged the
> > modules for expediency. I’ll spend some time next week doing that if we’d
> > like to move it forward.
> > >
> > > Regards
> > >
> > > Dennis
> > >
> > >> On Jul 11, 2020, at 5:04 AM, Peter Firmstone <
> > peter.firmst...@zeus.net.au> wrote:
> > >>
> > >> HI Dennis,
> > >>
> > >> Had a quick look just now, I can see why gradle is attractive.
> > >>
> > >> I'm not a big fan of the larger modules, but you have demonstrated it
> > can work.
> > >>
> > >> I guess it's a trade off between maintainability and avoiding the need
> > to untangle the circular links.
> > >>
> > >> Have you had a look at the code changes I made to remove the circular
> > links?
> > >>
> > >> Cheers,
> > >>
> > >> Peter.
> > >>
> > >>> On 7/11/2020 5:50 AM, Dennis Reedy wrote:
> > >>> Curious as to whether anyone has looked at this.
> > >>>
> > >>> Regards
> > >>>
> > >>> Dennis
> > >>>
> >  On Tue, Jul 7, 2020 at 1:30 PM Dennis Reedy 
> > wrote:
> > 
> >  To demonstrate how a modular Gradle build would look like, I put
> > together
> >  a clone of Apache River subversion branch of
> >  http://svn.apache.org/repos/asf/river/jtsk/modules, created as a Git
> >  repository, and built with Gradle here:
> >  https://github.com/dreedyman/apache-river.
> > 
> >  This is not to take away from the Maven effort by any means, that
> > work was
> >  the baseline for creating this effort last night. This is by means
> >  complete, or an accepted way of building Apache River, but used as a
> > means
> >  to demonstrate how a modular version of Apache River can be built with
> >  Gradle.
> > 
> >  - Besides using Gradle, there are differences in this project's
> >  structure. The river-jeri, river-jrmp, river-iiop and
> > river-pref-loader
> >  modules have been merged into river-platform to avoid circular
> > dependencies.
> >  - The groovy-config module has also been enabled.
> >  - All OSGi configurations have not been enabled.
> >  - There were issues with the Velocity work, it was removed
> > 
> >  Regards
> > 
> >  Dennis Reedy
> > 
> >

Re: Example Gradle Buuild

[Dennis Reedy]

Hi all,

I've updated the Gradle build project over here
. It reflects the latest from
the SVN version here .
If we'd like to move forward with this, I'd like to see us do that, and do
it with the approved move to a Git repository.


Regards

Dennis

On Sat, Jul 11, 2020 at 8:32 PM Peter Firmstone 
wrote:

> Hi Dennis,
>
> Yes definitely, if you're ok with that.
>
> The qa test suite could potentially be modularized as well, I'm guessing
> it would be easier to run these tests with a gradle build.
>
> Cheers,
>
> Peter.
>
> On 7/11/2020 11:12 PM, Dennis Reedy wrote:
> > Hi Peter,
> >
> > We could just fold what you’ve done into the project. I merged the
> modules for expediency. I’ll spend some time next week doing that if we’d
> like to move it forward.
> >
> > Regards
> >
> > Dennis
> >
> >> On Jul 11, 2020, at 5:04 AM, Peter Firmstone <
> peter.firmst...@zeus.net.au> wrote:
> >>
> >> HI Dennis,
> >>
> >> Had a quick look just now, I can see why gradle is attractive.
> >>
> >> I'm not a big fan of the larger modules, but you have demonstrated it
> can work.
> >>
> >> I guess it's a trade off between maintainability and avoiding the need
> to untangle the circular links.
> >>
> >> Have you had a look at the code changes I made to remove the circular
> links?
> >>
> >> Cheers,
> >>
> >> Peter.
> >>
> >>> On 7/11/2020 5:50 AM, Dennis Reedy wrote:
> >>> Curious as to whether anyone has looked at this.
> >>>
> >>> Regards
> >>>
> >>> Dennis
> >>>
>  On Tue, Jul 7, 2020 at 1:30 PM Dennis Reedy 
> wrote:
> 
>  To demonstrate how a modular Gradle build would look like, I put
> together
>  a clone of Apache River subversion branch of
>  http://svn.apache.org/repos/asf/river/jtsk/modules, created as a Git
>  repository, and built with Gradle here:
>  https://github.com/dreedyman/apache-river.
> 
>  This is not to take away from the Maven effort by any means, that
> work was
>  the baseline for creating this effort last night. This is by means
>  complete, or an accepted way of building Apache River, but used as a
> means
>  to demonstrate how a modular version of Apache River can be built with
>  Gradle.
> 
>  - Besides using Gradle, there are differences in this project's
>  structure. The river-jeri, river-jrmp, river-iiop and
> river-pref-loader
>  modules have been merged into river-platform to avoid circular
> dependencies.
>  - The groovy-config module has also been enabled.
>  - All OSGi configurations have not been enabled.
>  - There were issues with the Velocity work, it was removed
> 
>  Regards
> 
>  Dennis Reedy
> 
>

Re: Example Gradle Buuild

[Peter Firmstone]

On 7/13/2020 6:14 AM, Zsolt Kúti wrote:

On Sat, Jul 11, 2020 at 3:16 PM Dennis Reedy  wrote:


Hi Zsolt,

There are a few tests in there, most are in the qa directory in the main
svn repository. I think it would be great if we could find a way to merge
them into the modules and follow conventions.


I'll take a look at them, do not promise anything though.
Any jtreg version preferred from here?:
https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/



Yes the latest, for some reason the html reporter is no longer working, 
so best to redirect the output to a text file.






As far as the gradle version, did gradlew not work for you?


It's just I had JDK 11 set system-wide, gradle picked it up and missed rmi
and corba classes. Same goes for running from IDE.

Zsolt


River only builds on Java 8 presently.

We will need to come up with solutions to the missing classes.

There are changes made in JGDMS that allow it to build on Java 11 and 
run on 14, but there are a lot of changes (historically this has been 
controversial) and some work still remains, such as replacing the IIOP 
implementation with something  else.


I was thinking https://www.jacorb.org/ as well adding support for IIOP 
over TLS.


I initially tried using GlassFish, but there were security 
vulnerabilities present.


My notes in the relevant pom:


    
    
    
    org.jboss.openjdk-orb
    openjdk-orb
    8.1.4.Final
    

Cheers,

Peter.

Re: Example Gradle Buuild

[Zsolt Kúti]

On Sat, Jul 11, 2020 at 3:16 PM Dennis Reedy  wrote:

> Hi Zsolt,
>
> There are a few tests in there, most are in the qa directory in the main
> svn repository. I think it would be great if we could find a way to merge
> them into the modules and follow conventions.
>
I'll take a look at them, do not promise anything though.
Any jtreg version preferred from here?:
https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/


> As far as the gradle version, did gradlew not work for you?
>
It's just I had JDK 11 set system-wide, gradle picked it up and missed rmi
and corba classes. Same goes for running from IDE.

Zsolt

Re: Example Gradle Buuild

[Peter Firmstone]

Hi Dennis,

Yes definitely, if you're ok with that.

The qa test suite could potentially be modularized as well, I'm guessing 
it would be easier to run these tests with a gradle build.


Cheers,

Peter.

On 7/11/2020 11:12 PM, Dennis Reedy wrote:

Hi Peter,

We could just fold what you’ve done into the project. I merged the modules for 
expediency. I’ll spend some time next week doing that if we’d like to move it 
forward.

Regards

Dennis


On Jul 11, 2020, at 5:04 AM, Peter Firmstone  
wrote:

HI Dennis,

Had a quick look just now, I can see why gradle is attractive.

I'm not a big fan of the larger modules, but you have demonstrated it can work.

I guess it's a trade off between maintainability and avoiding the need to 
untangle the circular links.

Have you had a look at the code changes I made to remove the circular links?

Cheers,

Peter.


On 7/11/2020 5:50 AM, Dennis Reedy wrote:
Curious as to whether anyone has looked at this.

Regards

Dennis


On Tue, Jul 7, 2020 at 1:30 PM Dennis Reedy  wrote:

To demonstrate how a modular Gradle build would look like, I put together
a clone of Apache River subversion branch of
http://svn.apache.org/repos/asf/river/jtsk/modules, created as a Git
repository, and built with Gradle here:
https://github.com/dreedyman/apache-river.

This is not to take away from the Maven effort by any means, that work was
the baseline for creating this effort last night. This is by means
complete, or an accepted way of building Apache River, but used as a means
to demonstrate how a modular version of Apache River can be built with
Gradle.

- Besides using Gradle, there are differences in this project's
structure. The river-jeri, river-jrmp, river-iiop and river-pref-loader
modules have been merged into river-platform to avoid circular dependencies.
- The groovy-config module has also been enabled.
- All OSGi configurations have not been enabled.
- There were issues with the Velocity work, it was removed

Regards

Dennis Reedy

Re: Example Gradle Buuild

[Phillip Rhodes]

On Sat, Jul 11, 2020 at 9:12 AM Dennis Reedy  wrote:
>
> Hi Peter,
>
> We could just fold what you’ve done into the project. I merged the modules 
> for expediency. I’ll spend some
> time next week doing that if we’d like to move it forward.

Yeah, it would be nice to see the merged result of this Gradle work,
and the module restructuring work that was just done. It seems like
having that would put us in a pretty good place.

I don't personally have a strong preference between Maven and Gradle,
but I will say that - in my experience - Gradle tends to be faster
than Maven.  On that basis alone, I'd like to see a working Gradle
build.


Phil

Re: Example Gradle Buuild

[Dennis Reedy]

Hi Zsolt,

There are a few tests in there, most are in the qa directory in the main svn 
repository. I think it would be great if we could find a way to merge them into 
the modules and follow conventions.

As far as the gradle version, did gradlew not work for you?

Regards 

Dennis 

> On Jul 11, 2020, at 3:48 AM, Zsolt Kúti  wrote:
> 
> Hi Dennis,
> 
> Checked this out and gave it a try. Had to tell my gradle via my IDE(A)
> config to use JDK 8 ( I used Adopt) and then it compiled fine.
> Apart from a few warnings everything went smoothly. Out of curiosity run
> tests and have seen none. Are they held separately?
> Beyond that I did nothing else. Is there anything I could try?
> 
> Zsolt
> 
>> On Fri, Jul 10, 2020 at 9:50 PM Dennis Reedy  wrote:
>> 
>> Curious as to whether anyone has looked at this.
>> 
>> Regards
>> 
>> Dennis
>> 
>> On Tue, Jul 7, 2020 at 1:30 PM Dennis Reedy 
>> wrote:
>> 
>>> To demonstrate how a modular Gradle build would look like, I put together
>>> a clone of Apache River subversion branch of
>>> http://svn.apache.org/repos/asf/river/jtsk/modules, created as a Git
>>> repository, and built with Gradle here:
>>> https://github.com/dreedyman/apache-river.
>>> 
>>> This is not to take away from the Maven effort by any means, that work
>> was
>>> the baseline for creating this effort last night. This is by means
>>> complete, or an accepted way of building Apache River, but used as a
>> means
>>> to demonstrate how a modular version of Apache River can be built with
>>> Gradle.
>>> 
>>>   - Besides using Gradle, there are differences in this project's
>>>   structure. The river-jeri, river-jrmp, river-iiop and
>> river-pref-loader
>>>   modules have been merged into river-platform to avoid circular
>> dependencies.
>>>   - The groovy-config module has also been enabled.
>>>   - All OSGi configurations have not been enabled.
>>>   - There were issues with the Velocity work, it was removed
>>> 
>>> Regards
>>> 
>>> Dennis Reedy
>>> 
>> 

Re: Example Gradle Buuild

[Dennis Reedy]

Hi Peter,

We could just fold what you’ve done into the project. I merged the modules for 
expediency. I’ll spend some time next week doing that if we’d like to move it 
forward.

Regards 

Dennis

> On Jul 11, 2020, at 5:04 AM, Peter Firmstone  
> wrote:
> 
> HI Dennis,
> 
> Had a quick look just now, I can see why gradle is attractive.
> 
> I'm not a big fan of the larger modules, but you have demonstrated it can 
> work.
> 
> I guess it's a trade off between maintainability and avoiding the need to 
> untangle the circular links.
> 
> Have you had a look at the code changes I made to remove the circular links?
> 
> Cheers,
> 
> Peter.
> 
>> On 7/11/2020 5:50 AM, Dennis Reedy wrote:
>> Curious as to whether anyone has looked at this.
>> 
>> Regards
>> 
>> Dennis
>> 
>>> On Tue, Jul 7, 2020 at 1:30 PM Dennis Reedy  wrote:
>>> 
>>> To demonstrate how a modular Gradle build would look like, I put together
>>> a clone of Apache River subversion branch of
>>> http://svn.apache.org/repos/asf/river/jtsk/modules, created as a Git
>>> repository, and built with Gradle here:
>>> https://github.com/dreedyman/apache-river.
>>> 
>>> This is not to take away from the Maven effort by any means, that work was
>>> the baseline for creating this effort last night. This is by means
>>> complete, or an accepted way of building Apache River, but used as a means
>>> to demonstrate how a modular version of Apache River can be built with
>>> Gradle.
>>> 
>>>- Besides using Gradle, there are differences in this project's
>>>structure. The river-jeri, river-jrmp, river-iiop and river-pref-loader
>>>modules have been merged into river-platform to avoid circular 
>>> dependencies.
>>>- The groovy-config module has also been enabled.
>>>- All OSGi configurations have not been enabled.
>>>- There were issues with the Velocity work, it was removed
>>> 
>>> Regards
>>> 
>>> Dennis Reedy
>>> 

Re: Example Gradle Buuild

[Peter Firmstone]

HI Dennis,

Had a quick look just now, I can see why gradle is attractive.

I'm not a big fan of the larger modules, but you have demonstrated it 
can work.


I guess it's a trade off between maintainability and avoiding the need 
to untangle the circular links.


Have you had a look at the code changes I made to remove the circular links?

Cheers,

Peter.

On 7/11/2020 5:50 AM, Dennis Reedy wrote:

Curious as to whether anyone has looked at this.

Regards

Dennis

On Tue, Jul 7, 2020 at 1:30 PM Dennis Reedy  wrote:


To demonstrate how a modular Gradle build would look like, I put together
a clone of Apache River subversion branch of
http://svn.apache.org/repos/asf/river/jtsk/modules, created as a Git
repository, and built with Gradle here:
https://github.com/dreedyman/apache-river.

This is not to take away from the Maven effort by any means, that work was
the baseline for creating this effort last night. This is by means
complete, or an accepted way of building Apache River, but used as a means
to demonstrate how a modular version of Apache River can be built with
Gradle.

- Besides using Gradle, there are differences in this project's
structure. The river-jeri, river-jrmp, river-iiop and river-pref-loader
modules have been merged into river-platform to avoid circular dependencies.
- The groovy-config module has also been enabled.
- All OSGi configurations have not been enabled.
- There were issues with the Velocity work, it was removed

Regards

Dennis Reedy

Re: Example Gradle Buuild

[Zsolt Kúti]

Hi Dennis,

Checked this out and gave it a try. Had to tell my gradle via my IDE(A)
config to use JDK 8 ( I used Adopt) and then it compiled fine.
Apart from a few warnings everything went smoothly. Out of curiosity run
tests and have seen none. Are they held separately?
Beyond that I did nothing else. Is there anything I could try?

 Zsolt

On Fri, Jul 10, 2020 at 9:50 PM Dennis Reedy  wrote:

> Curious as to whether anyone has looked at this.
>
> Regards
>
> Dennis
>
> On Tue, Jul 7, 2020 at 1:30 PM Dennis Reedy 
> wrote:
>
> > To demonstrate how a modular Gradle build would look like, I put together
> > a clone of Apache River subversion branch of
> > http://svn.apache.org/repos/asf/river/jtsk/modules, created as a Git
> > repository, and built with Gradle here:
> > https://github.com/dreedyman/apache-river.
> >
> > This is not to take away from the Maven effort by any means, that work
> was
> > the baseline for creating this effort last night. This is by means
> > complete, or an accepted way of building Apache River, but used as a
> means
> > to demonstrate how a modular version of Apache River can be built with
> > Gradle.
> >
> >- Besides using Gradle, there are differences in this project's
> >structure. The river-jeri, river-jrmp, river-iiop and
> river-pref-loader
> >modules have been merged into river-platform to avoid circular
> dependencies.
> >- The groovy-config module has also been enabled.
> >- All OSGi configurations have not been enabled.
> >- There were issues with the Velocity work, it was removed
> >
> > Regards
> >
> > Dennis Reedy
> >
>

Re: Example Gradle Buuild

[Dennis Reedy]

Curious as to whether anyone has looked at this.

Regards

Dennis

On Tue, Jul 7, 2020 at 1:30 PM Dennis Reedy  wrote:

> To demonstrate how a modular Gradle build would look like, I put together
> a clone of Apache River subversion branch of
> http://svn.apache.org/repos/asf/river/jtsk/modules, created as a Git
> repository, and built with Gradle here:
> https://github.com/dreedyman/apache-river.
>
> This is not to take away from the Maven effort by any means, that work was
> the baseline for creating this effort last night. This is by means
> complete, or an accepted way of building Apache River, but used as a means
> to demonstrate how a modular version of Apache River can be built with
> Gradle.
>
>- Besides using Gradle, there are differences in this project's
>structure. The river-jeri, river-jrmp, river-iiop and river-pref-loader
>modules have been merged into river-platform to avoid circular 
> dependencies.
>- The groovy-config module has also been enabled.
>- All OSGi configurations have not been enabled.
>- There were issues with the Velocity work, it was removed
>
> Regards
>
> Dennis Reedy
>