GSoC Project update: Code and Test separation of Ofbiz and Implementing pure webdriver

[Ganath Rathnayake]

Hi all,
I need all of you to know what I did up to now in my Google summer of code
project, separating test/code of Ofbiz [1] and implementing a pure
webdriver[2].
I the first iteration of the summer I worked on separating test/code of
Ofbiz. In this we were separate the three main modules,

   1. applications
   2. specialpurpose
   3. framework


In those modules there were submodules and some modules does not include
java files which does not needed to do the separation. Here are the
submodules I separated the test and code.

application sub-modules

accounting    manufacturing    party    workeffort
content    marketing    product    commonext
humanres    order    securityext

specialpurpose sub-modules

assetmaint  crowd    googlebase    myportal    projectmgr
ebay    googlecheckout    oagis    shark
cmssite    ebaystore    hhfacility    ofbizwebsite
webpos    ecommerce    ldap    pos    workflow

framework sub-modules

appserver    catalina    entity    guiapp    security    webapp
base    common    entityext    images    service    webslinger
bi    example    jetty    sql    webtools
birt    datafile    exampleext    minilang    start    widget
documents    geronimo    resources    testtools

After separate tests and code I had to put them as separate modules,

   - src/main/java
   - src/test/java


This directory structure changes directly affected the building of ofbiz
since some of the build.xml files and other files were configured to the
older folder structure. So I have to fix them as well Erwan show me some
places where some building exceptions and test run exceptions were came.


   - After test/code separation of "applications", the code builded
   successfully and ran tests successfully.
   - After test/code separation of "specialpurpose", the code builded
   successfully but one test failed from the "securityext" module. Find the
   cause of this error was postponeded by Erwan since it need some work.
   - After test/code separation of "framework", the code still not building
   successfully. An exception thrown which we still didnt figure it out.

You can find the wiki page which I logged some of my experience in [3].

Also I follwed the Selenium basics which use to implementation of the
webdriver.

Plan for next iteration-
My plans for next iteration is,

   - Resolving the exception which block finishing the test/code separation
   part.
   - Make a plan for creating a webdriver
   - Implementation of the webdriver
   - Test with the newly created webdriver.
   - Document the webdriver options.


I must say that I was behind the timeline and I still not finish the
test/code separation as we expected. But I believe still I can finish the
project in time.

thanks
Ganath


[1].https://issues.apache.org/jira/browse/OFBIZ-4211
[2].https://issues.apache.org/jira/browse/OFBIZ-4189
[3].
https://cwiki.apache.org/confluence/display/OFBIZ/Code+and+test+separation+for+Apache+OFBiz

[Erwan de FERRIERES]

Le 11/07/2011 19:59, Ganath Rathnayaka a écrit :

> Hi all,
> I need all of you to know what I did up to now in my Google summer of code
> project, separating test/code of Ofbiz [1] and implementing a pure
> webdriver[2].
> I the first iteration of the summer I worked on separating test/code of
> Ofbiz. In this we were separate the three main modules,
>
>     1. applications
>     2. specialpurpose
>     3. framework
>
>
> In those modules there were submodules and some modules does not include
> java files which does not needed to do the separation. Here are the
> submodules I separated the test and code.
>
> application sub-modules
>
> accounting    manufacturing    party    workeffort
> content    marketing    product    commonext
> humanres    order    securityext
>
> specialpurpose sub-modules
>
> assetmaint  crowd    googlebase    myportal    projectmgr
> ebay    googlecheckout    oagis    shark
> cmssite    ebaystore    hhfacility    ofbizwebsite
> webpos    ecommerce    ldap    pos    workflow
>
> framework sub-modules
>
> appserver    catalina    entity    guiapp    security    webapp
> base    common    entityext    images    service    webslinger
> bi    example    jetty    sql    webtools
> birt    datafile    exampleext    minilang    start    widget
> documents    geronimo    resources    testtools
>
> After separate tests and code I had to put them as separate modules,
>
>     - src/main/java
>     - src/test/java
>
>
> This directory structure changes directly affected the building of ofbiz
> since some of the build.xml files and other files were configured to the
> older folder structure. So I have to fix them as well Erwan show me some
> places where some building exceptions and test run exceptions were came.
>
>
>     - After test/code separation of "applications", the code builded
>     successfully and ran tests successfully.
>     - After test/code separation of "specialpurpose", the code builded
>     successfully but one test failed from the "securityext" module. Find the
>     cause of this error was postponeded by Erwan since it need some work.
>     - After test/code separation of "framework", the code still not building
>     successfully. An exception thrown which we still didnt figure it out.
>
> You can find the wiki page which I logged some of my experience in [3].
>
> Also I follwed the Selenium basics which use to implementation of the
> webdriver.
>
> Plan for next iteration-
> My plans for next iteration is,
>
>     - Resolving the exception which block finishing the test/code separation
>     part.
>     - Make a plan for creating a webdriver
>     - Implementation of the webdriver
>     - Test with the newly created webdriver.
>     - Document the webdriver options.
>
>
> I must say that I was behind the timeline and I still not finish the
> test/code separation as we expected. But I believe still I can finish the
> project in time.
>
> thanks
> Ganath
>
>
> [1].https://issues.apache.org/jira/browse/OFBIZ-4211
> [2].https://issues.apache.org/jira/browse/OFBIZ-4189
> [3].
> https://cwiki.apache.org/confluence/display/OFBIZ/Code+and+test+separation+for+Apache+OFBiz
>

