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


Reply via email to