You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Tom Hobbs <tv...@googlemail.com> on 2011/05/19 21:29:54 UTC

Modular Build

Hi all,

I've been going through the modular build stuff (River 300?) because
what I think what would be really good is if we could execute "gradle
build" from a fresh checkout and have the whole distribution built
without any messing around.  At the moment, that doesn't happen
because there seems to be some cyclic dependencies in the 'core'
source directories that have been defined.  (Dennis/Peter correct me
if I'm wrong...)

So I got to thinking about a way around that.  My first reaction was
to create a special gradle build would use all the source directories
in one go and then use those same source directories as a template for
JAR-ing the class files.  (Example at end).  But that feels more like
a fudge than a fix.

So my questions then become;

1) Have we separated things out into the correct directories?  Do the
cyclic inter-dependencies imply that we haven't?
2) If the directory splits are correct; should be introducing a
core-core directory (possibly containing only interfaces) in order to
break the cyclic dependencies.

I just wanted to make sure that I'm on (what we can all agree) is the
right track before I go any further.

Thoughts anyone?

Cheers.

Tom


Example of "special gradle build":

Consider the following structure;

foo/src/main/java/org/apache/river/A.java
bar/src/main/java/org/apache/river/B.java

The above source directories would produce the following;

build/org/apache/river/A.class
build/org/apache/river/B.class

Then a clever/custom "jar" task would see that A.class comes from
A.java which is in the foo directory and so would be put in foo.jar.
And so on.

Re: Modular Build

Posted by Tom Hobbs <tv...@googlemail.com>.
If there's something else you want to learn, then I don't see why not
picking up gradle now would be a problem.

The problem I've outlined is equally applicable to Ant, Maven or any other
build tool you could name.

On 19 May 2011 23:31, "Patricia Shanahan" <pa...@acm.org> wrote:
> On 5/19/2011 12:29 PM, Tom Hobbs wrote:
> ...
>> Thoughts anyone?
> ...
>
> I have a question. Should I start studying gradle at this time? There
> are arguments both ways:
>
> Pro: After learning about it, I might be able to contribute to
> discussions of how to set up to use it.
>
> Con: I have other stuff I want to study, and if I remain gradle-ignorant
> I might be able to better test build instructions.
>
> Patricia

Re: Modular Build

Posted by Patricia Shanahan <pa...@acm.org>.
On 5/19/2011 12:29 PM, Tom Hobbs wrote:
...
> Thoughts anyone?
...

I have a question. Should I start studying gradle at this time? There 
are arguments both ways:

Pro: After learning about it, I might be able to contribute to 
discussions of how to set up to use it.

Con: I have other stuff I want to study, and if I remain gradle-ignorant 
I might be able to better test build instructions.

Patricia

Re: Modular Build

Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 20-05-11 11:51, Tom Hobbs wrote:
> I think that's largely what Dennis has done.  The problem has come from the
> dependencies between source files and how he and Peter have considered how
> they should be spit up.
>
> Maybe that split is wrong, I don't have the whole context or something
> else.  I don't know.

If the gradle build can coexist next to the current build, why not move 
it to the trunk?

We can tune the module splits by modifying the copy process, and if we 
svn:ignore the the 'new' source tree, and make sure it doesn't get 
checked in we can experiment until everybody is happy.

And if we make the copy process based on a macro <copy src='src/blah' 
dest='gradle/mod1/blah' />, we can later change that macro to modify the 
subversion source tree, when we definitively step over.

But i'm repeating myself now, and last time i proposed this it didn't 
make it.

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: Modular Build

Posted by Tom Hobbs <tv...@googlemail.com>.
I think that's largely what Dennis has done.  The problem has come from the
dependencies between source files and how he and Peter have considered how
they should be spit up.

Maybe that split is wrong, I don't have the whole context or something
else.  I don't know.

It's good to hear from you again, Sim!

On 20 May 2011 10:44, "Sim IJskes - QCG" <si...@qcg.nl> wrote:

On 19-05-11 21:29, Tom Hobbs wrote:
>
> So I got to thinking about a way around that.  My first reac...
To prototype the build, a favorable option though. My proposal is to take
the current source tree, and as a first step in the build copy the source
files to a new directory structure, and build with gradle from there.

If it works to our satisfaction we can then rearrange the current source
tree into the prefered tree layout for the gradle build.

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: Modular Build

Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 19-05-11 21:29, Tom Hobbs wrote:
> So I got to thinking about a way around that.  My first reaction was
> to create a special gradle build would use all the source directories
> in one go and then use those same source directories as a template for
> JAR-ing the class files.  (Example at end).  But that feels more like
> a fudge than a fix.

To prototype the build, a favorable option though. My proposal is to 
take the current source tree, and as a first step in the build copy the 
source files to a new directory structure, and build with gradle from there.

If it works to our satisfaction we can then rearrange the current source 
tree into the prefered tree layout for the gradle build.

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397