Thanks for this report.
For the exception, I think this is mostly due to the jar, which is not
built properly. You should, as I said before, investigate in this way.

Cheers,

--
Erwan de FERRIERES
www.nereide.biz

[Adam Heath-2]

On 07/11/2011 12:59 PM, Ganath Rathnayaka wrote:

> Hi all,
> I need all of you to know what I did up to now in my Google summer of code
> project, separating test/code of Ofbiz [1] and implementing a pure
> webdriver[2].
> I the first iteration of the summer I worked on separating test/code of
> Ofbiz. In this we were separate the three main modules,
>
>     1. applications
>     2. specialpurpose
>     3. framework
>
>
> In those modules there were submodules and some modules does not include
> java files which does not needed to do the separation. Here are the
> submodules I separated the test and code.
>
> application sub-modules
>
> accounting    manufacturing    party    workeffort
> content    marketing    product    commonext
> humanres    order    securityext
>
> specialpurpose sub-modules
>
> assetmaint  crowd    googlebase    myportal    projectmgr
> ebay    googlecheckout    oagis    shark
> cmssite    ebaystore    hhfacility    ofbizwebsite
> webpos    ecommerce    ldap    pos    workflow
>
> framework sub-modules
>
> appserver    catalina    entity    guiapp    security    webapp
> base    common    entityext    images    service    webslinger
> bi    example    jetty    sql    webtools
> birt    datafile    exampleext    minilang    start    widget
> documents    geronimo    resources    testtools
>
> After separate tests and code I had to put them as separate modules,
>
>     - src/main/java
>     - src/test/java

Er, no, do not do this.  Bad.  Stop.

Leave it as src/.  I already have stuff in ofbiz that creates
build/lib/ofbiz-base.jar and build/lib/ofbiz-base-test.jar.  There is
no reason to split the test java files out.

I actually *like* that a single javac call will compile all the code
for a component, not just the base stuff.  Makes it easier to detect
compile errors.

> This directory structure changes directly affected the building of ofbiz
> since some of the build.xml files and other files were configured to the
> older folder structure. So I have to fix them as well Erwan show me some
> places where some building exceptions and test run exceptions were came.
>
>
>     - After test/code separation of "applications", the code builded
>     successfully and ran tests successfully.
>     - After test/code separation of "specialpurpose", the code builded
>     successfully but one test failed from the "securityext" module. Find the
>     cause of this error was postponeded by Erwan since it need some work.
>     - After test/code separation of "framework", the code still not building
>     successfully. An exception thrown which we still didnt figure it out.
>
> You can find the wiki page which I logged some of my experience in [3].
>
> Also I follwed the Selenium basics which use to implementation of the
> webdriver.
>
> Plan for next iteration-
> My plans for next iteration is,
>
>     - Resolving the exception which block finishing the test/code separation
>     part.
>     - Make a plan for creating a webdriver
>     - Implementation of the webdriver
>     - Test with the newly created webdriver.
>     - Document the webdriver options.
>
>
> I must say that I was behind the timeline and I still not finish the
> test/code separation as we expected. But I believe still I can finish the
> project in time.
>
> thanks
> Ganath
>
>
> [1].https://issues.apache.org/jira/browse/OFBIZ-4211
> [2].https://issues.apache.org/jira/browse/OFBIZ-4189
> [3].
> https://cwiki.apache.org/confluence/display/OFBIZ/Code+and+test+separation+for+Apache+OFBiz
>

