Difference between revisions of "RoadmapToModularization"
(→Roadmap to Modularization) |
(→Roadmap to Modularization) |
||
| Line 3: | Line 3: | ||
''This article in the works.'' | ''This article in the works.'' | ||
| − | ''I am new to the community and have not been involved into former debates. | + | ''I am new to the community and have not been involved into former debates. So the analysis below is an high-level view and may miss some aspects. Nevertheless, to the newbie, the modularizations problems do not seem to be that hard and I just wanted to express that.'' |
| − | So the analysis below is an high-level view and may miss some aspects. | + | |
| − | Nevertheless, to the newbie, the modularizations problems do not seem to be that hard | + | |
| − | and I just wanted to express that.'' | + | |
== The Problem == | == The Problem == | ||
Revision as of 04:26, 27 March 2009
Roadmap to Modularization
This article in the works.
I am new to the community and have not been involved into former debates. So the analysis below is an high-level view and may miss some aspects. Nevertheless, to the newbie, the modularizations problems do not seem to be that hard and I just wanted to express that.
The Problem
Adempiere is the only real community-based open source ERP project.
As such, the community decides about goals and way, about preferrable extensions, subprojects, bugs and fixes. This is great.
Adempiere even provides (borrowed from Compiere) a solid technological foundation: The dictionary, where data structures and the corresponding user interfaces are stored and can be changed on-site. It even contains references to business logic (writting perferrably in Java): Callouts (onChange events in the UI) and Processes (onClick events on Buttons, if you want).
Now in day-to-days live, it turns out that these tools are not sufficient: Too often it is nessecary to change parts of the core code to get customer requirements satisfied. For example, if one wants the current user name to be printable on docs (https://sourceforge.net/forum/message.php?msg_id=6946827), one is required to code that in a print control class in the core. While the requirement is perfect and the solution, too, it can only be delivered to the customer as a "patch" or a "customization", jars that are put to the classpath in front of the core classes, overwriting them.
The drawback of this approach is obvious: Only one change can be deployed at a time. If you want more, you have to merge patches.
The alternative would be to commit the solution to the trunk and use it (dangerous) or wait for it to be released (slow). What in reality often is the last resort: Branch. Apply the patch here and use the branch. But while this seems to be a viable approach (I love branches), it too often lead to forks: Branches that became incompatible and can only be re-integrated with immense costs.
