H guys, I recently discovered Syncany and I started to look into the code and run it for the first time. It looks very promising.
My first step to get familiar with it was to build an openSUSE package. Usually packaging software gets you familiar with the build process. Specially in the Java world where most of the anti-packaging atrocities are committed :-) You can find my first package here: https://build.opensuse.org/package/show?package=syncany&project=home%3Admacvicar%3Ajava So what did I found? The first was obvious: all binary jars are in lib/ and lib/plugins. This is cool for development. But most Linux distros need (due to policy) to build all dependencies from source. I saw a thread about moving to maven. Don't do this. Packaging Java software for Linux is usually hard, but maven makes it 100x harder. Why? Because getting maven package built from source for a distribution means hundred of dependencies. Probably more than what maven will ever help build. Just imagine that "make" on Linux would need KDE to build itself. There are good things to get from maven: directory layout, dependency management, etc. Get those. But please stay away from maven. So after building the first Syncany package from source (but using the binary jars in /lib) I tried to cleanup lib/*. I wrote an ivy.xml file. ivy is a simple dependency manager. It solves _one_ of the problems maven solves, without bringing all the other complex stuff. The idea is simple. The source should not include any jars. The place where to get the jars is in ivysettings.xml and the dependencies for different configurations is in ivy.xml. As a developer you do "ant something" and it would download all the jars to lib/. Done. Any distro that ships binaries can include these in the _binary_ dist, but the source dist should be generated without those. Linux package descriptions will delete them anyway. I would like to contribute these ivy files and the modified build.xml. However I am still struggling with some jars, as they are not available in any public artifact repository or are not "resolvable". After that I will have to find out how to deal with bzr :-( I am also looking in how to organize the ivy dependencies with regard to the plugins. If you plan to support Linux, stay with ant. ant + ivy gives you most of the benefits and still more flexibility, while still allowing for packagers to just "find . -name *.jar | xargs rm -f" and then create a CLASSPATH from the packaged (and built from source) dependencies. Cheers! -- Duncan Mac-Vicar P.
-- Mailing list: https://launchpad.net/~syncany-team Post to : [email protected] Unsubscribe : https://launchpad.net/~syncany-team More help : https://help.launchpad.net/ListHelp
