So I’ve got a nice Java project, build with Ant to a /dist folder.
The whole project is under version control, so I can deploy the latest version just by ‘svn export’ on the path to the dist folder.
But my build keeps deleting the .svn folders inside my dist folder, and all its dependents, because it cleans out the folder when building instead of just overwriting. The precise culprit is JarBundler, the Ant task that builds my mac.app bundle – It deletes the whole bundle’s folder before recreating it.
This obviously craps up my svn, because all the .svn folders are now missing for that folder and so it says its in conflict.
Anyone have any ideas for how I could solve this? I can’t figure out how to stop jarbundler from deleting everything, so im going to have to do something more hacky I fear. Im pretty new to Ant as well, just for reference.
To have dist in source control can be considered as good practice if you want your source control system to be a unique referential for all:
BUT you need to have a proper release process to pull this through.
In your case, the build must be in a separate and private directory, that is a directory not in subversion. When the build is ok, you import it into subversion if it is an official release, or you import it to a shared directory if it is a temporary build, just needed by the next team (thus avoiding to commit hundreds of builds into SCM, using space for nothing).
Note: the main advantage for having the delivery (dist) in your SCM is to allow dependent project to work not with your sources, but directly with your delivery (which is bound to go at one point or another into production): if they manage to make their code work, by compiling with your delivery, chances are their own dist, when deployed with your, will work.
That way, the other teams access your delivery (your ‘myProject.jar’) as they access any of their sources: they can read through the SCM the version of your jar, its date, its history, its metadata, its label, and so on.
However, for one small monolithic (as in ‘no other projects depend on it’) project, it can be argued that dist (the final packaged delivery) could be re-build on demand and stored in an external referential system, as an external Maven repository for instance.
BUT: Maven is no SCM repository, meaning you need to sign you jar (‘MyProject-1.0.jar’), you have no history, and you need to report all your metadata on a separate text file along your delivery. Any other project accessing to that delivery in that Maven repo needs to adjust its scripts and classpaths accordingly to your version naming convention.
Plus, Maven is another repository in your development architecture. Whenever you can keep the number of repos to a minimum (of ‘1’ 😉 ), it is better.