Document Actions
Developer FAQs
Notice: many of these FAQs are currently outdated - they're being updated on our Developer's Wiki at this page, Developer FAQs.
Getting a build
- How do I get the sourcecode?
- How do I get a build working?
- Who is managing the build process?
- What are all of the various builds?
Contributing to the source code
- How do I find out what areas need the most help?
- How do I submit patches?
- What is the review process?
- What is the commit process?
- How do I use the build server to verify that my code doesn't break the build?
- What role do I need on the java.net site?
- What do I need to do code review?
- Do I need to do a build to do code review?
- How do I propose changes to the data model?
- How do I report a bug?
- I have an idea for a feature, should I enter that?
- Are there separate issue and bug tracking?
- What tools will I need to install?
- What are the overall test plans? How are we doing integration testing and stress testing?
- Is there an official build somewhere that people can hit so that they can determine if a bug reproduces in the main branch of the code (vs. their own private branch?)
- Build Server - is the build server posting to a known system somewhere that people can hit?
- Can we support mixed-mode environments; e.g., can someone working on the front end hit a shared back-end?
- How do you get the system into a known state for bug repros? E.g., if you create accounts and put money into them, how do you roll that back to reproduce things?
- What do you need to have installed in order to run test scripts (JUnit? Watir? Etc.)
Q: How do I get the sourcecode?
A: See Install Mifos.
Q: How do I get a build working?
A: See Install Mifos.
Q: Who is managing the build process?
A: Cardinal rule is that no one should break the build ("break" means cause any failure in any of the junit tests). If you break the build, you must fix it or back out your changes. Most of what goes on in the build is controlled by build.xml and other checked in files - subject to the same Code Submission Process as everything else. GFUSA is implementing a build server and will be hosting this. See #CruiseControl.
Q: What are all of the various builds?
A: First, the developer build. This is the developer build - pending : having that build post to a working container-mysql site.
The iteration build - or called the iteration release is at http://test.mifos.org:8080/mifos and is meant for testing purposes. Note that data is over-written every two weeks. See Install Mifos for details to access the iteration build.
Each iteration "release" is tagged in svn, and you can find a build of the tagged release in the snapshot folder. The official release build will be made available in the future. For more information, see Mifos Versions.
Q: How do I find out what areas need the most help?
A: Please review the Product Roadmap page, open issues, and Technical To Do's. Or, simply ask the listserv.
A: Send an email to the listserv prior to starting work, explaining your approach and asking for feedback, then provide the patch via the listserv including tests.
Generally speaking each patch should include jUnit tests for that functionality. Something like a 1:1 ratio is expected for lines of test: lines of code. Highly desireable to also include end-to-end integration test cases, so all exceptions should be discussed on the listserv. see also Code Submission Process.
Q: What is the review process?
A: If you can, it can be useful to pair up with a coding buddy, while you write code or afterwards, to ensure that at least one other person has reviewed before submitting. But it is more important to frequently check in with the Listserv or IRC. One good way to do this is to send in small patches every day (or so). That way you get feedback which you can apply when you write the next bit of code.
It can also be good to ask about what you are thinking of doing to see whether people like the idea, what the impacts of a change will be, etc.
Q: What is the commit process?
A: Grameen Foundation's Tech Lead manages the commit process. The key thing to understand is what we expect from checkins (chiefly, don't break the build and follow the Coding Standards).
Q: How do I use the build server to verify that my code doesn't break the build?
A: Just run the tests on your own machine. The build server should produce the same results.
*Q. What role do I need on the java.net site? Please see the roles and descriptions at Project Roles. Despite the name, Observer is what we ask that you as a developer request.
Q: What do I need to do code review?
A: Minimally, you only need the ability to access the code and read the code in an editor. Then send emails to the listserv. We use Eclipse IDE, and the settings are checked into the SVN.
Q: Do I need to do a build to do code review?
A: No, but most people like to see the runtime before they work on a set of code.
Q: How do I propose changes to the data model?
A: We have used DBDesigner4 for the data model. With this tool, we can create a mySQL database from the XML format and roundtrip back to DBDesigner from mySQL. Since there are multiple dependencies on the data model, if you are intending to modify the model to make a feature work better, the best way to make it happen is to also describe how data migration from the old model to the new model would work. See Database Standards for more on database upgrades.
A: See Bug Entry Guidelines.
Once you are familiar with the process, you can enter a bug in the Issue Tracker. Bugs are automatically assigned based on sub-component so there's no need to assign your bug to a specific developer. If you want to receive email notifications when a bug is entered into the issue tracker, you can send an email to issues-subscribe@mifos.dev.java.net.
Q: I have an idea for a feature, should I enter that?
A:Please send an email first to the mifos-functional listserv and then propose the feature in the feature tracker. Emily Tucker will be coordinating these requests.
Q: Are there separate issue and bug tracking?
A: No, See Issue Tracker; this will contain bugs and issues.
Q: What are the requirements for a deployment server?
A: Our target is a platform neutral build and developers on the list are providing sample.properties files. If you get a build running, please think about providing your properties file used during build. We do not yet have an official set of requirements for a development or deployment platform, however here are some recommendations
- Minimal RAM is 1GB to support the current version of the code in SVN that includes BIRT integration.
- MySQL 4.1, JBOSS - all on one machine is possible. See build options in README.
- All configuration files are in the SVN configuration directories.
- Our target is eventually to run on an in-memory database (e.g. Mayfly) and in a light-weight container (jetty).
Q: What are the overall test plans? How are we doing integration testing and stress testing?
A: Please see the Testing Plan page.
Q: Is there an official build somewhere that people can hit so that they can determine if a bug reproduces in the main branch of the code (vs. their own private branch?)
A: Yes, see the question on different builds above.
Q: Build server - are the builds generated on the build server posting to a known system somewhere that people can hit?
A: The build results and build stats can be found here. The build itself is not being posted to an application/DB server automatically yet.
Q: Can we support mixed-mode environments; e.g., can someone working on the front end hit a shared back-end?
A: We don't have any plans for a shared back-end. MySQL 4.1 is fairly straightforward to setup, and a shared back end causes problems with speed, versioning control issues, and tracking down why failures are happening. See also Roadmap.
Q: How do you get the system into a known state for bug repros? E.g., if you create accounts and put money into them, how do you roll that back to reproduce things?
A: Developers should expect to be able to test on the interation build and the current developer build. If the error cannot be reproduced, the developer should update locally.
Q: What do you need to have installed in order to run test scripts (JUnit? Watir? Etc.)
A: Currently, the team is only using JUnit, so this is the only dependency to run test scripts. In the future, we would like to add Watir scripts back in or Selenium running under Ruby (and at this point, we will call out these new dependencies). This is a project for someone to volunteer for. The junit jar is in the lib/ directory.