Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:

http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

More specifically I would like to switch from, for example:

script/org/ofbiz/product/
src/org/ofbiz/product/
src/org/ofbiz/product/test/

to:

src/main/java/org/ofbiz/product/
src/main/minilang/org/ofbiz/product/
src/main/groovy/...
src/test/java/org/ofbiz/product/

What do you think?

Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Adrian Crum <ad...@sandglass-software.com>]

True.

To summarize, I support any effort to make things more organized. This 
all sounds fine to me.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 1/21/2015 7:03 AM, Jacopo Cappellato wrote:
> On Jan 21, 2015, at 3:56 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>
>> I don't like the idea of mixing scripts with Java source code. I understand it makes sense from the perspective that scripts and Java are both "source code", but the nice thing about keeping the Java source separate is it can be removed during deployment - reducing the project's footprint on the target server.
>
> You could do the same by removing the src/main/java folders and by keeping the src/main/minilang/ ones.
>
> Jacopo
>
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 1/21/2015 12:36 AM, Jacopo Cappellato wrote:
>>>
>>> On Jan 20, 2015, at 4:29 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>>>
>>>> I suggested a Maven-like folder structure years ago, and there was pushback from Adam. He was concerned that test classes would reside in the same package as the classes being tested - which would expose their implementation.
>>>
>>> This is a non problem: even if we split the main and test classes using the src/main and src/test folders we are still free to place them in the packages we like.
>>>
>>>>
>>>> The classpath under the script folder is not necessary. That was used before we had FlexibleLocation and the "component://" URL feature. So, instead of your suggestion we could do:
>>>>
>>>> script/groovy/FooScript_1.groovy
>>>> script/groovy/FooScript_2.groovy
>>>> script/minilang/BarScript_1.xml
>>>> script/minilang/BarScript_2.xml
>>>> script/js/BazScript_1.js
>>>
>>> +1 on the idea of getting rid of the "classpaths" for Minilang as a general direction; I still think they should go under src/minilang but at this point this is just a matter of personal taste.
>>> As regards Groovy, with it you can implement classes and not just scripts and having the ability to define the packages will be very useful especially when we will have more services implemented in Groovy.
>>> Again, I think they should go into src/main/groovy or src/test/groovy.
>>>
>>>>
>>>> (Yes, the Service Engine supports JavaScript.)
>>>>
>>>> To use FooScript_1.groovy you can use two methods:
>>>>
>>>> 1. The  "component://" URL feature:
>>>>
>>>> component://mycomponent/script/groovy/FooScript_1.groovy
>>>>
>>>> 2. The classpath:
>>>>
>>>> groovy/FooScript_1.groovy
>>>>
>>>> Option 2 could have problems with name clash, so I have always preferred option 1.
>>>>
>>>> While we are having this discussion, we could also consider changing the package naming from
>>>>
>>>> org.ofbiz.*
>>>>
>>>> to
>>>>
>>>> org.apache.ofbiz.*
>>>
>>> +1!!!
>>>
>>> Jacopo
>>>
>>>>
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 1/20/2015 3:41 AM, Jacopo Cappellato wrote:
>>>>> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:
>>>>>
>>>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>>>>
>>>>> More specifically I would like to switch from, for example:
>>>>>
>>>>> script/org/ofbiz/product/
>>>>> src/org/ofbiz/product/
>>>>> src/org/ofbiz/product/test/
>>>>>
>>>>> to:
>>>>>
>>>>> src/main/java/org/ofbiz/product/
>>>>> src/main/minilang/org/ofbiz/product/
>>>>> src/main/groovy/...
>>>>> src/test/java/org/ofbiz/product/
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Jacopo
>>>>>
>>>
>

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler <rw...@artifact-software.com>]

Could you not do this by splitting the scripts into their own SVN 
project with a dependency in the build on a jar that is generated by the 
project that contains the Java code? The script project would generate 
the executable jar.

On 21/01/2015 10:03 AM, Jacopo Cappellato wrote:
> On Jan 21, 2015, at 3:56 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>
>> I don't like the idea of mixing scripts with Java source code. I understand it makes sense from the perspective that scripts and Java are both "source code", but the nice thing about keeping the Java source separate is it can be removed during deployment - reducing the project's footprint on the target server.
> You could do the same by removing the src/main/java folders and by keeping the src/main/minilang/ ones.
>
> Jacopo
>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 1/21/2015 12:36 AM, Jacopo Cappellato wrote:
>>> On Jan 20, 2015, at 4:29 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>>>
>>>> I suggested a Maven-like folder structure years ago, and there was pushback from Adam. He was concerned that test classes would reside in the same package as the classes being tested - which would expose their implementation.
>>> This is a non problem: even if we split the main and test classes using the src/main and src/test folders we are still free to place them in the packages we like.
>>>
>>>> The classpath under the script folder is not necessary. That was used before we had FlexibleLocation and the "component://" URL feature. So, instead of your suggestion we could do:
>>>>
>>>> script/groovy/FooScript_1.groovy
>>>> script/groovy/FooScript_2.groovy
>>>> script/minilang/BarScript_1.xml
>>>> script/minilang/BarScript_2.xml
>>>> script/js/BazScript_1.js
>>> +1 on the idea of getting rid of the "classpaths" for Minilang as a general direction; I still think they should go under src/minilang but at this point this is just a matter of personal taste.
>>> As regards Groovy, with it you can implement classes and not just scripts and having the ability to define the packages will be very useful especially when we will have more services implemented in Groovy.
>>> Again, I think they should go into src/main/groovy or src/test/groovy.
>>>
>>>> (Yes, the Service Engine supports JavaScript.)
>>>>
>>>> To use FooScript_1.groovy you can use two methods:
>>>>
>>>> 1. The  "component://" URL feature:
>>>>
>>>> component://mycomponent/script/groovy/FooScript_1.groovy
>>>>
>>>> 2. The classpath:
>>>>
>>>> groovy/FooScript_1.groovy
>>>>
>>>> Option 2 could have problems with name clash, so I have always preferred option 1.
>>>>
>>>> While we are having this discussion, we could also consider changing the package naming from
>>>>
>>>> org.ofbiz.*
>>>>
>>>> to
>>>>
>>>> org.apache.ofbiz.*
>>> +1!!!
>>>
>>> Jacopo
>>>
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 1/20/2015 3:41 AM, Jacopo Cappellato wrote:
>>>>> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:
>>>>>
>>>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>>>>
>>>>> More specifically I would like to switch from, for example:
>>>>>
>>>>> script/org/ofbiz/product/
>>>>> src/org/ofbiz/product/
>>>>> src/org/ofbiz/product/test/
>>>>>
>>>>> to:
>>>>>
>>>>> src/main/java/org/ofbiz/product/
>>>>> src/main/minilang/org/ofbiz/product/
>>>>> src/main/groovy/...
>>>>> src/test/java/org/ofbiz/product/
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Jacopo
>>>>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Jan 21, 2015, at 3:56 PM, Adrian Crum <ad...@sandglass-software.com> wrote:

> I don't like the idea of mixing scripts with Java source code. I understand it makes sense from the perspective that scripts and Java are both "source code", but the nice thing about keeping the Java source separate is it can be removed during deployment - reducing the project's footprint on the target server.

You could do the same by removing the src/main/java folders and by keeping the src/main/minilang/ ones.

Jacopo

> 
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
> 
> On 1/21/2015 12:36 AM, Jacopo Cappellato wrote:
>> 
>> On Jan 20, 2015, at 4:29 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>> 
>>> I suggested a Maven-like folder structure years ago, and there was pushback from Adam. He was concerned that test classes would reside in the same package as the classes being tested - which would expose their implementation.
>> 
>> This is a non problem: even if we split the main and test classes using the src/main and src/test folders we are still free to place them in the packages we like.
>> 
>>> 
>>> The classpath under the script folder is not necessary. That was used before we had FlexibleLocation and the "component://" URL feature. So, instead of your suggestion we could do:
>>> 
>>> script/groovy/FooScript_1.groovy
>>> script/groovy/FooScript_2.groovy
>>> script/minilang/BarScript_1.xml
>>> script/minilang/BarScript_2.xml
>>> script/js/BazScript_1.js
>> 
>> +1 on the idea of getting rid of the "classpaths" for Minilang as a general direction; I still think they should go under src/minilang but at this point this is just a matter of personal taste.
>> As regards Groovy, with it you can implement classes and not just scripts and having the ability to define the packages will be very useful especially when we will have more services implemented in Groovy.
>> Again, I think they should go into src/main/groovy or src/test/groovy.
>> 
>>> 
>>> (Yes, the Service Engine supports JavaScript.)
>>> 
>>> To use FooScript_1.groovy you can use two methods:
>>> 
>>> 1. The  "component://" URL feature:
>>> 
>>> component://mycomponent/script/groovy/FooScript_1.groovy
>>> 
>>> 2. The classpath:
>>> 
>>> groovy/FooScript_1.groovy
>>> 
>>> Option 2 could have problems with name clash, so I have always preferred option 1.
>>> 
>>> While we are having this discussion, we could also consider changing the package naming from
>>> 
>>> org.ofbiz.*
>>> 
>>> to
>>> 
>>> org.apache.ofbiz.*
>> 
>> +1!!!
>> 
>> Jacopo
>> 
>>> 
>>> 
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>> 
>>> On 1/20/2015 3:41 AM, Jacopo Cappellato wrote:
>>>> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:
>>>> 
>>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>>> 
>>>> More specifically I would like to switch from, for example:
>>>> 
>>>> script/org/ofbiz/product/
>>>> src/org/ofbiz/product/
>>>> src/org/ofbiz/product/test/
>>>> 
>>>> to:
>>>> 
>>>> src/main/java/org/ofbiz/product/
>>>> src/main/minilang/org/ofbiz/product/
>>>> src/main/groovy/...
>>>> src/test/java/org/ofbiz/product/
>>>> 
>>>> What do you think?
>>>> 
>>>> Jacopo
>>>> 
>> 

Re: Proposal: redefining the components' directory layout for source files

[Adrian Crum <ad...@sandglass-software.com>]

I don't like the idea of mixing scripts with Java source code. I 
understand it makes sense from the perspective that scripts and Java are 
both "source code", but the nice thing about keeping the Java source 
separate is it can be removed during deployment - reducing the project's 
footprint on the target server.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 1/21/2015 12:36 AM, Jacopo Cappellato wrote:
>
> On Jan 20, 2015, at 4:29 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>
>> I suggested a Maven-like folder structure years ago, and there was pushback from Adam. He was concerned that test classes would reside in the same package as the classes being tested - which would expose their implementation.
>
> This is a non problem: even if we split the main and test classes using the src/main and src/test folders we are still free to place them in the packages we like.
>
>>
>> The classpath under the script folder is not necessary. That was used before we had FlexibleLocation and the "component://" URL feature. So, instead of your suggestion we could do:
>>
>> script/groovy/FooScript_1.groovy
>> script/groovy/FooScript_2.groovy
>> script/minilang/BarScript_1.xml
>> script/minilang/BarScript_2.xml
>> script/js/BazScript_1.js
>
> +1 on the idea of getting rid of the "classpaths" for Minilang as a general direction; I still think they should go under src/minilang but at this point this is just a matter of personal taste.
> As regards Groovy, with it you can implement classes and not just scripts and having the ability to define the packages will be very useful especially when we will have more services implemented in Groovy.
> Again, I think they should go into src/main/groovy or src/test/groovy.
>
>>
>> (Yes, the Service Engine supports JavaScript.)
>>
>> To use FooScript_1.groovy you can use two methods:
>>
>> 1. The  "component://" URL feature:
>>
>> component://mycomponent/script/groovy/FooScript_1.groovy
>>
>> 2. The classpath:
>>
>> groovy/FooScript_1.groovy
>>
>> Option 2 could have problems with name clash, so I have always preferred option 1.
>>
>> While we are having this discussion, we could also consider changing the package naming from
>>
>> org.ofbiz.*
>>
>> to
>>
>> org.apache.ofbiz.*
>
> +1!!!
>
> Jacopo
>
>>
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 1/20/2015 3:41 AM, Jacopo Cappellato wrote:
>>> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:
>>>
>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>>
>>> More specifically I would like to switch from, for example:
>>>
>>> script/org/ofbiz/product/
>>> src/org/ofbiz/product/
>>> src/org/ofbiz/product/test/
>>>
>>> to:
>>>
>>> src/main/java/org/ofbiz/product/
>>> src/main/minilang/org/ofbiz/product/
>>> src/main/groovy/...
>>> src/test/java/org/ofbiz/product/
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>
>

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Jan 20, 2015, at 4:29 PM, Adrian Crum <ad...@sandglass-software.com> wrote:

> I suggested a Maven-like folder structure years ago, and there was pushback from Adam. He was concerned that test classes would reside in the same package as the classes being tested - which would expose their implementation.

This is a non problem: even if we split the main and test classes using the src/main and src/test folders we are still free to place them in the packages we like.

> 
> The classpath under the script folder is not necessary. That was used before we had FlexibleLocation and the "component://" URL feature. So, instead of your suggestion we could do:
> 
> script/groovy/FooScript_1.groovy
> script/groovy/FooScript_2.groovy
> script/minilang/BarScript_1.xml
> script/minilang/BarScript_2.xml
> script/js/BazScript_1.js

+1 on the idea of getting rid of the "classpaths" for Minilang as a general direction; I still think they should go under src/minilang but at this point this is just a matter of personal taste.
As regards Groovy, with it you can implement classes and not just scripts and having the ability to define the packages will be very useful especially when we will have more services implemented in Groovy.
Again, I think they should go into src/main/groovy or src/test/groovy.

> 
> (Yes, the Service Engine supports JavaScript.)
> 
> To use FooScript_1.groovy you can use two methods:
> 
> 1. The  "component://" URL feature:
> 
> component://mycomponent/script/groovy/FooScript_1.groovy
> 
> 2. The classpath:
> 
> groovy/FooScript_1.groovy
> 
> Option 2 could have problems with name clash, so I have always preferred option 1.
> 
> While we are having this discussion, we could also consider changing the package naming from
> 
> org.ofbiz.*
> 
> to
> 
> org.apache.ofbiz.*

+1!!!

Jacopo

> 
> 
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
> 
> On 1/20/2015 3:41 AM, Jacopo Cappellato wrote:
>> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:
>> 
>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>> 
>> More specifically I would like to switch from, for example:
>> 
>> script/org/ofbiz/product/
>> src/org/ofbiz/product/
>> src/org/ofbiz/product/test/
>> 
>> to:
>> 
>> src/main/java/org/ofbiz/product/
>> src/main/minilang/org/ofbiz/product/
>> src/main/groovy/...
>> src/test/java/org/ofbiz/product/
>> 
>> What do you think?
>> 
>> Jacopo
>> 

