Proposal: redefining the components' directory layout for source files

[Adrian Crum-3]

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

[Pierre Smits]

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

> 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

[Jacopo Cappellato-5]

Adrian, Pierre,

this is exactly what I meant.

Jacopo

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

[Michael Brohl-3]

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

[Ron Wheeler]

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

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[darrell73s]

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

[darrell73s]

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

[Jacques Le Roux]

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

[Adam Heath-2]

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

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

[Jacques Le Roux]

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

[Jacques Le Roux]

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

[Jacopo Cappellato-5]

On Apr 28, 2015, at 10:06 AM, Jacques Le Roux <[hidden email]> 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

[Jacques Le Roux]

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

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

[Jacopo Cappellato-5]

On Apr 28, 2015, at 10:16 AM, Jacques Le Roux <[hidden email]> 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

[Michael Brohl-3]

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

[Jacques Le Roux]

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

[Jacques Le Roux]

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

[Jacques Le Roux]

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

[Jacques Le Roux]

Le 28/04/2015 10:27, Jacopo Cappellato a écrit :
> On Apr 28, 2015, at 10:16 AM, Jacques Le Roux <[hidden email]> 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