Re: [Java-gnome-developer] (Hacked) version of 4.0.13 in Maven repo

[Andrew C. <an...@op...>]

The Linux world is radically different that the others; if we want
something installed on a system we build packages for it and depend on
those.  So personally, I have no use for Maven because it is out-of-band
of the system management infrastructure.

++

Then there's a second issue, which is _executing_ Java programs, and
Maven [nor Ivy, and don't even mention Ant] doesn't help with setting up
the correct linking to run a Java program. This problem is much bigger
than java-gnome; in fact, it's a horrid weakness in Java period. 

I've actually been giving talks about this at conferences for years; ie
http://www.operationaldynamics.com/reference/talks/Equivalence/Equivalence_Presentation.html
(no you don't have to read that) and why I started with Equivalence. The
idea was sound, but admittedly [and I'm quite embarrassed about this] it
never made it past the bloated prototype that presently lives in it's
fifth project and sixth projects, java-gnome & slashtime. But frankly,
the configure problem prefacing the build is not enough; its still no
help running programs.

Five years later I actually have some radically new ideas about this,
largely to do with not using .jars any more at all and instead using the
native linking infrastructure to handle transitive dependencies, but
that's a still just a prototype too. 

++

My principle and only concern for java-gnome is consistency of developer
experience. I am  *constantly* on the case of distros encouraging them
to _not_ do something different that the others when it comes to
packaging java-gnome. If they do, then someone trying to develop — let
alone ship & package — their own work using java-gnome will be an
inconsistent nightmare. 

Back to Maven, it is widely used in some places, making it [much to my
chagrin] essentially a distro too. I'd be perfectly happy to ignore it.
If people are going to insist on using it, though, then I'm certainly
willing to listen to see what we can do to make sure that the experience
if using Maven is comparable to depending on java-gnome properly from a
distro package [or building it from source yourself, of course].

But not at the cost of corrupting the clean & integrated experience we
presently have for java-gnome "when installed on system" and "when built
in-place".

I was discussing this with Kenneth Prugh a few days ago, and he recalled
the trouble we went to [and why] to get the .so loading the way it is
now (there's was a thread on java-gnome-hackers about this at the time).
We put a lot of effort in to make that work well, and tested the hell
out of it. So it's not something I'm interested in screwing with.

++

My aesthetic & technical sense is that burying the .so in the .jar is
not the right answer, but if we're going to address this it's an
engineering issue that we need to get right for all distros, not just
Maven.

++

There is a third issue, Maven is a disaster for the security of the
ecosystem.

Distros build their own binaries for a reason. I am not a supporter of
upstreams releasing binaries, and I am even less enthusiastic about the
idea of people using some Maven repo with some copy of java-gnome in it
which we have no idea what was done to it, have no idea who made it, and
have no idea if anyone is actively maintained it. I for one flat out
refuse to run any program that sources binaries from the anonymous
public Maven repositories. I have no idea, none at all, what code is in
those binaries. And neither does anyone else. It's a *huge* security
threat. The fact that many people use them doesn't change a thing.

++

Finally, I would note that consistent experience is not just for people
developing with the library; ensuring sane and consistent packaging is
really important so that the maintainers of the library have a hope in
hell of helping people who come to us with bugs.

++

> I am not too happy about having to patch the code to get this to work
> and I have a gut feeling Andrew likes it even less...any alternate
> suggestions would be therefore welcome.


Engineering the library & packaging it for distros is something we need
to co-ordinate as a community, so if you want to pursue this please
start a thread on java-gnome-hackers and leave this list for discussing
how best to use GTK to develop rich user interfaces for GNOME desktops.

/me goes back to writing code.

AfC
Sydney