syncany-team team mailing list archive

[Duncan Mac-Vicar Prett <dmacvicar@xxxxxxxxx>]

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.