On Fri, Nov 04, 2011 at 09:33:16AM +0000, Jim Procter wrote:
> On 03/11/2011 22:32, Vincent Fourmond wrote:
> >
> > This leads me to the bad news: jalview is fresh but already
> >broken. Debian now ships jmol version 12.2.2 (that's the stable
> >release, isn't it ?), and jalview doesn't build against it.
> >
> > Although I could tackle porting to the newer jmol, I guess it
> >won't take much time to you. I'm attaching the build failure log
> >in case someone wants to have a look. If no one steps forward,
> >I'll give it a try ;-)...
> I've been watching the jmol-dev list with feelings both of fear and
> wonderment - they have just completed a major refactoring in order
> to support an android build, and I've been looking at the new
> architecture to see how jalview might be refactored to achieve the
> same goals. I think some of the changes were already pushed into the
> 12.2 stream.
>
> I'll take a look at this over the next few days and see if it can be
> rectified. If it can, I'll push changes to both the 2.7, master and
> develop branch.
Thanks a lot !
> Unfortunately, I was somewhat concerned that this might happen with
> the packaging. Unless there is an explicit API jar generated by a
> project, they are almost always likely to change their APIs at every
> release. Would it be possible to specify a specific Jmol.deb that
> Jalview.deb requires ? As I understand it, the FTPmasters preserve
> all older versions.
Actually, that isn't the case. If you think in terms of distribution
(say, squeeze, wheezy, I don't know if that actually tells anything to
all of you), there may exist only one version of a package.
It is possible to duplicate code and have, say, a jmol-12.1 package
and a jmol-12.2 package, but that's a real pain to maintain, and the
Debian Security frowns upon that: two times the same code means
potentially having to fix security issues twice (keep in mind Debian
provides security support for all of its packages). Basically, this is
accepted as a transition to avoid breaking too many things at once,
but very seldom in a durable fashion.
That makes it particularly painfull to package Java stuff, as there
are so many tools that make it easy for a java developer to use a
particular version of a library that in general developers are a
little less careful about API breakages.
I don't know what could be a long-term solution. If this time, jmol
underwent heavy refactoring, API breakages are normal. I hope that
won't happen that often for later versions of jmol. Maybe just raising
the awareness there about which interfaces you use would encourage
jmol developers to stabilize them ? Probably you don't use too much of
jmol's internals to make it a pain for jmol developers to keep the
interface you use constant. Think about it: this means that jmol
upgrades for you would be mostly painless, and that also means that
jalview users would have an up-to-date embedded copy of jmol...
Cheers,
Vincent
_______________________________________________
Jalview-dev mailing list
[email protected]
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
