Proposal: redefining the components' directory layout for source files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
78 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Proposal: redefining the components' directory layout for source files

Jacopo Cappellato-4
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
Reply | Threaded
Open this post in threaded view
|

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

Jacques Le Roux
Administrator
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
>
Reply | Threaded
Open this post in threaded view
|

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

Ron Wheeler
In reply to this post by Jacopo Cappellato-4
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: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Reply | Threaded
Open this post in threaded view
|

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

Adrian Crum-3
In reply to this post by Jacopo Cappellato-4
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
>
Reply | Threaded
Open this post in threaded view
|

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

hans_bakker
In reply to this post by Jacopo Cappellato-4
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

Reply | Threaded
Open this post in threaded view
|

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

Adrian Crum-3
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
>
Reply | Threaded
Open this post in threaded view
|

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

Ron Wheeler
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: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Reply | Threaded
Open this post in threaded view
|

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

Jacques Le Roux
Administrator
In reply to this post by Adrian Crum-3
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
>>
>
Reply | Threaded
Open this post in threaded view
|

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

Jacques Le Roux
Administrator
In reply to this post by Ron Wheeler
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
>>>
>>
>
>
Reply | Threaded
Open this post in threaded view
|

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

Jacopo Cappellato-4
In reply to this post by Adrian Crum-3

On Jan 20, 2015, at 4:29 PM, Adrian Crum <[hidden email]> 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
>>

Reply | Threaded
Open this post in threaded view
|

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

Jacopo Cappellato-4
In reply to this post by Jacques Le Roux
On Jan 20, 2015, at 1:49 PM, Jacques Le Roux <[hidden email]> 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
>>

Reply | Threaded
Open this post in threaded view
|

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

Youssef Khaye-2
In reply to this post by Adrian Crum-3

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
>>

Reply | Threaded
Open this post in threaded view
|

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

Jacques Le Roux
Administrator
In reply to this post by Jacopo Cappellato-4

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
Reply | Threaded
Open this post in threaded view
|

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

Jacopo Cappellato-4
There is an excellent tool for Groovy in Eclipse

Jacopo

On Jan 21, 2015, at 1:47 PM, Jacques Le Roux <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Jacques Le Roux
Administrator
In reply to this post by Jacopo Cappellato-4

Le 21/01/2015 10:06, Jacopo Cappellato a écrit :
>> On Jan 20, 2015, at 1:49 PM, Jacques Le Roux<[hidden email]>  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
Reply | Threaded
Open this post in threaded view
|

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

Adrian Crum-3
In reply to this post by Jacopo Cappellato-4
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 <[hidden email]> 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
>>>
>
Reply | Threaded
Open this post in threaded view
|

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

Jacopo Cappellato-4
On Jan 21, 2015, at 3:56 PM, Adrian Crum <[hidden email]> 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 <[hidden email]> 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
>>>>
>>

Reply | Threaded
Open this post in threaded view
|

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

Pierre Smits
In reply to this post by Jacques Le Roux
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
Reply | Threaded
Open this post in threaded view
|

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

Ron Wheeler
In reply to this post by Jacopo Cappellato-4

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 <[hidden email]> 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: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Reply | Threaded
Open this post in threaded view
|

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

Ron Wheeler
In reply to this post by Jacopo Cappellato-4
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

1234