Hi Adam,
Thanks for your ideas and comments. I like to do some the changes you
mentioned.
> Your script should do 'set -e' at the beginning. It's possible that
> your script is buggy, or doesn't handle something on a particular
> machine, or the disk runs out of space. Without that, you would have
> to check the return of *every* command(cp, rm, cat, whatever), and
> handle the error. Without such checking, things can sometimes go very
> bad.
>
I'll do it.
>
> > 1. Creating the main/java and test/java folders in the src directory and
> put
> > test files in test/java and rest in the main/java
> > I did this by putting the tests in the test folders in each module in the
> > test/java folder. I used the following code to do that. $test variable is
> > the folder structure of each module.
>
> What is $test? Don't summarize, show code. I don't understand your
> explanation.
>
$test is a variable I use to store the relative path to the test folders. I
used this variable since one module can have several different test classes.
>
> > cp main/java/$test/test/* test/java/$test/
>
> cp -a, preserve timestamps/permissions/ownership.
>
> Your cp will *not* work if there are sub-folders in test, as it would
> then copy the .svn files, which is *not* what you want.
>
> rsync main/java/$test/test/ test/java/$test/ -a --exclude '.svn'
>
Since I worked in the the git repo I didn't notice that. Thanks for pointing
out me the issue and the solution.
sed 's,@{prefix}src,@{prefix}src/main/java,'
>
> Note the use of ',' as the separator; this is easier to read, as you
> don't have to escape all the / in the path.
>
Thanks for the suggestion. I didn't know it before.
>
> > cat temp >macros.xml
> > rm temp
> >
> > 3. Fixing the paths in build.xml files. This was achieved by first
> replacing
> > all the paths by adding main/java/ to the baginning of each path and then
> > changing it with test/java if it is a test. You can see the code follows.
> > Also some package name the files also change when it needed to do so.
> >
> > for x in $(ls main/java/$test/test/)
> > do
> > echo $x
> > sed 's/\.test;/;/' <main/java/$test/test/$x >temp
> >
> > cat temp >main/java/$test/test/$x
> >
> > j=`expr "$test" : 'org/ofbiz/base'`
> > if [ $j != 0 ];
> > then
> > sed 's/\.test\./\./' <main/java/$test/test/$x >temp
> > cat temp >main/java/$test/test/$x
> > fi
>
> What? Are we removing the test sub packages? As in:
>
> package org.ofbiz.entity.test;
>
> becomes
>
> package org.ofbiz.entity;
>
> ?
>
> If so, then NO! DO NOT DO THAT. Test cases should not ever be inside
> the same package as the code they are testing. Bugs might be missed,
> as you can call package private/protected methods when in the same
> package, that you can't when in another sub-package.
>
> I can *not* stress this enough. Do *NOT* move the test code out of a
> test sub-package.
>
>
Here I removed the test folder because it already in a different package.
src
|---main
| `----java
`---test
`----java
Since all the test classes in the test/java I thought we do not have to use
extra test class for module structure. We can make a jar for that by
changing the packaging criteria described in macro.xml. Please let me know
your ideas on this.
thanks
Ganath
