You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2012/03/22 12:06:07 UTC
Some ideas to prepare our first community roadmap
Hi all,
now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by listing the actionable items and also by considering other topics that may be of interest to the community.
This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
(MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
* setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there); the OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
* move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details (how to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and also at least one maintainer (OFBiz committer or not) for each component
* move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details (how to remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
The above will form the first part of the roadmap.
====
The following list is simply my personal attempt to propose some priorities for the community; some of them are based on comments from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an OFBiz roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a clear roadmap to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals need to be enough generic to gather consensus on a larger group of people (otherwise each individual committer will end up proposing her own specific item to the list, of less interest to the community, and then she will start working on it... instead of better spending the time that she decided to "contribute" to tasks that the community really considers important) and they shouldn't be too big (gathering consensus and implementing as a community will take a lot of time). If we will not find an agreement on some items or a large consensus then it will be fine: the roadmap will be lighter and will be completed earlier; at that point we will discuss again what we want to do next.
Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and "quality".
BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to try to see if we can find an agreement for some actionable tasks)
* resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its dependencies on applications)
* gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing Content Framework with it
* discuss, design and implement (if needed) or define best practices for a plug in architecture
* discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they don't require big design and discussions and are mostly all actionable)
* bug fixes
* automated tests
* migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
* check proper handling of EntityListIterators
* check proper handling of errors and exceptions in services, events, scripts
* check proper handling of events/services messages
* replace simple CRUD services with entity-auto services
* refactor security handling in services to declare the security service in the service definition
* identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for removal and reimplementation using DynamicEntityView API
* identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they look very specific)
* cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
* review old events and verify if they can be converted into services
* review old code and refactor/rewrite
* review existing events/services
Kind regards,
Jacopo
Re: Some ideas to prepare our first community roadmap
Posted by Pierre Smits <pi...@gmail.com>.
Hi Jacopo,
This is a sound approach, so a +1 from me. Specifically on using JIRA for
this. It will help keeping focus. If the set of actions is to big to
completed in a reasonable time frame, it might be wise to split it over
multiple releases (All great works of art weren't there over night).
I would like to propose to cancel the 12.04 release, so that this roadmap
will lead to the new release and keep the old ones open for bug fixing
only. For the next release I wouldn't use 13 as well, given that might be
people having some superstition about this.
Regards,
Pierre
Op 22 maart 2012 12:06 schreef Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> het volgende:
> Hi all,
>
> now that the great community discussion about the "Lose Weight Program"
> for OFBiz is settling down (thanks to all of you for the great ideas,
> enthusiasm and participation) we can start to wrap up a roadmap (it would
> be nice to set it up in Jira, using a specific "Jira version" so that we
> can keep track of progress together... any ideas for a good name for it?)
> by listing the actionable items and also by considering other topics that
> may be of interest to the community.
> This thread is an attempt to integrate the roadmap with some additional
> tasks if the community will consider them a priority.
>
> But first of all, here is the list with a categorization/summary of the
> tasks being discussed so far:
>
> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we
> will create tasks in Jira for each):
> * setup a nice page in the OFBiz website to describe the OFBiz Extras
> ecosystem (external project names will be added there); the OFBiz PMC will
> have to work on this (also check if there is additional paperwork to do)
> * move some of the component/code to Extras: we will create individual
> Jira tasks for each component and then design details (how to move) will be
> discussed in the task; we will need volunteers (committers and not) to
> contribute patches/commits and also at least one maintainer (OFBiz
> committer or not) for each component
> * move some of the component/code to Attic: we will create individual Jira
> tasks for each removal and then design details (how to remove) will be
> discussed in the tasks; we will need volunteers (committers and not) to
> contribute patches/commits
>
> The above will form the first part of the roadmap.
>
> ====
>
> The following list is simply my personal attempt to propose some
> priorities for the community; some of them are based on comments from
> people on the dev list, some of them are personal ideas based on some
> reviews I did to the OFBiz codebase.
> Feel free to add/remove items to the list but please while doing this
> consider that we are discussing candidate tasks for an OFBiz roadmap shared
> by the community: when the list will be discussed, approved and finalized
> the community will have a clear roadmap to focus on (with all
> contributions/commits going in this direction); but this also means that
> the tasks/goals need to be enough generic to gather consensus on a larger
> group of people (otherwise each individual committer will end up proposing
> her own specific item to the list, of less interest to the community, and
> then she will start working on it... instead of better spending the time
> that she decided to "contribute" to tasks that the community really
> considers important) and they shouldn't be too big (gathering consensus and
> implementing as a community will take a lot of time). If we will not find
> an agreement on some items or a large consensus then it will be fine: the
> roadmap will be lighter and will be completed earlier; at that point we
> will discuss again what we want to do next.
> Even if no big tasks will be added to the roadmap, I think it will still
> be an interesting one focused on "maintenance" and "quality".
>
> BIG TASKS (these are potentially big tasks that may be difficult to plan
> in this first roadmap... but it may make sense to try to see if we can find
> an agreement for some actionable tasks)
> * resolving framework dependencies on applications (this is *not* about
> "refactoring" the framework, simply to resolve its dependencies on
> applications)
> * gather requirements (from existing applications), design and implement
> JCR/Jackrabbit and replace parts of the existing Content Framework with it
> * discuss, design and implement (if needed) or define best practices for a
> plug in architecture
> * discuss, design and implement (if needed) or define best practices for
> an integrated reporting tool for OFBiz
>
> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that
> should be easy to include in the roadmap because they don't require big
> design and discussions and are mostly all actionable)
> * bug fixes
> * automated tests
> * migration from Beanshell to Groovy (i.e. continue in the trunk the work
> started in the branch)
> * check proper handling of EntityListIterators
> * check proper handling of errors and exceptions in services, events,
> scripts
> * check proper handling of events/services messages
> * replace simple CRUD services with entity-auto services
> * refactor security handling in services to declare the security service
> in the service definition
> * identify all view-entity definitions that are only used in one place (or
> never used): they may be good candidates for removal and reimplementation
> using DynamicEntityView API
> * identify all services that are used only in one place (or never used):
> they may be removed and inlined (especially if they look very specific)
> * cleanup (following some best practices - to be defined- for names) and
> improve service names and descriptions
> * review old events and verify if they can be converted into services
> * review old code and refactor/rewrite
> * review existing events/services
>
> Kind regards,
>
> Jacopo
>
>
Re: Some ideas to prepare our first community roadmap
Posted by Erwan de FERRIERES <er...@nereide.fr>.
Le 22/03/2012 12:06, Jacopo Cappellato a écrit :
> Hi all,
>
> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by listing the actionable items and also by considering other topics that may be of interest to the community.
> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>
../..
If I remember well, there was a refactoring needed for the themes, as
there were some unused or duplicated CSS classes.
Regards,
--
Erwan de FERRIERES
www.nereide.biz
Re: Some ideas to prepare our first community roadmap
Posted by Olivier Heintz <ho...@nereide.biz>.
Thank you for this first roadmap
I agree with all points but I have 3 remarks
1) about the very important Rules "I think it will still be an
interesting one focused on "maintenance" and "quality"."
maybe a third main goal like "usability" on a end user point of view (or
a sub goal of quality but oriented user, not technical) should be added
2) maybe this roadmap is little too technical and not enough business
functionality
3) nothing about contribution which have a quality and maintainability
the ofbiz community define : are they integrated or rejected pending
completion of these steps.
About MAINTENANCE, REFACTORING AND CLEANUP list
+1 for Nicolas proposition
On refactoring idea :
* review/improve best pratice screen (to manage icons, strong table
line, ...),
Le 22/03/2012 12:06, Jacopo Cappellato a écrit :
> Hi all,
>
> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by listing the actionable items and also by considering other topics that may be of interest to the community.
> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>
> But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
>
> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
> * setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there); the OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
> * move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details (how to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and also at least one maintainer (OFBiz committer or not) for each component
> * move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details (how to remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
>
> The above will form the first part of the roadmap.
>
> ====
>
> The following list is simply my personal attempt to propose some priorities for the community; some of them are based on comments from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
> Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an OFBiz roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a clear roadmap to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals need to be enough generic to gather consensus on a larger group of people (otherwise each individual committer will end up proposing her own specific item to the list, of less interest to the community, and then she will start working on it... instead of better spending the time that she decided to "contribute" to tasks that the community really considers important) and they shouldn't be too big (gathering consensus and implementing as a community will take a lot of time). If we will not find an agreement on some items or a large consensus then it will be fine: the roadmap will be lighter and will be completed earlier; at that point we will discuss again what we want to do next.
> Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and "quality".
>
> BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to try to see if we can find an agreement for some actionable tasks)
> * resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its dependencies on applications)
> * gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing Content Framework with it
> * discuss, design and implement (if needed) or define best practices for a plug in architecture
> * discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
>
> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they don't require big design and discussions and are mostly all actionable)
> * bug fixes
> * automated tests
> * migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
> * check proper handling of EntityListIterators
> * check proper handling of errors and exceptions in services, events, scripts
> * check proper handling of events/services messages
> * replace simple CRUD services with entity-auto services
> * refactor security handling in services to declare the security service in the service definition
> * identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for removal and reimplementation using DynamicEntityView API
> * identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they look very specific)
> * cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
> * review old events and verify if they can be converted into services
> * review old code and refactor/rewrite
> * review existing events/services
>
> Kind regards,
>
> Jacopo
>
>
Re: Some ideas to prepare our first community roadmap
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes good idea. In case we could still create mains and sub-taks if needed
Jacques
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>
> On Mar 23, 2012, at 8:15 PM, Jacques Le Roux wrote:
>
>>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
>>
>> Sub-tasks of "Slim down", right?
>
> Rather than subtasks I would suggest to:
>
> 1) create a new Jira version for the roadmap: "Slim Down" (or similar)
> 2) create task and then assign as "fix version" to the roadmap
>
> In this way we will be very flexible; Jira also provides some nice ootb reports to show progress on versions and this will be very
> useful.
>
> Jacopo
Re: Some ideas to prepare our first community roadmap
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Mar 23, 2012, at 8:15 PM, Jacques Le Roux wrote:
>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
>
> Sub-tasks of "Slim down", right?
Rather than subtasks I would suggest to:
1) create a new Jira version for the roadmap: "Slim Down" (or similar)
2) create task and then assign as "fix version" to the roadmap
In this way we will be very flexible; Jira also provides some nice ootb reports to show progress on versions and this will be very useful.
Jacopo
Re: Some ideas to prepare our first community roadmap
Posted by Jacques Le Roux <jl...@les7arts.com>.
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> Hi all,
>
> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for the
> great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using a
> specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by listing the
> actionable items and also by considering other topics that may be of interest to the community.
I like Erwan's idea: "Slim down" easy to remember, I have nothing againt 13 though, I'm not superstitious at all.
When you believe in things that you don't understand,
Then you suffer,
Superstition ain't the way
Stevie Wonder
> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>
> But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
>
> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
Sub-tasks of "Slim down", right?
> * setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there); the
> OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
> * move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details (how
> to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and also at
> least one maintainer (OFBiz committer or not) for each component
Sub-tasks of "Slim down", right? Mmm... Unfortunately Jira has only one level of sub-tasks, we could create another Main task for
them an relate it to "Slim down" task
> * move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details (how to
> remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
Sub-tasks of "Slim down", right? Mmm... Unfortunately Jira has only one level of sub-tasks, we could create another Main task for
them an relate it to "Slim down" task
> The above will form the first part of the roadmap.
>
> ====
>
> The following list is simply my personal attempt to propose some priorities for the community; some of them are based on comments
> from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
> Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an OFBiz
> roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a clear roadmap
> to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals need to be enough
> generic to gather consensus on a larger group of people (otherwise each individual committer will end up proposing her own
> specific item to the list, of less interest to the community, and then she will start working on it... instead of better spending
> the time that she decided to "contribute" to tasks that the community really considers important) and they shouldn't be too big
> (gathering consensus and implementing as a community will take a lot of time). If we will not find an agreement on some items or a
> large consensus then it will be fine: the roadmap will be lighter and will be completed earlier; at that point we will discuss
> again what we want to do next.
> Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and
> "quality".
+1 on QA, and BUG FIXES desesperately waiting to be fixed with patches in Jira anxious to not be unusable (contributions lost)
> BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to try to
> see if we can find an agreement for some actionable tasks)
> * resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its
> dependencies on applications)
> * gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing Content
> Framework with it
> * discuss, design and implement (if needed) or define best practices for a plug in architecture
> * discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
+1
> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they don't
> require big design and discussions and are mostly all actionable)
> * bug fixes
> * automated tests
> * migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
> * check proper handling of EntityListIterators
> * check proper handling of errors and exceptions in services, events, scripts
> * check proper handling of events/services messages
> * replace simple CRUD services with entity-auto services
> * refactor security handling in services to declare the security service in the service definition
> * identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for removal
> and reimplementation using DynamicEntityView API
> * identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they look
> very specific)
> * cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
> * review old events and verify if they can be converted into services
> * review old code and refactor/rewrite
> * review existing events/services
Mansour made some interesting propositions, to be discusses one by one, else we will be lost
I also have some but can't remember from the top of my head... later...
Thanks
Jacques
> Kind regards,
>
> Jacopo
>
>
Re: Some ideas to prepare our first community roadmap
Posted by Erwan de FERRIERES <er...@nereide.fr>.
Le 22/03/2012 12:06, Jacopo Cappellato a écrit :
> Hi all,
>
../..
Hi,
+1 on everything for me.
using Jira is also the right idea, we'll be more efficient this way.
There are 2 things I'd like to add:
* change the Debug class name to Logger (or anything) as you proposed,
* migrate from json-lib to anything else ().
json-lib is dependent on commons-lang 2, which is preventing us for
migrating to the lang3. Moreover this project seems dead, last update in
december 2010.
for the version name, "slim down" ?
Regards,
--
Erwan de FERRIERES
www.nereide.biz
Re: Some ideas to prepare our first community roadmap
Posted by Jacques Le Roux <ja...@les7arts.com>.
There are Jiras pending out there with already questions/answers, just need to be continued
Jacques
Erwan de FERRIERES wrote:
>> eBay and eBay Store could be merged together and there's also no functionality to post variants to eBay, I wrote some custom
>> code as
>
> Hi Prince,
>
> this should have been merged a long time ago. Thanks for volunteering
> on this task !
>
> Cheers,
Re: Some ideas to prepare our first community roadmap
Posted by Erwan de FERRIERES <er...@gmail.com>.
>
> eBay and eBay Store could be merged together and there's also no functionality to post variants to eBay, I wrote some custom code as
Hi Prince,
this should have been merged a long time ago. Thanks for volunteering
on this task !
Cheers,
--
Erwan de FERRIERES
Re: Some ideas to prepare our first community roadmap
Posted by Jacques Le Roux <ja...@les7arts.com>.
Mansour Al Akeel wrote:
> Back again to the subject of ORMs. MyBatis, may be the fastest ORM I
> have worked with, compared to JPA (hibernate, EclipseLink, ..etc).
> While I didn't do a practical comparison with OfBiz entity engine, I
> think ofbiz entity engine is the most optimized, and fastest,
> because it's closer to JDBC than any other ORM framework. I am not
> sure if any optimization can be with the EE beside cleaning the code
> a bit, and refactoring.
Exactly
Jacques
>
>
> On Fri, Mar 23, 2012 at 9:27 AM, Prince Sewani <pr...@ymail.com> wrote:
>> Yeah making it more OO is what I'm actually referring to, OFBiz entity-engine is
>> a different architecture altogether if we compare it to other existing counter-parts like hibernate and
>>
>> Ibatis, I haven't really looked at the query generation code, but does anyone thinks that it needs a
>>
>> bit more optimization? I know I'm talking at a very high level despite of checking out the
>> implementation, Also for cases where we need to plug-in our queries (And I really mean SQL Queries) there should be additional
>> methods in
>>
>> GenericDelegator to achieve it, in the current scenario we've to make an instace of SQLProcessor to get that done,
>> I'm not sure, but it must be a singleton as per my understanding, Is there any way to get that existing Singleton
>>
>> in our code using some method, If not we should think of that too, it would make OFBiz Entity Engine
>>
>> superior to its counterparts and that idea of permissions at the entity level is awesome!!
>>
>> P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what to be done.
>>
>> Regards
>> Prince
>>
>>
>>
>> ________________________________
>> From: Mansour Al Akeel <ma...@gmail.com>
>> To: dev@ofbiz.apache.org; Prince Sewani <pr...@ymail.com>
>> Sent: Friday, March 23, 2012 6:37 PM
>> Subject: Re: Some ideas to prepare our first community roadmap
>>
>> For me +1 to refactor.
>>
>> I am not sure the ORM needs any work. May be I am missing something.
>> Please let me know what part ?
>>
>> Just cleaning the entity engine code a bit, and make it more OO, will
>> make it easier to work with.
>> For example, I like to add a custom Delegator that will append some
>> fields to each query and will enforce Row Level Security.
>> For example, adding something like "acl.xml" next to the entity
>> definitions, which contains the rules about the access.
>> I know Oracle database has what is called virtual Private Database,
>> and will be nice to have something similar instead of checking for
>> access control in each service call.
>> Just looking at the code currently there, makes the idea goes away.
>> Refactoring the code will make things a bit easier.
>>
>> Ofbiz currently uses its own container to load all it's component. I
>> was not able to find a lot of docs. May be missed them.
>> I don't know if using alternative container is a reasonable suggestion.
>>
>> I see a lot of documentations and examples about using IoC containers
>> with tomcat/jetty/geronimo and OSGI.
>>
>>
>> On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani <pr...@ymail.com> wrote:
>>>
>>>
>>> +1 to the Refractor, Have a few questions and a few suggestions :
>>> Questions :
>>>
>>>
>>> Are we looking to improve upon the ORM as well ?
>>>
>>> And what about the OSGI stuff, are we planning something on that to enhance the plug-in approach?
>>>
>>> What's all about the extra stuff? are we just gonna keep 'em separately and maintain 'em separately or are we
>>> really commercializing?
>>>
>>> Also, What all is that we're thinking to add on to the existing application or are we just looking to reduce/resize and enhance
>>> what all
>>> is there?
>>>
>>>
>>> Suggestions :
>>>
>>> Google Base Component : Google has upgraded to Google Content API long back so the one in 10.04 no more works to upload
>>> products to Google merchant haven't checked 11.04 yet.
>>>
>>> eBay and eBay Store could be merged together and there's also no functionality to post variants to eBay, I wrote some custom
>>> code as
>>>
>>> part of a POC for that, also customer grievances from eBay is something that's missing.
>>>
>>> Integration with Amazon using Amazon MWS will be cool.
>>>
>>> Upgrade for Fedex API as they're retiring the SOAP API that is currently used, on 31st may 2012.
>>>
>>> Also I'm ready to volunteer any component at any level, be it a committer or not.
>>> I'm very much excited about the massive change that we're about to bring as a community to
>>>
>>> the application.
>>>
>>> Regards
>>> Prince
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: Nicolas Malin <ma...@librenberry.net>
>>> To: dev@ofbiz.apache.org
>>> Sent: Friday, March 23, 2012 4:21 PM
>>> Subject: Re: Some ideas to prepare our first community roadmap
>>>
>>> +1 a greate roadmap with lot of works
>>>
>>> On refactoring idea :
>>> * review/improve best pratice screen (to manage icons, strong table
>>> line, ...), I had started on this subject but not finalize.
>>>
>>> Nicolas
>>>
>>> Le 23/03/2012 11:07, Scott Gray a écrit :
>>>> I'm in favor of all of those things so +1 from me.
>>>>
>>>> For a JIRA version, how about 13.04? :-)
>>>>
>>>> One other topic that's been on my mind, payment gateway implementations:
>>>> - Move the test implementation into it's own class so that it isn't overcrowding PaymentGatewayServices and is consistent with
>>>> the others
>>>> - Refactor the test implementation so that you can use the CVV code to test different behaviors instead of having a bunch of
>>>> different methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
>>>> - Ensure consistency between the implementations and better document the gateway interfaces. Also remove virtually all
>>>> database calls from the implementations (they run in their own transaction which can be painful when querying new data).
>>>> - After cleaning them up, consider moving some of the implementations to Extras, I would prefer all of them except test but we
>>>> could start with some of the more obscure ones at least
>>>>
>>>> Oh and another one on my wish list:
>>>> - Finish the query builder implementation that I started a year or two ago and deprecate the bulk of the delegator find
>>>> methods.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for
>>>>> the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira,
>>>>> using a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by
>>>>> listing the actionable items and also by considering other topics that may be of interest to the community.
>>>>> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>>>>>
>>>>> But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
>>>>>
>>>>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
>>>>> * setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there);
>>>>> the OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
>>>>> * move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details
>>>>> (how to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and
>>>>> also at least one maintainer (OFBiz committer or not) for each component
>>>>> * move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details
>>>>> (how to remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
>>>>>
>>>>> The above will form the first part of the roadmap.
>>>>>
>>>>> ====
>>>>>
>>>>> The following list is simply my personal attempt to propose some priorities for the community; some of them are based on
>>>>> comments from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
>>>>> Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an
>>>>> OFBiz roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a
>>>>> clear roadmap to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals
>>>>> need to be enough generic to gather consensus on a larger group of people (otherwise each individual committer will end up
>>>>> proposing her own specific item to the list, of less interest to the community, and then she will start working on it...
>>>>> instead of better spending the time that she decided to "contribute" to tasks that the community really considers important)
>>>>> and they shouldn't be too big (gathering consensus and implementing as a community will take a lot of time). If we will not
>>>>> find an agreement on some items or a large consensus then it will be fine: the roadmap will be
>>> lighter and will be completed earlier; at that point we will discuss again what we want to do next.
>>>>> Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and
>>>>> "quality".
>>>>>
>>>>> BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to
>>>>> try to see if we can find an agreement for some actionable tasks)
>>>>> * resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its
>>>>> dependencies on applications)
>>>>> * gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing
>>>>> Content Framework with it
>>>>> * discuss, design and implement (if needed) or define best practices for a plug in architecture
>>>>> * discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
>>>>>
>>>>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they
>>>>> don't require big design and discussions and are mostly all actionable)
>>>>> * bug fixes
>>>>> * automated tests
>>>>> * migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
>>>>> * check proper handling of EntityListIterators
>>>>> * check proper handling of errors and exceptions in services, events, scripts
>>>>> * check proper handling of events/services messages
>>>>> * replace simple CRUD services with entity-auto services
>>>>> * refactor security handling in services to declare the security service in the service definition
>>>>> * identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for
>>>>> removal and reimplementation using DynamicEntityView API
>>>>> * identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they
>>>>> look very specific)
>>>>> * cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
>>>>> * review old events and verify if they can be converted into services
>>>>> * review old code and refactor/rewrite
>>>>> * review existing events/services
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Jacopo
>>>>>
>>>
>>>
>>> --
>>> Nicolas MALIN
>>> Consultant
>>> Tél : 06.17.66.40.06
>>> Site projet : http://www.neogia.org/
>>> -------
>>> Société LibrenBerry
>>> Tél : 02.48.02.56.12
>>> Site : http://www.librenberry.net/
Re: Some ideas to prepare our first community roadmap
Posted by Mansour Al Akeel <ma...@gmail.com>.
Paul,
adding a temp variable is not object oriented, but it just makes debugging and
stepping through the code easier. Thank you for pointing out that this
function is
called only three times in the whole code. If I am not wrong it's
called in loops.
May be this was bad example for introducing OO, but we agree that
having some sort
of structure and following some OO design pattern will make easier for
us to extend, and
bring contributions.
Anyhow, Paul, my point was, we just need some cleaning and organizing the code.
On Sat, Mar 24, 2012 at 2:15 AM, Paul Foxworthy <pa...@cohsoft.com.au> wrote:
> Hi Mansour,
>
> There is perhaps a code smell in your example, but IMHO your example is no
> improvement at all, and not more object oriented.
>
> A variable that is set once and read once like the three in your example is
> not pulling its weight, and it should be eliminated, so the original code is
> the better of the two. Neither approach is more or less object oriented.
>
> On the other hand, a series of dots is a code smell. It's a symptom of
> excessive coupling. The fix for that is not to introduce temporary
> variables. They just move the problem, add noise, obscure the fact that
> there is excessive coupling, and fractionally slow things down. A better
> fix, in principle, is to write a method to hide detail: "don't ask for data,
> ask for help".
>
> So a possible improvement might be to add a method getDelegatorInfos to the
> EntityConfigUtil class. Once again, that only makes sense if the method will
> be used several times. I've just done a quick search, and it seems to me
> that delegatorInfos is private to EntityConfigUtil and used on a total of
> three lines of code. If I'm right, I would live with the original code.
>
> Cheers
>
> Paul Foxworthy
>
>
> Mansour wrote
>>
>> Ok,
>> let's be clear about what I mean here, and explain a bit about what I
>> think.
>> I think it's better to keep the entity engine as is, with regard to
>> handling data, where it return records and not objects.
>>
>> However, OO can be done in the framework level. Cleaning the code a
>> bit, removing deprecated methods, rely less on static methods,
>> and use dependency injection. For example:
>>
>> public static DelegatorInfo getDelegatorInfo(String name) {
>> return configRef.get().delegatorInfos.get(name);
>> }
>>
>> can be replace by a little more verbose, but more readable:
>>
>> public static DelegatorInfo getDelegatorInfo(String name) {
>> EntityConfigUtil configUtil = configRef.get();
>> Map<String, DelegatorInfo> map = configUtil.delegatorInfos;
>> DelegatorInfo tmp = map.get(name);
>> return tmp;
>> }
>>
>> And really, instead of using static methods to lookup objects by name,
>> a container can used to track all this and
>> lookup those instances when needed. For example,
>> org.ofbiz.entity.model.ModelReader doesn't have to provide a static
>> method to be used a factory, so it can keep on tracking instances
>> created of itself. It's the job of the container.
>> Same thing applies to caching. We see caching code all over the place.
>> Code that does the lookup, but checking a
>> hashtable used as a cache before deciding to create an object.
>>
>> Cleaning the code, a bit and make it OO, will allow using Aspects for
>> things like this.
>>
>> This is what I meant by making the code more OO.
>>
>> Back again to the subject of ORMs. MyBatis, may be the fastest ORM I
>> have worked with, compared to JPA (hibernate, EclipseLink, ..etc).
>> While I didn't do a practical comparison with OfBiz entity engine, I
>> think ofbiz entity engine is the most optimized, and fastest,
>> because it's closer to JDBC than any other ORM framework. I am not
>> sure if any optimization can be with the EE beside cleaning the code
>> a bit, and refactoring.
>>
>>
>>
>> On Fri, Mar 23, 2012 at 9:27 AM, Prince Sewani <princesewani@>
>> wrote:
>>> Yeah making it more OO is what I'm actually referring to, OFBiz
>>> entity-engine is
>>> a different architecture altogether if we compare it to other existing
>>> counter-parts like hibernate and
>>>
>>> Ibatis, I haven't really looked at the query generation code, but does
>>> anyone thinks that it needs a
>>>
>>> bit more optimization? I know I'm talking at a very high level despite
>>> of checking out the
>>> implementation, Also for cases where we need to plug-in our queries (And
>>> I really mean SQL Queries) there should be additional methods in
>>>
>>> GenericDelegator to achieve it, in the current scenario we've to make an
>>> instace of SQLProcessor to get that done,
>>> I'm not sure, but it must be a singleton as per my understanding, Is
>>> there any way to get that existing Singleton
>>>
>>> in our code using some method, If not we should think of that too, it
>>> would make OFBiz Entity Engine
>>>
>>> superior to its counterparts and that idea of permissions at the entity
>>> level is awesome!!
>>>
>>> P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what
>>> to be done.
>>>
>>> Regards
>>> Prince
>>>
>>>
>>>
>>> ________________________________
>>> From: Mansour Al Akeel <mansour.alakeel@>
>>> To: dev@.apache; Prince Sewani <princesewani@>
>>> Sent: Friday, March 23, 2012 6:37 PM
>>> Subject: Re: Some ideas to prepare our first community roadmap
>>>
>>> For me +1 to refactor.
>>>
>>> I am not sure the ORM needs any work. May be I am missing something.
>>> Please let me know what part ?
>>>
>>> Just cleaning the entity engine code a bit, and make it more OO, will
>>> make it easier to work with.
>>> For example, I like to add a custom Delegator that will append some
>>> fields to each query and will enforce Row Level Security.
>>> For example, adding something like "acl.xml" next to the entity
>>> definitions, which contains the rules about the access.
>>> I know Oracle database has what is called virtual Private Database,
>>> and will be nice to have something similar instead of checking for
>>> access control in each service call.
>>> Just looking at the code currently there, makes the idea goes away.
>>> Refactoring the code will make things a bit easier.
>>>
>>> Ofbiz currently uses its own container to load all it's component. I
>>> was not able to find a lot of docs. May be missed them.
>>> I don't know if using alternative container is a reasonable suggestion.
>>>
>>> I see a lot of documentations and examples about using IoC containers
>>> with tomcat/jetty/geronimo and OSGI.
>>>
>>>
>>> On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani <princesewani@>
>>> wrote:
>>>>
>>>>
>>>> +1 to the Refractor, Have a few questions and a few suggestions :
>>>> Questions :
>>>>
>>>>
>>>> Are we looking to improve upon the ORM as well ?
>>>>
>>>> And what about the OSGI stuff, are we planning something on that to
>>>> enhance the plug-in approach?
>>>>
>>>> What's all about the extra stuff? are we just gonna keep 'em separately
>>>> and maintain 'em separately or are we
>>>> really commercializing?
>>>>
>>>> Also, What all is that we're thinking to add on to the existing
>>>> application or are we just looking to reduce/resize and enhance what all
>>>> is there?
>>>>
>>>>
>>>> Suggestions :
>>>>
>>>> Google Base Component : Google has upgraded to Google Content API long
>>>> back so the one in 10.04 no more works to upload products to Google
>>>> merchant
>>>> haven't checked 11.04 yet.
>>>>
>>>> eBay and eBay Store could be merged together and there's also no
>>>> functionality to post variants to eBay, I wrote some custom code as
>>>>
>>>> part of a POC for that, also customer grievances from eBay is something
>>>> that's missing.
>>>>
>>>> Integration with Amazon using Amazon MWS will be cool.
>>>>
>>>> Upgrade for Fedex API as they're retiring the SOAP API that is currently
>>>> used, on 31st may 2012.
>>>>
>>>> Also I'm ready to volunteer any component at any level, be it a
>>>> committer or not.
>>>> I'm very much excited about the massive change that we're about to bring
>>>> as a community to
>>>>
>>>> the application.
>>>>
>>>> Regards
>>>> Prince
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>> From: Nicolas Malin <malin.nicolas@>
>>>> To: dev@.apache
>>>> Sent: Friday, March 23, 2012 4:21 PM
>>>> Subject: Re: Some ideas to prepare our first community roadmap
>>>>
>>>> +1 a greate roadmap with lot of works
>>>>
>>>> On refactoring idea :
>>>> * review/improve best pratice screen (to manage icons, strong table
>>>> line, ...), I had started on this subject but not finalize.
>>>>
>>>> Nicolas
>>>>
>>>> Le 23/03/2012 11:07, Scott Gray a écrit :
>>>>> I'm in favor of all of those things so +1 from me.
>>>>>
>>>>> For a JIRA version, how about 13.04? :-)
>>>>>
>>>>> One other topic that's been on my mind, payment gateway
>>>>> implementations:
>>>>> - Move the test implementation into it's own class so that it isn't
>>>>> overcrowding PaymentGatewayServices and is consistent with the others
>>>>> - Refactor the test implementation so that you can use the C V V code
>>>>> to test different behaviors instead of having a bunch of different
>>>>> methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
>>>>> - Ensure consistency between the implementations and better document
>>>>> the gateway interfaces. Also remove virtually all database calls from
>>>>> the implementations (they run in their own transaction which can be
>>>>> painful when querying new data).
>>>>> - After cleaning them up, consider moving some of the implementations
>>>>> to Extras, I would prefer all of them except test but we could start
>>>>> with some of the more obscure ones at least
>>>>>
>>>>> Oh and another one on my wish list:
>>>>> - Finish the query builder implementation that I started a year or two
>>>>> ago and deprecate the bulk of the delegator find methods.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> now that the great community discussion about the "Lose Weight
>>>>>> Program" for OFBiz is settling down (thanks to all of you for the
>>>>>> great ideas, enthusiasm and participation) we can start to wrap up a
>>>>>> roadmap (it would be nice to set it up in Jira, using a specific "Jira
>>>>>> version" so that we can keep track of progress together... any ideas
>>>>>> for a good name for it?) by listing the actionable items and also by
>>>>>> considering other topics that may be of interest to the community.
>>>>>> This thread is an attempt to integrate the roadmap with some
>>>>>> additional tasks if the community will consider them a priority.
>>>>>>
>>>>>> But first of all, here is the list with a categorization/summary of
>>>>>> the tasks being discussed so far:
>>>>>>
>>>>>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized
>>>>>> we will create tasks in Jira for each):
>>>>>> * setup a nice page in the OFBiz website to describe the OFBiz Extras
>>>>>> ecosystem (external project names will be added there); the OFBiz PMC
>>>>>> will have to work on this (also check if there is additional paperwork
>>>>>> to do)
>>>>>> * move some of the component/code to Extras: we will create individual
>>>>>> Jira tasks for each component and then design details (how to move)
>>>>>> will be discussed in the task; we will need volunteers (committers and
>>>>>> not) to contribute patches/commits and also at least one maintainer
>>>>>> (OFBiz committer or not) for each component
>>>>>> * move some of the component/code to Attic: we will create individual
>>>>>> Jira tasks for each removal and then design details (how to remove)
>>>>>> will be discussed in the tasks; we will need volunteers (committers
>>>>>> and not) to contribute patches/commits
>>>>>>
>>>>>> The above will form the first part of the roadmap.
>>>>>>
>>>>>> ====
>>>>>>
>>>>>> The following list is simply my personal attempt to propose some
>>>>>> priorities for the community; some of them are based on comments from
>>>>>> people on the dev list, some of them are personal ideas based on some
>>>>>> reviews I did to the OFBiz codebase.
>>>>>> Feel free to add/remove items to the list but please while doing this
>>>>>> consider that we are discussing candidate tasks for an OFBiz roadmap
>>>>>> shared by the community: when the list will be discussed, approved and
>>>>>> finalized the community will have a clear roadmap to focus on (with
>>>>>> all contributions/commits going in this direction); but this also
>>>>>> means that the tasks/goals need to be enough generic to gather
>>>>>> consensus on a larger group of people (otherwise each individual
>>>>>> committer will end up proposing her own specific item to the list, of
>>>>>> less interest to the community, and then she will start working on
>>>>>> it... instead of better spending the time that she decided to
>>>>>> "contribute" to tasks that the community really considers important)
>>>>>> and they shouldn't be too big (gathering consensus and implementing as
>>>>>> a community will take a lot of time). If we will not find an agreement
>>>>>> on some items or a large consensus then it will be fine: the roadmap
>>>>>> will be
>>>> lighter and will be completed earlier; at that point we will discuss
>>>> again what we want to do next.
>>>>>> Even if no big tasks will be added to the roadmap, I think it will
>>>>>> still be an interesting one focused on "maintenance" and "quality".
>>>>>>
>>>>>> BIG TASKS (these are potentially big tasks that may be difficult to
>>>>>> plan in this first roadmap... but it may make sense to try to see if
>>>>>> we can find an agreement for some actionable tasks)
>>>>>> * resolving framework dependencies on applications (this is *not*
>>>>>> about "refactoring" the framework, simply to resolve its dependencies
>>>>>> on applications)
>>>>>> * gather requirements (from existing applications), design and
>>>>>> implement JCR/Jackrabbit and replace parts of the existing Content
>>>>>> Framework with it
>>>>>> * discuss, design and implement (if needed) or define best practices
>>>>>> for a plug in architecture
>>>>>> * discuss, design and implement (if needed) or define best practices
>>>>>> for an integrated reporting tool for OFBiz
>>>>>>
>>>>>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that
>>>>>> should be easy to include in the roadmap because they don't require
>>>>>> big design and discussions and are mostly all actionable)
>>>>>> * bug fixes
>>>>>> * automated tests
>>>>>> * migration from Beanshell to Groovy (i.e. continue in the trunk the
>>>>>> work started in the branch)
>>>>>> * check proper handling of EntityListIterators
>>>>>> * check proper handling of errors and exceptions in services, events,
>>>>>> scripts
>>>>>> * check proper handling of events/services messages
>>>>>> * replace simple CRUD services with entity-auto services
>>>>>> * refactor security handling in services to declare the security
>>>>>> service in the service definition
>>>>>> * identify all view-entity definitions that are only used in one place
>>>>>> (or never used): they may be good candidates for removal and
>>>>>> reimplementation using DynamicEntityView API
>>>>>> * identify all services that are used only in one place (or never
>>>>>> used): they may be removed and inlined (especially if they look very
>>>>>> specific)
>>>>>> * cleanup (following some best practices - to be defined- for names)
>>>>>> and improve service names and descriptions
>>>>>> * review old events and verify if they can be converted into services
>>>>>> * review old code and refactor/rewrite
>>>>>> * review existing events/services
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>
>>>>
>>>> --
>>>> Nicolas MALIN
>>>> Consultant
>>>> Tél : 06.17.66.40.06
>>>> Site projet : http://www.neogia.org/
>>>> -------
>>>> Société LibrenBerry
>>>> Tél : 02.48.02.56.12
>>>> Site : http://www.librenberry.net/
>>
>
> -----
> --
> Coherent Software Australia Pty Ltd
> http://www.cohsoft.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-to-prepare-our-first-community-roadmap-tp4495191p4500883.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Some ideas to prepare our first community roadmap
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
Hi Mansour,
There is perhaps a code smell in your example, but IMHO your example is no
improvement at all, and not more object oriented.
A variable that is set once and read once like the three in your example is
not pulling its weight, and it should be eliminated, so the original code is
the better of the two. Neither approach is more or less object oriented.
On the other hand, a series of dots is a code smell. It's a symptom of
excessive coupling. The fix for that is not to introduce temporary
variables. They just move the problem, add noise, obscure the fact that
there is excessive coupling, and fractionally slow things down. A better
fix, in principle, is to write a method to hide detail: "don't ask for data,
ask for help".
So a possible improvement might be to add a method getDelegatorInfos to the
EntityConfigUtil class. Once again, that only makes sense if the method will
be used several times. I've just done a quick search, and it seems to me
that delegatorInfos is private to EntityConfigUtil and used on a total of
three lines of code. If I'm right, I would live with the original code.
Cheers
Paul Foxworthy
Mansour wrote
>
> Ok,
> let's be clear about what I mean here, and explain a bit about what I
> think.
> I think it's better to keep the entity engine as is, with regard to
> handling data, where it return records and not objects.
>
> However, OO can be done in the framework level. Cleaning the code a
> bit, removing deprecated methods, rely less on static methods,
> and use dependency injection. For example:
>
> public static DelegatorInfo getDelegatorInfo(String name) {
> return configRef.get().delegatorInfos.get(name);
> }
>
> can be replace by a little more verbose, but more readable:
>
> public static DelegatorInfo getDelegatorInfo(String name) {
> EntityConfigUtil configUtil = configRef.get();
> Map<String, DelegatorInfo> map = configUtil.delegatorInfos;
> DelegatorInfo tmp = map.get(name);
> return tmp;
> }
>
> And really, instead of using static methods to lookup objects by name,
> a container can used to track all this and
> lookup those instances when needed. For example,
> org.ofbiz.entity.model.ModelReader doesn't have to provide a static
> method to be used a factory, so it can keep on tracking instances
> created of itself. It's the job of the container.
> Same thing applies to caching. We see caching code all over the place.
> Code that does the lookup, but checking a
> hashtable used as a cache before deciding to create an object.
>
> Cleaning the code, a bit and make it OO, will allow using Aspects for
> things like this.
>
> This is what I meant by making the code more OO.
>
> Back again to the subject of ORMs. MyBatis, may be the fastest ORM I
> have worked with, compared to JPA (hibernate, EclipseLink, ..etc).
> While I didn't do a practical comparison with OfBiz entity engine, I
> think ofbiz entity engine is the most optimized, and fastest,
> because it's closer to JDBC than any other ORM framework. I am not
> sure if any optimization can be with the EE beside cleaning the code
> a bit, and refactoring.
>
>
>
> On Fri, Mar 23, 2012 at 9:27 AM, Prince Sewani <princesewani@>
> wrote:
>> Yeah making it more OO is what I'm actually referring to, OFBiz
>> entity-engine is
>> a different architecture altogether if we compare it to other existing
>> counter-parts like hibernate and
>>
>> Ibatis, I haven't really looked at the query generation code, but does
>> anyone thinks that it needs a
>>
>> bit more optimization? I know I'm talking at a very high level despite
>> of checking out the
>> implementation, Also for cases where we need to plug-in our queries (And
>> I really mean SQL Queries) there should be additional methods in
>>
>> GenericDelegator to achieve it, in the current scenario we've to make an
>> instace of SQLProcessor to get that done,
>> I'm not sure, but it must be a singleton as per my understanding, Is
>> there any way to get that existing Singleton
>>
>> in our code using some method, If not we should think of that too, it
>> would make OFBiz Entity Engine
>>
>> superior to its counterparts and that idea of permissions at the entity
>> level is awesome!!
>>
>> P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what
>> to be done.
>>
>> Regards
>> Prince
>>
>>
>>
>> ________________________________
>> From: Mansour Al Akeel <mansour.alakeel@>
>> To: dev@.apache; Prince Sewani <princesewani@>
>> Sent: Friday, March 23, 2012 6:37 PM
>> Subject: Re: Some ideas to prepare our first community roadmap
>>
>> For me +1 to refactor.
>>
>> I am not sure the ORM needs any work. May be I am missing something.
>> Please let me know what part ?
>>
>> Just cleaning the entity engine code a bit, and make it more OO, will
>> make it easier to work with.
>> For example, I like to add a custom Delegator that will append some
>> fields to each query and will enforce Row Level Security.
>> For example, adding something like "acl.xml" next to the entity
>> definitions, which contains the rules about the access.
>> I know Oracle database has what is called virtual Private Database,
>> and will be nice to have something similar instead of checking for
>> access control in each service call.
>> Just looking at the code currently there, makes the idea goes away.
>> Refactoring the code will make things a bit easier.
>>
>> Ofbiz currently uses its own container to load all it's component. I
>> was not able to find a lot of docs. May be missed them.
>> I don't know if using alternative container is a reasonable suggestion.
>>
>> I see a lot of documentations and examples about using IoC containers
>> with tomcat/jetty/geronimo and OSGI.
>>
>>
>> On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani <princesewani@>
>> wrote:
>>>
>>>
>>> +1 to the Refractor, Have a few questions and a few suggestions :
>>> Questions :
>>>
>>>
>>> Are we looking to improve upon the ORM as well ?
>>>
>>> And what about the OSGI stuff, are we planning something on that to
>>> enhance the plug-in approach?
>>>
>>> What's all about the extra stuff? are we just gonna keep 'em separately
>>> and maintain 'em separately or are we
>>> really commercializing?
>>>
>>> Also, What all is that we're thinking to add on to the existing
>>> application or are we just looking to reduce/resize and enhance what all
>>> is there?
>>>
>>>
>>> Suggestions :
>>>
>>> Google Base Component : Google has upgraded to Google Content API long
>>> back so the one in 10.04 no more works to upload products to Google
>>> merchant
>>> haven't checked 11.04 yet.
>>>
>>> eBay and eBay Store could be merged together and there's also no
>>> functionality to post variants to eBay, I wrote some custom code as
>>>
>>> part of a POC for that, also customer grievances from eBay is something
>>> that's missing.
>>>
>>> Integration with Amazon using Amazon MWS will be cool.
>>>
>>> Upgrade for Fedex API as they're retiring the SOAP API that is currently
>>> used, on 31st may 2012.
>>>
>>> Also I'm ready to volunteer any component at any level, be it a
>>> committer or not.
>>> I'm very much excited about the massive change that we're about to bring
>>> as a community to
>>>
>>> the application.
>>>
>>> Regards
>>> Prince
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: Nicolas Malin <malin.nicolas@>
>>> To: dev@.apache
>>> Sent: Friday, March 23, 2012 4:21 PM
>>> Subject: Re: Some ideas to prepare our first community roadmap
>>>
>>> +1 a greate roadmap with lot of works
>>>
>>> On refactoring idea :
>>> * review/improve best pratice screen (to manage icons, strong table
>>> line, ...), I had started on this subject but not finalize.
>>>
>>> Nicolas
>>>
>>> Le 23/03/2012 11:07, Scott Gray a écrit :
>>>> I'm in favor of all of those things so +1 from me.
>>>>
>>>> For a JIRA version, how about 13.04? :-)
>>>>
>>>> One other topic that's been on my mind, payment gateway
>>>> implementations:
>>>> - Move the test implementation into it's own class so that it isn't
>>>> overcrowding PaymentGatewayServices and is consistent with the others
>>>> - Refactor the test implementation so that you can use the C V V code
>>>> to test different behaviors instead of having a bunch of different
>>>> methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
>>>> - Ensure consistency between the implementations and better document
>>>> the gateway interfaces. Also remove virtually all database calls from
>>>> the implementations (they run in their own transaction which can be
>>>> painful when querying new data).
>>>> - After cleaning them up, consider moving some of the implementations
>>>> to Extras, I would prefer all of them except test but we could start
>>>> with some of the more obscure ones at least
>>>>
>>>> Oh and another one on my wish list:
>>>> - Finish the query builder implementation that I started a year or two
>>>> ago and deprecate the bulk of the delegator find methods.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> now that the great community discussion about the "Lose Weight
>>>>> Program" for OFBiz is settling down (thanks to all of you for the
>>>>> great ideas, enthusiasm and participation) we can start to wrap up a
>>>>> roadmap (it would be nice to set it up in Jira, using a specific "Jira
>>>>> version" so that we can keep track of progress together... any ideas
>>>>> for a good name for it?) by listing the actionable items and also by
>>>>> considering other topics that may be of interest to the community.
>>>>> This thread is an attempt to integrate the roadmap with some
>>>>> additional tasks if the community will consider them a priority.
>>>>>
>>>>> But first of all, here is the list with a categorization/summary of
>>>>> the tasks being discussed so far:
>>>>>
>>>>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized
>>>>> we will create tasks in Jira for each):
>>>>> * setup a nice page in the OFBiz website to describe the OFBiz Extras
>>>>> ecosystem (external project names will be added there); the OFBiz PMC
>>>>> will have to work on this (also check if there is additional paperwork
>>>>> to do)
>>>>> * move some of the component/code to Extras: we will create individual
>>>>> Jira tasks for each component and then design details (how to move)
>>>>> will be discussed in the task; we will need volunteers (committers and
>>>>> not) to contribute patches/commits and also at least one maintainer
>>>>> (OFBiz committer or not) for each component
>>>>> * move some of the component/code to Attic: we will create individual
>>>>> Jira tasks for each removal and then design details (how to remove)
>>>>> will be discussed in the tasks; we will need volunteers (committers
>>>>> and not) to contribute patches/commits
>>>>>
>>>>> The above will form the first part of the roadmap.
>>>>>
>>>>> ====
>>>>>
>>>>> The following list is simply my personal attempt to propose some
>>>>> priorities for the community; some of them are based on comments from
>>>>> people on the dev list, some of them are personal ideas based on some
>>>>> reviews I did to the OFBiz codebase.
>>>>> Feel free to add/remove items to the list but please while doing this
>>>>> consider that we are discussing candidate tasks for an OFBiz roadmap
>>>>> shared by the community: when the list will be discussed, approved and
>>>>> finalized the community will have a clear roadmap to focus on (with
>>>>> all contributions/commits going in this direction); but this also
>>>>> means that the tasks/goals need to be enough generic to gather
>>>>> consensus on a larger group of people (otherwise each individual
>>>>> committer will end up proposing her own specific item to the list, of
>>>>> less interest to the community, and then she will start working on
>>>>> it... instead of better spending the time that she decided to
>>>>> "contribute" to tasks that the community really considers important)
>>>>> and they shouldn't be too big (gathering consensus and implementing as
>>>>> a community will take a lot of time). If we will not find an agreement
>>>>> on some items or a large consensus then it will be fine: the roadmap
>>>>> will be
>>> lighter and will be completed earlier; at that point we will discuss
>>> again what we want to do next.
>>>>> Even if no big tasks will be added to the roadmap, I think it will
>>>>> still be an interesting one focused on "maintenance" and "quality".
>>>>>
>>>>> BIG TASKS (these are potentially big tasks that may be difficult to
>>>>> plan in this first roadmap... but it may make sense to try to see if
>>>>> we can find an agreement for some actionable tasks)
>>>>> * resolving framework dependencies on applications (this is *not*
>>>>> about "refactoring" the framework, simply to resolve its dependencies
>>>>> on applications)
>>>>> * gather requirements (from existing applications), design and
>>>>> implement JCR/Jackrabbit and replace parts of the existing Content
>>>>> Framework with it
>>>>> * discuss, design and implement (if needed) or define best practices
>>>>> for a plug in architecture
>>>>> * discuss, design and implement (if needed) or define best practices
>>>>> for an integrated reporting tool for OFBiz
>>>>>
>>>>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that
>>>>> should be easy to include in the roadmap because they don't require
>>>>> big design and discussions and are mostly all actionable)
>>>>> * bug fixes
>>>>> * automated tests
>>>>> * migration from Beanshell to Groovy (i.e. continue in the trunk the
>>>>> work started in the branch)
>>>>> * check proper handling of EntityListIterators
>>>>> * check proper handling of errors and exceptions in services, events,
>>>>> scripts
>>>>> * check proper handling of events/services messages
>>>>> * replace simple CRUD services with entity-auto services
>>>>> * refactor security handling in services to declare the security
>>>>> service in the service definition
>>>>> * identify all view-entity definitions that are only used in one place
>>>>> (or never used): they may be good candidates for removal and
>>>>> reimplementation using DynamicEntityView API
>>>>> * identify all services that are used only in one place (or never
>>>>> used): they may be removed and inlined (especially if they look very
>>>>> specific)
>>>>> * cleanup (following some best practices - to be defined- for names)
>>>>> and improve service names and descriptions
>>>>> * review old events and verify if they can be converted into services
>>>>> * review old code and refactor/rewrite
>>>>> * review existing events/services
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Jacopo
>>>>>
>>>
>>>
>>> --
>>> Nicolas MALIN
>>> Consultant
>>> Tél : 06.17.66.40.06
>>> Site projet : http://www.neogia.org/
>>> -------
>>> Société LibrenBerry
>>> Tél : 02.48.02.56.12
>>> Site : http://www.librenberry.net/
>
-----
--
Coherent Software Australia Pty Ltd
http://www.cohsoft.com.au/
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-to-prepare-our-first-community-roadmap-tp4495191p4500883.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Some ideas to prepare our first community roadmap
Posted by Mansour Al Akeel <ma...@gmail.com>.
Jacques,
thank you for encouraging me to contribute. I will discuss new ideas
when I know I can apply them.
I have a firm believe that the value of any idea, becomes useless when
the idea can not become real,
and remain an idea.
I will be wasting everyone else time, if I discuss something, I can
not complete.
Thank you.
On Fri, Mar 23, 2012 at 2:56 PM, Jacques Le Roux
<ja...@les7arts.com> wrote:
> Mansour,
>
> You are welcome to provide patches with test cases and explanations for all
> your ideas.
> But to no get frustrated by rejects, it's better before to discuss each
> point in details in this ML.
>
> The more brains, the better
>
> Jacques
>
>
> Mansour Al Akeel wrote:
>>
>> Ok,
>> let's be clear about what I mean here, and explain a bit about what I
>> think.
>> I think it's better to keep the entity engine as is, with regard to
>> handling data, where it return records and not objects.
>>
>> However, OO can be done in the framework level. Cleaning the code a
>> bit, removing deprecated methods, rely less on static methods,
>> and use dependency injection. For example:
>>
>> public static DelegatorInfo getDelegatorInfo(String name) {
>> return configRef.get().delegatorInfos.get(name);
>> }
>>
>> can be replace by a little more verbose, but more readable:
>>
>> public static DelegatorInfo getDelegatorInfo(String name) {
>> EntityConfigUtil configUtil = configRef.get();
>> Map<String, DelegatorInfo> map = configUtil.delegatorInfos;
>> DelegatorInfo tmp = map.get(name);
>> return tmp;
>> }
>>
>> And really, instead of using static methods to lookup objects by name,
>> a container can used to track all this and
>> lookup those instances when needed. For example,
>> org.ofbiz.entity.model.ModelReader doesn't have to provide a static
>> method to be used a factory, so it can keep on tracking instances
>> created of itself. It's the job of the container.
>> Same thing applies to caching. We see caching code all over the place.
>> Code that does the lookup, but checking a
>> hashtable used as a cache before deciding to create an object.
>>
>> Cleaning the code, a bit and make it OO, will allow using Aspects for
>> things like this.
>>
>> This is what I meant by making the code more OO.
>>
>> Back again to the subject of ORMs. MyBatis, may be the fastest ORM I
>> have worked with, compared to JPA (hibernate, EclipseLink, ..etc).
>> While I didn't do a practical comparison with OfBiz entity engine, I
>> think ofbiz entity engine is the most optimized, and fastest,
>> because it's closer to JDBC than any other ORM framework. I am not
>> sure if any optimization can be with the EE beside cleaning the code
>> a bit, and refactoring.
>>
>>
>>
>> On Fri, Mar 23, 2012 at 9:27 AM, Prince Sewani <pr...@ymail.com>
>> wrote:
>>>
>>> Yeah making it more OO is what I'm actually referring to, OFBiz
>>> entity-engine is
>>> a different architecture altogether if we compare it to other existing
>>> counter-parts like hibernate and
>>>
>>> Ibatis, I haven't really looked at the query generation code, but does
>>> anyone thinks that it needs a
>>>
>>> bit more optimization? I know I'm talking at a very high level despite of
>>> checking out the
>>> implementation, Also for cases where we need to plug-in our queries (And
>>> I really mean SQL Queries) there should be additional
>>> methods in
>>>
>>> GenericDelegator to achieve it, in the current scenario we've to make an
>>> instace of SQLProcessor to get that done,
>>> I'm not sure, but it must be a singleton as per my understanding, Is
>>> there any way to get that existing Singleton
>>>
>>> in our code using some method, If not we should think of that too, it
>>> would make OFBiz Entity Engine
>>>
>>> superior to its counterparts and that idea of permissions at the entity
>>> level is awesome!!
>>>
>>> P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what
>>> to be done.
>>>
>>> Regards
>>> Prince
>>>
>>>
>>>
>>> ________________________________
>>> From: Mansour Al Akeel <ma...@gmail.com>
>>> To: dev@ofbiz.apache.org; Prince Sewani <pr...@ymail.com>
>>> Sent: Friday, March 23, 2012 6:37 PM
>>> Subject: Re: Some ideas to prepare our first community roadmap
>>>
>>> For me +1 to refactor.
>>>
>>> I am not sure the ORM needs any work. May be I am missing something.
>>> Please let me know what part ?
>>>
>>> Just cleaning the entity engine code a bit, and make it more OO, will
>>> make it easier to work with.
>>> For example, I like to add a custom Delegator that will append some
>>> fields to each query and will enforce Row Level Security.
>>> For example, adding something like "acl.xml" next to the entity
>>> definitions, which contains the rules about the access.
>>> I know Oracle database has what is called virtual Private Database,
>>> and will be nice to have something similar instead of checking for
>>> access control in each service call.
>>> Just looking at the code currently there, makes the idea goes away.
>>> Refactoring the code will make things a bit easier.
>>>
>>> Ofbiz currently uses its own container to load all it's component. I
>>> was not able to find a lot of docs. May be missed them.
>>> I don't know if using alternative container is a reasonable suggestion.
>>>
>>> I see a lot of documentations and examples about using IoC containers
>>> with tomcat/jetty/geronimo and OSGI.
>>>
>>>
>>> On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani <pr...@ymail.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> +1 to the Refractor, Have a few questions and a few suggestions :
>>>> Questions :
>>>>
>>>>
>>>> Are we looking to improve upon the ORM as well ?
>>>>
>>>> And what about the OSGI stuff, are we planning something on that to
>>>> enhance the plug-in approach?
>>>>
>>>> What's all about the extra stuff? are we just gonna keep 'em separately
>>>> and maintain 'em separately or are we
>>>> really commercializing?
>>>>
>>>> Also, What all is that we're thinking to add on to the existing
>>>> application or are we just looking to reduce/resize and enhance
>>>> what all
>>>> is there?
>>>>
>>>>
>>>> Suggestions :
>>>>
>>>> Google Base Component : Google has upgraded to Google Content API long
>>>> back so the one in 10.04 no more works to upload
>>>> products to Google merchant haven't checked 11.04 yet.
>>>>
>>>> eBay and eBay Store could be merged together and there's also no
>>>> functionality to post variants to eBay, I wrote some custom
>>>> code as
>>>>
>>>> part of a POC for that, also customer grievances from eBay is something
>>>> that's missing.
>>>>
>>>> Integration with Amazon using Amazon MWS will be cool.
>>>>
>>>> Upgrade for Fedex API as they're retiring the SOAP API that is currently
>>>> used, on 31st may 2012.
>>>>
>>>> Also I'm ready to volunteer any component at any level, be it a
>>>> committer or not.
>>>> I'm very much excited about the massive change that we're about to bring
>>>> as a community to
>>>>
>>>> the application.
>>>>
>>>> Regards
>>>> Prince
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>> From: Nicolas Malin <ma...@librenberry.net>
>>>> To: dev@ofbiz.apache.org
>>>> Sent: Friday, March 23, 2012 4:21 PM
>>>> Subject: Re: Some ideas to prepare our first community roadmap
>>>>
>>>> +1 a greate roadmap with lot of works
>>>>
>>>> On refactoring idea :
>>>> * review/improve best pratice screen (to manage icons, strong table
>>>> line, ...), I had started on this subject but not finalize.
>>>>
>>>> Nicolas
>>>>
>>>> Le 23/03/2012 11:07, Scott Gray a écrit :
>>>>>
>>>>> I'm in favor of all of those things so +1 from me.
>>>>>
>>>>> For a JIRA version, how about 13.04? :-)
>>>>>
>>>>> One other topic that's been on my mind, payment gateway
>>>>> implementations:
>>>>> - Move the test implementation into it's own class so that it isn't
>>>>> overcrowding PaymentGatewayServices and is consistent with
>>>>> the others
>>>>> - Refactor the test implementation so that you can use the CVV code to
>>>>> test different behaviors instead of having a bunch of
>>>>> different methods like alwaysDecline, randomlyDecline, alwaysApprove
>>>>> etc. etc.
>>>>> - Ensure consistency between the implementations and better document
>>>>> the gateway interfaces. Also remove virtually all
>>>>> database calls from the implementations (they run in their own
>>>>> transaction which can be painful when querying new data).
>>>>> - After cleaning them up, consider moving some of the implementations
>>>>> to Extras, I would prefer all of them except test but we
>>>>> could start with some of the more obscure ones at least
>>>>>
>>>>> Oh and another one on my wish list:
>>>>> - Finish the query builder implementation that I started a year or two
>>>>> ago and deprecate the bulk of the delegator find
>>>>> methods.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> now that the great community discussion about the "Lose Weight
>>>>>> Program" for OFBiz is settling down (thanks to all of you for
>>>>>> the great ideas, enthusiasm and participation) we can start to wrap up
>>>>>> a roadmap (it would be nice to set it up in Jira,
>>>>>> using a specific "Jira version" so that we can keep track of progress
>>>>>> together... any ideas for a good name for it?) by
>>>>>> listing the actionable items and also by considering other topics that
>>>>>> may be of interest to the community.
>>>>>> This thread is an attempt to integrate the roadmap with some
>>>>>> additional tasks if the community will consider them a priority.
>>>>>>
>>>>>> But first of all, here is the list with a categorization/summary of
>>>>>> the tasks being discussed so far:
>>>>>>
>>>>>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized
>>>>>> we will create tasks in Jira for each):
>>>>>> * setup a nice page in the OFBiz website to describe the OFBiz Extras
>>>>>> ecosystem (external project names will be added there);
>>>>>> the OFBiz PMC will have to work on this (also check if there is
>>>>>> additional paperwork to do)
>>>>>> * move some of the component/code to Extras: we will create individual
>>>>>> Jira tasks for each component and then design details
>>>>>> (how to move) will be discussed in the task; we will need volunteers
>>>>>> (committers and not) to contribute patches/commits and
>>>>>> also at least one maintainer (OFBiz committer or not) for each
>>>>>> component
>>>>>> * move some of the component/code to Attic: we will create individual
>>>>>> Jira tasks for each removal and then design details
>>>>>> (how to remove) will be discussed in the tasks; we will need
>>>>>> volunteers (committers and not) to contribute patches/commits
>>>>>>
>>>>>> The above will form the first part of the roadmap.
>>>>>>
>>>>>> ====
>>>>>>
>>>>>> The following list is simply my personal attempt to propose some
>>>>>> priorities for the community; some of them are based on
>>>>>> comments from people on the dev list, some of them are personal ideas
>>>>>> based on some reviews I did to the OFBiz codebase.
>>>>>> Feel free to add/remove items to the list but please while doing this
>>>>>> consider that we are discussing candidate tasks for an
>>>>>> OFBiz roadmap shared by the community: when the list will be
>>>>>> discussed, approved and finalized the community will have a
>>>>>> clear roadmap to focus on (with all contributions/commits going in
>>>>>> this direction); but this also means that the tasks/goals
>>>>>> need to be enough generic to gather consensus on a larger group of
>>>>>> people (otherwise each individual committer will end up
>>>>>> proposing her own specific item to the list, of less interest to the
>>>>>> community, and then she will start working on it...
>>>>>> instead of better spending the time that she decided to "contribute"
>>>>>> to tasks that the community really considers important)
>>>>>> and they shouldn't be too big (gathering consensus and implementing as
>>>>>> a community will take a lot of time). If we will not
>>>>>> find an agreement on some items or a large consensus then it will be
>>>>>> fine: the roadmap will be
>>>>
>>>> lighter and will be completed earlier; at that point we will discuss
>>>> again what we want to do next.
>>>>>>
>>>>>> Even if no big tasks will be added to the roadmap, I think it will
>>>>>> still be an interesting one focused on "maintenance" and
>>>>>> "quality".
>>>>>>
>>>>>> BIG TASKS (these are potentially big tasks that may be difficult to
>>>>>> plan in this first roadmap... but it may make sense to
>>>>>> try to see if we can find an agreement for some actionable tasks)
>>>>>> * resolving framework dependencies on applications (this is *not*
>>>>>> about "refactoring" the framework, simply to resolve its
>>>>>> dependencies on applications)
>>>>>> * gather requirements (from existing applications), design and
>>>>>> implement JCR/Jackrabbit and replace parts of the existing
>>>>>> Content Framework with it
>>>>>> * discuss, design and implement (if needed) or define best practices
>>>>>> for a plug in architecture
>>>>>> * discuss, design and implement (if needed) or define best practices
>>>>>> for an integrated reporting tool for OFBiz
>>>>>>
>>>>>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that
>>>>>> should be easy to include in the roadmap because they
>>>>>> don't require big design and discussions and are mostly all
>>>>>> actionable)
>>>>>> * bug fixes
>>>>>> * automated tests
>>>>>> * migration from Beanshell to Groovy (i.e. continue in the trunk the
>>>>>> work started in the branch)
>>>>>> * check proper handling of EntityListIterators
>>>>>> * check proper handling of errors and exceptions in services, events,
>>>>>> scripts
>>>>>> * check proper handling of events/services messages
>>>>>> * replace simple CRUD services with entity-auto services
>>>>>> * refactor security handling in services to declare the security
>>>>>> service in the service definition
>>>>>> * identify all view-entity definitions that are only used in one place
>>>>>> (or never used): they may be good candidates for
>>>>>> removal and reimplementation using DynamicEntityView API
>>>>>> * identify all services that are used only in one place (or never
>>>>>> used): they may be removed and inlined (especially if they
>>>>>> look very specific)
>>>>>> * cleanup (following some best practices - to be defined- for names)
>>>>>> and improve service names and descriptions
>>>>>> * review old events and verify if they can be converted into services
>>>>>> * review old code and refactor/rewrite
>>>>>> * review existing events/services
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>
>>>>
>>>> --
>>>> Nicolas MALIN
>>>> Consultant
>>>> Tél : 06.17.66.40.06
>>>> Site projet : http://www.neogia.org/
>>>> -------
>>>> Société LibrenBerry
>>>> Tél : 02.48.02.56.12
>>>> Site : http://www.librenberry.net/
Re: Some ideas to prepare our first community roadmap
Posted by Jacques Le Roux <ja...@les7arts.com>.
Mansour,
You are welcome to provide patches with test cases and explanations for all your ideas.
But to no get frustrated by rejects, it's better before to discuss each point in details in this ML.
The more brains, the better
Jacques
Mansour Al Akeel wrote:
> Ok,
> let's be clear about what I mean here, and explain a bit about what I think.
> I think it's better to keep the entity engine as is, with regard to
> handling data, where it return records and not objects.
>
> However, OO can be done in the framework level. Cleaning the code a
> bit, removing deprecated methods, rely less on static methods,
> and use dependency injection. For example:
>
> public static DelegatorInfo getDelegatorInfo(String name) {
> return configRef.get().delegatorInfos.get(name);
> }
>
> can be replace by a little more verbose, but more readable:
>
> public static DelegatorInfo getDelegatorInfo(String name) {
> EntityConfigUtil configUtil = configRef.get();
> Map<String, DelegatorInfo> map = configUtil.delegatorInfos;
> DelegatorInfo tmp = map.get(name);
> return tmp;
> }
>
> And really, instead of using static methods to lookup objects by name,
> a container can used to track all this and
> lookup those instances when needed. For example,
> org.ofbiz.entity.model.ModelReader doesn't have to provide a static
> method to be used a factory, so it can keep on tracking instances
> created of itself. It's the job of the container.
> Same thing applies to caching. We see caching code all over the place.
> Code that does the lookup, but checking a
> hashtable used as a cache before deciding to create an object.
>
> Cleaning the code, a bit and make it OO, will allow using Aspects for
> things like this.
>
> This is what I meant by making the code more OO.
>
> Back again to the subject of ORMs. MyBatis, may be the fastest ORM I
> have worked with, compared to JPA (hibernate, EclipseLink, ..etc).
> While I didn't do a practical comparison with OfBiz entity engine, I
> think ofbiz entity engine is the most optimized, and fastest,
> because it's closer to JDBC than any other ORM framework. I am not
> sure if any optimization can be with the EE beside cleaning the code
> a bit, and refactoring.
>
>
>
> On Fri, Mar 23, 2012 at 9:27 AM, Prince Sewani <pr...@ymail.com> wrote:
>> Yeah making it more OO is what I'm actually referring to, OFBiz entity-engine is
>> a different architecture altogether if we compare it to other existing counter-parts like hibernate and
>>
>> Ibatis, I haven't really looked at the query generation code, but does anyone thinks that it needs a
>>
>> bit more optimization? I know I'm talking at a very high level despite of checking out the
>> implementation, Also for cases where we need to plug-in our queries (And I really mean SQL Queries) there should be additional
>> methods in
>>
>> GenericDelegator to achieve it, in the current scenario we've to make an instace of SQLProcessor to get that done,
>> I'm not sure, but it must be a singleton as per my understanding, Is there any way to get that existing Singleton
>>
>> in our code using some method, If not we should think of that too, it would make OFBiz Entity Engine
>>
>> superior to its counterparts and that idea of permissions at the entity level is awesome!!
>>
>> P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what to be done.
>>
>> Regards
>> Prince
>>
>>
>>
>> ________________________________
>> From: Mansour Al Akeel <ma...@gmail.com>
>> To: dev@ofbiz.apache.org; Prince Sewani <pr...@ymail.com>
>> Sent: Friday, March 23, 2012 6:37 PM
>> Subject: Re: Some ideas to prepare our first community roadmap
>>
>> For me +1 to refactor.
>>
>> I am not sure the ORM needs any work. May be I am missing something.
>> Please let me know what part ?
>>
>> Just cleaning the entity engine code a bit, and make it more OO, will
>> make it easier to work with.
>> For example, I like to add a custom Delegator that will append some
>> fields to each query and will enforce Row Level Security.
>> For example, adding something like "acl.xml" next to the entity
>> definitions, which contains the rules about the access.
>> I know Oracle database has what is called virtual Private Database,
>> and will be nice to have something similar instead of checking for
>> access control in each service call.
>> Just looking at the code currently there, makes the idea goes away.
>> Refactoring the code will make things a bit easier.
>>
>> Ofbiz currently uses its own container to load all it's component. I
>> was not able to find a lot of docs. May be missed them.
>> I don't know if using alternative container is a reasonable suggestion.
>>
>> I see a lot of documentations and examples about using IoC containers
>> with tomcat/jetty/geronimo and OSGI.
>>
>>
>> On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani <pr...@ymail.com> wrote:
>>>
>>>
>>> +1 to the Refractor, Have a few questions and a few suggestions :
>>> Questions :
>>>
>>>
>>> Are we looking to improve upon the ORM as well ?
>>>
>>> And what about the OSGI stuff, are we planning something on that to enhance the plug-in approach?
>>>
>>> What's all about the extra stuff? are we just gonna keep 'em separately and maintain 'em separately or are we
>>> really commercializing?
>>>
>>> Also, What all is that we're thinking to add on to the existing application or are we just looking to reduce/resize and enhance
>>> what all
>>> is there?
>>>
>>>
>>> Suggestions :
>>>
>>> Google Base Component : Google has upgraded to Google Content API long back so the one in 10.04 no more works to upload
>>> products to Google merchant haven't checked 11.04 yet.
>>>
>>> eBay and eBay Store could be merged together and there's also no functionality to post variants to eBay, I wrote some custom
>>> code as
>>>
>>> part of a POC for that, also customer grievances from eBay is something that's missing.
>>>
>>> Integration with Amazon using Amazon MWS will be cool.
>>>
>>> Upgrade for Fedex API as they're retiring the SOAP API that is currently used, on 31st may 2012.
>>>
>>> Also I'm ready to volunteer any component at any level, be it a committer or not.
>>> I'm very much excited about the massive change that we're about to bring as a community to
>>>
>>> the application.
>>>
>>> Regards
>>> Prince
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: Nicolas Malin <ma...@librenberry.net>
>>> To: dev@ofbiz.apache.org
>>> Sent: Friday, March 23, 2012 4:21 PM
>>> Subject: Re: Some ideas to prepare our first community roadmap
>>>
>>> +1 a greate roadmap with lot of works
>>>
>>> On refactoring idea :
>>> * review/improve best pratice screen (to manage icons, strong table
>>> line, ...), I had started on this subject but not finalize.
>>>
>>> Nicolas
>>>
>>> Le 23/03/2012 11:07, Scott Gray a écrit :
>>>> I'm in favor of all of those things so +1 from me.
>>>>
>>>> For a JIRA version, how about 13.04? :-)
>>>>
>>>> One other topic that's been on my mind, payment gateway implementations:
>>>> - Move the test implementation into it's own class so that it isn't overcrowding PaymentGatewayServices and is consistent with
>>>> the others
>>>> - Refactor the test implementation so that you can use the CVV code to test different behaviors instead of having a bunch of
>>>> different methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
>>>> - Ensure consistency between the implementations and better document the gateway interfaces. Also remove virtually all
>>>> database calls from the implementations (they run in their own transaction which can be painful when querying new data).
>>>> - After cleaning them up, consider moving some of the implementations to Extras, I would prefer all of them except test but we
>>>> could start with some of the more obscure ones at least
>>>>
>>>> Oh and another one on my wish list:
>>>> - Finish the query builder implementation that I started a year or two ago and deprecate the bulk of the delegator find
>>>> methods.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for
>>>>> the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira,
>>>>> using a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by
>>>>> listing the actionable items and also by considering other topics that may be of interest to the community.
>>>>> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>>>>>
>>>>> But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
>>>>>
>>>>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
>>>>> * setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there);
>>>>> the OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
>>>>> * move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details
>>>>> (how to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and
>>>>> also at least one maintainer (OFBiz committer or not) for each component
>>>>> * move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details
>>>>> (how to remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
>>>>>
>>>>> The above will form the first part of the roadmap.
>>>>>
>>>>> ====
>>>>>
>>>>> The following list is simply my personal attempt to propose some priorities for the community; some of them are based on
>>>>> comments from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
>>>>> Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an
>>>>> OFBiz roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a
>>>>> clear roadmap to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals
>>>>> need to be enough generic to gather consensus on a larger group of people (otherwise each individual committer will end up
>>>>> proposing her own specific item to the list, of less interest to the community, and then she will start working on it...
>>>>> instead of better spending the time that she decided to "contribute" to tasks that the community really considers important)
>>>>> and they shouldn't be too big (gathering consensus and implementing as a community will take a lot of time). If we will not
>>>>> find an agreement on some items or a large consensus then it will be fine: the roadmap will be
>>> lighter and will be completed earlier; at that point we will discuss again what we want to do next.
>>>>> Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and
>>>>> "quality".
>>>>>
>>>>> BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to
>>>>> try to see if we can find an agreement for some actionable tasks)
>>>>> * resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its
>>>>> dependencies on applications)
>>>>> * gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing
>>>>> Content Framework with it
>>>>> * discuss, design and implement (if needed) or define best practices for a plug in architecture
>>>>> * discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
>>>>>
>>>>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they
>>>>> don't require big design and discussions and are mostly all actionable)
>>>>> * bug fixes
>>>>> * automated tests
>>>>> * migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
>>>>> * check proper handling of EntityListIterators
>>>>> * check proper handling of errors and exceptions in services, events, scripts
>>>>> * check proper handling of events/services messages
>>>>> * replace simple CRUD services with entity-auto services
>>>>> * refactor security handling in services to declare the security service in the service definition
>>>>> * identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for
>>>>> removal and reimplementation using DynamicEntityView API
>>>>> * identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they
>>>>> look very specific)
>>>>> * cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
>>>>> * review old events and verify if they can be converted into services
>>>>> * review old code and refactor/rewrite
>>>>> * review existing events/services
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Jacopo
>>>>>
>>>
>>>
>>> --
>>> Nicolas MALIN
>>> Consultant
>>> Tél : 06.17.66.40.06
>>> Site projet : http://www.neogia.org/
>>> -------
>>> Société LibrenBerry
>>> Tél : 02.48.02.56.12
>>> Site : http://www.librenberry.net/
Re: Some ideas to prepare our first community roadmap
Posted by Mansour Al Akeel <ma...@gmail.com>.
Ok,
let's be clear about what I mean here, and explain a bit about what I think.
I think it's better to keep the entity engine as is, with regard to
handling data, where it return records and not objects.
However, OO can be done in the framework level. Cleaning the code a
bit, removing deprecated methods, rely less on static methods,
and use dependency injection. For example:
public static DelegatorInfo getDelegatorInfo(String name) {
return configRef.get().delegatorInfos.get(name);
}
can be replace by a little more verbose, but more readable:
public static DelegatorInfo getDelegatorInfo(String name) {
EntityConfigUtil configUtil = configRef.get();
Map<String, DelegatorInfo> map = configUtil.delegatorInfos;
DelegatorInfo tmp = map.get(name);
return tmp;
}
And really, instead of using static methods to lookup objects by name,
a container can used to track all this and
lookup those instances when needed. For example,
org.ofbiz.entity.model.ModelReader doesn't have to provide a static
method to be used a factory, so it can keep on tracking instances
created of itself. It's the job of the container.
Same thing applies to caching. We see caching code all over the place.
Code that does the lookup, but checking a
hashtable used as a cache before deciding to create an object.
Cleaning the code, a bit and make it OO, will allow using Aspects for
things like this.
This is what I meant by making the code more OO.
Back again to the subject of ORMs. MyBatis, may be the fastest ORM I
have worked with, compared to JPA (hibernate, EclipseLink, ..etc).
While I didn't do a practical comparison with OfBiz entity engine, I
think ofbiz entity engine is the most optimized, and fastest,
because it's closer to JDBC than any other ORM framework. I am not
sure if any optimization can be with the EE beside cleaning the code
a bit, and refactoring.
On Fri, Mar 23, 2012 at 9:27 AM, Prince Sewani <pr...@ymail.com> wrote:
> Yeah making it more OO is what I'm actually referring to, OFBiz entity-engine is
> a different architecture altogether if we compare it to other existing counter-parts like hibernate and
>
> Ibatis, I haven't really looked at the query generation code, but does anyone thinks that it needs a
>
> bit more optimization? I know I'm talking at a very high level despite of checking out the
> implementation, Also for cases where we need to plug-in our queries (And I really mean SQL Queries) there should be additional methods in
>
> GenericDelegator to achieve it, in the current scenario we've to make an instace of SQLProcessor to get that done,
> I'm not sure, but it must be a singleton as per my understanding, Is there any way to get that existing Singleton
>
> in our code using some method, If not we should think of that too, it would make OFBiz Entity Engine
>
> superior to its counterparts and that idea of permissions at the entity level is awesome!!
>
> P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what to be done.
>
> Regards
> Prince
>
>
>
> ________________________________
> From: Mansour Al Akeel <ma...@gmail.com>
> To: dev@ofbiz.apache.org; Prince Sewani <pr...@ymail.com>
> Sent: Friday, March 23, 2012 6:37 PM
> Subject: Re: Some ideas to prepare our first community roadmap
>
> For me +1 to refactor.
>
> I am not sure the ORM needs any work. May be I am missing something.
> Please let me know what part ?
>
> Just cleaning the entity engine code a bit, and make it more OO, will
> make it easier to work with.
> For example, I like to add a custom Delegator that will append some
> fields to each query and will enforce Row Level Security.
> For example, adding something like "acl.xml" next to the entity
> definitions, which contains the rules about the access.
> I know Oracle database has what is called virtual Private Database,
> and will be nice to have something similar instead of checking for
> access control in each service call.
> Just looking at the code currently there, makes the idea goes away.
> Refactoring the code will make things a bit easier.
>
> Ofbiz currently uses its own container to load all it's component. I
> was not able to find a lot of docs. May be missed them.
> I don't know if using alternative container is a reasonable suggestion.
>
> I see a lot of documentations and examples about using IoC containers
> with tomcat/jetty/geronimo and OSGI.
>
>
> On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani <pr...@ymail.com> wrote:
>>
>>
>> +1 to the Refractor, Have a few questions and a few suggestions :
>> Questions :
>>
>>
>> Are we looking to improve upon the ORM as well ?
>>
>> And what about the OSGI stuff, are we planning something on that to enhance the plug-in approach?
>>
>> What's all about the extra stuff? are we just gonna keep 'em separately and maintain 'em separately or are we
>> really commercializing?
>>
>> Also, What all is that we're thinking to add on to the existing application or are we just looking to reduce/resize and enhance what all
>> is there?
>>
>>
>> Suggestions :
>>
>> Google Base Component : Google has upgraded to Google Content API long back so the one in 10.04 no more works to upload products to Google merchant
>> haven't checked 11.04 yet.
>>
>> eBay and eBay Store could be merged together and there's also no functionality to post variants to eBay, I wrote some custom code as
>>
>> part of a POC for that, also customer grievances from eBay is something that's missing.
>>
>> Integration with Amazon using Amazon MWS will be cool.
>>
>> Upgrade for Fedex API as they're retiring the SOAP API that is currently used, on 31st may 2012.
>>
>> Also I'm ready to volunteer any component at any level, be it a committer or not.
>> I'm very much excited about the massive change that we're about to bring as a community to
>>
>> the application.
>>
>> Regards
>> Prince
>>
>>
>>
>>
>> ________________________________
>> From: Nicolas Malin <ma...@librenberry.net>
>> To: dev@ofbiz.apache.org
>> Sent: Friday, March 23, 2012 4:21 PM
>> Subject: Re: Some ideas to prepare our first community roadmap
>>
>> +1 a greate roadmap with lot of works
>>
>> On refactoring idea :
>> * review/improve best pratice screen (to manage icons, strong table
>> line, ...), I had started on this subject but not finalize.
>>
>> Nicolas
>>
>> Le 23/03/2012 11:07, Scott Gray a écrit :
>>> I'm in favor of all of those things so +1 from me.
>>>
>>> For a JIRA version, how about 13.04? :-)
>>>
>>> One other topic that's been on my mind, payment gateway implementations:
>>> - Move the test implementation into it's own class so that it isn't overcrowding PaymentGatewayServices and is consistent with the others
>>> - Refactor the test implementation so that you can use the CVV code to test different behaviors instead of having a bunch of different methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
>>> - Ensure consistency between the implementations and better document the gateway interfaces. Also remove virtually all database calls from the implementations (they run in their own transaction which can be painful when querying new data).
>>> - After cleaning them up, consider moving some of the implementations to Extras, I would prefer all of them except test but we could start with some of the more obscure ones at least
>>>
>>> Oh and another one on my wish list:
>>> - Finish the query builder implementation that I started a year or two ago and deprecate the bulk of the delegator find methods.
>>>
>>> Regards
>>> Scott
>>>
>>> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
>>>
>>>> Hi all,
>>>>
>>>> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by listing the actionable items and also by considering other topics that may be of interest to the community.
>>>> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>>>>
>>>> But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
>>>>
>>>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
>>>> * setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there); the OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
>>>> * move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details (how to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and also at least one maintainer (OFBiz committer or not) for each component
>>>> * move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details (how to remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
>>>>
>>>> The above will form the first part of the roadmap.
>>>>
>>>> ====
>>>>
>>>> The following list is simply my personal attempt to propose some priorities for the community; some of them are based on comments from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
>>>> Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an OFBiz roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a clear roadmap to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals need to be enough generic to gather consensus on a larger group of people (otherwise each individual committer will end up proposing her own specific item to the list, of less interest to the community, and then she will start working on it... instead of better spending the time that she decided to "contribute" to tasks that the community really considers important) and they shouldn't be too big (gathering consensus and implementing as a community will take a lot of time). If we will not find an agreement on some items or a large consensus then it will be fine: the roadmap will be
>> lighter and will be completed earlier; at that point we will discuss again what we want to do next.
>>>> Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and "quality".
>>>>
>>>> BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to try to see if we can find an agreement for some actionable tasks)
>>>> * resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its dependencies on applications)
>>>> * gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing Content Framework with it
>>>> * discuss, design and implement (if needed) or define best practices for a plug in architecture
>>>> * discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
>>>>
>>>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they don't require big design and discussions and are mostly all actionable)
>>>> * bug fixes
>>>> * automated tests
>>>> * migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
>>>> * check proper handling of EntityListIterators
>>>> * check proper handling of errors and exceptions in services, events, scripts
>>>> * check proper handling of events/services messages
>>>> * replace simple CRUD services with entity-auto services
>>>> * refactor security handling in services to declare the security service in the service definition
>>>> * identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for removal and reimplementation using DynamicEntityView API
>>>> * identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they look very specific)
>>>> * cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
>>>> * review old events and verify if they can be converted into services
>>>> * review old code and refactor/rewrite
>>>> * review existing events/services
>>>>
>>>> Kind regards,
>>>>
>>>> Jacopo
>>>>
>>
>>
>> --
>> Nicolas MALIN
>> Consultant
>> Tél : 06.17.66.40.06
>> Site projet : http://www.neogia.org/
>> -------
>> Société LibrenBerry
>> Tél : 02.48.02.56.12
>> Site : http://www.librenberry.net/
Re: Some ideas to prepare our first community roadmap
Posted by Prince Sewani <pr...@ymail.com>.
Yeah making it more OO is what I'm actually referring to, OFBiz entity-engine is
a different architecture altogether if we compare it to other existing counter-parts like hibernate and
Ibatis, I haven't really looked at the query generation code, but does anyone thinks that it needs a
bit more optimization? I know I'm talking at a very high level despite of checking out the
implementation, Also for cases where we need to plug-in our queries (And I really mean SQL Queries) there should be additional methods in
GenericDelegator to achieve it, in the current scenario we've to make an instace of SQLProcessor to get that done,
I'm not sure, but it must be a singleton as per my understanding, Is there any way to get that existing Singleton
in our code using some method, If not we should think of that too, it would make OFBiz Entity Engine
superior to its counterparts and that idea of permissions at the entity level is awesome!!
P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what to be done.
Regards
Prince
________________________________
From: Mansour Al Akeel <ma...@gmail.com>
To: dev@ofbiz.apache.org; Prince Sewani <pr...@ymail.com>
Sent: Friday, March 23, 2012 6:37 PM
Subject: Re: Some ideas to prepare our first community roadmap
For me +1 to refactor.
I am not sure the ORM needs any work. May be I am missing something.
Please let me know what part ?
Just cleaning the entity engine code a bit, and make it more OO, will
make it easier to work with.
For example, I like to add a custom Delegator that will append some
fields to each query and will enforce Row Level Security.
For example, adding something like "acl.xml" next to the entity
definitions, which contains the rules about the access.
I know Oracle database has what is called virtual Private Database,
and will be nice to have something similar instead of checking for
access control in each service call.
Just looking at the code currently there, makes the idea goes away.
Refactoring the code will make things a bit easier.
Ofbiz currently uses its own container to load all it's component. I
was not able to find a lot of docs. May be missed them.
I don't know if using alternative container is a reasonable suggestion.
I see a lot of documentations and examples about using IoC containers
with tomcat/jetty/geronimo and OSGI.
On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani <pr...@ymail.com> wrote:
>
>
> +1 to the Refractor, Have a few questions and a few suggestions :
> Questions :
>
>
> Are we looking to improve upon the ORM as well ?
>
> And what about the OSGI stuff, are we planning something on that to enhance the plug-in approach?
>
> What's all about the extra stuff? are we just gonna keep 'em separately and maintain 'em separately or are we
> really commercializing?
>
> Also, What all is that we're thinking to add on to the existing application or are we just looking to reduce/resize and enhance what all
> is there?
>
>
> Suggestions :
>
> Google Base Component : Google has upgraded to Google Content API long back so the one in 10.04 no more works to upload products to Google merchant
> haven't checked 11.04 yet.
>
> eBay and eBay Store could be merged together and there's also no functionality to post variants to eBay, I wrote some custom code as
>
> part of a POC for that, also customer grievances from eBay is something that's missing.
>
> Integration with Amazon using Amazon MWS will be cool.
>
> Upgrade for Fedex API as they're retiring the SOAP API that is currently used, on 31st may 2012.
>
> Also I'm ready to volunteer any component at any level, be it a committer or not.
> I'm very much excited about the massive change that we're about to bring as a community to
>
> the application.
>
> Regards
> Prince
>
>
>
>
> ________________________________
> From: Nicolas Malin <ma...@librenberry.net>
> To: dev@ofbiz.apache.org
> Sent: Friday, March 23, 2012 4:21 PM
> Subject: Re: Some ideas to prepare our first community roadmap
>
> +1 a greate roadmap with lot of works
>
> On refactoring idea :
> * review/improve best pratice screen (to manage icons, strong table
> line, ...), I had started on this subject but not finalize.
>
> Nicolas
>
> Le 23/03/2012 11:07, Scott Gray a écrit :
>> I'm in favor of all of those things so +1 from me.
>>
>> For a JIRA version, how about 13.04? :-)
>>
>> One other topic that's been on my mind, payment gateway implementations:
>> - Move the test implementation into it's own class so that it isn't overcrowding PaymentGatewayServices and is consistent with the others
>> - Refactor the test implementation so that you can use the CVV code to test different behaviors instead of having a bunch of different methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
>> - Ensure consistency between the implementations and better document the gateway interfaces. Also remove virtually all database calls from the implementations (they run in their own transaction which can be painful when querying new data).
>> - After cleaning them up, consider moving some of the implementations to Extras, I would prefer all of them except test but we could start with some of the more obscure ones at least
>>
>> Oh and another one on my wish list:
>> - Finish the query builder implementation that I started a year or two ago and deprecate the bulk of the delegator find methods.
>>
>> Regards
>> Scott
>>
>> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
>>
>>> Hi all,
>>>
>>> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by listing the actionable items and also by considering other topics that may be of interest to the community.
>>> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>>>
>>> But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
>>>
>>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
>>> * setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there); the OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
>>> * move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details (how to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and also at least one maintainer (OFBiz committer or not) for each component
>>> * move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details (how to remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
>>>
>>> The above will form the first part of the roadmap.
>>>
>>> ====
>>>
>>> The following list is simply my personal attempt to propose some priorities for the community; some of them are based on comments from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
>>> Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an OFBiz roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a clear roadmap to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals need to be enough generic to gather consensus on a larger group of people (otherwise each individual committer will end up proposing her own specific item to the list, of less interest to the community, and then she will start working on it... instead of better spending the time that she decided to "contribute" to tasks that the community really considers important) and they shouldn't be too big (gathering consensus and implementing as a community will take a lot of time). If we will not find an agreement on some items or a large consensus then it will be fine: the roadmap will be
> lighter and will be completed earlier; at that point we will discuss again what we want to do next.
>>> Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and "quality".
>>>
>>> BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to try to see if we can find an agreement for some actionable tasks)
>>> * resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its dependencies on applications)
>>> * gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing Content Framework with it
>>> * discuss, design and implement (if needed) or define best practices for a plug in architecture
>>> * discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
>>>
>>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they don't require big design and discussions and are mostly all actionable)
>>> * bug fixes
>>> * automated tests
>>> * migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
>>> * check proper handling of EntityListIterators
>>> * check proper handling of errors and exceptions in services, events, scripts
>>> * check proper handling of events/services messages
>>> * replace simple CRUD services with entity-auto services
>>> * refactor security handling in services to declare the security service in the service definition
>>> * identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for removal and reimplementation using DynamicEntityView API
>>> * identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they look very specific)
>>> * cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
>>> * review old events and verify if they can be converted into services
>>> * review old code and refactor/rewrite
>>> * review existing events/services
>>>
>>> Kind regards,
>>>
>>> Jacopo
>>>
>
>
> --
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
Re: Some ideas to prepare our first community roadmap
Posted by Mansour Al Akeel <ma...@gmail.com>.
For me +1 to refactor.
I am not sure the ORM needs any work. May be I am missing something.
Please let me know what part ?
Just cleaning the entity engine code a bit, and make it more OO, will
make it easier to work with.
For example, I like to add a custom Delegator that will append some
fields to each query and will enforce Row Level Security.
For example, adding something like "acl.xml" next to the entity
definitions, which contains the rules about the access.
I know Oracle database has what is called virtual Private Database,
and will be nice to have something similar instead of checking for
access control in each service call.
Just looking at the code currently there, makes the idea goes away.
Refactoring the code will make things a bit easier.
Ofbiz currently uses its own container to load all it's component. I
was not able to find a lot of docs. May be missed them.
I don't know if using alternative container is a reasonable suggestion.
I see a lot of documentations and examples about using IoC containers
with tomcat/jetty/geronimo and OSGI.
On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani <pr...@ymail.com> wrote:
>
>
> +1 to the Refractor, Have a few questions and a few suggestions :
> Questions :
>
>
> Are we looking to improve upon the ORM as well ?
>
> And what about the OSGI stuff, are we planning something on that to enhance the plug-in approach?
>
> What's all about the extra stuff? are we just gonna keep 'em separately and maintain 'em separately or are we
> really commercializing?
>
> Also, What all is that we're thinking to add on to the existing application or are we just looking to reduce/resize and enhance what all
> is there?
>
>
> Suggestions :
>
> Google Base Component : Google has upgraded to Google Content API long back so the one in 10.04 no more works to upload products to Google merchant
> haven't checked 11.04 yet.
>
> eBay and eBay Store could be merged together and there's also no functionality to post variants to eBay, I wrote some custom code as
>
> part of a POC for that, also customer grievances from eBay is something that's missing.
>
> Integration with Amazon using Amazon MWS will be cool.
>
> Upgrade for Fedex API as they're retiring the SOAP API that is currently used, on 31st may 2012.
>
> Also I'm ready to volunteer any component at any level, be it a committer or not.
> I'm very much excited about the massive change that we're about to bring as a community to
>
> the application.
>
> Regards
> Prince
>
>
>
>
> ________________________________
> From: Nicolas Malin <ma...@librenberry.net>
> To: dev@ofbiz.apache.org
> Sent: Friday, March 23, 2012 4:21 PM
> Subject: Re: Some ideas to prepare our first community roadmap
>
> +1 a greate roadmap with lot of works
>
> On refactoring idea :
> * review/improve best pratice screen (to manage icons, strong table
> line, ...), I had started on this subject but not finalize.
>
> Nicolas
>
> Le 23/03/2012 11:07, Scott Gray a écrit :
>> I'm in favor of all of those things so +1 from me.
>>
>> For a JIRA version, how about 13.04? :-)
>>
>> One other topic that's been on my mind, payment gateway implementations:
>> - Move the test implementation into it's own class so that it isn't overcrowding PaymentGatewayServices and is consistent with the others
>> - Refactor the test implementation so that you can use the CVV code to test different behaviors instead of having a bunch of different methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
>> - Ensure consistency between the implementations and better document the gateway interfaces. Also remove virtually all database calls from the implementations (they run in their own transaction which can be painful when querying new data).
>> - After cleaning them up, consider moving some of the implementations to Extras, I would prefer all of them except test but we could start with some of the more obscure ones at least
>>
>> Oh and another one on my wish list:
>> - Finish the query builder implementation that I started a year or two ago and deprecate the bulk of the delegator find methods.
>>
>> Regards
>> Scott
>>
>> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
>>
>>> Hi all,
>>>
>>> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by listing the actionable items and also by considering other topics that may be of interest to the community.
>>> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>>>
>>> But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
>>>
>>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
>>> * setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there); the OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
>>> * move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details (how to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and also at least one maintainer (OFBiz committer or not) for each component
>>> * move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details (how to remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
>>>
>>> The above will form the first part of the roadmap.
>>>
>>> ====
>>>
>>> The following list is simply my personal attempt to propose some priorities for the community; some of them are based on comments from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
>>> Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an OFBiz roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a clear roadmap to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals need to be enough generic to gather consensus on a larger group of people (otherwise each individual committer will end up proposing her own specific item to the list, of less interest to the community, and then she will start working on it... instead of better spending the time that she decided to "contribute" to tasks that the community really considers important) and they shouldn't be too big (gathering consensus and implementing as a community will take a lot of time). If we will not find an agreement on some items or a large consensus then it will be fine: the roadmap will be
> lighter and will be completed earlier; at that point we will discuss again what we want to do next.
>>> Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and "quality".
>>>
>>> BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to try to see if we can find an agreement for some actionable tasks)
>>> * resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its dependencies on applications)
>>> * gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing Content Framework with it
>>> * discuss, design and implement (if needed) or define best practices for a plug in architecture
>>> * discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
>>>
>>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they don't require big design and discussions and are mostly all actionable)
>>> * bug fixes
>>> * automated tests
>>> * migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
>>> * check proper handling of EntityListIterators
>>> * check proper handling of errors and exceptions in services, events, scripts
>>> * check proper handling of events/services messages
>>> * replace simple CRUD services with entity-auto services
>>> * refactor security handling in services to declare the security service in the service definition
>>> * identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for removal and reimplementation using DynamicEntityView API
>>> * identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they look very specific)
>>> * cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
>>> * review old events and verify if they can be converted into services
>>> * review old code and refactor/rewrite
>>> * review existing events/services
>>>
>>> Kind regards,
>>>
>>> Jacopo
>>>
>
>
> --
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
Re: Some ideas to prepare our first community roadmap
Posted by Jacques Le Roux <ja...@les7arts.com>.
Prince Sewani wrote:
> +1 to the Refractor, Have a few questions and a few suggestions :
> Questions :
>
>
> Are we looking to improve upon the ORM as well ?
You need to read more about that. OFBiz is not ORM and the Entity Engine was actually there before ORM took its flight. This one of
the reason Jira picked the Entity Engine at this time (we speak of 10 years ago).
I'm not against ORM, but I still believe David had a great idea.
> And what about the OSGI stuff, are we planning something on that to enhance the plug-in approach?
I think it will not be done in this iteration (aka release time frame). But it's not out of the radar scope.
> What's all about the extra stuff? are we just gonna keep 'em separately and maintain 'em separately or are we
> really commercializing?
commercializing??? This is open source with and ASF license. You can commercialize it when you want.
> Also, What all is that we're thinking to add on to the existing application or are we just looking to reduce/resize and enhance
> what all
> is there?
For now we want to slim down .-
>
> Suggestions :
>
> Google Base Component : Google has upgraded to Google Content API long back so the one in 10.04 no more works to upload products
> to Google merchant
> haven't checked 11.04 yet.
>
> eBay and eBay Store could be merged together and there's also no functionality to post variants to eBay, I wrote some custom code
> as
>
> part of a POC for that, also customer grievances from eBay is something that's missing.
>
> Integration with Amazon using Amazon MWS will be cool.
>
> Upgrade for Fedex API as they're retiring the SOAP API that is currently used, on 31st may 2012.
>
> Also I'm ready to volunteer any component at any level, be it a committer or not.
Welcome to do all that in Extra
> I'm very much excited about the massive change that we're about to bring as a community to
>
> the application.
Great, looking forward for your efforts :o)
Jacques
> Regards
> Prince
>
>
>
>
> ________________________________
> From: Nicolas Malin <ma...@librenberry.net>
> To: dev@ofbiz.apache.org
> Sent: Friday, March 23, 2012 4:21 PM
> Subject: Re: Some ideas to prepare our first community roadmap
>
> +1 a greate roadmap with lot of works
>
> On refactoring idea :
> * review/improve best pratice screen (to manage icons, strong table
> line, ...), I had started on this subject but not finalize.
>
> Nicolas
>
> Le 23/03/2012 11:07, Scott Gray a écrit :
>> I'm in favor of all of those things so +1 from me.
>>
>> For a JIRA version, how about 13.04? :-)
>>
>> One other topic that's been on my mind, payment gateway implementations:
>> - Move the test implementation into it's own class so that it isn't overcrowding PaymentGatewayServices and is consistent with
>> the others
>> - Refactor the test implementation so that you can use the CVV code to test different behaviors instead of having a bunch of
>> different methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
>> - Ensure consistency between the implementations and better document the gateway interfaces. Also remove virtually all database
>> calls from the implementations (they run in their own transaction which can be painful when querying new data).
>> - After cleaning them up, consider moving some of the implementations to Extras, I would prefer all of them except test but we
>> could start with some of the more obscure ones at least
>>
>> Oh and another one on my wish list:
>> - Finish the query builder implementation that I started a year or two ago and deprecate the bulk of the delegator find methods.
>>
>> Regards
>> Scott
>>
>> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
>>
>>> Hi all,
>>>
>>> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for
>>> the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using
>>> a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by listing the
>>> actionable items and also by considering other topics that may be of interest to the community.
>>> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>>>
>>> But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
>>>
>>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
>>> * setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there);
>>> the OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
>>> * move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details
>>> (how to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and
>>> also at least one maintainer (OFBiz committer or not) for each component
>>> * move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details (how
>>> to remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
>>>
>>> The above will form the first part of the roadmap.
>>>
>>> ====
>>>
>>> The following list is simply my personal attempt to propose some priorities for the community; some of them are based on
>>> comments from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
>>> Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an
>>> OFBiz roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a clear
>>> roadmap to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals need to
>>> be enough generic to gather consensus on a larger group of people (otherwise each individual committer will end up proposing
>>> her own specific item to the list, of less interest to the community, and then she will start working on it... instead of
>>> better spending the time that she decided to "contribute" to tasks that the community really considers important) and they
>>> shouldn't be too big (gathering consensus and implementing as a community will take a lot of time). If we will not find an
>>> agreement on some items or a large consensus then it will be fine: the roadmap will be
> lighter and will be completed earlier; at that point we will discuss again what we want to do next.
>>> Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and
>>> "quality".
>>>
>>> BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to try
>>> to see if we can find an agreement for some actionable tasks)
>>> * resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its
>>> dependencies on applications)
>>> * gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing
>>> Content Framework with it
>>> * discuss, design and implement (if needed) or define best practices for a plug in architecture
>>> * discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
>>>
>>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they
>>> don't require big design and discussions and are mostly all actionable)
>>> * bug fixes
>>> * automated tests
>>> * migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
>>> * check proper handling of EntityListIterators
>>> * check proper handling of errors and exceptions in services, events, scripts
>>> * check proper handling of events/services messages
>>> * replace simple CRUD services with entity-auto services
>>> * refactor security handling in services to declare the security service in the service definition
>>> * identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for removal
>>> and reimplementation using DynamicEntityView API
>>> * identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they
>>> look very specific)
>>> * cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
>>> * review old events and verify if they can be converted into services
>>> * review old code and refactor/rewrite
>>> * review existing events/services
>>>
>>> Kind regards,
>>>
>>> Jacopo
Re: Some ideas to prepare our first community roadmap
Posted by Prince Sewani <pr...@ymail.com>.
+1 to the Refractor, Have a few questions and a few suggestions :
Questions :
Are we looking to improve upon the ORM as well ?
And what about the OSGI stuff, are we planning something on that to enhance the plug-in approach?
What's all about the extra stuff? are we just gonna keep 'em separately and maintain 'em separately or are we
really commercializing?
Also, What all is that we're thinking to add on to the existing application or are we just looking to reduce/resize and enhance what all
is there?
Suggestions :
Google Base Component : Google has upgraded to Google Content API long back so the one in 10.04 no more works to upload products to Google merchant
haven't checked 11.04 yet.
eBay and eBay Store could be merged together and there's also no functionality to post variants to eBay, I wrote some custom code as
part of a POC for that, also customer grievances from eBay is something that's missing.
Integration with Amazon using Amazon MWS will be cool.
Upgrade for Fedex API as they're retiring the SOAP API that is currently used, on 31st may 2012.
Also I'm ready to volunteer any component at any level, be it a committer or not.
I'm very much excited about the massive change that we're about to bring as a community to
the application.
Regards
Prince
________________________________
From: Nicolas Malin <ma...@librenberry.net>
To: dev@ofbiz.apache.org
Sent: Friday, March 23, 2012 4:21 PM
Subject: Re: Some ideas to prepare our first community roadmap
+1 a greate roadmap with lot of works
On refactoring idea :
* review/improve best pratice screen (to manage icons, strong table
line, ...), I had started on this subject but not finalize.
Nicolas
Le 23/03/2012 11:07, Scott Gray a écrit :
> I'm in favor of all of those things so +1 from me.
>
> For a JIRA version, how about 13.04? :-)
>
> One other topic that's been on my mind, payment gateway implementations:
> - Move the test implementation into it's own class so that it isn't overcrowding PaymentGatewayServices and is consistent with the others
> - Refactor the test implementation so that you can use the CVV code to test different behaviors instead of having a bunch of different methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
> - Ensure consistency between the implementations and better document the gateway interfaces. Also remove virtually all database calls from the implementations (they run in their own transaction which can be painful when querying new data).
> - After cleaning them up, consider moving some of the implementations to Extras, I would prefer all of them except test but we could start with some of the more obscure ones at least
>
> Oh and another one on my wish list:
> - Finish the query builder implementation that I started a year or two ago and deprecate the bulk of the delegator find methods.
>
> Regards
> Scott
>
> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
>
>> Hi all,
>>
>> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by listing the actionable items and also by considering other topics that may be of interest to the community.
>> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>>
>> But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
>>
>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
>> * setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there); the OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
>> * move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details (how to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and also at least one maintainer (OFBiz committer or not) for each component
>> * move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details (how to remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
>>
>> The above will form the first part of the roadmap.
>>
>> ====
>>
>> The following list is simply my personal attempt to propose some priorities for the community; some of them are based on comments from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
>> Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an OFBiz roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a clear roadmap to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals need to be enough generic to gather consensus on a larger group of people (otherwise each individual committer will end up proposing her own specific item to the list, of less interest to the community, and then she will start working on it... instead of better spending the time that she decided to "contribute" to tasks that the community really considers important) and they shouldn't be too big (gathering consensus and implementing as a community will take a lot of time). If we will not find an agreement on some items or a large consensus then it will be fine: the roadmap will be
lighter and will be completed earlier; at that point we will discuss again what we want to do next.
>> Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and "quality".
>>
>> BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to try to see if we can find an agreement for some actionable tasks)
>> * resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its dependencies on applications)
>> * gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing Content Framework with it
>> * discuss, design and implement (if needed) or define best practices for a plug in architecture
>> * discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
>>
>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they don't require big design and discussions and are mostly all actionable)
>> * bug fixes
>> * automated tests
>> * migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
>> * check proper handling of EntityListIterators
>> * check proper handling of errors and exceptions in services, events, scripts
>> * check proper handling of events/services messages
>> * replace simple CRUD services with entity-auto services
>> * refactor security handling in services to declare the security service in the service definition
>> * identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for removal and reimplementation using DynamicEntityView API
>> * identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they look very specific)
>> * cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
>> * review old events and verify if they can be converted into services
>> * review old code and refactor/rewrite
>> * review existing events/services
>>
>> Kind regards,
>>
>> Jacopo
>>
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Some ideas to prepare our first community roadmap
Posted by Nicolas Malin <ma...@librenberry.net>.
+1 a greate roadmap with lot of works
On refactoring idea :
* review/improve best pratice screen (to manage icons, strong table
line, ...), I had started on this subject but not finalize.
Nicolas
Le 23/03/2012 11:07, Scott Gray a écrit :
> I'm in favor of all of those things so +1 from me.
>
> For a JIRA version, how about 13.04? :-)
>
> One other topic that's been on my mind, payment gateway implementations:
> - Move the test implementation into it's own class so that it isn't overcrowding PaymentGatewayServices and is consistent with the others
> - Refactor the test implementation so that you can use the CVV code to test different behaviors instead of having a bunch of different methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
> - Ensure consistency between the implementations and better document the gateway interfaces. Also remove virtually all database calls from the implementations (they run in their own transaction which can be painful when querying new data).
> - After cleaning them up, consider moving some of the implementations to Extras, I would prefer all of them except test but we could start with some of the more obscure ones at least
>
> Oh and another one on my wish list:
> - Finish the query builder implementation that I started a year or two ago and deprecate the bulk of the delegator find methods.
>
> Regards
> Scott
>
> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
>
>> Hi all,
>>
>> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by listing the actionable items and also by considering other topics that may be of interest to the community.
>> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>>
>> But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
>>
>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
>> * setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there); the OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
>> * move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details (how to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and also at least one maintainer (OFBiz committer or not) for each component
>> * move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details (how to remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
>>
>> The above will form the first part of the roadmap.
>>
>> ====
>>
>> The following list is simply my personal attempt to propose some priorities for the community; some of them are based on comments from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
>> Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an OFBiz roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a clear roadmap to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals need to be enough generic to gather consensus on a larger group of people (otherwise each individual committer will end up proposing her own specific item to the list, of less interest to the community, and then she will start working on it... instead of better spending the time that she decided to "contribute" to tasks that the community really considers important) and they shouldn't be too big (gathering consensus and implementing as a community will take a lot of time). If we will not find an agreement on some items or a large consensus then it will be fine: the roadmap will be lighter and will be completed earlier; at that point we will discuss again what we want to do next.
>> Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and "quality".
>>
>> BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to try to see if we can find an agreement for some actionable tasks)
>> * resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its dependencies on applications)
>> * gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing Content Framework with it
>> * discuss, design and implement (if needed) or define best practices for a plug in architecture
>> * discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
>>
>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they don't require big design and discussions and are mostly all actionable)
>> * bug fixes
>> * automated tests
>> * migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
>> * check proper handling of EntityListIterators
>> * check proper handling of errors and exceptions in services, events, scripts
>> * check proper handling of events/services messages
>> * replace simple CRUD services with entity-auto services
>> * refactor security handling in services to declare the security service in the service definition
>> * identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for removal and reimplementation using DynamicEntityView API
>> * identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they look very specific)
>> * cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
>> * review old events and verify if they can be converted into services
>> * review old code and refactor/rewrite
>> * review existing events/services
>>
>> Kind regards,
>>
>> Jacopo
>>
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Some ideas to prepare our first community roadmap
Posted by Scott Gray <sc...@hotwaxmedia.com>.
I'm in favor of all of those things so +1 from me.
For a JIRA version, how about 13.04? :-)
One other topic that's been on my mind, payment gateway implementations:
- Move the test implementation into it's own class so that it isn't overcrowding PaymentGatewayServices and is consistent with the others
- Refactor the test implementation so that you can use the CVV code to test different behaviors instead of having a bunch of different methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
- Ensure consistency between the implementations and better document the gateway interfaces. Also remove virtually all database calls from the implementations (they run in their own transaction which can be painful when querying new data).
- After cleaning them up, consider moving some of the implementations to Extras, I would prefer all of them except test but we could start with some of the more obscure ones at least
Oh and another one on my wish list:
- Finish the query builder implementation that I started a year or two ago and deprecate the bulk of the delegator find methods.
Regards
Scott
On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:
> Hi all,
>
> now that the great community discussion about the "Lose Weight Program" for OFBiz is settling down (thanks to all of you for the great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using a specific "Jira version" so that we can keep track of progress together... any ideas for a good name for it?) by listing the actionable items and also by considering other topics that may be of interest to the community.
> This thread is an attempt to integrate the roadmap with some additional tasks if the community will consider them a priority.
>
> But first of all, here is the list with a categorization/summary of the tasks being discussed so far:
>
> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will create tasks in Jira for each):
> * setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there); the OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
> * move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details (how to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and also at least one maintainer (OFBiz committer or not) for each component
> * move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details (how to remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits
>
> The above will form the first part of the roadmap.
>
> ====
>
> The following list is simply my personal attempt to propose some priorities for the community; some of them are based on comments from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
> Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an OFBiz roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a clear roadmap to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals need to be enough generic to gather consensus on a larger group of people (otherwise each individual committer will end up proposing her own specific item to the list, of less interest to the community, and then she will start working on it... instead of better spending the time that she decided to "contribute" to tasks that the community really considers important) and they shouldn't be too big (gathering consensus and implementing as a community will take a lot of time). If we will not find an agreement on some items or a large consensus then it will be fine: the roadmap will be lighter and will be completed earlier; at that point we will discuss again what we want to do next.
> Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on "maintenance" and "quality".
>
> BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to try to see if we can find an agreement for some actionable tasks)
> * resolving framework dependencies on applications (this is *not* about "refactoring" the framework, simply to resolve its dependencies on applications)
> * gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing Content Framework with it
> * discuss, design and implement (if needed) or define best practices for a plug in architecture
> * discuss, design and implement (if needed) or define best practices for an integrated reporting tool for OFBiz
>
> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they don't require big design and discussions and are mostly all actionable)
> * bug fixes
> * automated tests
> * migration from Beanshell to Groovy (i.e. continue in the trunk the work started in the branch)
> * check proper handling of EntityListIterators
> * check proper handling of errors and exceptions in services, events, scripts
> * check proper handling of events/services messages
> * replace simple CRUD services with entity-auto services
> * refactor security handling in services to declare the security service in the service definition
> * identify all view-entity definitions that are only used in one place (or never used): they may be good candidates for removal and reimplementation using DynamicEntityView API
> * identify all services that are used only in one place (or never used): they may be removed and inlined (especially if they look very specific)
> * cleanup (following some best practices - to be defined- for names) and improve service names and descriptions
> * review old events and verify if they can be converted into services
> * review old code and refactor/rewrite
> * review existing events/services
>
> Kind regards,
>
> Jacopo
>