Making Processing Library Templates Fit For Collaboration

[craftoid]

Problem

When several people work on a Processing library or tool via git, they usually have different operating systems, classpaths, sketchbook locations etc. These things are configured in build.properties, and are under version control (which is a bad thing).

Solution

• Create custom config files named local.properties that are excluded from version control.
• Provide template files: local.properties.tmpl that the developers need to copy and customize to their needs.
• Modify the build process to use both local.properties and build.properties

Implementation

I already implemented a solution and opened a pull-request for the old repo, which you can find here: processing/processing-templates#1

[prisonerjohn]

Hi Martin,

First of all, sorry for not noticing this pull request on the old repo, it must've slipped through the cracks.

Thanks for this, these updates are very useful for teams working on a library or tool. However, most contributions to Processing are developed by individuals. My goal with the library template is to have an as easy as possible starting point to offer developers, which they can modify to suit their needs.

As it stands, the template user only needs to edit a single file to configure their project. This config file feeds the Ant script, library properties file, and web directory. I feel that the extra steps involved with your changes (duplicating and renaming a second properties file, editing settings in both local.properties and build.properties) will not be advantageous to most users, who are working on their own.

Maybe the new git-friendly templates will encourage collaboration, in which case we should definitely revisit a solution such as this one!

[craftoid]

Hi Elie,

Thank you for your response! The suggested changes emerged in a a situation where I started to work on a tool collaboratively.

I must say, I totally agree with you: Simpilicity first!

However: The problem with the simple solution is that even if some folks just wants to pull the repo, and build the library on their own machine, they always have to manually adjust the build.properties file every single time they issue a pull request.

Probably it would be best to have different git branches, each with a different pre-configured properties file. Like one for OSX, one for Windows, one for Linux and one for collaborative work. So if you wanted to start a new library, you would just fork the branch that suits your needs, and it would work out of the box for most users...