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 >
