Proposal: redefining the components' directory layout for source files

[Adrian Crum-3]

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

[Jacques Le Roux]

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

[Jacques Le Roux]

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

[Jacopo Cappellato-4]

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

[Jacques Le Roux]

Le 22/01/2015 09:53, Jacopo Cappellato a écrit :
> On Jan 21, 2015, at 6:35 PM, Jacques Le Roux <[hidden email]> 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
>
>

[Pierre Smits]

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 <
[hidden email]> wrote:

>
> Le 22/01/2015 09:53, Jacopo Cappellato a écrit :
>
>> On Jan 21, 2015, at 6:35 PM, Jacques Le Roux <
>> [hidden email]> 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
>>>>
>>>
>>
>>

[David E. Jones-2]

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

[Scott Gray-3]

+1

Regards
Scott

On 21 January 2015 at 00:41, Jacopo Cappellato <
[hidden email]> 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]

+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 <
> [hidden email]> 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: [phone], ext 102

[Divesh Dutta-2]

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 <
[hidden email]> 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
> >>
>
>

[Adam Heath-2]

+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 <
> [hidden email]> 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.

[Jacopo Cappellato-5]

On Apr 24, 2015, at 4:36 PM, Adam Heath <[hidden email]> 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

[Adam Heath-2]

On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
> On Apr 24, 2015, at 4:36 PM, Adam Heath <[hidden email]> 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.

[Ron Wheeler]

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

[Adam Heath-2]

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]

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

[Adrian Crum-3]

+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 <[hidden email]> 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
>

[Jacopo Cappellato-5]

On Apr 24, 2015, at 5:01 PM, Adam Heath <[hidden email]> wrote:

> On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
>> On Apr 24, 2015, at 4:36 PM, Adam Heath <[hidden email]> 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

[Pierre Smits]

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 <
[hidden email]> wrote:

> On Apr 24, 2015, at 5:01 PM, Adam Heath <[hidden email]> wrote:
>
> > On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
> >> On Apr 24, 2015, at 4:36 PM, Adam Heath <[hidden email]> 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
>

[Jacopo Cappellato-5]

On Apr 25, 2015, at 10:39 AM, Pierre Smits <[hidden email]> 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