Hi all, my turn on this thread :-)
First of all, I recognize that we -platform 1 scrum team- have not done right doing this change without a previous explanation of the change. My apologies for that. All of us should keep in mind that any change in code relevant for developers should be announced here BEFORE the change is done to avoid people wasting their time. Changing the build process, project structure or main libraries MUST be announced at least one day before the change is done to keep everybody informed and to get FEEDBACK. Peter, please take this one: how to ensure that it never happens again. About the topic, first please read my previous post (Improvements in Openbravo build process) about the project where this task is included. It will help to understand all my points. I'm putting together all the points in this thread and an my explanation for each of them, but first I want to explain why openbravo project has its current structure -main project depending on three subprojects included within it- and the rational of our decision to include jar files in the repository. I fully agree with Martin that openbravo project structure is odd. It was caused because we tried to achieve two objectives that are difficult to combine: core, trl and wad should be independent projects (in the case or core we thought it could be used independently and it is delivered with a different license) while Openbravo distribution should be complete, including all openbravo source code to make it easier for developers to change any part of the system. Now I think that decision was wrong -my fault- and that the second objective adds few if any value and the solution we designed did not achieve the "make it easier" part. If we have a look to statistics in our svn repository we will realize that changes in the three subprojects are less than 3% of total commits and always done by just three people. If we include -and we should- our community here then this porcentage is MUCH smaller, just irrelevant. Now I have a strong opinion that these subprojects should be managed as fully independent projects in the same way we manage DBSourceManager code, with an independent repository. But we have a problem with crossed dependencies and it is not quite simple to make them fully independent. This is the reason because we decided to do the simplest thing: add the jars but keeping the project structure. In my opinion the benefits are: -hide complexity to most openbravo developers (99% of them do not care about the three subprojects code, they will not change a line of code there) -improve performance (below I explain why this improvement is not irrelevant) and the only disadvantage: -possible but very unlikely inconsistencies because of duplicity in the repository (jar can be calculated from source code) About the points raised in the thread: 1.- If jars are included source code should be removed from the repository: Fully agree but it is not quite simple because of crossed dependencies. As we have a tight schedule I think it makes sense to postpone this process to a early project in 2.60 2.- The time it takes is irrelevant in the whole process: I don't agree. If we succeed in the project the average of a quickbuild will be around 40 seconds and usually less than 20 seconds. With the fix done by Stefan to build the three libraries takes 2 seconds (so from 5 to 10%) BUT only if there has not been changes in code. If changes have happened then it takes 20 seconds that 99% of the people should skip 3.- It is a mess. I don't agree. In fact it is just the opposite. Once the project finishes 99% of the people do not need to think about how to build the system: quickbuild.partial when working locally and quickbuild.complete after svn.update. 4.- Managing commits for this three projects is a mess I don't think it is so complicated. Once the jar's are included in the repository the svn client will realize changes there. Most of the times only three people need to take care about this 5.- Inconsistencies because of different jdks I don't agree. Each openbravo version has a recommended jdk and it should be used, the mistake is not to use the proper jdk. We don't have this problem with DBSourceManager nor any third party library I hope my explanations have been clear enough. Let me know if you (don't) agree with my analysis and let's try to close this topic asap. Thanks to all for your feedback, and sorry again for not posting this explanation two days ago. Regards, 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
