Posting example code

Sometimes when you post a question or a suspected defect to the Lift mailing list, someone may ask you to put together an example of the problem.

In this case, an example means a fully running application that everyone can use to see/test the problem that is hosted on GitHub so that everyone can easily see the delta between the question and the answer.

Please follow all these steps:

1. Create a new Lift project
2. Write just enough code to demonstrate the issue you’re posting about
3. Make sure that the application runs via either Maven or Simple Build Tool . If you’re using a version of sbt other than 0.12.x, please include the sbt binaries in the project and make sure you include the exact command line that one needs to type to execute the app)
4. Make sure that the application has no dependencies on your database or other systems
5. Make a detailed description of both the command line steps to follow to run the example and the sequence in the browser, what you expect to see and what you actually see.
6. Create public GitHub 1 project and put your runnable code in the GitHub project
7. Make sure to add a .gitignore 2 file so pulling from your project does not take a long time.
8. Post the link to your newly created GitHub project on the Lift mailing list

Okay, so why all the work on your part? Well, in the case of non-trivial issues, someone has to take the time to put together a running example of the problem, and it might as well be you as you’re asking for other peoples’ time to address the issue. It also has to run using a build tool that is likely to be installed on a Lift committer’s machine .

We look forward to helping you address your issues.

Thanks!

1 David Whittaker explained, why to use a versioning repository popular in the Lift community: “While grabbing your source from DropBox was not a big deal, it’s nice to be able to fork the repo and then push my fixes back so you can see exactly what I did to get it to compile.” See discussion Lift%2C Squeryl and relationships.

This isn’t only a preference, it makes a huge difference when we try to help you. All the committers use git and have github accounts, so looking at your example app becomes really easy. Many times, we only have a few minutes left to look at a project and figure out why it isn’t doing what you expect, if instead of getting to work we have to unzip your file, and keep track of what we changed, and then email the zip back to you, it cuts down on the time we have left to help you. Remember, we are doing this on our free time, we want to help you, but you need to make it easy for us to help you. Unless you are willing to hire someone, and then you can just pay for the time it takes to look at your sample project.

2 .gitignore :

lib_managed
project/boot
project/build/target
target