[Erwan de FERRIERES]

Le 13/07/2011 20:59, Adam Heath a écrit :

> On 07/11/2011 12:59 PM, Ganath Rathnayaka wrote:
>> Hi all,
>> I need all of you to know what I did up to now in my Google summer of
>> code
>> project, separating test/code of Ofbiz [1] and implementing a pure
>> webdriver[2].
>> I the first iteration of the summer I worked on separating test/code of
>> Ofbiz. In this we were separate the three main modules,
>>
>> 1. applications
>> 2. specialpurpose
>> 3. framework
>>
>>
>> In those modules there were submodules and some modules does not include
>> java files which does not needed to do the separation. Here are the
>> submodules I separated the test and code.
>>
>> application sub-modules
>>
>> accounting manufacturing party workeffort
>> content marketing product commonext
>> humanres order securityext
>>
>> specialpurpose sub-modules
>>
>> assetmaint crowd googlebase myportal projectmgr
>> ebay googlecheckout oagis shark
>> cmssite ebaystore hhfacility ofbizwebsite
>> webpos ecommerce ldap pos workflow
>>
>> framework sub-modules
>>
>> appserver catalina entity guiapp security webapp
>> base common entityext images service webslinger
>> bi example jetty sql webtools
>> birt datafile exampleext minilang start widget
>> documents geronimo resources testtools
>>
>> After separate tests and code I had to put them as separate modules,
>>
>> - src/main/java
>> - src/test/java
>
> Er, no, do not do this. Bad. Stop.
>
> Leave it as src/. I already have stuff in ofbiz that creates
> build/lib/ofbiz-base.jar and build/lib/ofbiz-base-test.jar. There is no
> reason to split the test java files out.
>

Adam,
thanks for your comment. But why didn't you told this before ? Ganath
has been working on this theme for more than a month now...



--
Erwan de FERRIERES
www.nereide.biz

[Adam Heath-2]

On 07/13/2011 02:49 PM, Erwan de FERRIERES wrote:

> Le 13/07/2011 20:59, Adam Heath a écrit :
>> On 07/11/2011 12:59 PM, Ganath Rathnayaka wrote:
>>> Hi all,
>>> I need all of you to know what I did up to now in my Google summer of
>>> code
>>> project, separating test/code of Ofbiz [1] and implementing a pure
>>> webdriver[2].
>>> I the first iteration of the summer I worked on separating test/code of
>>> Ofbiz. In this we were separate the three main modules,
>>>
>>> 1. applications
>>> 2. specialpurpose
>>> 3. framework
>>>
>>>
>>> In those modules there were submodules and some modules does not include
>>> java files which does not needed to do the separation. Here are the
>>> submodules I separated the test and code.
>>>
>>> application sub-modules
>>>
>>> accounting manufacturing party workeffort
>>> content marketing product commonext
>>> humanres order securityext
>>>
>>> specialpurpose sub-modules
>>>
>>> assetmaint crowd googlebase myportal projectmgr
>>> ebay googlecheckout oagis shark
>>> cmssite ebaystore hhfacility ofbizwebsite
>>> webpos ecommerce ldap pos workflow
>>>
>>> framework sub-modules
>>>
>>> appserver catalina entity guiapp security webapp
>>> base common entityext images service webslinger
>>> bi example jetty sql webtools
>>> birt datafile exampleext minilang start widget
>>> documents geronimo resources testtools
>>>
>>> After separate tests and code I had to put them as separate modules,
>>>
>>> - src/main/java
>>> - src/test/java
>>
>> Er, no, do not do this. Bad. Stop.
>>
>> Leave it as src/. I already have stuff in ofbiz that creates
>> build/lib/ofbiz-base.jar and build/lib/ofbiz-base-test.jar. There is no
>> reason to split the test java files out.
>>
> Adam,
> thanks for your comment. But why didn't you told this before ? Ganath
> has been working on this theme for more than a month now...

