Modularization

[Dennis Reedy <de...@gmail.com>]

I've been working on creating a modular version of the project in the
qa_refactor branch. The approach I've taken is to develop a Groovy script
to load existing River jars, iterate through the contents of each jar, and
copy sources to a multi-module project. The basic assumption with the
multi-module project is that each module produces one jar.

If you checkout qa_refactor, go to the modularize directory and run
ModularizeRiver.groovy (you'll need groovy in your path). This will
populate the source tree into the multi-module project, reading each jar
for it's contents, placing PREFERRED.LIST and any META-INF/service files
into their correct location for inclusion into respective jars. I've also
taken care to not duplicate classes across modules.

I've taken the initial approach to use Maven, and once the multi-module
project is populated with source (using ModularizeRiver.groovy), you can cd
into it and run mvn install to produce a release that is in the
apache-river/dist/target/apache-river-3.0-SNAPSHOT directory.

A this point I'm soliciting opinions and thoughts. Note that using Gradle
is certainly an option here, the breakout into multi-modules is not tied to
Maven, it's based on accepted conventions. I chose Maven because it was the
quickest (for me) to get going.

I've included *most* of the River platform and services. I haven't gotten
around to others based simply on time. This is an experiment, it's located
in skunk/qa_refactor, and may help us think a little more about what River
The multi-module project might look like.

I do want to note, that this currently fixes absolutely nothing. There is
nothing wrong with the current River build. This simply offers a different
way of structuring River, using a multi-module project, where each module
reflects the basic architectural element of a distributed system.

Regards

Dennis

Re: Modularization

[Peter <ji...@zeus.net.au>]

----- Original message -----
> On 01-05-14 00:29, Peter wrote:
> > ----- Original message -----
> > On 30-04-14 02:02, Dennis Reedy wrote:
> > 
> > A this point I'm soliciting opinions and thoughts. Note that using
> > Gradle is certainly an option here, the breakout into multi-modules is
> > not tied to Maven, it's based on accepted conventions. I chose Maven
> > because it was the quickest (for me) to get going.
> > 
> > Good thing! Just to show support! I applaud a separation into multiple
> > source trees, as a starting point for modularization.
> > 
> > Any change we can re-apply your effort on trunk while maintaining
> > subversion history? i.e. 'svn mv' commands?
> > 
> > Lets wait until after confirming the modular build structure though.
> 
> How do you define this milestone? On what step, decision, or positive 
> outcome shall we wait?

When the the following can be executed in succession:

run script
build river modules
build qa suite
run qa suite.

So we can confirm all the java source files have been successfully copied, then change the script to svn move.

That's not set in stone, just what came to mind at the time, if you have some time to help and want to do it differently, you're most welcome to.

Regards,

Peter.

Re: Modularization

[Simon IJskes - QCG <si...@qcg.nl>]

On 01-05-14 00:29, Peter wrote:
> ----- Original message -----
>  > On 30-04-14 02:02, Dennis Reedy wrote:
>  >
>  > > A this point I'm soliciting opinions and thoughts. Note that using
>  > > Gradle is certainly an option here, the breakout into multi-modules is
>  > > not tied to Maven, it's based on accepted conventions. I chose Maven
>  > > because it was the quickest (for me) to get going.
>  >
>  > Good thing! Just to show support! I applaud a separation into multiple
>  > source trees, as a starting point for modularization.
>  >
>  > Any change we can re-apply your effort on trunk while maintaining
>  > subversion history? i.e. 'svn mv' commands?
>
> Lets wait until after confirming the modular build structure though.

How do you define this milestone? On what step, decision, or positive 
outcome shall we wait?

Gr. Simon

Re: Modularization

[Peter <ji...@zeus.net.au>]

----- Original message -----
> On 30-04-14 02:02, Dennis Reedy wrote:
> 
> > A this point I'm soliciting opinions and thoughts. Note that using
> > Gradle is certainly an option here, the breakout into multi-modules is
> > not tied to Maven, it's based on accepted conventions. I chose Maven
> > because it was the quickest (for me) to get going.
> 
> Good thing! Just to show support! I applaud a separation into multiple 
> source trees, as a starting point for modularization.
> 
> Any change we can re-apply your effort on trunk while maintaining 
> subversion history? i.e. 'svn mv' commands?

Lets wait until after confirming the modular build structure though.

Cheers,

Peter.


> 
> Gr. Simon
> 
> 

Re: Modularization

[Peter <ji...@zeus.net.au>]

Thanks Dennis,

The test harness presently includes a number of classes from the the main build, so it'll depend on them, but not include them.

Jsk-policy also needs investigating.

Cheers,

Peter.

----- Original message -----
> You can certainly use the approach in qa_refactor. I did make 2 changes
> to the code to make the approach work:
>
> 1. Moved com.sun.jini.landlord.LeasedResource into jsk-dl.jar. This was
> done to accomodate outrigger-dl.jar's
> reliance on com.sun.jini.landlord.LeasedResource from
> com.sun.jini.outrigger.StorableResource.
> In the ant based build, LeasedResource was included using classdepandjar.
> Using a Maven build,
> outrigger-dl depends on river-dl (new name for jsk-dl). Adding
> LeasedResource to river-dl
> made sense. The approach taken to populate the source tree in the
> maven-zed structure is to
> load exiting jars, and for each entry in the loaded jar, copy the source
> files into each respective
> module's src directory, taking care not to duplicate any classes between
> modules. Making he
> change to jsk-dl.jar's build allows the river-dl module to be created
> correctly.
>
> 2. Removed import of net.jini.discovery.LookupLocatorDiscoveryfrom
> net.jini.core.discovery.LookupLocator. The
> net.jini.discovery.LookupLocatorDiscovery class is not in the
> jsk-platform module, and causes a compile error when included as an
> import.
>
> The import is only required since it is used in the @see javadoc
> directive. Including the
> fully qualified net.jini.discovery.LookupLocatorDiscovery class in the
> @see directive resolves
> the issue.
>
> If those get done, then you should be able to run the script and create
> the mavenized project that should build and assemble.
>
> HTH
>
> Dennis
>
>
> On Wed, Apr 30, 2014 at 2:57 PM, Simon IJskes - QCG <si...@qcg.nl> wrote:
>
> > On 30-04-14 02:02, Dennis Reedy wrote:
> >
> > A this point I'm soliciting opinions and thoughts. Note that using
> > Gradle
> > > is certainly an option here, the breakout into multi-modules is not
> > > tied to
> > > Maven, it's based on accepted conventions. I chose Maven because it
> > > was the
> > > quickest (for me) to get going.
> > >
> >
> > Good thing! Just to show support! I applaud a separation into multiple
> > source trees, as a starting point for modularization.
> >
> > Any change we can re-apply your effort on trunk while maintaining
> > subversion history? i.e. 'svn mv' commands?
> >
> > Gr. Simon
> >
> >
> >

Re: Modularization

[Dennis Reedy <de...@gmail.com>]

You can certainly use the approach in qa_refactor. I did make 2 changes to
the code to make the approach work:

1. Moved com.sun.jini.landlord.LeasedResource into jsk-dl.jar. This was
done to accomodate outrigger-dl.jar's
reliance on com.sun.jini.landlord.LeasedResource from
com.sun.jini.outrigger.StorableResource.
In the ant based build, LeasedResource was included using classdepandjar.
Using a Maven build,
outrigger-dl depends on river-dl (new name for jsk-dl). Adding
LeasedResource to river-dl
made sense. The approach taken to populate the source tree in the maven-zed
structure is to
load exiting jars, and for each entry in the loaded jar, copy the source
files into each respective
module's src directory, taking care not to duplicate any classes between
modules. Making he
change to jsk-dl.jar's build allows the river-dl module to be created
correctly.

2. Removed import of net.jini.discovery.LookupLocatorDiscoveryfrom
net.jini.core.discovery.LookupLocator. The
net.jini.discovery.LookupLocatorDiscovery class is not in the jsk-platform
module, and causes a compile error when included as an import.

The import is only required since it is used in the @see javadoc directive.
Including the
fully qualified net.jini.discovery.LookupLocatorDiscovery class in the @see
directive resolves
the issue.

If those get done, then you should be able to run the script and create the
mavenized project that should build and assemble.

HTH

Dennis


On Wed, Apr 30, 2014 at 2:57 PM, Simon IJskes - QCG <si...@qcg.nl> wrote:

> On 30-04-14 02:02, Dennis Reedy wrote:
>
>  A this point I'm soliciting opinions and thoughts. Note that using Gradle
>> is certainly an option here, the breakout into multi-modules is not tied
>> to
>> Maven, it's based on accepted conventions. I chose Maven because it was
>> the
>> quickest (for me) to get going.
>>
>
> Good thing! Just to show support! I applaud a separation into multiple
> source trees, as a starting point for modularization.
>
> Any change we can re-apply your effort on trunk while maintaining
> subversion history? i.e. 'svn mv' commands?
>
> Gr. Simon
>
>
>

Re: Modularization

[Simon IJskes - QCG <si...@qcg.nl>]

On 30-04-14 20:57, Simon IJskes - QCG wrote:
> On 30-04-14 02:02, Dennis Reedy wrote:

> Any change we can re-apply your effort on trunk while maintaining
> subversion history? i.e. 'svn mv' commands?

if so, we can adjust the ant script to maintain compatibility (as an 
intermediate step).

Gr. Simon

Re: Modularization

[Simon IJskes - QCG <si...@qcg.nl>]

On 30-04-14 02:02, Dennis Reedy wrote:

> A this point I'm soliciting opinions and thoughts. Note that using Gradle
> is certainly an option here, the breakout into multi-modules is not tied to
> Maven, it's based on accepted conventions. I chose Maven because it was the
> quickest (for me) to get going.

Good thing! Just to show support! I applaud a separation into multiple 
source trees, as a starting point for modularization.

Any change we can re-apply your effort on trunk while maintaining 
subversion history? i.e. 'svn mv' commands?

Gr. Simon