Re: Proposal: redefining the components' directory layout for source files

[Adrian Crum <ad...@sandglass-software.com>]

I suggested a Maven-like folder structure years ago, and there was 
pushback from Adam. He was concerned that test classes would reside in 
the same package as the classes being tested - which would expose their 
implementation.

The classpath under the script folder is not necessary. That was used 
before we had FlexibleLocation and the "component://" URL feature. So, 
instead of your suggestion we could do:

script/groovy/FooScript_1.groovy
script/groovy/FooScript_2.groovy
script/minilang/BarScript_1.xml
script/minilang/BarScript_2.xml
script/js/BazScript_1.js

(Yes, the Service Engine supports JavaScript.)

To use FooScript_1.groovy you can use two methods:

1. The  "component://" URL feature:

component://mycomponent/script/groovy/FooScript_1.groovy

2. The classpath:

groovy/FooScript_1.groovy

Option 2 could have problems with name clash, so I have always preferred 
option 1.

While we are having this discussion, we could also consider changing the 
package naming from

org.ofbiz.*

to

org.apache.ofbiz.*


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 1/20/2015 3:41 AM, Jacopo Cappellato wrote:
> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:
>
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>
> More specifically I would like to switch from, for example:
>
> script/org/ofbiz/product/
> src/org/ofbiz/product/
> src/org/ofbiz/product/test/
>
> to:
>
> src/main/java/org/ofbiz/product/
> src/main/minilang/org/ofbiz/product/
> src/main/groovy/...
> src/test/java/org/ofbiz/product/
>
> What do you think?
>
> Jacopo
>

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

So what are the advantages vs drawbacks? Who can clearly tell us that?

Jacques

Le 21/01/2015 02:13, Adrian Crum a écrit :
> I disagree. This is an open source software project where decisions should be made based on good design principles. The work is being done by 
> volunteers, so I don't see how "cost/benefit" applies.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/20/2015 5:04 PM, Hans Bakker wrote:
>> Jacopo,
>>
>> 'nice' is not enough reason to change the directory structure.....
>> Please this is a business application where decisions should be taken
>> based on cost/benefit.
>>
>> Regards, Hans
>>
>> On 20/01/15 18:41, Jacopo Cappellato wrote:
>>> In my opinion it would be nice to review how we organize the code in
>>> our components and switch to a directory layout that is more inline
>>> with what other projects are doing, for example:
>>>
>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>>
>>>
>>> More specifically I would like to switch from, for example:
>>>
>>> script/org/ofbiz/product/
>>> src/org/ofbiz/product/
>>> src/org/ofbiz/product/test/
>>>
>>> to:
>>>
>>> src/main/java/org/ofbiz/product/
>>> src/main/minilang/org/ofbiz/product/
>>> src/main/groovy/...
>>> src/test/java/org/ofbiz/product/
>>>
>>> What do you think?
>>>
>>> Jacopo
>>
>

Re: Proposal: redefining the components' directory layout for source files

[Youssef Khaye <yo...@o-toit.com>]

Le 21/01/2015 02:13, Adrian Crum a écrit :
> I disagree. This is an open source software project where decisions 
> should be made based on good design principles. The work is being done 
> by volunteers, so I don't see how "cost/benefit" applies.
It is also a community driven project where decisions get debated, 
volunteers working for the project should take into consideration users 
point of view.

If a such modification has advantages for the community, it may also 
have some drawbacks.
"cost/benefit" should be interpreted as " pros and cons" and should be 
always apply.

So it is good to have such proposal , debate theme but it will better to 
have a kind of road map and plan the changes for future.

Sometime, some volunteers decide to make some important changes and 
commit theme without a pre-discussions, without jira and that is a not 
the good way to manage the project.
Thank you all for the work you provide, the commitment etc..

Youssef Khaye
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/20/2015 5:04 PM, Hans Bakker wrote:
>> Jacopo,
>>
>> 'nice' is not enough reason to change the directory structure.....
>> Please this is a business application where decisions should be taken
>> based on cost/benefit.
>>
>> Regards, Hans
>>
>> On 20/01/15 18:41, Jacopo Cappellato wrote:
>>> In my opinion it would be nice to review how we organize the code in
>>> our components and switch to a directory layout that is more inline
>>> with what other projects are doing, for example:
>>>
>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html 
>>>
>>>
>>>
>>> More specifically I would like to switch from, for example:
>>>
>>> script/org/ofbiz/product/
>>> src/org/ofbiz/product/
>>> src/org/ofbiz/product/test/
>>>
>>> to:
>>>
>>> src/main/java/org/ofbiz/product/
>>> src/main/minilang/org/ofbiz/product/
>>> src/main/groovy/...
>>> src/test/java/org/ofbiz/product/
>>>
>>> What do you think?
>>>
>>> Jacopo
>>

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

I agree about those benefits (even if they are weak) but I'd like to have the drawbacks measured better.
Doing an easy things does not mean it has no implications, see when we decided to remove the specialpurpose from R13

Jacques

Le 21/01/2015 02:32, Ron Wheeler a écrit :
> It will make the project look more professional which has some benefit in reviews by IT departments of potential adopters or by technical reviewers 
> for blogs or journals.
>
> I am not sure if this can be quantified but it is a benefit.
>
> The cost seems pretty low since it should only affect the build and the docs.
>
> Ron
>
>
>
> On 20/01/2015 8:13 PM, Adrian Crum wrote:
>> I disagree. This is an open source software project where decisions should be made based on good design principles. The work is being done by 
>> volunteers, so I don't see how "cost/benefit" applies.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 1/20/2015 5:04 PM, Hans Bakker wrote:
>>> Jacopo,
>>>
>>> 'nice' is not enough reason to change the directory structure.....
>>> Please this is a business application where decisions should be taken
>>> based on cost/benefit.
>>>
>>> Regards, Hans
>>>
>>> On 20/01/15 18:41, Jacopo Cappellato wrote:
>>>> In my opinion it would be nice to review how we organize the code in
>>>> our components and switch to a directory layout that is more inline
>>>> with what other projects are doing, for example:
>>>>
>>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>>>
>>>>
>>>> More specifically I would like to switch from, for example:
>>>>
>>>> script/org/ofbiz/product/
>>>> src/org/ofbiz/product/
>>>> src/org/ofbiz/product/test/
>>>>
>>>> to:
>>>>
>>>> src/main/java/org/ofbiz/product/
>>>> src/main/minilang/org/ofbiz/product/
>>>> src/main/groovy/...
>>>> src/test/java/org/ofbiz/product/
>>>>
>>>> What do you think?
>>>>
>>>> Jacopo
>>>
>>
>
>

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler <rw...@artifact-software.com>]

It will make the project look more professional which has some benefit 
in reviews by IT departments of potential adopters or by technical 
reviewers for blogs or journals.

I am not sure if this can be quantified but it is a benefit.

The cost seems pretty low since it should only affect the build and the 
docs.

Ron



On 20/01/2015 8:13 PM, Adrian Crum wrote:
> I disagree. This is an open source software project where decisions 
> should be made based on good design principles. The work is being done 
> by volunteers, so I don't see how "cost/benefit" applies.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/20/2015 5:04 PM, Hans Bakker wrote:
>> Jacopo,
>>
>> 'nice' is not enough reason to change the directory structure.....
>> Please this is a business application where decisions should be taken
>> based on cost/benefit.
>>
>> Regards, Hans
>>
>> On 20/01/15 18:41, Jacopo Cappellato wrote:
>>> In my opinion it would be nice to review how we organize the code in
>>> our components and switch to a directory layout that is more inline
>>> with what other projects are doing, for example:
>>>
>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html 
>>>
>>>
>>>
>>> More specifically I would like to switch from, for example:
>>>
>>> script/org/ofbiz/product/
>>> src/org/ofbiz/product/
>>> src/org/ofbiz/product/test/
>>>
>>> to:
>>>
>>> src/main/java/org/ofbiz/product/
>>> src/main/minilang/org/ofbiz/product/
>>> src/main/groovy/...
>>> src/test/java/org/ofbiz/product/
>>>
>>> What do you think?
>>>
>>> Jacopo
>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files

[Adrian Crum <ad...@sandglass-software.com>]

I disagree. This is an open source software project where decisions 
should be made based on good design principles. The work is being done 
by volunteers, so I don't see how "cost/benefit" applies.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 1/20/2015 5:04 PM, Hans Bakker wrote:
> Jacopo,
>
> 'nice' is not enough reason to change the directory structure.....
> Please this is a business application where decisions should be taken
> based on cost/benefit.
>
> Regards, Hans
>
> On 20/01/15 18:41, Jacopo Cappellato wrote:
>> In my opinion it would be nice to review how we organize the code in
>> our components and switch to a directory layout that is more inline
>> with what other projects are doing, for example:
>>
>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>
>>
>> More specifically I would like to switch from, for example:
>>
>> script/org/ofbiz/product/
>> src/org/ofbiz/product/
>> src/org/ofbiz/product/test/
>>
>> to:
>>
>> src/main/java/org/ofbiz/product/
>> src/main/minilang/org/ofbiz/product/
>> src/main/groovy/...
>> src/test/java/org/ofbiz/product/
>>
>> What do you think?
>>
>> Jacopo
>

Re: Proposal: redefining the components' directory layout for source files

[Hans Bakker <ma...@antwebsystems.com>]

Jacopo,

'nice' is not enough reason to change the directory structure.....
Please this is a business application where decisions should be taken 
based on cost/benefit.

Regards, Hans

On 20/01/15 18:41, Jacopo Cappellato wrote:
> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:
>
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>
> More specifically I would like to switch from, for example:
>
> script/org/ofbiz/product/
> src/org/ofbiz/product/
> src/org/ofbiz/product/test/
>
> to:
>
> src/main/java/org/ofbiz/product/
> src/main/minilang/org/ofbiz/product/
> src/main/groovy/...
> src/test/java/org/ofbiz/product/
>
> What do you think?
>
> Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler <rw...@artifact-software.com>]

Good step forward.

Ron

On 20/01/2015 6:41 AM, Jacopo Cappellato wrote:
> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:
>
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>
> More specifically I would like to switch from, for example:
>
> script/org/ofbiz/product/
> src/org/ofbiz/product/
> src/org/ofbiz/product/test/
>
> to:
>
> src/main/java/org/ofbiz/product/
> src/main/minilang/org/ofbiz/product/
> src/main/groovy/...
> src/test/java/org/ofbiz/product/
>
> What do you think?
>
> Jacopo


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files

[Pierre Smits <pi...@gmail.com>]

Quoting:

We will not change your custom projects :-)


On top of that, with proper notification you can plan to address the
migration aspects to your wishes.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Tue, Apr 28, 2015 at 11:07 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:

> On Apr 28, 2015, at 10:52 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
> > In custom projects I like to use simple-methods events...
>
> We will not change your custom projects :-)
>
> Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

On Apr 28, 2015, at 10:52 AM, Jacques Le Roux <ja...@les7arts.com> wrote:

> In custom projects I like to use simple-methods events...

We will not change your custom projects :-)

Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 28/04/2015 10:27, Jacopo Cappellato a écrit :
> On Apr 28, 2015, at 10:16 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> So you would like to suppress the concept of event?
> Most of the events are currently implemented in Java and are already under src folder.
>
> Jacopo
>

In custom projects I like to use simple-methods events...

Jacques

Re: Proposal: redefining the components' directory layout for source files

[Adam Heath <do...@brainfood.com>]

On 04/28/2015 03:27 AM, Jacopo Cappellato wrote:
> On Apr 28, 2015, at 10:16 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> So you would like to suppress the concept of event?
> Most of the events are currently implemented in Java and are already under src folder.

Not what I mean.  The following method definition pattern is the problem:

==
public static String $methodName(HttpServletRequest request, 
HttpServletResponse response) {
   Integer pageNum = 
NumberParsingUtil.parseInt(request.getParameter("page"));
   ...
   // core logic starts here
   List<Map<String, Object>> searchDataResults = 
dispatcher.runSync("doSearch", context);
   Map<String, Object> parsedData = new HashMap<>();
   int largeSizeCount = 0, smallSizeCount = 0;
   for (Map<String, Object> data: searchDataResults) {
     if (data.size() > 10) largeSizeCount++;
     if (data.size() > 5) smallSizeCount++;
   }
   parsedData.put("largeSizeCount", largeSizeCount);
   parsedData.put("smallSizeCount", smallSizeCount);
   parsedData.put("totalCount", searchDataResults.size());
   parsedData.put("results", searchDataResults);
   ..
   request.setAttribute("search:parsedData", parsedData);
   return "success";
}
==

There are 3 things going on here.  The first part reads the incoming 
request data, fetching whatever it needs.  The second does some kind of 
business logic.  The third then places the results of that back into the 
request for later processing by further code.

The middle part needs to be extracted into a separate location that is 
callable through the service engine.

ps: this is pseudo code

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

On Apr 28, 2015, at 10:16 AM, Jacques Le Roux <ja...@les7arts.com> wrote:

> So you would like to suppress the concept of event?

Most of the events are currently implemented in Java and are already under src folder.

Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 28/04/2015 18:59, Jacques Le Roux a écrit :
> Le 28/04/2015 16:47, Adam Heath a écrit :
>>
>> On 04/28/2015 03:16 AM, Jacques Le Roux wrote:
>>> Le 24/04/2015 17:01, Adam Heath a écrit :
>>>>
>>>> On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
>>>>> On Apr 24, 2015, at 4:36 PM, Adam Heath <do...@brainfood.com> wrote:
>>>>>
>>>>>>>> src/main/java/org/ofbiz/product/
>>>>>>>> src/main/minilang/org/ofbiz/product/
>>>>>>>> src/main/groovy/...
>>>>>>>> src/test/java/org/ofbiz/product/
>>>>>> I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project.
>>>>> When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; 
>>>>> most of them could be used in non web applications.
>>>>
>>>> Hmm, right.  Good idea.  We(Brainfood) would love it if all the action code was turned into services.  But, even in that case, src/main/scripts 
>>>> would be used, as I think src/main/groovy is for groovyc.  I'll find out today if that is the case.
>>>>
>>>>
>>>
>>> So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and 
>>> the convenience of events in some cases?
>>> https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService 
>>>
>>>
>>
>> Way way way too much business logic is embedded and tied to events that *require* javax.servlet.  This makes it hard to use ofbiz soley as a 
>> backend api layer.
>>
>> Not all servlet code can be removed.  Aka, the aforementioned parameter validation/conversion logic.  However, all such input methods should just 
>> pass the munged data stream(s) to the service engine, for processing.  This includes the ShoppingCart code.
>>
>>
>>
> Following Hans's initiative in r1163084 I used MockHttpServletRequest/Response in services but I must agree it's more a (interesting) hack than an 
> architecture solution
>
> Jacques
>

