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
