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 <https://github.com/dreedyman/apache-river> 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 <peter.firmst...@zeus.net.au> 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 <dennis.re...@gmail.com> > wrote: > >> Hi all, > >> > >> I've updated the Gradle build project over here > >> <https://github.com/dreedyman/apache-river>. 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 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 > >>>>>>> >