To clarify this was to reuse events inside services, notably the ShoppingCart...

Jacques

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 28/04/2015 16:47, Adam Heath a écrit :
>
> On 04/28/2015 03:16 AM, Jacques Le Roux wrote:
>> Le 24/04/2015 17:01, Adam Heath a écrit :
>>>
>>> On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
>>>> On Apr 24, 2015, at 4:36 PM, Adam Heath <do...@brainfood.com> wrote:
>>>>
>>>>>>> src/main/java/org/ofbiz/product/
>>>>>>> src/main/minilang/org/ofbiz/product/
>>>>>>> src/main/groovy/...
>>>>>>> src/test/java/org/ofbiz/product/
>>>>> I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project.
>>>> When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; 
>>>> most of them could be used in non web applications.
>>>
>>> Hmm, right.  Good idea.  We(Brainfood) would love it if all the action code was turned into services.  But, even in that case, src/main/scripts 
>>> would be used, as I think src/main/groovy is for groovyc.  I'll find out today if that is the case.
>>>
>>>
>>
>> So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the 
>> convenience of events in some cases?
>> https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService 
>>
>>
>
> Way way way too much business logic is embedded and tied to events that *require* javax.servlet.  This makes it hard to use ofbiz soley as a backend 
> api layer.
>
> Not all servlet code can be removed.  Aka, the aforementioned parameter validation/conversion logic.  However, all such input methods should just 
> pass the munged data stream(s) to the service engine, for processing.  This includes the ShoppingCart code.
>
>
>
Following Hans's initiative in r1163084 I used MockHttpServletRequest/Response in services but I must agree it's more a (interesting) hack than an 
architecture solution

Jacques

Re: Proposal: redefining the components' directory layout for source files

[Adam Heath <do...@brainfood.com>]

On 04/28/2015 03:16 AM, Jacques Le Roux wrote:
> Le 24/04/2015 17:01, Adam Heath a écrit :
>>
>> On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
>>> On Apr 24, 2015, at 4:36 PM, Adam Heath <do...@brainfood.com> wrote:
>>>
>>>>>> src/main/java/org/ofbiz/product/
>>>>>> src/main/minilang/org/ofbiz/product/
>>>>>> src/main/groovy/...
>>>>>> src/test/java/org/ofbiz/product/
>>>> I haven't yet gotten to integrating a groovy compiler plugin, I see 
>>>> only one .groovy in framework/service/src, for the entire project.
>>> When I proposed this I was also thinking about to move the groovy 
>>> (data preparation) scripts that are currently under WEB-INF/actions 
>>> folders; most of them could be used in non web applications.
>>
>> Hmm, right.  Good idea.  We(Brainfood) would love it if all the 
>> action code was turned into services.  But, even in that case, 
>> src/main/scripts would be used, as I think src/main/groovy is for 
>> groovyc.  I'll find out today if that is the case.
>>
>>
>
> So you would like to suppress the concept of event? What about the 
> validation and conversion with the map-processor (only in 
> simple-method) and the convenience of events in some cases?
> https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService 
>
>

Way way way too much business logic is embedded and tied to events that 
*require* javax.servlet.  This makes it hard to use ofbiz soley as a 
backend api layer.

Not all servlet code can be removed.  Aka, the aforementioned parameter 
validation/conversion logic.  However, all such input methods should 
just pass the munged data stream(s) to the service engine, for 
processing.  This includes the ShoppingCart code.

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 24/04/2015 17:01, Adam Heath a écrit :
>
> On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
>> On Apr 24, 2015, at 4:36 PM, Adam Heath <do...@brainfood.com> wrote:
>>
>>>>> src/main/java/org/ofbiz/product/
>>>>> src/main/minilang/org/ofbiz/product/
>>>>> src/main/groovy/...
>>>>> src/test/java/org/ofbiz/product/
>>> I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project.
>> When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; most 
>> of them could be used in non web applications.
>
> Hmm, right.  Good idea.  We(Brainfood) would love it if all the action code was turned into services.  But, even in that case, src/main/scripts 
> would be used, as I think src/main/groovy is for groovyc.  I'll find out today if that is the case.
>
>

So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the 
convenience of events in some cases?
https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService

Jacques

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

+1

Jacques

Le 25/04/2015 12:39, Jacopo Cappellato a écrit :
> Adrian, Pierre,
>
> this is exactly what I meant.
>
> Jacopo
>
> On Apr 25, 2015, at 11:36 AM, Pierre Smits <pi...@gmail.com> wrote:
>
>> Migration plans help to ensure that external issues are addressed. It also
>> helps to pick future release branch that will have these major changes, say
>> r15 or 16 and plan/work towards having everything in place for that.
>>
>> I suggest we start working on getting the JIRA side first, before the
>> creating the release branch so that we can get all issues identified and we
>> don't get confronted with things overlooked.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Sat, Apr 25, 2015 at 11:24 AM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>
>>> On Apr 25, 2015, at 10:39 AM, Pierre Smits <pi...@gmail.com> wrote:
>>>
>>>> I can imagine that some will vote a -1 regarding this reorganisation of
>>> the
>>>> structure, as this will break backward compatibility and puts the
>>> pressure
>>>> on all those users who have created extensions and replacements
>>> Same here, and I really hope that people will not oppose to new ideas
>>> because of the concerns on backward incompatibilities or impact on existing
>>> investments.
>>> The OFBiz codebase needs to evolve into the future and this cannot be done
>>> if every new ideas gets a pushback because of impacts on other systems or
>>> user base: I see this trend happening lately and I think it is not wise.
>>>
>>> I am not saying that backward compatibility, stability and migration plans
>>> are not important factors: but I think they should not influence new ideas;
>>> only after a new ideas is considered valid for OFBiz, we should then focus
>>> on how to implement a roadmap to alleviate the pains of external codebases
>>> or users.
>>>
>>> We could create a stable release branch right before we start working to
>>> incompatible changes etc... but we should discuss what to do only after we
>>> have decided about the future.
>>>
>>> Jacopo
>
>

Re: Proposal: redefining the components' directory layout for source files

[Darrell Donati <da...@gmail.com>]

+1

I agree that while backward-compatibility is an important factor to
consider, it should not be the sole reason for halting an evolutionary
effort such as this. 

Following along with what Adrian has already said, whether it is this
proposal or some other effort where there has been a potential for user
impact, I feel that as long as any "gotchas" are expressed with such a
release, the users' expectations will be able to be set appropriately.



--
View this message in context: http://ofbiz.135035.n4.nabble.com/Proposal-redefining-the-components-directory-layout-for-source-files-tp4662062p4667483.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler <rw...@artifact-software.com>]

Has anyone actually made any findings regarding the file 
reorganization's impact on the ability to support previous releases.

I did not see any mention of changes to class names (other than fixing 
the organization name org.ofbiz to org.apache.ofbiz which seems to have 
been put on pause for now).
I gather that there is an impact on the build scripts and perhaps the 
organization of classes into jar files.

Is there anything else that people who have private forks need to evaluate.

Ron


On 25/04/2015 8:32 AM, Michael Brohl wrote:
> +1
>
> for the mentioned statements, especially planning, an announced branch 
> which is not backward compatible and a sensible look at users who 
> build their business on the OFBiz foundation without denying serious 
> changes just because of this fact.
>
> Maybe it is possible to provide some "migration tools" (scripts etc.) 
> to help automate the migration and make it less painless for the 
> users. At least a good documentation should be provided which should 
> be started during development to get every change and best practice 
> documented. Things often get lost when documenting later.
>
> It could be a must have for a patch for fundamental changes: no 
> documentation, no commit.
>
> Michael
> ecomify GmbH
> www.ecomify.de
>
> Am 25.04.15 um 12:39 schrieb Jacopo Cappellato:
>> Adrian, Pierre,
>>
>> this is exactly what I meant.
>>
>> Jacopo
>>
>> On Apr 25, 2015, at 11:36 AM, Pierre Smits <pi...@gmail.com> 
>> wrote:
>>
>>> Migration plans help to ensure that external issues are addressed. 
>>> It also
>>> helps to pick future release branch that will have these major 
>>> changes, say
>>> r15 or 16 and plan/work towards having everything in place for that.
>>>
>>> I suggest we start working on getting the JIRA side first, before the
>>> creating the release branch so that we can get all issues identified 
>>> and we
>>> don't get confronted with things overlooked.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Sat, Apr 25, 2015 at 11:24 AM, Jacopo Cappellato <
>>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>>
>>>> On Apr 25, 2015, at 10:39 AM, Pierre Smits <pi...@gmail.com> 
>>>> wrote:
>>>>
>>>>> I can imagine that some will vote a -1 regarding this 
>>>>> reorganisation of
>>>> the
>>>>> structure, as this will break backward compatibility and puts the
>>>> pressure
>>>>> on all those users who have created extensions and replacements
>>>> Same here, and I really hope that people will not oppose to new ideas
>>>> because of the concerns on backward incompatibilities or impact on 
>>>> existing
>>>> investments.
>>>> The OFBiz codebase needs to evolve into the future and this cannot 
>>>> be done
>>>> if every new ideas gets a pushback because of impacts on other 
>>>> systems or
>>>> user base: I see this trend happening lately and I think it is not 
>>>> wise.
>>>>
>>>> I am not saying that backward compatibility, stability and 
>>>> migration plans
>>>> are not important factors: but I think they should not influence 
>>>> new ideas;
>>>> only after a new ideas is considered valid for OFBiz, we should 
>>>> then focus
>>>> on how to implement a roadmap to alleviate the pains of external 
>>>> codebases
>>>> or users.
>>>>
>>>> We could create a stable release branch right before we start 
>>>> working to
>>>> incompatible changes etc... but we should discuss what to do only 
>>>> after we
>>>> have decided about the future.
>>>>
>>>> Jacopo
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 25/04/2015 14:32, Michael Brohl a écrit :
> +1
>
> for the mentioned statements, especially planning, an announced branch which is not backward compatible and a sensible look at users who build their 
> business on the OFBiz foundation without denying serious changes just because of this fact.
>
> Maybe it is possible to provide some "migration tools" (scripts etc.) to help automate the migration and make it less painless for the users. At 
> least a good documentation should be provided which should be started during development to get every change and best practice documented. Things 
> often get lost when documenting later.
>
> It could be a must have for a patch for fundamental changes: no documentation, no commit.

Indeed a bit like TDD. What Adam is doing with Git rebase and separated commit is heading in the right direction but we need also complete external 
documentation (wiki > commits log)

Jacques

>
> Michael
> ecomify GmbH
> www.ecomify.de
>
> Am 25.04.15 um 12:39 schrieb Jacopo Cappellato:
>> Adrian, Pierre,
>>
>> this is exactly what I meant.
>>
>> Jacopo
>>
>> On Apr 25, 2015, at 11:36 AM, Pierre Smits <pi...@gmail.com> wrote:
>>
>>> Migration plans help to ensure that external issues are addressed. It also
>>> helps to pick future release branch that will have these major changes, say
>>> r15 or 16 and plan/work towards having everything in place for that.
>>>
>>> I suggest we start working on getting the JIRA side first, before the
>>> creating the release branch so that we can get all issues identified and we
>>> don't get confronted with things overlooked.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Sat, Apr 25, 2015 at 11:24 AM, Jacopo Cappellato <
>>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>>
>>>> On Apr 25, 2015, at 10:39 AM, Pierre Smits <pi...@gmail.com> wrote:
>>>>
>>>>> I can imagine that some will vote a -1 regarding this reorganisation of
>>>> the
>>>>> structure, as this will break backward compatibility and puts the
>>>> pressure
>>>>> on all those users who have created extensions and replacements
>>>> Same here, and I really hope that people will not oppose to new ideas
>>>> because of the concerns on backward incompatibilities or impact on existing
>>>> investments.
>>>> The OFBiz codebase needs to evolve into the future and this cannot be done
>>>> if every new ideas gets a pushback because of impacts on other systems or
>>>> user base: I see this trend happening lately and I think it is not wise.
>>>>
>>>> I am not saying that backward compatibility, stability and migration plans
>>>> are not important factors: but I think they should not influence new ideas;
>>>> only after a new ideas is considered valid for OFBiz, we should then focus
>>>> on how to implement a roadmap to alleviate the pains of external codebases
>>>> or users.
>>>>
>>>> We could create a stable release branch right before we start working to
>>>> incompatible changes etc... but we should discuss what to do only after we
>>>> have decided about the future.
>>>>
>>>> Jacopo
>
>

Re: Proposal: redefining the components' directory layout for source files

[Michael Brohl <mi...@ecomify.de>]

+1

for the mentioned statements, especially planning, an announced branch 
which is not backward compatible and a sensible look at users who build 
their business on the OFBiz foundation without denying serious changes 
just because of this fact.

Maybe it is possible to provide some "migration tools" (scripts etc.) to 
help automate the migration and make it less painless for the users. At 
least a good documentation should be provided which should be started 
during development to get every change and best practice documented. 
Things often get lost when documenting later.

It could be a must have for a patch for fundamental changes: no 
documentation, no commit.

Michael
ecomify GmbH
www.ecomify.de

Am 25.04.15 um 12:39 schrieb Jacopo Cappellato:
> Adrian, Pierre,
>
> this is exactly what I meant.
>
> Jacopo
>
> On Apr 25, 2015, at 11:36 AM, Pierre Smits <pi...@gmail.com> wrote:
>
>> Migration plans help to ensure that external issues are addressed. It also
>> helps to pick future release branch that will have these major changes, say
>> r15 or 16 and plan/work towards having everything in place for that.
>>
>> I suggest we start working on getting the JIRA side first, before the
>> creating the release branch so that we can get all issues identified and we
>> don't get confronted with things overlooked.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Sat, Apr 25, 2015 at 11:24 AM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>
>>> On Apr 25, 2015, at 10:39 AM, Pierre Smits <pi...@gmail.com> wrote:
>>>
>>>> I can imagine that some will vote a -1 regarding this reorganisation of
>>> the
>>>> structure, as this will break backward compatibility and puts the
>>> pressure
>>>> on all those users who have created extensions and replacements
>>> Same here, and I really hope that people will not oppose to new ideas
>>> because of the concerns on backward incompatibilities or impact on existing
>>> investments.
>>> The OFBiz codebase needs to evolve into the future and this cannot be done
>>> if every new ideas gets a pushback because of impacts on other systems or
>>> user base: I see this trend happening lately and I think it is not wise.
>>>
>>> I am not saying that backward compatibility, stability and migration plans
>>> are not important factors: but I think they should not influence new ideas;
>>> only after a new ideas is considered valid for OFBiz, we should then focus
>>> on how to implement a roadmap to alleviate the pains of external codebases
>>> or users.
>>>
>>> We could create a stable release branch right before we start working to
>>> incompatible changes etc... but we should discuss what to do only after we
>>> have decided about the future.
>>>
>>> Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Darrell Donati <da...@gmail.com>]