Because I wasn't aware of it?  We are all busy.

And as a GSoC person, he should have investigated what the system
already did before changing a bunch of stuff.

I added the "test-jar" macro to common.xml last April.  It's been
there for quite a while.

As for splitting any entitymodel/servicemodel/seed-data stuff, there
is no reason to move any files around.  All the loaders need to be
modified to support "test" type loading(some already support this).
Then, downstream distributors that don't want to include example or
test stuff can just parse the same set of files(or we can include a
tool to do it for them).

[David E. Jones-2]

There was actually a discussion about this on this mailing list.

The consensus seemed to be in favour of what Ganath proposed. I though that was unfortunate because have non-source directories under an src directory is an annoying practice IMO, and I HATE to see that going into the project. I voiced that concern but no one else seemed to think it was a big deal.

-David


On Jul 13, 2011, at 10:06 PM, Adam Heath wrote:

> On 07/13/2011 02:49 PM, Erwan de FERRIERES wrote:
>> Le 13/07/2011 20:59, Adam Heath a écrit :
>>> On 07/11/2011 12:59 PM, Ganath Rathnayaka wrote:
>>>> Hi all,
>>>> I need all of you to know what I did up to now in my Google summer of
>>>> code
>>>> project, separating test/code of Ofbiz [1] and implementing a pure
>>>> webdriver[2].
>>>> I the first iteration of the summer I worked on separating test/code of
>>>> Ofbiz. In this we were separate the three main modules,
>>>>
>>>> 1. applications
>>>> 2. specialpurpose
>>>> 3. framework
>>>>
>>>>
>>>> In those modules there were submodules and some modules does not include
>>>> java files which does not needed to do the separation. Here are the
>>>> submodules I separated the test and code.
>>>>
>>>> application sub-modules
>>>>
>>>> accounting manufacturing party workeffort
>>>> content marketing product commonext
>>>> humanres order securityext
>>>>
>>>> specialpurpose sub-modules
>>>>
>>>> assetmaint crowd googlebase myportal projectmgr
>>>> ebay googlecheckout oagis shark
>>>> cmssite ebaystore hhfacility ofbizwebsite
>>>> webpos ecommerce ldap pos workflow
>>>>
>>>> framework sub-modules
>>>>
>>>> appserver catalina entity guiapp security webapp
>>>> base common entityext images service webslinger
>>>> bi example jetty sql webtools
>>>> birt datafile exampleext minilang start widget
>>>> documents geronimo resources testtools
>>>>
>>>> After separate tests and code I had to put them as separate modules,
>>>>
>>>> - src/main/java
>>>> - src/test/java
>>>
>>> Er, no, do not do this. Bad. Stop.
>>>
>>> Leave it as src/. I already have stuff in ofbiz that creates
>>> build/lib/ofbiz-base.jar and build/lib/ofbiz-base-test.jar. There is no
>>> reason to split the test java files out.
>>>
>> Adam,
>> thanks for your comment. But why didn't you told this before ? Ganath
>> has been working on this theme for more than a month now...
>
> Because I wasn't aware of it?  We are all busy.
>
> And as a GSoC person, he should have investigated what the system already did before changing a bunch of stuff.
>
> I added the "test-jar" macro to common.xml last April.  It's been there for quite a while.
>
> As for splitting any entitymodel/servicemodel/seed-data stuff, there is no reason to move any files around.  All the loaders need to be modified to support "test" type loading(some already support this). Then, downstream distributors that don't want to include example or test stuff can just parse the same set of files(or we can include a tool to do it for them).
>

[Adam Heath-2]

On 07/13/2011 03:17 PM, David E Jones wrote:
>
> There was actually a discussion about this on this mailing list.
>
> The consensus seemed to be in favour of what Ganath proposed.
 > I though that was unfortunate because have non-source
 > directories under an src directory is an annoying practice
 > IMO, and I HATE to see that going into the project. I voiced
 > that concern but no one else seemed to think it was a big deal.

I agree with David.  I could possibly see a src/java src/c src/python
layout, but that is as far as I'm willing to go.

