Hi all, there is a thread in this list about adding openbravo-core.jar, openbravo-trl.jar and openbravo-wad.lib to openbravo repository. I will reply in short a post in that thread to explain my point but before that is is worth to explain the "project" where this tasks is included to have an overall understanding of the problem.
Performance in standard openbravo build process has been an issue for a long time. We have got used to wait for a number of minutes just to rebuild the system to test any change done in code. That is painful and decreases our productivity as developers. Last week platform 1 scrum team decided to face this problem asap with the strong feeling that this effort will pay back in short term: if we can dramatically reduce the time that the build process takes the productivity of Openbravo Product development team and Openbravo community will be highly improved. As a result of some analysis meetings last week and taking into account inputs from different people in the team we prepared the following plan to improve the build process: 1.- Improve documentation and communication about this process: during the last months update.database task have been unstable because of integrating it with DAL. As a result many people "feel safer" rebuilding the system through an install.source task that takes 20 minutes instead of through the usual update.database and compile.complete that takes less than 10 minutes. More over the process is not simple enough and it is not clearly explained so it is not crystal clear for most people how to perform it properly. We will deliver a clear and complete document to describe the build process and how to use it. In my opinion it is the most important deliverable of this project 2.- Improve performance by avoiding "not needed" computation in the process (eg. re-generate a window that has not been modified). It can be split in the following subtaks: 2.1.- Implement a quickexport.database: check if any change has happened in db model and sourcedata based on a timestamp from the last synchronization (update.database or export.database). Depending on that the task will skip the export, export just sourcedata or do a full export. 2.2.- Implement quickbuild.partial: it will be fully equivalent to current compile.complete, but it is implemented in a smart way: generate.entities is executed only if needed -changes in data model- and wad is executed only for modified windows. Finally it compiles the code as usual. As a result, when working locally (changes done in the local instance without changes coming from the SCM) developers will build their systems always in the same way by just executing this task. We estimate that it will take an average of 30-40 seconds instead of the 6 minutes it currently takes, and usually it will be less than 10 seconds depending on the type of changes you have done. 2.3.- Implement quickbuild.complete: it is fully equivalent to update.database and compile.complete. Update.database will be done in a smart way: check if any change has happened in db model and sourcedata based on a CRC from the involved xml files in the last synchronization (update.database or export.database). Depending on that the task will skip the update, update just sourcedata or do a full update.database. As a result, when applying changes coming from the SCM developers will build their systems always in the same way by just executing this task. We estimate that it will take an average of 2-3 minutes instead of the 11 minutes it currently takes, and usually it will be less than 15 seconds depending on the type of changes you receive from the SCM. 2.4.- Include core, trl and wad jar files in the repository. This is a first step to make this three projects independent from openbravo project. It improves performance and simplifies the process for most developers in openbravo community (currently less than 3% of commits in openbravo repository are done on these three subprojects) 2.5.- When creating the database gather db optimizer statistics to guarantee that sql's are performed as fast as possible. It will be also an option available when executing update.database but not executed by default since usually update.database will slightly change those statistics 2.6.- Optionally stop and start tomcat within both quickbuild partial and complete tasks: it is very common to reboot tomcat server (or reload openbravo context) after rebuiding the system to test it and doing all together in one task will help to reduce the number of "distraction" when developing (changes of developers mind-context) To avoid problems during the transition from the current build process to the new one all current build tasks are kept stable. 3.- Avoid mistakes: currently you can loose the changes you have done in your database if you do an update.database without having exported your changes before. Using the same infrastructure a validation will be added to stop update.database task if there are changes in your db that have not been exported 4.- Increase reliability: add continuous testing for all build tasks to guarantee that they are rock solid 5.- Rationalize our source code: currently audit info and some transient columns are exported and included in our sourcecode (eg. ad_table.sql_column_identifier). The benefits of this are clearly explained in a very clear and detailed post that Antonio Moreno did yesterday to this list (Subject: Audit info in sourcedata XML files). The benefit of this project can be summarized as improve openbravo developers productivity: the build process -that is performed many times a day- will be much faster and the process will be much simpler, always in the same way, always in the shortest time and with guarantee that it rebuilds the system safely and completely. This "peace of mind" for developers will allow them to focus on their real objective: provide value through high quality code. I hope you will appreciate this effort. As usual feedback is more than welcome, both posive and negative. Ismael ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Openbravo-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openbravo-development