+1

I agree that while backward-compatibility is an important factor to
consider, it should not be the sole reason for halting an evolutionary
effort such as this. 

Following along with what Adrian has already said, whether it is this
proposal or some other effort where there is a potential for user impact, I
feel that as long as any "gotchas" are expressed with such a release, the
users' expectations will be able to be set appropriately.



--
View this message in context: http://ofbiz.135035.n4.nabble.com/Proposal-redefining-the-components-directory-layout-for-source-files-tp4662062p4667482.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

Adrian, Pierre,

this is exactly what I meant.

Jacopo

On Apr 25, 2015, at 11:36 AM, Pierre Smits <pi...@gmail.com> wrote:

> Migration plans help to ensure that external issues are addressed. It also
> helps to pick future release branch that will have these major changes, say
> r15 or 16 and plan/work towards having everything in place for that.
> 
> I suggest we start working on getting the JIRA side first, before the
> creating the release branch so that we can get all issues identified and we
> don't get confronted with things overlooked.
> 
> Best regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> On Sat, Apr 25, 2015 at 11:24 AM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxsystems.com> wrote:
> 
>> On Apr 25, 2015, at 10:39 AM, Pierre Smits <pi...@gmail.com> wrote:
>> 
>>> I can imagine that some will vote a -1 regarding this reorganisation of
>> the
>>> structure, as this will break backward compatibility and puts the
>> pressure
>>> on all those users who have created extensions and replacements
>> 
>> Same here, and I really hope that people will not oppose to new ideas
>> because of the concerns on backward incompatibilities or impact on existing
>> investments.
>> The OFBiz codebase needs to evolve into the future and this cannot be done
>> if every new ideas gets a pushback because of impacts on other systems or
>> user base: I see this trend happening lately and I think it is not wise.
>> 
>> I am not saying that backward compatibility, stability and migration plans
>> are not important factors: but I think they should not influence new ideas;
>> only after a new ideas is considered valid for OFBiz, we should then focus
>> on how to implement a roadmap to alleviate the pains of external codebases
>> or users.
>> 
>> We could create a stable release branch right before we start working to
>> incompatible changes etc... but we should discuss what to do only after we
>> have decided about the future.
>> 
>> Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Pierre Smits <pi...@gmail.com>]

Migration plans help to ensure that external issues are addressed. It also
helps to pick future release branch that will have these major changes, say
r15 or 16 and plan/work towards having everything in place for that.

I suggest we start working on getting the JIRA side first, before the
creating the release branch so that we can get all issues identified and we
don't get confronted with things overlooked.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Apr 25, 2015 at 11:24 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:

> On Apr 25, 2015, at 10:39 AM, Pierre Smits <pi...@gmail.com> wrote:
>
> > I can imagine that some will vote a -1 regarding this reorganisation of
> the
> > structure, as this will break backward compatibility and puts the
> pressure
> > on all those users who have created extensions and replacements
>
> Same here, and I really hope that people will not oppose to new ideas
> because of the concerns on backward incompatibilities or impact on existing
> investments.
> The OFBiz codebase needs to evolve into the future and this cannot be done
> if every new ideas gets a pushback because of impacts on other systems or
> user base: I see this trend happening lately and I think it is not wise.
>
> I am not saying that backward compatibility, stability and migration plans
> are not important factors: but I think they should not influence new ideas;
> only after a new ideas is considered valid for OFBiz, we should then focus
> on how to implement a roadmap to alleviate the pains of external codebases
> or users.
>
> We could create a stable release branch right before we start working to
> incompatible changes etc... but we should discuss what to do only after we
> have decided about the future.
>
> Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Adrian Crum <ad...@sandglass-software.com>]

I would like to suggest again that the R15.x branch be labelled and 
advertised as a major rewrite that will not be backward compatible.

Let's do all of our major changes in one revision, and as Pierre 
suggested, include in that revision instructions on how to migrate from 
pre-R15 to post-R15.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/25/2015 10:24 AM, Jacopo Cappellato wrote:
> On Apr 25, 2015, at 10:39 AM, Pierre Smits <pi...@gmail.com> wrote:
>
>> I can imagine that some will vote a -1 regarding this reorganisation of the
>> structure, as this will break backward compatibility and puts the pressure
>> on all those users who have created extensions and replacements
>
> Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments.
> The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise.
>
> I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users.
>
> We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future.
>
> Jacopo
>

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

On Apr 25, 2015, at 10:39 AM, Pierre Smits <pi...@gmail.com> wrote:

> I can imagine that some will vote a -1 regarding this reorganisation of the
> structure, as this will break backward compatibility and puts the pressure
> on all those users who have created extensions and replacements

Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments.
The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise.

I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users.

We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future.

Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Pierre Smits <pi...@gmail.com>]

I can imagine that some will vote a -1 regarding this reorganisation of the
structure, as this will break backward compatibility and puts the pressure
on all those users who have created extensions and replacements (e.g. in
hot-deploy), especially regarding referenced scripts.

How do we ensure that the pain is minimised? How do we plan for success?

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Apr 25, 2015 at 9:45 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:

> On Apr 24, 2015, at 5:01 PM, Adam Heath <do...@brainfood.com> wrote:
>
> > On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
> >> On Apr 24, 2015, at 4:36 PM, Adam Heath <do...@brainfood.com> wrote:
> >>
> >>>>> src/main/java/org/ofbiz/product/
> >>>>> src/main/minilang/org/ofbiz/product/
> >>>>> src/main/groovy/...
> >>>>> src/test/java/org/ofbiz/product/
> >>> I haven't yet gotten to integrating a groovy compiler plugin, I see
> only one .groovy in framework/service/src, for the entire project.
> >> When I proposed this I was also thinking about to move the groovy (data
> preparation) scripts that are currently under WEB-INF/actions folders; most
> of them could be used in non web applications.
> >
> > Hmm, right.  Good idea.  We(Brainfood) would love it if all the action
> code was turned into services.  But, even in that case, src/main/scripts
> would be used, as I think src/main/groovy is for groovyc.  I'll find out
> today if that is the case.
>
> I like the idea of differentiating between pre-compiled vs parsed scripts
> using src/main/groovy vs src/main/scripts
>
> Just to re-state the motivations for my initial proposal I am quoting here
> them from a previous message in this thread (I apologize for the double
> posting but I my comments may have been lost in this long thread):
>
> > 1) standardize our layout structure to make it consistent with other
> projects (may make it easier for a new developer to understand OFBiz and
> appreciate it since the beginning)
> > 2) review of past decision in light of the experience, lessons learned
> and established conventions: most of the decision we took for the project
> were optimal at that time but may be suboptimal in light of new
> technologies, standards, trends etc... in order for our (more than 10 years
> old) project to stay fresh and healthy we have to always revisit our
> decisions and keep it young; when the first objection to proposals is that
> this could impact custom projects or existing contributors, then in my
> opinion it is a sign of defensive mentality that could bring to staleness;
> these concerns and considerations are still important, but should be
> discussed (trying to propose a good migration plan) at a later point and
> not used to slow down or stop the change
> > 3) simplify the pre compilation of Groovy (and possibly other) scripts:
> this could be done to spot coding errors in advance, to improve performance
> at runtime, or just to simplify the deployment
> > 4) simplify our build scripts: right now the ant scripts do some
> funny/complex stuff in order to separate test classes from main ones
> > 5) moving a step forward in the direction of allowing the adoption of
> Maven like tools (Maven, Gradle etc..) that could make it easier to share
> external components (grow the ecosystem)
> > 6) right now there is not a standard place for non-Java services or
> events: the script folder is traditionally used for Minilang, where should
> Groovy (or other languages) service implementation live?
> > 7) I have some, longer term, plans to make the OFBiz framework codebase
> more modular: several smaller jars with clear dependencies that could be
> deployed in different ways (vs the monolithic approach we have to follow
> now); a standardization of the source folders may help the adoption of
> tools and strategies for achieving this
>
> Regards,
>
> Jacopo
>

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

On Apr 24, 2015, at 5:01 PM, Adam Heath <do...@brainfood.com> wrote:

> On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
>> On Apr 24, 2015, at 4:36 PM, Adam Heath <do...@brainfood.com> wrote:
>> 
>>>>> src/main/java/org/ofbiz/product/
>>>>> src/main/minilang/org/ofbiz/product/
>>>>> src/main/groovy/...
>>>>> src/test/java/org/ofbiz/product/
>>> I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project.
>> When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; most of them could be used in non web applications.
> 
> Hmm, right.  Good idea.  We(Brainfood) would love it if all the action code was turned into services.  But, even in that case, src/main/scripts would be used, as I think src/main/groovy is for groovyc.  I'll find out today if that is the case.

I like the idea of differentiating between pre-compiled vs parsed scripts using src/main/groovy vs src/main/scripts

Just to re-state the motivations for my initial proposal I am quoting here them from a previous message in this thread (I apologize for the double posting but I my comments may have been lost in this long thread):

> 1) standardize our layout structure to make it consistent with other projects (may make it easier for a new developer to understand OFBiz and appreciate it since the beginning)
> 2) review of past decision in light of the experience, lessons learned and established conventions: most of the decision we took for the project were optimal at that time but may be suboptimal in light of new technologies, standards, trends etc... in order for our (more than 10 years old) project to stay fresh and healthy we have to always revisit our decisions and keep it young; when the first objection to proposals is that this could impact custom projects or existing contributors, then in my opinion it is a sign of defensive mentality that could bring to staleness; these concerns and considerations are still important, but should be discussed (trying to propose a good migration plan) at a later point and not used to slow down or stop the change
> 3) simplify the pre compilation of Groovy (and possibly other) scripts: this could be done to spot coding errors in advance, to improve performance at runtime, or just to simplify the deployment
> 4) simplify our build scripts: right now the ant scripts do some funny/complex stuff in order to separate test classes from main ones
> 5) moving a step forward in the direction of allowing the adoption of Maven like tools (Maven, Gradle etc..) that could make it easier to share external components (grow the ecosystem)
> 6) right now there is not a standard place for non-Java services or events: the script folder is traditionally used for Minilang, where should Groovy (or other languages) service implementation live?
> 7) I have some, longer term, plans to make the OFBiz framework codebase more modular: several smaller jars with clear dependencies that could be deployed in different ways (vs the monolithic approach we have to follow now); a standardization of the source folders may help the adoption of tools and strategies for achieving this

Regards,

Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Adam Heath <do...@brainfood.com>]

On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
> On Apr 24, 2015, at 4:36 PM, Adam Heath <do...@brainfood.com> wrote:
>
>>>> src/main/java/org/ofbiz/product/
>>>> src/main/minilang/org/ofbiz/product/
>>>> src/main/groovy/...
>>>> src/test/java/org/ofbiz/product/
>> I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project.
> When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; most of them could be used in non web applications.

Hmm, right.  Good idea.  We(Brainfood) would love it if all the action 
code was turned into services.  But, even in that case, src/main/scripts 
would be used, as I think src/main/groovy is for groovyc.  I'll find out 
today if that is the case.

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Interesting, it did not occur to me this was J2EE related

+1

Jacques

Le 24/04/2015 18:47, Adrian Crum a écrit :
> +1
>
> OFBiz stopped following J2EE patterns years ago, so we might as well make it official.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/24/2015 3:57 PM, Jacopo Cappellato wrote:
>> On Apr 24, 2015, at 4:36 PM, Adam Heath <do...@brainfood.com> wrote:
>>
>>>>> src/main/java/org/ofbiz/product/
>>>>> src/main/minilang/org/ofbiz/product/
>>>>> src/main/groovy/...
>>>>> src/test/java/org/ofbiz/product/
>>>
>>> I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project.
>>
>> When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; most 
>> of them could be used in non web applications.
>>
>> Jacopo
>>
>

Re: Proposal: redefining the components' directory layout for source files

[Adrian Crum <ad...@sandglass-software.com>]

+1

OFBiz stopped following J2EE patterns years ago, so we might as well 
make it official.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/24/2015 3:57 PM, Jacopo Cappellato wrote:
> On Apr 24, 2015, at 4:36 PM, Adam Heath <do...@brainfood.com> wrote:
>
>>>> src/main/java/org/ofbiz/product/
>>>> src/main/minilang/org/ofbiz/product/
>>>> src/main/groovy/...
>>>> src/test/java/org/ofbiz/product/
>>
>> I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project.
>
> When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; most of them could be used in non web applications.
>
> Jacopo
>

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

On Apr 24, 2015, at 4:36 PM, Adam Heath <do...@brainfood.com> wrote:

>>> src/main/java/org/ofbiz/product/
>>> src/main/minilang/org/ofbiz/product/
>>> src/main/groovy/...
>>> src/test/java/org/ofbiz/product/
> 
> I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project.

When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; most of them could be used in non web applications.

Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler <rw...@artifact-software.com>]