But anyways, ofbiz already *does* split out */test/* stuff into a
separate jar, which is the whole point of the src/ splitting that was
proposed.  And I did it without having to change the way anyone did
ofbiz source development.  Which is the better thing.

And my suggestions about adding the correct 'spline' stuff to any
loader, is the correct approach as well.  Esp. considering that most
loaders already *do* have spline type support.

[David E. Jones-2]

On Jul 13, 2011, at 10:23 PM, Adam Heath wrote:

> On 07/13/2011 03:17 PM, David E Jones wrote:
>>
>> There was actually a discussion about this on this mailing list.
>>
>> The consensus seemed to be in favour of what Ganath proposed.
> > I though that was unfortunate because have non-source
> > directories under an src directory is an annoying practice
> > IMO, and I HATE to see that going into the project. I voiced
> > that concern but no one else seemed to think it was a big deal.
>
> I agree with David.  I could possibly see a src/java src/c src/python layout, but that is as far as I'm willing to go.
>
> But anyways, ofbiz already *does* split out */test/* stuff into a separate jar, which is the whole point of the src/ splitting that was proposed.  And I did it without having to change the way anyone did ofbiz source development.  Which is the better thing.
>
> And my suggestions about adding the correct 'spline' stuff to any loader, is the correct approach as well.  Esp. considering that most loaders already *do* have spline type support.

I wouldn't mind so much having the tests split out into a separate directory (through as I think you're getting at they already ARE in separate directories, just deeper under the src directory), but I'd much rather have something like:

component/src
component/src-test

instead of:

component/src/main
component/src/test

-David

[Ganath Rathnayake]

Hi David,
Since we have the current structure of the code,
component/src/main
component/src/test
which contains separated test and code. We can do the code transformation
to,
component/src
component/src-test
easily. But to build the project, it may need some work to change the build,
commons and macros xml files. Since I need to finish the project before 16th
August, I and Erwan need to change the scope of the project if this change
need to be done because we have another part (implementing a webdriver) of
the project to be done.
Here I am expecting all your final decision before I make my next movement.

thanks
Ganath

[Adrian Crum-3]

On 7/13/2011 9:23 PM, Adam Heath wrote:

> On 07/13/2011 03:17 PM, David E Jones wrote:
>>
>> There was actually a discussion about this on this mailing list.
>>
>> The consensus seemed to be in favour of what Ganath proposed.
> > I though that was unfortunate because have non-source
> > directories under an src directory is an annoying practice
> > IMO, and I HATE to see that going into the project. I voiced
> > that concern but no one else seemed to think it was a big deal.
>
> I agree with David.  I could possibly see a src/java src/c src/python
> layout, but that is as far as I'm willing to go.
>
> But anyways, ofbiz already *does* split out */test/* stuff into a
> separate jar, which is the whole point of the src/ splitting that was
> proposed.  And I did it without having to change the way anyone did
> ofbiz source development.  Which is the better thing.
>
> And my suggestions about adding the correct 'spline' stuff to any
> loader, is the correct approach as well.  Esp. considering that most
> loaders already *do* have spline type support.

I don't see the different approaches as "right" or "wrong" - they are
just different.

One of the things I don't like about Adam's approach is how all of the
test classes are in a different package than the classes being tested -
so imports are needed. In the proposed folder structure, test classes
can be in the same package - eliminating the need to import the classes
being tested.

The folder structure being proposed is used in a number of other open
source projects. Right or wrong, it is ubiquitous - and as a result it
is intuitive.

-Adrian

[Adam Heath-2]

On 07/13/2011 04:57 PM, Adrian Crum wrote:

> On 7/13/2011 9:23 PM, Adam Heath wrote:
>> On 07/13/2011 03:17 PM, David E Jones wrote:
>>>
>>> There was actually a discussion about this on this mailing list.
>>>
>>> The consensus seemed to be in favour of what Ganath proposed.
>> > I though that was unfortunate because have non-source
>> > directories under an src directory is an annoying practice
>> > IMO, and I HATE to see that going into the project. I voiced
>> > that concern but no one else seemed to think it was a big deal.
>>
>> I agree with David. I could possibly see a src/java src/c src/python
>> layout, but that is as far as I'm willing to go.
>>
>> But anyways, ofbiz already *does* split out */test/* stuff into a
>> separate jar, which is the whole point of the src/ splitting that was
>> proposed. And I did it without having to change the way anyone did
>> ofbiz source development. Which is the better thing.
>>
>> And my suggestions about adding the correct 'spline' stuff to any
>> loader, is the correct approach as well. Esp. considering that most
>> loaders already *do* have spline type support.
>
> I don't see the different approaches as "right" or "wrong" - they are
> just different.
>
> One of the things I don't like about Adam's approach is how all of the
> test classes are in a different package than the classes being tested -
> so imports are needed. In the proposed folder structure, test classes
> can be in the same package - eliminating the need to import the classes
> being tested.
>
> The folder structure being proposed is used in a number of other open
> source projects. Right or wrong, it is ubiquitous - and as a result it
> is intuitive.

How can one sign and seal a Package then?  One a Package is sealed,
you can't add other classes in other jars to it.

[Adam Heath-2]

On 07/13/2011 04:57 PM, Adrian Crum wrote:
> One of the things I don't like about Adam's approach is how all of the
> test classes are in a different package than the classes being tested -
> so imports are needed. In the proposed folder structure, test classes
> can be in the same package - eliminating the need to import the classes
> being tested.

Having test classes in the same package is also bad for ensuring api
leakage.  A method marked 'protected' or 'nothing' is accessible to
any other class in the same package.  With the test code in a separate
package directory(./test), then the test code can only really test the
exposed api methods, and doesn't get tied to the internals of the
class(thereby allowed the class to change how it is implemented
without breaking random tests).

[Adrian Crum-3]

On 7/13/2011 11:13 PM, Adam Heath wrote:

> On 07/13/2011 04:57 PM, Adrian Crum wrote:
>> One of the things I don't like about Adam's approach is how all of the
>> test classes are in a different package than the classes being tested -
>> so imports are needed. In the proposed folder structure, test classes
>> can be in the same package - eliminating the need to import the classes
>> being tested.
>
> Having test classes in the same package is also bad for ensuring api
> leakage.  A method marked 'protected' or 'nothing' is accessible to
> any other class in the same package.  With the test code in a separate
> package directory(./test), then the test code can only really test the
> exposed api methods, and doesn't get tied to the internals of the
> class(thereby allowed the class to change how it is implemented
> without breaking random tests).
>

Good point - I hadn't thought of that.

-Adrian

[David E. Jones-2]

I've been doing a little more research on Maven, and I'm guessing that the pattern that Ganath is proposing is at least partly based on the convention for src directories in Maven (which appears to be required for use of Maven, BTW... ie with their convention over configuration approach, which is certainly nice for various reasons even if it does impose certain constraints).

If we wanted our src directories to be Maven-friendly, it would look like:

<component>/src/main/java
<component>/src/test/java

In other words, if we're going to make a change, perhaps we should change to that as the Maven conventions seem to be turning into industry standards (perhaps because the Maven conventions are some of the few that exist and are even remotely widely used).

Along that vein, we might also consider moving the files under <component>/script and even <component>/config to:

<component>/src/main/resources

BTW, just as a side note if we ever had Maven POM files, their location in each component would just be <component>/pom.xml

-David


On Jul 13, 2011, at 11:09 PM, Ganath Rathnayaka wrote:

> Hi David,
> Since we have the current structure of the code,
> component/src/main
> component/src/test
> which contains separated test and code. We can do the code transformation
> to,
> component/src
> component/src-test
> easily. But to build the project, it may need some work to change the build,
> commons and macros xml files. Since I need to finish the project before 16th
> August, I and Erwan need to change the scope of the project if this change
> need to be done because we have another part (implementing a webdriver) of
> the project to be done.
> Here I am expecting all your final decision before I make my next movement.
>
> thanks
> Ganath

[Adrian Crum-3]

Thank you David.

-Adrian

On 7/15/2011 10:03 AM, David E Jones wrote:

> I've been doing a little more research on Maven, and I'm guessing that the pattern that Ganath is proposing is at least partly based on the convention for src directories in Maven (which appears to be required for use of Maven, BTW... ie with their convention over configuration approach, which is certainly nice for various reasons even if it does impose certain constraints).
>
> If we wanted our src directories to be Maven-friendly, it would look like:
>
> <component>/src/main/java
> <component>/src/test/java
>
> In other words, if we're going to make a change, perhaps we should change to that as the Maven conventions seem to be turning into industry standards (perhaps because the Maven conventions are some of the few that exist and are even remotely widely used).
>
> Along that vein, we might also consider moving the files under<component>/script and even<component>/config to:
>
> <component>/src/main/resources
>
> BTW, just as a side note if we ever had Maven POM files, their location in each component would just be<component>/pom.xml
>
> -David
>
>
> On Jul 13, 2011, at 11:09 PM, Ganath Rathnayaka wrote:
>
>> Hi David,
>> Since we have the current structure of the code,
>> component/src/main
>> component/src/test
>> which contains separated test and code. We can do the code transformation
>> to,
>> component/src
>> component/src-test
>> easily. But to build the project, it may need some work to change the build,
>> commons and macros xml files. Since I need to finish the project before 16th
>> August, I and Erwan need to change the scope of the project if this change
>> need to be done because we have another part (implementing a webdriver) of
>> the project to be done.
>> Here I am expecting all your final decision before I make my next movement.
>>
>> thanks
>> Ganath

[Erwan de FERRIERES]

Le 15/07/2011 11:03, David E Jones a écrit :

>
> I've been doing a little more research on Maven, and I'm guessing that the pattern that Ganath is proposing is at least partly based on the convention for src directories in Maven (which appears to be required for use of Maven, BTW... ie with their convention over configuration approach, which is certainly nice for various reasons even if it does impose certain constraints).
>
> If we wanted our src directories to be Maven-friendly, it would look like:
>
> <component>/src/main/java
> <component>/src/test/java
>
> In other words, if we're going to make a change, perhaps we should change to that as the Maven conventions seem to be turning into industry standards (perhaps because the Maven conventions are some of the few that exist and are even remotely widely used).
>
> Along that vein, we might also consider moving the files under<component>/script and even<component>/config to:
>
> <component>/src/main/resources
>
> BTW, just as a side note if we ever had Maven POM files, their location in each component would just be<component>/pom.xml
>
> -David

Thanks David. The first idea was to propose a common directory
structure, like the one most of the java projects is using.
Once the POC is finished (just a question of days now), we'll have to
review it and decide what to do with it.
The resources can also be moved, I will ask Ganath to go this way too.

Cheers,

--
Erwan de FERRIERES
www.nereide.biz

[BJ Freeman]

since there is some emails that refer to the scripting folder, maybe
leave with a readme to where the code went. the others are more obvious.

David E Jones sent the following on 7/15/2011 2:03 AM:

>
> I've been doing a little more research on Maven, and I'm guessing that the pattern that Ganath is proposing is at least partly based on the convention for src directories in Maven (which appears to be required for use of Maven, BTW... ie with their convention over configuration approach, which is certainly nice for various reasons even if it does impose certain constraints).
>
> If we wanted our src directories to be Maven-friendly, it would look like:
>
> <component>/src/main/java
> <component>/src/test/java
>
> In other words, if we're going to make a change, perhaps we should change to that as the Maven conventions seem to be turning into industry standards (perhaps because the Maven conventions are some of the few that exist and are even remotely widely used).
>
> Along that vein, we might also consider moving the files under <component>/script and even <component>/config to:
>
> <component>/src/main/resources
>
> BTW, just as a side note if we ever had Maven POM files, their location in each component would just be <component>/pom.xml
>
> -David
>
>
> On Jul 13, 2011, at 11:09 PM, Ganath Rathnayaka wrote:
>
>> Hi David,
>> Since we have the current structure of the code,
>> component/src/main
>> component/src/test
>> which contains separated test and code. We can do the code transformation
>> to,
>> component/src
>> component/src-test
>> easily. But to build the project, it may need some work to change the build,
>> commons and macros xml files. Since I need to finish the project before 16th
>> August, I and Erwan need to change the scope of the project if this change
>> need to be done because we have another part (implementing a webdriver) of
>> the project to be done.
>> Here I am expecting all your final decision before I make my next movement.
>>
>> thanks
>> Ganath
>
>