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