Still +1 !
Ron
On 24/04/2015 11:12 AM, Adam Heath wrote:
>
> On 04/24/2015 10:05 AM, Ron Wheeler wrote:
>> +1
>> Looks like Adam has the right approach.
>>
>
> Thanks.
>
> However, I'm thinking of adding a few steps.  See below.
>
>> Ron
>> On 24/04/2015 10:36 AM, Adam Heath wrote:
>>> +0.5 (see below, comment inline)
>>>
>>> Yes, I agree.  I even have a way forward, if you've been paying 
>>> attention to the maven branch(OFBIZ-6271).
>>>
>>> I have maven working with the *existing* layout in ofbiz. My plan 
>>> for migration has been this:
>>>
>>> * Get maven working with existing structure.  Ie, maven can compile 
>>> all the code, can create all the jars, basically, it can do 
>>> everything that the build.xml files do.  This is a little tricky, as 
>>> the top-level build.xml contains several custom targets; I'll 
>>> probably just use the antrun plugin for these.
>>>
>>> * Add top-level properties in ofbiz-parent.pom, that define all the 
>>> folders we might need to move; update ofbiz-component-pom.xml to use 
>>> these variables.
>>>
>
> * Add top-level properties in common.xml(and/or macros.xml), same as 
> maven/pom.
>
>>> * Switch each component one at a time, setting variables in the 
>>> local pom.xml(s) with the new location.  Each one of these should be 
>>> a separate commit.
>>>
>
> * Do this to each component's build.xml as well.  This change should 
> be part of the commit above.
>
>>> * Announce(!)
>>>
>>> * ??? Profit?
>>>
>>> ps: The standard maven test hooks do *not* run coverage against code 
>>> compiled by the test phase.  Aka, there is no way to know if 
>>> src/test/* is getting correct coverage.  I think I can fix this, as 
>>> we really should verify not only the baseline code, but the testing 
>>> code, for correctness.
>>>
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files

[Adam Heath <do...@brainfood.com>]

On 04/24/2015 10:05 AM, Ron Wheeler wrote:
> +1
> Looks like Adam has the right approach.
>

Thanks.

However, I'm thinking of adding a few steps.  See below.

> Ron
> On 24/04/2015 10:36 AM, Adam Heath wrote:
>> +0.5 (see below, comment inline)
>>
>> Yes, I agree.  I even have a way forward, if you've been paying 
>> attention to the maven branch(OFBIZ-6271).
>>
>> I have maven working with the *existing* layout in ofbiz. My plan for 
>> migration has been this:
>>
>> * Get maven working with existing structure.  Ie, maven can compile 
>> all the code, can create all the jars, basically, it can do 
>> everything that the build.xml files do.  This is a little tricky, as 
>> the top-level build.xml contains several custom targets; I'll 
>> probably just use the antrun plugin for these.
>>
>> * Add top-level properties in ofbiz-parent.pom, that define all the 
>> folders we might need to move; update ofbiz-component-pom.xml to use 
>> these variables.
>>

* Add top-level properties in common.xml(and/or macros.xml), same as 
maven/pom.

>> * Switch each component one at a time, setting variables in the local 
>> pom.xml(s) with the new location.  Each one of these should be a 
>> separate commit.
>>

* Do this to each component's build.xml as well.  This change should be 
part of the commit above.

>> * Announce(!)
>>
>> * ??? Profit?
>>
>> ps: The standard maven test hooks do *not* run coverage against code 
>> compiled by the test phase.  Aka, there is no way to know if 
>> src/test/* is getting correct coverage.  I think I can fix this, as 
>> we really should verify not only the baseline code, but the testing 
>> code, for correctness.
>>

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler <rw...@artifact-software.com>]

+1
Looks like Adam has the right approach.

Ron
On 24/04/2015 10:36 AM, Adam Heath wrote:
> +0.5 (see below, comment inline)
>
> Yes, I agree.  I even have a way forward, if you've been paying 
> attention to the maven branch(OFBIZ-6271).
>
> I have maven working with the *existing* layout in ofbiz. My plan for 
> migration has been this:
>
> * Get maven working with existing structure.  Ie, maven can compile 
> all the code, can create all the jars, basically, it can do everything 
> that the build.xml files do.  This is a little tricky, as the 
> top-level build.xml contains several custom targets; I'll probably 
> just use the antrun plugin for these.
>
> * Add top-level properties in ofbiz-parent.pom, that define all the 
> folders we might need to move; update ofbiz-component-pom.xml to use 
> these variables.
>
> * Switch each component one at a time, setting variables in the local 
> pom.xml(s) with the new location.  Each one of these should be a 
> separate commit.
>
> * Announce(!)
>
> * ??? Profit?
>
> ps: The standard maven test hooks do *not* run coverage against code 
> compiled by the test phase.  Aka, there is no way to know if 
> src/test/* is getting correct coverage.  I think I can fix this, as we 
> really should verify not only the baseline code, but the testing code, 
> for correctness.
>
> On 04/23/2015 10:42 PM, Scott Gray wrote:
>> +1
>>
>> Regards
>> Scott
>>
>> On 21 January 2015 at 00:41, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxmedia.com> wrote:
>>
>>> In my opinion it would be nice to review how we organize the code in 
>>> our
>>> components and switch to a directory layout that is more inline with 
>>> what
>>> other projects are doing, for example:
>>>
>>>
>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html 
>>>
>>>
>>> More specifically I would like to switch from, for example:
>>>
>>> script/org/ofbiz/product/
>>> src/org/ofbiz/product/
>>> src/org/ofbiz/product/test/
>>>
>>> to:
>>>
>>> src/main/java/org/ofbiz/product/
>>> src/main/minilang/org/ofbiz/product/
>>> src/main/groovy/...
>>> src/test/java/org/ofbiz/product/
>
> Altho, actually, I think this layout is because maven is stupid, and 
> the plugins and fileset api does not allow for different type files in 
> different folders.  Aka, the groovyc and javac hooks have a hard time 
> compiling .groovy and .java when they exist together in src/, so maven 
> authors decided to split them into src/*/groovy and src/*/java.
>
> I haven't yet gotten to integrating a groovy compiler plugin, I see 
> only one .groovy in framework/service/src, for the entire project.
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files

[Adam Heath <do...@brainfood.com>]

+0.5 (see below, comment inline)

Yes, I agree.  I even have a way forward, if you've been paying 
attention to the maven branch(OFBIZ-6271).

I have maven working with the *existing* layout in ofbiz. My plan for 
migration has been this:

* Get maven working with existing structure.  Ie, maven can compile all 
the code, can create all the jars, basically, it can do everything that 
the build.xml files do.  This is a little tricky, as the top-level 
build.xml contains several custom targets; I'll probably just use the 
antrun plugin for these.

* Add top-level properties in ofbiz-parent.pom, that define all the 
folders we might need to move; update ofbiz-component-pom.xml to use 
these variables.

* Switch each component one at a time, setting variables in the local 
pom.xml(s) with the new location.  Each one of these should be a 
separate commit.

* Announce(!)

* ??? Profit?

ps: The standard maven test hooks do *not* run coverage against code 
compiled by the test phase.  Aka, there is no way to know if src/test/* 
is getting correct coverage.  I think I can fix this, as we really 
should verify not only the baseline code, but the testing code, for 
correctness.

On 04/23/2015 10:42 PM, Scott Gray wrote:
> +1
>
> Regards
> Scott
>
> On 21 January 2015 at 00:41, Jacopo Cappellato <
> jacopo.cappellato@hotwaxmedia.com> wrote:
>
>> In my opinion it would be nice to review how we organize the code in our
>> components and switch to a directory layout that is more inline with what
>> other projects are doing, for example:
>>
>>
>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>
>> More specifically I would like to switch from, for example:
>>
>> script/org/ofbiz/product/
>> src/org/ofbiz/product/
>> src/org/ofbiz/product/test/
>>
>> to:
>>
>> src/main/java/org/ofbiz/product/
>> src/main/minilang/org/ofbiz/product/
>> src/main/groovy/...
>> src/test/java/org/ofbiz/product/

Altho, actually, I think this layout is because maven is stupid, and the 
plugins and fileset api does not allow for different type files in 
different folders.  Aka, the groovyc and javac hooks have a hard time 
compiling .groovy and .java when they exist together in src/, so maven 
authors decided to split them into src/*/groovy and src/*/java.

I haven't yet gotten to integrating a groovy compiler plugin, I see only 
one .groovy in framework/service/src, for the entire project.

Re: Proposal: redefining the components' directory layout for source files

[Adam Heath <do...@brainfood.com>]

On 04/28/2015 02:31 AM, Jacques Le Roux wrote:
> Le 27/04/2015 16:52, Adam Heath a écrit :
>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>> You can already compile components separately by using the specific 
>>> build files
>>
>> Yeah, I know, and it's a pain in my side.  I actually like being able 
>> to *compile* each component separately, by changing to that folder, 
>> and running ant.  I haven't yet been able to get maven to make that 
>> possible. 
>
> Yikes, that would be a Maven only solution (no Ant) blocker :/
>

If each component were released separately, then it becomes a non-problem.

I haven't yet given up on this, tho.

Re: Proposal: redefining the components' directory layout for source files

[Pierre Smits <pi...@gmail.com>]

And the reasoning behind that is quite simple: saving on storage and
bandwidth, thus cost.

Best regards,

Pierre

Op dinsdag 28 april 2015 heeft Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> het volgende geschreven:

> On Apr 28, 2015, at 6:45 PM, Jacques Le Roux <jacques.le.roux@les7arts.com
> <javascript:;>> wrote:
>
> > This is interesting, now I wonder if Jacopo still think the same than at
> https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664
>
> Recently I have read in some ASF thread that the ASF prefers that source
> releases do not contain binaries; in light of this I would not be against a
> change in this direction.
>
> Jacopo
>
>

-- 
Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

On Apr 28, 2015, at 6:45 PM, Jacques Le Roux <ja...@les7arts.com> wrote:

> This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664

Recently I have read in some ASF thread that the ASF prefers that source releases do not contain binaries; in light of this I would not be against a change in this direction.

Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler <rw...@artifact-software.com>]

I agree with you.
I have already committed to bilingualism in my development and system 
administration  processes.

Once we get through this discussion, I  might put out an argument for an 
installer like IzPack that can make deployment into different 
environments with the appropriate seed data loaded a bit less 
transparent and more user friendly.

Ron

On 28/04/2015 12:45 PM, Jacques Le Roux wrote:
>
> Le 28/04/2015 15:22, Ron Wheeler a écrit :
>> On 28/04/2015 3:31 AM, Jacques Le Roux wrote:
>>> Le 27/04/2015 16:52, Adam Heath a écrit :
>>>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>>>> You can already compile components separately by using the 
>>>>> specific build files
>>>>
>>>> Yeah, I know, and it's a pain in my side.  I actually like being 
>>>> able to *compile* each component separately, by changing to that 
>>>> folder, and running ant.  I haven't yet been able to get maven to 
>>>> make that possible. 
>>>
>>> Yikes, that would be a Maven only solution (no Ant) blocker :/
>>>
>>> Jacques
>>>
>>>
>> Why would Ant have trouble with a different project structure?
>
> No I meant if ever we would head to Maven only (no Ant build in the 
> project) then it would be a blocker.
>
>>
>> Ant is the ultimate in flexibility.
>>
>> The change will affect the existing Ant processes but I find it hard 
>> to imagine how it would prevent Ant from building OFBiz.
>> I would be tempted to look at providing alternative Ant builds.
>
> I'm undecided on this, but it seems redundant to me and duplicate to 
> maintain.
>
>>
>> It might be nice to have a simple final assemble with Ant that pulls 
>> jar files from Maven Central and uses these jars to build OFBiz
>> http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html 
>>
>
> This is interesting, now I wonder if Jacopo still think the same than 
> at 
> https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664
>
>>
>> Having Ant scripts that build individual components or groups of 
>> components should be pretty simple.
>
> That exists already
>
>>
>> It is also possible to deploy artifacts built with Ant to Maven Central.
>> http://central.sonatype.org/pages/apache-ant.html
>>
>>
>> I don't see Ant support as a difficult part of a move to Maven but if 
>> there is a real demand to support the use of Ant for 100% of the 
>> development tasks, it can be part of the move to Maven and any 
>> reorganization of the applications.
>>
>> This will require a high level of cooperation between the experts in 
>> the Ant build scripts and the experts promoting Maven.
>
> I think, if ever we go the Maven way, we will still need Ant around 
> and ready
>
> Jacques
>
>>
>> Ron
>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 28/04/2015 15:22, Ron Wheeler a écrit :
> On 28/04/2015 3:31 AM, Jacques Le Roux wrote:
>> Le 27/04/2015 16:52, Adam Heath a écrit :
>>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>>> You can already compile components separately by using the specific build files
>>>
>>> Yeah, I know, and it's a pain in my side.  I actually like being able to *compile* each component separately, by changing to that folder, and 
>>> running ant.  I haven't yet been able to get maven to make that possible. 
>>
>> Yikes, that would be a Maven only solution (no Ant) blocker :/
>>
>> Jacques
>>
>>
> Why would Ant have trouble with a different project structure?

No I meant if ever we would head to Maven only (no Ant build in the project) then it would be a blocker.

>
> Ant is the ultimate in flexibility.
>
> The change will affect the existing Ant processes but I find it hard to imagine how it would prevent Ant from building OFBiz.
> I would be tempted to look at providing alternative Ant builds.

I'm undecided on this, but it seems redundant to me and duplicate to maintain.

>
> It might be nice to have a simple final assemble with Ant that pulls jar files from Maven Central and uses these jars to build OFBiz
> http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html

This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664

>
> Having Ant scripts that build individual components or groups of components should be pretty simple.

That exists already

>
> It is also possible to deploy artifacts built with Ant to Maven Central.
> http://central.sonatype.org/pages/apache-ant.html
>
>
> I don't see Ant support as a difficult part of a move to Maven but if there is a real demand to support the use of Ant for 100% of the development 
> tasks, it can be part of the move to Maven and any reorganization of the applications.
>
> This will require a high level of cooperation between the experts in the Ant build scripts and the experts promoting Maven.

I think, if ever we go the Maven way, we will still need Ant around and ready

Jacques

>
> Ron
>

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 28/04/2015 16:59, Adam Heath a écrit :
>
> On 04/28/2015 08:22 AM, Ron Wheeler wrote:
>> On 28/04/2015 3:31 AM, Jacques Le Roux wrote:
>>> Le 27/04/2015 16:52, Adam Heath a écrit :
>>>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>>>> You can already compile components separately by using the specific build files
>>>>
>>>> Yeah, I know, and it's a pain in my side.  I actually like being able to *compile* each component separately, by changing to that folder, and 
>>>> running ant.  I haven't yet been able to get maven to make that possible. 
>>>
>>> Yikes, that would be a Maven only solution (no Ant) blocker :/
>>>
>>> Jacques
>>>
>>>
>> Why would Ant have trouble with a different project structure?
>>
>
> You mis-parsed Jacques' statement.  Remove the (no Ant) part, and it becomes: "that would be a Maven only solution blocker".  It is an issue with 
> maven, not ant.

Yes, I'm a specialist of digressions in parenthesis, my mind is built that way it seems

Jacques

Re: Proposal: redefining the components' directory layout for source files

[Adam Heath <do...@brainfood.com>]

On 04/28/2015 08:22 AM, Ron Wheeler wrote:
> On 28/04/2015 3:31 AM, Jacques Le Roux wrote:
>> Le 27/04/2015 16:52, Adam Heath a écrit :
>>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>>> You can already compile components separately by using the specific 
>>>> build files
>>>
>>> Yeah, I know, and it's a pain in my side.  I actually like being 
>>> able to *compile* each component separately, by changing to that 
>>> folder, and running ant.  I haven't yet been able to get maven to 
>>> make that possible. 
>>
>> Yikes, that would be a Maven only solution (no Ant) blocker :/
>>
>> Jacques
>>
>>
> Why would Ant have trouble with a different project structure?
>

You mis-parsed Jacques' statement.  Remove the (no Ant) part, and it 
becomes: "that would be a Maven only solution blocker".  It is an issue 
with maven, not ant.

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler <rw...@artifact-software.com>]

On 28/04/2015 3:31 AM, Jacques Le Roux wrote:
> Le 27/04/2015 16:52, Adam Heath a écrit :
>> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>>> You can already compile components separately by using the specific 
>>> build files
>>
>> Yeah, I know, and it's a pain in my side.  I actually like being able 
>> to *compile* each component separately, by changing to that folder, 
>> and running ant.  I haven't yet been able to get maven to make that 
>> possible. 
>
> Yikes, that would be a Maven only solution (no Ant) blocker :/
>
> Jacques
>
>
Why would Ant have trouble with a different project structure?

Ant is the ultimate in flexibility.

The change will affect the existing Ant processes but I find it hard to 
imagine how it would prevent Ant from building OFBiz.
I would be tempted to look at providing alternative Ant builds.

It might be nice to have a simple final assemble with Ant that pulls jar 
files from Maven Central and uses these jars to build OFBiz
http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html

Having Ant scripts that build individual components or groups of 
components should be pretty simple.

It is also possible to deploy artifacts built with Ant to Maven Central.
http://central.sonatype.org/pages/apache-ant.html


I don't see Ant support as a difficult part of a move to Maven but if 
there is a real demand to support the use of Ant for 100% of the 
development tasks, it can be part of the move to Maven and any 
reorganization of the applications.

This will require a high level of cooperation between the experts in the 
Ant build scripts and the experts promoting Maven.

Ron

-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 27/04/2015 16:52, Adam Heath a écrit :
> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>> You can already compile components separately by using the specific build files
>
> Yeah, I know, and it's a pain in my side.  I actually like being able to *compile* each component separately, by changing to that folder, and 
> running ant.  I haven't yet been able to get maven to make that possible. 

Yikes, that would be a Maven only solution (no Ant) blocker :/

Jacques

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler <rw...@artifact-software.com>]

On 27/04/2015 10:52 AM, Adam Heath wrote:
>
> On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
>> You can already compile components separately by using the specific 
>> build files
>
> Yeah, I know, and it's a pain in my side.  I actually like being able 
> to *compile* each component separately, by changing to that folder, 
> and running ant.  I haven't yet been able to get maven to make that 
> possible.
>
> What I think Ron meant, is that it'd be nice to be able to checkout 
> out *just* one component, and have all it's 
> dependants(jars/other-components) downloaded automatically.  Then, 
> work can be done on *just* this component, in isolation.  For this, 
> maven works great.

Yes. That is what I meant.

>
> ps: Note Ron's phrase of "breaking the project up".
>
> pps: But, even then, other projects have multiple released artifacts 
> per checkout, so maybe all of framework is one repo, and each 
> application/specialpurpose/hot-deploy component becomes separate.
>

Sounds about right.
I would also look at ways to separate the data from code so that could 
be easier to sort out required core seed data from customized entities 
and to build simple installation automated procedures. For example, an 
interactive iZPack installer that installs the OFBiz modules that you 
want and loads the seed data that you need and sets up the services.




>> Jacques
>>
>> Le 24/04/2015 06:26, Ron Wheeler a écrit :
>>> +1
>>>
>>> Any change of breaking the project up into components that are 
>>> compiled separately?
>>>
>>> Ron
>>>
>>> On 23/04/2015 11:42 PM, Scott Gray wrote:
>>>> +1
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 21 January 2015 at 00:41, Jacopo Cappellato <
>>>> jacopo.cappellato@hotwaxmedia.com> wrote:
>>>>
>>>>> In my opinion it would be nice to review how we organize the code 
>>>>> in our
>>>>> components and switch to a directory layout that is more inline 
>>>>> with what
>>>>> other projects are doing, for example:
>>>>>
>>>>>
>>>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html 
>>>>>
>>>>>
>>>>> More specifically I would like to switch from, for example:
>>>>>
>>>>> script/org/ofbiz/product/
>>>>> src/org/ofbiz/product/
>>>>> src/org/ofbiz/product/test/
>>>>>
>>>>> to:
>>>>>
>>>>> src/main/java/org/ofbiz/product/
>>>>> src/main/minilang/org/ofbiz/product/
>>>>> src/main/groovy/...
>>>>> src/test/java/org/ofbiz/product/
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Jacopo
>>>
>>>
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files

[Adam Heath <do...@brainfood.com>]

On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
> You can already compile components separately by using the specific 
> build files

Yeah, I know, and it's a pain in my side.  I actually like being able to 
*compile* each component separately, by changing to that folder, and 
running ant.  I haven't yet been able to get maven to make that possible.

What I think Ron meant, is that it'd be nice to be able to checkout out 
*just* one component, and have all it's 
dependants(jars/other-components) downloaded automatically.  Then, work 
can be done on *just* this component, in isolation.  For this, maven 
works great.

ps: Note Ron's phrase of "breaking the project up".

pps: But, even then, other projects have multiple released artifacts per 
checkout, so maybe all of framework is one repo, and each 
application/specialpurpose/hot-deploy component becomes separate.

> Jacques
>
> Le 24/04/2015 06:26, Ron Wheeler a écrit :
>> +1
>>
>> Any change of breaking the project up into components that are 
>> compiled separately?
>>
>> Ron
>>
>> On 23/04/2015 11:42 PM, Scott Gray wrote:
>>> +1
>>>
>>> Regards
>>> Scott
>>>
>>> On 21 January 2015 at 00:41, Jacopo Cappellato <
>>> jacopo.cappellato@hotwaxmedia.com> wrote:
>>>
>>>> In my opinion it would be nice to review how we organize the code 
>>>> in our
>>>> components and switch to a directory layout that is more inline 
>>>> with what
>>>> other projects are doing, for example:
>>>>
>>>>
>>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html 
>>>>
>>>>
>>>> More specifically I would like to switch from, for example:
>>>>
>>>> script/org/ofbiz/product/
>>>> src/org/ofbiz/product/
>>>> src/org/ofbiz/product/test/
>>>>
>>>> to:
>>>>
>>>> src/main/java/org/ofbiz/product/
>>>> src/main/minilang/org/ofbiz/product/
>>>> src/main/groovy/...
>>>> src/test/java/org/ofbiz/product/
>>>>
>>>> What do you think?
>>>>
>>>> Jacopo
>>
>>

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

You can already compile components separately by using the specific build files

Jacques

Le 24/04/2015 06:26, Ron Wheeler a écrit :
> +1
>
> Any change of breaking the project up into components that are compiled separately?
>
> Ron
>
> On 23/04/2015 11:42 PM, Scott Gray wrote:
>> +1
>>
>> Regards
>> Scott
>>
>> On 21 January 2015 at 00:41, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxmedia.com> wrote:
>>
>>> In my opinion it would be nice to review how we organize the code in our
>>> components and switch to a directory layout that is more inline with what
>>> other projects are doing, for example:
>>>
>>>
>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>>
>>> More specifically I would like to switch from, for example:
>>>
>>> script/org/ofbiz/product/
>>> src/org/ofbiz/product/
>>> src/org/ofbiz/product/test/
>>>
>>> to:
>>>
>>> src/main/java/org/ofbiz/product/
>>> src/main/minilang/org/ofbiz/product/
>>> src/main/groovy/...
>>> src/test/java/org/ofbiz/product/
>>>
>>> What do you think?
>>>
>>> Jacopo
>
>

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler <rw...@artifact-software.com>]

+1

Any change of breaking the project up into components that are compiled 
separately?

Ron

On 23/04/2015 11:42 PM, Scott Gray wrote:
> +1
>
> Regards
> Scott
>
> On 21 January 2015 at 00:41, Jacopo Cappellato <
> jacopo.cappellato@hotwaxmedia.com> wrote:
>
>> In my opinion it would be nice to review how we organize the code in our
>> components and switch to a directory layout that is more inline with what
>> other projects are doing, for example:
>>
>>
>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>
>> More specifically I would like to switch from, for example:
>>
>> script/org/ofbiz/product/
>> src/org/ofbiz/product/
>> src/org/ofbiz/product/test/
>>
>> to:
>>
>> src/main/java/org/ofbiz/product/
>> src/main/minilang/org/ofbiz/product/
>> src/main/groovy/...
>> src/test/java/org/ofbiz/product/
>>
>> What do you think?
>>
>> Jacopo


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files

[Scott Gray <sc...@hotwaxsystems.com>]

+1

Regards
Scott

On 21 January 2015 at 00:41, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> wrote:

> In my opinion it would be nice to review how we organize the code in our
> components and switch to a directory layout that is more inline with what
> other projects are doing, for example:
>
>
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>
> More specifically I would like to switch from, for example:
>
> script/org/ofbiz/product/
> src/org/ofbiz/product/
> src/org/ofbiz/product/test/
>
> to:
>
> src/main/java/org/ofbiz/product/
> src/main/minilang/org/ofbiz/product/
> src/main/groovy/...
> src/test/java/org/ofbiz/product/
>
> What do you think?
>
> Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Divesh Dutta <di...@hotwaxsystems.com>]

Thanks for detailed advantages of going with this approach. My +1 for going
with this approach.

Thanks
--
Divesh Dutta

On Wed, Jan 21, 2015 at 2:36 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> wrote:

> On Jan 20, 2015, at 1:49 PM, Jacques Le Roux <ja...@les7arts.com>
> wrote:
>
> > Have you a clear idea of that this entails in term of migration, no only
> OOTB, but for custom projects which relies on trunk?
>
> I did some reasonings about it and it shouldn't be a big deal, especially
> on the programming side (it will require mostly search and replace
> sessions); of course I didn't do a thorough analysis, I just wanted to
> start the conversation here; the good news is that it can be done in
> chunks, hopefully with the help of the community (that could also support
> the migration of custom projects).
>
> > I guess for Java it should not be so hard but for minilang and groovy
> could be harder, everybody does not use Idea (groovy part)...
>
> I am sorry but the above sentence doesn't make any sense to me...
>
> >
> > Also what does this bring to the project? Why do you want to do so
> (apart being in line with other projects)? And why should we be in line
> with them, do you envision something?
>
> The main advantages are the following:
>
> 1) standardize our layout structure to make it consistent with other
> projects (may make it easier for a new developer to understand OFBiz and
> appreciate it since the beginning)
> 2) review of past decision in light of the experience, lessons learned and
> established conventions: most of the decision we took for the project were
> optimal at that time but may be suboptimal in light of new technologies,
> standards, trends etc... in order for our (more than 10 years old) project
> to stay fresh and healthy we have to always revisit our decisions and keep
> it young; when the first objection to proposals is that this could impact
> custom projects or existing contributors, then in my opinion it is a sign
> of defensive mentality that could bring to staleness; these concerns and
> considerations are still important, but should be discussed (trying to
> propose a good migration plan) at a later point and not used to slow down
> or stop the change
> 3) simplify the pre compilation of Groovy (and possibly other) scripts:
> this could be done to spot coding errors in advance, to improve performance
> at runtime, or just to simplify the deployment
> 4) simplify our build scripts: right now the ant scripts do some
> funny/complex stuff in order to separate test classes from main ones
> 5) moving a step forward in the direction of allowing the adoption of
> Maven like tools (Maven, Gradle etc..) that could make it easier to share
> external components (grow the ecosystem)
> 6) right now there is not a standard place for non-Java services or
> events: the script folder is traditionally used for Minilang, where should
> Groovy (or other languages) service implementation live?
> 7) I have some, longer term, plans to make the OFBiz framework codebase
> more modular: several smaller jars with clear dependencies that could be
> deployed in different ways (vs the monolithic approach we have to follow
> now); a standardization of the source folders may help the adoption of
> tools and strategies for achieving this
>
> Regards,
>
> Jacopo
>
> >
> > Jacques
> >
> > Le 20/01/2015 12:41, Jacopo Cappellato a écrit :
> >> In my opinion it would be nice to review how we organize the code in
> our components and switch to a directory layout that is more inline with
> what other projects are doing, for example:
> >>
> >>
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
> >>
> >> More specifically I would like to switch from, for example:
> >>
> >> script/org/ofbiz/product/
> >> src/org/ofbiz/product/
> >> src/org/ofbiz/product/test/
> >>
> >> to:
> >>
> >> src/main/java/org/ofbiz/product/
> >> src/main/minilang/org/ofbiz/product/
> >> src/main/groovy/...
> >> src/test/java/org/ofbiz/product/
> >>
> >> What do you think?
> >>
> >> Jacopo
> >>
>
>

Re: OFBiz blog feeds

[Jacques Le Roux <ja...@les7arts.com>]

Interesting proposition: +1

Jacques

Le 28/04/2015 11:28, Pierre Smits a écrit :
> With a blog by means of Apache Roller, the PMC can delegate authorship to
> cater for blog posts in various languages and for various focus areas.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Apr 28, 2015 at 11:17 AM, Sharan Foga <sh...@gmail.com> wrote:
>
>> Hi Michael
>>
>> Thanks for the link and also the offer. It looks really good and I think
>> it would be great to have something like this on our site. So yes it would
>> be nice to have this information in English so that we can publish it as
>> part of a our official resurrected blog.
>>
>>
>> Thanks
>> Sharan
>>
>>
>>
>> On 28.4.2015 10:32, Michael Brohl wrote:
>>
>>> Hi,
>>>
>>> we currently maintain an OFBiz news section with monthly updates on our
>>> blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The
>>> monthly update contains a summary of the latest community efforts,
>>> proposals and discussions and a more detailed summary of the changes in
>>> trunk with direct links to the issues.
>>>
>>> It is meant to be an information service for the german speaking OFBiz
>>> users to have easy access to the latest activities in the project without
>>> digging the MLs, commit history etc..
>>>
>>> I could provide this also in english for the OFbiz community if you like.
>>>
>>> Michael
>>> ecomify GmbH
>>> www.ecomify.de
>>>
>>>
>>> Am 28.04.15 um 10:17 schrieb Jacopo Cappellato:
>>>
>>>> On Apr 28, 2015, at 10:06 AM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>>   This reminds me that long ago I created an Apache Roller blog for OFBiz
>>>>> but we never used it. This is a good reason to resurrect it. Some people
>>>>> don't use Twitter, don't follow the MLs, but they could still register to a
>>>>> blog which is only sending few messages/year! I spoke about it with Sharan
>>>>> the week ago
>>>>> https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1
>>>>>
>>>> I like the idea of resurrecting the blog and use it for official
>>>> announcements of the project.
>>>> It would be great if we could include its feeds into the OFBiz main web
>>>> page and replace the static "News" section we have now.
>>>>
>>>> Jacopo
>>>>
>>>>
>>>

Re: OFBiz blog feeds

[Pierre Smits <pi...@gmail.com>]

With a blog by means of Apache Roller, the PMC can delegate authorship to
cater for blog posts in various languages and for various focus areas.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Tue, Apr 28, 2015 at 11:17 AM, Sharan Foga <sh...@gmail.com> wrote:

> Hi Michael
>
> Thanks for the link and also the offer. It looks really good and I think
> it would be great to have something like this on our site. So yes it would
> be nice to have this information in English so that we can publish it as
> part of a our official resurrected blog.
>
>
> Thanks
> Sharan
>
>
>
> On 28.4.2015 10:32, Michael Brohl wrote:
>
>> Hi,
>>
>> we currently maintain an OFBiz news section with monthly updates on our
>> blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The
>> monthly update contains a summary of the latest community efforts,
>> proposals and discussions and a more detailed summary of the changes in
>> trunk with direct links to the issues.
>>
>> It is meant to be an information service for the german speaking OFBiz
>> users to have easy access to the latest activities in the project without
>> digging the MLs, commit history etc..
>>
>> I could provide this also in english for the OFbiz community if you like.
>>
>> Michael
>> ecomify GmbH
>> www.ecomify.de
>>
>>
>> Am 28.04.15 um 10:17 schrieb Jacopo Cappellato:
>>
>>> On Apr 28, 2015, at 10:06 AM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>>  This reminds me that long ago I created an Apache Roller blog for OFBiz
>>>> but we never used it. This is a good reason to resurrect it. Some people
>>>> don't use Twitter, don't follow the MLs, but they could still register to a
>>>> blog which is only sending few messages/year! I spoke about it with Sharan
>>>> the week ago
>>>> https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1
>>>>
>>> I like the idea of resurrecting the blog and use it for official
>>> announcements of the project.
>>> It would be great if we could include its feeds into the OFBiz main web
>>> page and replace the static "News" section we have now.
>>>
>>> Jacopo
>>>
>>>
>>
>>
>

Re: OFBiz blog feeds

[Sharan Foga <sh...@gmail.com>]

Hi Michael

Thanks for the link and also the offer. It looks really good and I think 
it would be great to have something like this on our site. So yes it 
would be nice to have this information in English so that we can publish 
it as part of a our official resurrected blog.


Thanks
Sharan


On 28.4.2015 10:32, Michael Brohl wrote:
> Hi,
>
> we currently maintain an OFBiz news section with monthly updates on 
> our blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The 
> monthly update contains a summary of the latest community efforts, 
> proposals and discussions and a more detailed summary of the changes 
> in trunk with direct links to the issues.
>
> It is meant to be an information service for the german speaking OFBiz 
> users to have easy access to the latest activities in the project 
> without digging the MLs, commit history etc..
>
> I could provide this also in english for the OFbiz community if you like.
>
> Michael
> ecomify GmbH
> www.ecomify.de
>
>
> Am 28.04.15 um 10:17 schrieb Jacopo Cappellato:
>> On Apr 28, 2015, at 10:06 AM, Jacques Le Roux 
>> <ja...@les7arts.com> wrote:
>>
>>> This reminds me that long ago I created an Apache Roller blog for 
>>> OFBiz but we never used it. This is a good reason to resurrect it. 
>>> Some people don't use Twitter, don't follow the MLs, but they could 
>>> still register to a blog which is only sending few messages/year! I 
>>> spoke about it with Sharan the week ago 
>>> https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1
>> I like the idea of resurrecting the blog and use it for official 
>> announcements of the project.
>> It would be great if we could include its feeds into the OFBiz main 
>> web page and replace the static "News" section we have now.
>>
>> Jacopo
>>
>
>

Re: OFBiz blog feeds

[Jacques Le Roux <ja...@les7arts.com>]

I believe every good will is welcome, I wait Sharan's answer has she is currently more involved in this than anyone else

Jacques

Le 28/04/2015 10:32, Michael Brohl a écrit :
> Hi,
>
> we currently maintain an OFBiz news section with monthly updates on our blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The monthly 
> update contains a summary of the latest community efforts, proposals and discussions and a more detailed summary of the changes in trunk with direct 
> links to the issues.
>
> It is meant to be an information service for the german speaking OFBiz users to have easy access to the latest activities in the project without 
> digging the MLs, commit history etc..
>
> I could provide this also in english for the OFbiz community if you like.
>
> Michael
> ecomify GmbH
> www.ecomify.de
>
>
> Am 28.04.15 um 10:17 schrieb Jacopo Cappellato:
>> On Apr 28, 2015, at 10:06 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>
>>> This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people 
>>> don't use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with 
>>> Sharan the week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1
>> I like the idea of resurrecting the blog and use it for official announcements of the project.
>> It would be great if we could include its feeds into the OFBiz main web page and replace the static "News" section we have now.
>>
>> Jacopo
>>
>
>

Re: OFBiz blog feeds

[Michael Brohl <mi...@ecomify.de>]

Hi,

we currently maintain an OFBiz news section with monthly updates on our 
blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The 
monthly update contains a summary of the latest community efforts, 
proposals and discussions and a more detailed summary of the changes in 
trunk with direct links to the issues.

It is meant to be an information service for the german speaking OFBiz 
users to have easy access to the latest activities in the project 
without digging the MLs, commit history etc..

I could provide this also in english for the OFbiz community if you like.

Michael
ecomify GmbH
www.ecomify.de


Am 28.04.15 um 10:17 schrieb Jacopo Cappellato:
> On Apr 28, 2015, at 10:06 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people don't use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with Sharan the week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1
> I like the idea of resurrecting the blog and use it for official announcements of the project.
> It would be great if we could include its feeds into the OFBiz main web page and replace the static "News" section we have now.
>
> Jacopo
>

OFBiz blog feeds

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

On Apr 28, 2015, at 10:06 AM, Jacques Le Roux <ja...@les7arts.com> wrote:

> This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people don't use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with Sharan the week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1

I like the idea of resurrecting the blog and use it for official announcements of the project.
It would be great if we could include its feeds into the OFBiz main web page and replace the static "News" section we have now.

Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 21/01/2015 16:08, Ron Wheeler a écrit :
>
> Very good reasons.
> I am excited by #7. If done correctly, it could make it much easier for new people to get involved since it should partition the application into 
> chunks that are easier to learn.
> It will also relieve some of the management burden since the people reviewing code changes will be able to focus on key changes by ignoring 
> check-ins that involve functions that they do not feel the need to examine closely and spending the time on check-ins to critical or complex code 
> where there is a real danger that the code may pass the acceptance tests but have consequences for other modules or use cases.
> First step on the road to sub-projects?
>
> #2 does introduce the requirement for a sensible plan for the restructuring so that the impact on existing forks is controlled.
> It probably should be planned to coincide with a major release (so-called freeze) so that it is clear to everyone that the structure changed at a 
> well-defined point.
>
> Might not be a bad time to look at changing "org.ofbiz" to "org.apache.ofbiz" since that will bring the code up to date and make the searching for 
> modules in Maven Central a bit more sensible.

I saw so far no really valuable reasons to change "org.ofbiz" to "org.apache.ofbiz". Everybody knows I'm not a huge fan of currently planned changes, 
including and especially Maven.
But if ever we get into this direction, I think this is a good reason... as you said to be carefully planned... and advertised, we have now also 
Twitter for that for people who have not enough time to follow the MLs.

This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people don't 
use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with Sharan the 
week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1

Jacques

> It is also a simple but messy change that has a big impact of forks so it need to happen at a well defined point.
> It is a bigger project but not unmanageable with a bit of teamwork and a good IDE.
>
> Ron
>
>
> On 21/01/2015 4:06 AM, Jacopo Cappellato wrote:
>> On Jan 20, 2015, at 1:49 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>
>>> Have you a clear idea of that this entails in term of migration, no only OOTB, but for custom projects which relies on trunk?
>> I did some reasonings about it and it shouldn't be a big deal, especially on the programming side (it will require mostly search and replace 
>> sessions); of course I didn't do a thorough analysis, I just wanted to start the conversation here; the good news is that it can be done in chunks, 
>> hopefully with the help of the community (that could also support the migration of custom projects).
>>
>>> I guess for Java it should not be so hard but for minilang and groovy could be harder, everybody does not use Idea (groovy part)...
>> I am sorry but the above sentence doesn't make any sense to me...
>>
>>> Also what does this bring to the project? Why do you want to do so (apart being in line with other projects)? And why should we be in line with 
>>> them, do you envision something?
>> The main advantages are the following:
>>
>> 1) standardize our layout structure to make it consistent with other projects (may make it easier for a new developer to understand OFBiz and 
>> appreciate it since the beginning)
>> 2) review of past decision in light of the experience, lessons learned and established conventions: most of the decision we took for the project 
>> were optimal at that time but may be suboptimal in light of new technologies, standards, trends etc... in order for our (more than 10 years old) 
>> project to stay fresh and healthy we have to always revisit our decisions and keep it young; when the first objection to proposals is that this 
>> could impact custom projects or existing contributors, then in my opinion it is a sign of defensive mentality that could bring to staleness; these 
>> concerns and considerations are still important, but should be discussed (trying to propose a good migration plan) at a later point and not used to 
>> slow down or stop the change
>> 3) simplify the pre compilation of Groovy (and possibly other) scripts: this could be done to spot coding errors in advance, to improve performance 
>> at runtime, or just to simplify the deployment
>> 4) simplify our build scripts: right now the ant scripts do some funny/complex stuff in order to separate test classes from main ones
>> 5) moving a step forward in the direction of allowing the adoption of Maven like tools (Maven, Gradle etc..) that could make it easier to share 
>> external components (grow the ecosystem)
>> 6) right now there is not a standard place for non-Java services or events: the script folder is traditionally used for Minilang, where should 
>> Groovy (or other languages) service implementation live?
>> 7) I have some, longer term, plans to make the OFBiz framework codebase more modular: several smaller jars with clear dependencies that could be 
>> deployed in different ways (vs the monolithic approach we have to follow now); a standardization of the source folders may help the adoption of 
>> tools and strategies for achieving this
>>
>> Regards,
>>
>> Jacopo
>>
>>> Jacques
>>>
>>> Le 20/01/2015 12:41, Jacopo Cappellato a écrit :
>>>> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with 
>>>> what other projects are doing, for example:
>>>>
>>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>>>
>>>> More specifically I would like to switch from, for example:
>>>>
>>>> script/org/ofbiz/product/
>>>> src/org/ofbiz/product/
>>>> src/org/ofbiz/product/test/
>>>>
>>>> to:
>>>>
>>>> src/main/java/org/ofbiz/product/
>>>> src/main/minilang/org/ofbiz/product/
>>>> src/main/groovy/...
>>>> src/test/java/org/ofbiz/product/
>>>>
>>>> What do you think?
>>>>
>>>> Jacopo
>>>>
>>
>
>

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler <rw...@artifact-software.com>]

Very good reasons.
I am excited by #7. If done correctly, it could make it much easier for 
new people to get involved since it should partition the application 
into chunks that are easier to learn.
It will also relieve some of the management burden since the people 
reviewing code changes will be able to focus on key changes by ignoring 
check-ins that involve functions that they do not feel the need to 
examine closely and spending the time on check-ins to critical or 
complex code where there is a real danger that the code may pass the 
acceptance tests but have consequences for other modules or use cases.
First step on the road to sub-projects?

#2 does introduce the requirement for a sensible plan for the 
restructuring so that the impact on existing forks is controlled.
It probably should be planned to coincide with a major release 
(so-called freeze) so that it is clear to everyone that the structure 
changed at a well-defined point.

Might not be a bad time to look at changing "org.ofbiz" to 
"org.apache.ofbiz" since that will bring the code up to date and make 
the searching for modules in Maven Central a bit more sensible.
It is also a simple but messy change that has a big impact of forks so 
it need to happen at a well defined point.
It is a bigger project but not unmanageable with a bit of teamwork and a 
good IDE.

Ron


On 21/01/2015 4:06 AM, Jacopo Cappellato wrote:
> On Jan 20, 2015, at 1:49 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> Have you a clear idea of that this entails in term of migration, no only OOTB, but for custom projects which relies on trunk?
> I did some reasonings about it and it shouldn't be a big deal, especially on the programming side (it will require mostly search and replace sessions); of course I didn't do a thorough analysis, I just wanted to start the conversation here; the good news is that it can be done in chunks, hopefully with the help of the community (that could also support the migration of custom projects).
>
>> I guess for Java it should not be so hard but for minilang and groovy could be harder, everybody does not use Idea (groovy part)...
> I am sorry but the above sentence doesn't make any sense to me...
>
>> Also what does this bring to the project? Why do you want to do so (apart being in line with other projects)? And why should we be in line with them, do you envision something?
> The main advantages are the following:
>
> 1) standardize our layout structure to make it consistent with other projects (may make it easier for a new developer to understand OFBiz and appreciate it since the beginning)
> 2) review of past decision in light of the experience, lessons learned and established conventions: most of the decision we took for the project were optimal at that time but may be suboptimal in light of new technologies, standards, trends etc... in order for our (more than 10 years old) project to stay fresh and healthy we have to always revisit our decisions and keep it young; when the first objection to proposals is that this could impact custom projects or existing contributors, then in my opinion it is a sign of defensive mentality that could bring to staleness; these concerns and considerations are still important, but should be discussed (trying to propose a good migration plan) at a later point and not used to slow down or stop the change
> 3) simplify the pre compilation of Groovy (and possibly other) scripts: this could be done to spot coding errors in advance, to improve performance at runtime, or just to simplify the deployment
> 4) simplify our build scripts: right now the ant scripts do some funny/complex stuff in order to separate test classes from main ones
> 5) moving a step forward in the direction of allowing the adoption of Maven like tools (Maven, Gradle etc..) that could make it easier to share external components (grow the ecosystem)
> 6) right now there is not a standard place for non-Java services or events: the script folder is traditionally used for Minilang, where should Groovy (or other languages) service implementation live?
> 7) I have some, longer term, plans to make the OFBiz framework codebase more modular: several smaller jars with clear dependencies that could be deployed in different ways (vs the monolithic approach we have to follow now); a standardization of the source folders may help the adoption of tools and strategies for achieving this
>
> Regards,
>
> Jacopo
>
>> Jacques
>>
>> Le 20/01/2015 12:41, Jacopo Cappellato a écrit :
>>> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:
>>>
>>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>>
>>> More specifically I would like to switch from, for example:
>>>
>>> script/org/ofbiz/product/
>>> src/org/ofbiz/product/
>>> src/org/ofbiz/product/test/
>>>
>>> to:
>>>
>>> src/main/java/org/ofbiz/product/
>>> src/main/minilang/org/ofbiz/product/
>>> src/main/groovy/...
>>> src/test/java/org/ofbiz/product/
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files

[Pierre Smits <pi...@gmail.com>]

Improvements, though painful at first when applied, are always intended
with the future in mind. And it is based on the past. Not improving is like
living in the past.

That being said, I find good in any argument provided. Yes, it has impact
And yes, undertaking something like this should be done with JIRA issues
and in a separate branch. So that persons can evaluate and assess impact on
migration aspects for their custom dependencies. And after it has been
evaluated and people have had time to assess impact on the migration
aspects, it is time to vote on bringing it back into trunk and a release.

Jacques remarked 'sounds like marketing to me', and there is nothing wrong
with being able to promote OFBiz with innovations applied. No one forgoes
the 'New/Improved' opportunity when it comes to promotions. It brings fresh
blood, even to open source projects.

When all the viewpoints have been posted, it is time to assess each
argument and work towards consensus by means of compromising.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

Re: Proposal: redefining the components' directory layout for source files

["David E. Jones" <de...@me.com>]

> On 21 Jan 2015, at 09:24, Jacques Le Roux <ja...@les7arts.com> wrote:
> 
> 
> Le 21/01/2015 15:45, Jacques Le Roux a écrit :
>>> 5) moving a step forward in the direction of allowing the adoption of Maven like tools (Maven, Gradle etc..) that could make it easier to share external components (grow the ecosystem)
>> 
>> Maven, are you serious (have mercy!)?
>> And Gradle seems still a bit unstable (this is a year old opinion based on exchanges in the Moqui community so could be biased) and no longer backed by Pivotal, I read those last days (Groovy as well)
> 
> I was wrong only Groovy and Grails are directly concerned, not Gradle  (though indirectly)
> https://www.voxxed.com/blog/2015/01/sad-odd-decision-pivotal-set-groovy-adrift/ (see also link to Pivotal FAQ)

That was from January. I don't know where Grails is headed, but Groovy has already found a new home:

http://incubator.apache.org/projects/groovy.html

-David

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 21/01/2015 15:45, Jacques Le Roux a écrit :
>> 5) moving a step forward in the direction of allowing the adoption of Maven like tools (Maven, Gradle etc..) that could make it easier to share 
>> external components (grow the ecosystem)
>
> Maven, are you serious (have mercy!)?
> And Gradle seems still a bit unstable (this is a year old opinion based on exchanges in the Moqui community so could be biased) and no longer backed 
> by Pivotal, I read those last days (Groovy as well)

I was wrong only Groovy and Grails are directly concerned, not Gradle  (though indirectly)
https://www.voxxed.com/blog/2015/01/sad-odd-decision-pivotal-set-groovy-adrift/ (see also link to Pivotal FAQ)

Jacques

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 21/01/2015 10:06, Jacopo Cappellato a écrit :
>> On Jan 20, 2015, at 1:49 PM, Jacques Le Roux<ja...@les7arts.com>  wrote:
>> >Also what does this bring to the project? Why do you want to do so (apart being in line with other projects)? And why should we be in line with them, do you envision something?
> The main advantages are the following:
>
> 1) standardize our layout structure to make it consistent with other projects (may make it easier for a new developer to understand OFBiz and appreciate it since the beginning)

Thought weak, that's a +1 indeed

> 2) review of past decision in light of the experience, lessons learned and established conventions: most of the decision we took for the project were optimal at that time but may be suboptimal in light of new technologies, standards, trends etc... in order for our (more than 10 years old) project to stay fresh and healthy we have to always revisit our decisions and keep it young;

Sorry, but sounds like marketing to me ;)

> when the first objection to proposals is that this could impact custom projects or existing contributors, then in my opinion it is a sign of defensive mentality that could bring to staleness;

I know the "We have always doing things like that" derision leitmotiv, but sorry I don't see much innovation in this. Especially when counterbalanced 
with the risks and mostly the necessary effort. I have currently any responsabilities in a custom project based on the trunk and I don't want to 
discuss that point. But I'd like to have the opinions of concerned persons. Apart Hans and Youssef nobody seems concerned, but I guess there are more 
people who will be affected; how do they see things, notably about their patches on the core code, and that will be also valid for people who will 
want to upgrade later to say 15.xx and/or later  release/s... From this perspective, these changes can have a real impact depending on the number and 
size of the patches.
As said Youssef, we can't no longer ignore our base of users, OFBiz is now a well established product in some companies which really rely on it.

> these concerns and considerations are still important, but should be discussed (trying to propose a good migration plan) at a later point and not used to slow down or stop the change

Good point! Looking forward for a good and complete discussion, not disdain as we sometimes do...

> 3) simplify the pre compilation of Groovy (and possibly other) scripts: this could be done to spot coding errors in advance, to improve performance at runtime, or just to simplify the deployment

I must say I have no idea how this can be done, since it's dynamic, but could be interesting indeed.

> 4) simplify our build scripts: right now the ant scripts do some funny/complex stuff in order to separate test classes from main ones

+1

> 5) moving a step forward in the direction of allowing the adoption of Maven like tools (Maven, Gradle etc..) that could make it easier to share external components (grow the ecosystem)

Maven, are you serious (have mercy!)?
And Gradle seems still a bit unstable (this is a year old opinion based on exchanges in the Moqui community so could be biased) and no longer backed 
by Pivotal, I read those last days (Groovy as well)

> 6) right now there is not a standard place for non-Java services or events: the script folder is traditionally used for Minilang, where should Groovy (or other languages) service implementation live?

Good question

> 7) I have some, longer term, plans to make the OFBiz framework codebase more modular: several smaller jars with clear dependencies that could be deployed in different ways (vs the monolithic approach we have to follow now); a standardization of the source folders may help the adoption of tools and strategies for achieving this

Maybe and hopefully...

Jacques

>
> Regards,
>
> Jacopo

Thanks Jacopo,

It clarifies things

Re: Proposal: redefining the components' directory layout for source files

[Pierre Smits <pi...@gmail.com>]

Is this still an ongoing discussion? Has all been said? Is it time for
trying to get to some consensus, e.g. through a vote?

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Thu, Jan 22, 2015 at 11:39 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

>
> Le 22/01/2015 09:53, Jacopo Cappellato a écrit :
>
>> On Jan 21, 2015, at 6:35 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>  I guess you think about http://groovy.codehaus.org/Eclipse+Plugin (also
>>> called GGTS) ? I just updated, thanks!
>>>
>>> I agree it's far better than what I had (previsou version I guess)
>>> But I guess you can't have the strength a strongly typed language like
>>> Java give you in term of navigation between artefacts and refactoring
>>>
>> I don't use refactoring tools, but navigation is indeed supported;
>> however this is a bit off topic in this thread and maybe in these forums :-)
>>
>
> Indeed, I just wanted to share :)
>
> Jacques
>
>
>
>> Jacopo
>>
>>  Jacques
>>>
>>> Le 21/01/2015 14:14, Jacopo Cappellato a écrit :
>>>
>>>> There is an excellent tool for Groovy in Eclipse
>>>>
>>>> Jacopo
>>>>
>>>
>>
>>

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 22/01/2015 09:53, Jacopo Cappellato a écrit :
> On Jan 21, 2015, at 6:35 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> I guess you think about http://groovy.codehaus.org/Eclipse+Plugin (also called GGTS) ? I just updated, thanks!
>>
>> I agree it's far better than what I had (previsou version I guess)
>> But I guess you can't have the strength a strongly typed language like Java give you in term of navigation between artefacts and refactoring
> I don't use refactoring tools, but navigation is indeed supported; however this is a bit off topic in this thread and maybe in these forums :-)

Indeed, I just wanted to share :)

Jacques

>
> Jacopo
>
>> Jacques
>>
>> Le 21/01/2015 14:14, Jacopo Cappellato a écrit :
>>> There is an excellent tool for Groovy in Eclipse
>>>
>>> Jacopo
>
>

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Jan 21, 2015, at 6:35 PM, Jacques Le Roux <ja...@les7arts.com> wrote:

> I guess you think about http://groovy.codehaus.org/Eclipse+Plugin (also called GGTS) ? I just updated, thanks!
> 
> I agree it's far better than what I had (previsou version I guess)
> But I guess you can't have the strength a strongly typed language like Java give you in term of navigation between artefacts and refactoring

I don't use refactoring tools, but navigation is indeed supported; however this is a bit off topic in this thread and maybe in these forums :-)

Jacopo

> 
> Jacques
> 
> Le 21/01/2015 14:14, Jacopo Cappellato a écrit :
>> There is an excellent tool for Groovy in Eclipse
>> 
>> Jacopo
> 

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

I guess you think about http://groovy.codehaus.org/Eclipse+Plugin (also called GGTS) ? I just updated, thanks!

I agree it's far better than what I had (previsou version I guess)
But I guess you can't have the strength a strongly typed language like Java give you in term of navigation between artefacts and refactoring

Jacques

Le 21/01/2015 14:14, Jacopo Cappellato a écrit :
> There is an excellent tool for Groovy in Eclipse
>
> Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

There is an excellent tool for Groovy in Eclipse

Jacopo

On Jan 21, 2015, at 1:47 PM, Jacques Le Roux <ja...@les7arts.com> wrote:

> 
> Le 21/01/2015 10:06, Jacopo Cappellato a écrit :
>>> >I guess for Java it should not be so hard but for minilang and groovy could be harder, everybody does not use Idea (groovy part)...
>> I am sorry but the above sentence doesn't make any sense to me...
>> 
> I mean that refactoring with an IDE is easier. For Eclipse users there are tools for Java but not minilang and groovy where things must be done by hand with a less secure manner. I don't use IntelliJ IDEA but I know it has more Groovy support, hence more secure when refactoring.
> 
> Jacques

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Le 21/01/2015 10:06, Jacopo Cappellato a écrit :
>> >I guess for Java it should not be so hard but for minilang and groovy could be harder, everybody does not use Idea (groovy part)...
> I am sorry but the above sentence doesn't make any sense to me...
>
I mean that refactoring with an IDE is easier. For Eclipse users there are tools for Java but not minilang and groovy where things must be done by 
hand with a less secure manner. I don't use IntelliJ IDEA but I know it has more Groovy support, hence more secure when refactoring.

Jacques

Re: Proposal: redefining the components' directory layout for source files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On Jan 20, 2015, at 1:49 PM, Jacques Le Roux <ja...@les7arts.com> wrote:

> Have you a clear idea of that this entails in term of migration, no only OOTB, but for custom projects which relies on trunk?

I did some reasonings about it and it shouldn't be a big deal, especially on the programming side (it will require mostly search and replace sessions); of course I didn't do a thorough analysis, I just wanted to start the conversation here; the good news is that it can be done in chunks, hopefully with the help of the community (that could also support the migration of custom projects).

> I guess for Java it should not be so hard but for minilang and groovy could be harder, everybody does not use Idea (groovy part)...

I am sorry but the above sentence doesn't make any sense to me...

> 
> Also what does this bring to the project? Why do you want to do so (apart being in line with other projects)? And why should we be in line with them, do you envision something?

The main advantages are the following:

1) standardize our layout structure to make it consistent with other projects (may make it easier for a new developer to understand OFBiz and appreciate it since the beginning)
2) review of past decision in light of the experience, lessons learned and established conventions: most of the decision we took for the project were optimal at that time but may be suboptimal in light of new technologies, standards, trends etc... in order for our (more than 10 years old) project to stay fresh and healthy we have to always revisit our decisions and keep it young; when the first objection to proposals is that this could impact custom projects or existing contributors, then in my opinion it is a sign of defensive mentality that could bring to staleness; these concerns and considerations are still important, but should be discussed (trying to propose a good migration plan) at a later point and not used to slow down or stop the change
3) simplify the pre compilation of Groovy (and possibly other) scripts: this could be done to spot coding errors in advance, to improve performance at runtime, or just to simplify the deployment
4) simplify our build scripts: right now the ant scripts do some funny/complex stuff in order to separate test classes from main ones
5) moving a step forward in the direction of allowing the adoption of Maven like tools (Maven, Gradle etc..) that could make it easier to share external components (grow the ecosystem)
6) right now there is not a standard place for non-Java services or events: the script folder is traditionally used for Minilang, where should Groovy (or other languages) service implementation live?
7) I have some, longer term, plans to make the OFBiz framework codebase more modular: several smaller jars with clear dependencies that could be deployed in different ways (vs the monolithic approach we have to follow now); a standardization of the source folders may help the adoption of tools and strategies for achieving this

Regards,

Jacopo

> 
> Jacques
> 
> Le 20/01/2015 12:41, Jacopo Cappellato a écrit :
>> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:
>> 
>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>> 
>> More specifically I would like to switch from, for example:
>> 
>> script/org/ofbiz/product/
>> src/org/ofbiz/product/
>> src/org/ofbiz/product/test/
>> 
>> to:
>> 
>> src/main/java/org/ofbiz/product/
>> src/main/minilang/org/ofbiz/product/
>> src/main/groovy/...
>> src/test/java/org/ofbiz/product/
>> 
>> What do you think?
>> 
>> Jacopo
>> 

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux <ja...@les7arts.com>]

Have you a clear idea of that this entails in term of migration, no only OOTB, but for custom projects which relies on trunk?
I guess for Java it should not be so hard but for minilang and groovy could be harder, everybody does not use Idea (groovy part)...

Also what does this bring to the project? Why do you want to do so (apart being in line with other projects)? And why should we be in line with them, 
do you envision something?

Jacques

Le 20/01/2015 12:41, Jacopo Cappellato a écrit :
> In my opinion it would be nice to review how we organize the code in our components and switch to a directory layout that is more inline with what other projects are doing, for example:
>
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>
> More specifically I would like to switch from, for example:
>
> script/org/ofbiz/product/
> src/org/ofbiz/product/
> src/org/ofbiz/product/test/
>
> to:
>
> src/main/java/org/ofbiz/product/
> src/main/minilang/org/ofbiz/product/
> src/main/groovy/...
> src/test/java/org/ofbiz/product/
>
> What do you think?
>
> Jacopo
>