Re: [java-gnome-hackers] Libraries vs Packaging (1): Linkage
Brought to you by:
afcowie
From: Vreixo F. L. <met...@ya...> - 2011-06-19 15:03:44
|
Hi! I have been reading this thread the last days and I would like to tell you all my opinion, as I don't really agree with many of the options discussed so far. First, I'd think we should distinguish between gnome stuff, that is present in most (if not all) gnome-based distros, and other stuff that only some distros provides (I'm thinking of things like appindicator). In the first case (pure gnome stuff) it MAY BE interesting to java a single jar file and it MAY BE useful to have a single .so. I will discuss about this later. For now, let me focus in the second case: libraries that are not part of gnome or that they are not installed in most distros. In this particular case, in my opinion it MAKES NO SENSE to include it in java-gnome (I mean in the java-gnome jar), neither always nor conditionally by means of a compile time flag. In the first case (always including that sutff) it would be a pain in the ass for users of distros that do not include it. I don't like to install things that require too many dependencies to stuff I'm not going to use, and I think most people don't like it neither. So I think it would be a terrible idea to do so. On the other side, a compile-time flag is also, imho, a bad idea. Distros will surely include different flavours of java-gnome, leading to an inconsistent API across distros. A pain for developers and a terrible approach, too (in fact, it is a terrible solution also in C, although it is very common). Runtime checks like hasModule(xxx) are also a bad idea imho, as aplications will either behave very differently across distros or fail at runtime. If an application feature is going to be enabled only on some distros, it is better to leave that for compile time, not at runtime. But, does this mean that this no-gnome stuff should not be include in java-gnome? Not, at least it shouldn't. I my opinion the best approach is to include it with java-gnome sources (maybe in an /src/opt folder), but never include then in the main java-gnome jar. Instead, we should generate different JARs (and JNI so) for each independient stuff (for example, java-gnome-appindicator, java-gnome-whatever...). A compile-time flag should be used to choose whether to build those optional jars. Then distros can package them separately. In this case, applications that depend on, let's say, appaindicator, should add a dependency to the desired jar, and check for the presence of that jar at compile time. This way we keep a common API, but also offer support for non-gnome stuff. We should provide some way for developers to know with of our classes require additional dependencies, by means of documentation, and maybe naming conventions (for example, including them under an org.gnome.optional package?). So, at this point, let me go back to gnome stuff. In this case, it is good to have a single jar and single API, but we could consider generate separate jars for stuff that is not very commonly used, or stuff that is sometimes used independently of other parts of the library (I think you had mentioned cairo...). But all of them should be compiled and distributed always, for the sake of a common API across distros, and the only purpose of separation is efficiency, memory usage, etc. Some experiments should be carried out in order to check if there is actually a significant impact, anyway. Another idea is to have a single jar, but different .so, that are loaded only when needed. So, what do you think? Any other idea? Best regards, Vreixo |