Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ormf-dev] Setting out task

Hello,

It has taken much longer than I anticipated to get here but it is finally time to start doing some work.  I am going to outline the work we need to start tackling and who I think would be best to pick that up.

  • Generic Requirements Schema [Achim] - The schemas that define the documents in Useme are specific to the document type. While we have performed some generalisation in reusable parts, there is more that can be done to simplify the task of creating new document types. The "holy grail" would be to come up with a schema that was sufficiently generalised that it did not require the creation of document specific schemas whatsoever. The advantage to this would be that no new EMF objects would have to be created to support the new document, which reduce the task of adding a new document type to defining 1) metadata that drove the type; 2) the new editors; 3) and reports. I am not at all certain if this is achievable, and I have concerns that generalising to this degree might degrade the structured nature we are aiming for. It is, however, worth some thought and discussion. This is the time to consider the issue of supporting standards. The outcome of the this task will be an appropriate schema(s) (XSD) to feed into EMF.

  • OSGI Server Architecture [Wolfgang] - Design and then prove our new OSGI based server. We have the strategic question of whether we initially support a WAR dropped into container, a standalone OSGI or both. I would like a paper design in the first instance that sets out the bundles and features, including dependencies. At the moment I see at the following components be required, but I certain this is not yet complete: 1) Equinox; 2) EclipseLink; 3) Derby; 4) Jetty; 5) BIRT; 6) EMF; 7) Spring. Once we have agreed on the architecture it will be constructed, this will require that CQs be filed before anything can be deposited into SVN. The outcome of the task will be a proven architecture ready for use in the ORMF SVN.

  • Size Effort to Move Editor to Forms Based [Ben] - The Useme editors are the out of data in that they are not based on the Forms API. It would be desirable to move onto forms before we create any new editors, but we need to know that impact of both redoing the existing and if there will be any changes required to our editor mechanisms. The outcome of this task will be a scoping document that estimates time and risk. Also it will be training exercise in the use of forms.

  • Preparation of Functional Testing [Vasile (Achim)] -  The current thinking is that the existing Use Case editor will not change unless we make a decision to move forward with forms. In either case we need to start preparing for functional testing now. Barbara has done a lot of work towards specifying the test cases for Useme and this should be built on as the basis testing going forward. My plans are to use GuiDancer which I believe Bredex has made available to EF projects. (Please correct me, Achim, if I am misstating.) I would like for Achim to manage Vasile in getting up to speed so he can take on the responsibility for functional testing. The outcome of the task will be a trained resource who is familiar with the tools and has the skills to perform ORMF testing.

  • Design BIRT Base Publisher [Barbara] - The ORMF publishing/reporting system will be based on BIRT. The outcome of this task will be the architecture and design of the publishing/reporting system, an prototype BIRT design for the use case document and user guide for creating ORMF reports.

  • Strategy to Replace Current Model with EMF Model [Joel] - We will replace the existing Dom4J based model with EMF. This will require some surgery on both the server and client as they share the same model. While the replacement work cannot actually start until we have a new schema agreed, the mechanics of what will have to be done can be designed. The outcome of this task will be a strategy and scoping for converting to EMF.

  • Complete Set Up of ORMF Web Site [Barbara]The outcome of this task will be the ORMF Web Site and Wiki.

  • Project Plan for ORMF [Joel/Barbara] - The EF requires by September 30th, 2008, all projects will have public project plans in the standardized project plan format. The outcome of this task will be the ORMF project plan submitted and posted on the web site.

  • Complete IP Processing on Existing CQs [Joel/Achim] - There are several filed CQs that require our attention before we can use these third party libraries. I will handle all of the ones that need packaging work and Achim will pick up the two that need chasing for pedigree issues. We will drop the requests for Dom4J and Jaxen. The outcome of this task will be that all currently used third parties will be approved for usage and committed to SVN.


This should be enough to get us going on the path. I would like to make that point that this is not intended to be a comprehensive assignment of areas of responsibility. We will all have plenty of other things to do and arenas to play in as we go forward.

As always, any questions please ask.

All the best,
Joel 





Back to the top