I will be coordinating the execution, and will be recruiting people to work on this project. To do, I created a step-by-step plan to perform all the necessary tasks.
The steps are followed below, in the order in which I expect them to finish. Some steps can actually start earlier, but since they involve the entire code tree will likely not be finished until much later, and an actual effort to finsih those tasks will be done after some big moving/cleaning have been performed.
A number of steps will be so involved that they will need to claim CVS for their duration, to avoid conflicts.
These steps are indicated below. when such a Step starts, I will send a mailing to the developers list to indicate which parts of the code tree will be resreved for the prohect, and for what dirationm. This will gibe peopel time to cehck in any bugs or last-minute changes to their own projects. For the duration of the step, changes to that part of the code in CVS need be coordinated with the project coordinator. Hoepfully these periods will be short.
Note that for the duration of these steps, no guarantee can be given to the stability of the CVS. When a step is closed, source in CVS should be stable (at least be able to compile, and free of bugs introduced by the change).
Not every step is fully detailed - class lists are not yet up to date and some code needs discussion.
Where I believe discussion is needed, I listed it below.
Every step will get its owen documentation page in the project page, with info on people involved, date staretd/ended, and all info needed to fulfill the task (class lists, notes on problems, bug references).
Some specific steps need to be voted on (noted below).
However, a lot of elements should probably be not be voted on as single entities, since that will slow down the project conciderably.
If people desire votes anyway, I can ask a vote for each step, providing a list of changes, but I don't think that will be helpful - this project will change a lot of things and as such voting is not the bestw ay to aprtic[pate. Instead, if you want to avoid any of the many smaller changes (such as the removal of a deprecated method) you can join the project team.
As a side note, unless people indicate a need to vote on each step, I plan to run STEP 1 today, as it has little real impact (all functionality in the old storage classes are also present in the new).
Below is the outline of the steps. You are welcome to send in additional changes. Please note that while most of the code is tagged, not everything may be up to date.
The following stages in the optimalization project exists:
STEP 1 Remove deprecated storage/database code [1]: Remove the old storage classes This includes the following sources: - org.mmbase.storage.Storage - org.mmbase.storage.Transaction - org.mmbase.storage.database.* - org.mmbase.util.DatabaseLookup and config: - database/hsqldb-storage.xml - database/mysql.xml - database/postgresql.xml - database/relation.xml - database/lookup.xml - database/lookup_postgresql.xml - database/README.TXT References to these classes should be removed (i.e. in MMBase.java).
STEP 2
Move out all SCAN code to a seperate application.
Some code may be tagged with @application SCAN.
This also includes :
- org.mmbase.module.gui.html.*
- org.mmbase.util.scanpage
- various classes used for generating HTML in org.mmbase.util
In addition, several issues will need to be solved, such as references to scan classes in MMObjectBuilder, ProcessorModule, etc.
This step needs a meeting on the removal of classes such as scanpage before it can be started.
This step may also need a proposal and a vote if interfaces are changed.
STEP 3
Move any remaining code that belongs in an application, rather than the core.
Create appropriate applications.
Code is tagged in MMBase using @application
A list of tagged classes will be provided.
Some code may not be tagged yet - these may be removed or moved to a 'tools' application after debate.
This step needs a meeting on what applications to add before it can be started, and likely discussion by email/irc on further implementation.
STEP 4
Adapt code to use SearchQuery, and remove any direct references to MultiConnection.
This includes classes tagged with @sql, but also any code that calls MMObjectBuilder.search() with hardcoded SQL.
This step needs a discussion (possibly irc or email) on the removal of methods from MMObjectBuilder before it can be started.
STEP 5
Remove deprecated storage/database code [2]:
Remove the database support classes:
- org.mmbase.module.database.support.*
This also involves removing all references to MMJDBC2NodeInterface, replacing it with calls to either serachquery or the storagemanager.
This step needs a meeting on remaining storage issues in the new layer (what to solve now and what later) before it can be started.
This step needs a proposal and a vote to allow for the deletion of the support classes.
STEP 6
The JDBC Module should be re-evaluated, and possibly moved to org.mmbase.storage.implementation.database.JDBC.
This step may need a proposal and a vote if teh JDBC module is significantly changed.
STEP 7
Change classnames, move classes, and change package structure where this makes sense.
Code is tagged in MMBase using @rename or @move
A list of tagged classes will be provided at:
http://www.mmbase.org/?docnr=33149&template=%2Fincludes%2Fdoc_index.jsp
This step needs a proposal and a vote to move and rename classes.
As of yet, moving code from org.mmbase.module.core or org.mmbase.module.corebuilders to org.mmbase.core is not yet contemplated.
This step needs a proposal and a vote to see if that specific move is something we want to do in 1.8
STEP 8
Remove all deprecated code (methods and classes), and solve any issues that occur.
Remove any remaining legacy code from the VPRO.
ALso move any code if that makes it more generic, and remove any duplicate code.
This can be done during the whole project, but a final pass should ensure that this is done everywhere.
Code is tagged in MMBase using @deprecated or @deprecated-now, @dependency, @duplicate, and @vpro
A list of tagged classes will be provided at:
http://www.mmbase.org/?docnr=33151&template=%2Fincludes%2Fdoc_index.jsp
STEP 9
Solve all issues with configuration and use of member variables.
Make use of the resourceloader for configuration where possible (if the resourceloader is accepted as a Hack).
This can be done during the whole project, but a final pass should ensure that this is done everywhere.
This includes scoping issues, as well as the use of badliterals or the use of variables that are not configurable.
Code is tagged in MMBase using @scope, @bad-literal, and @bad-constant
A list of tagged classes will be provided.
STEP 10
Remove all use of deprecated code.
This can be done during the whole project, but a final pass should ensure that this is done everywhere.
This includes use of any code that was deprecated bu Sun, and that shows up when compiling with deprecation on.
STEP 11
Apply Code Conventions, and add javadoc.
This can be done during the whole project, but a final pass should ensure that this is done everywhere.
Code is tagged in MMBase using @code-conventions or @javadoc
A list of tagged classes will be provided.
See also:
http://www.mmbase.org/?docnr=33153&template=%2Fincludes%2Fdoc_index.jsp
STEP 12
Apply internationalisation where possible.
This may be only possible in limited cases, and it is possible we skip this step, or leave it to the internationalization project.
This step may need a meeting.
STEP 13 Find performance issues and improve these. Use of a profiler may be useful in finding issues.
