On 2012-04-20 09:55:44 (+0200), Adrian Schröter
Am Donnerstag, 19. April 2012, 22:21:52 schrieb Angelos Tzotsos:
There was a small discussion among Application:Geo project members about this issue today. I was asked to bring this issue to this list so that we can all discuss it.
The problem: Currently it is forbidden to package binaries in OBS without building from source code. This causes issues when we need to build very complex Java applications or web applications (eg like Geoserver, Geonetwork, JOSM etc). In Java it is nearly impossible to build everything without bringing jar binaries in the game at some point (eg maven depends on itself to build). If we want to do this without binaries it would take a very large effort for many packages and it would be a dependency nightmare for packagers.
On the other hand, the build.o.o instance has open source and transparency in mind, so the policy to request sources and not binaries is fair.
While I think it is not a good idea to have exceptions, some exceptions for very few packages to be able to boot strap may be okay from my POV. On the other hand, all other languages, like C/C++/C# or even pascal and haskal can boot strap themselfs. Why should java be an exception?
Sorry, very long email ahead, but I'd like to clarify a few points to not have to argue about them again and again ^^ Java can bootstrap itself. OpenJDK bootstraps from C (the kernel of the JVM (Java Virtual Machine) is written in C). Maven can bootstrap itself too, and does so, actually. It _can_ be done, and is done for OpenJDK at least, that's not the issue. It is a question of effort vs benefit. If we take the example of Maven, which is particularily painful because it is pretty complex to build by bootstrapping and by using our "Linux" (rpm/deb) technical model for "packages" and "dependencies": Maven, as most Java based things, is designed to be portable across all operating systems that can run a JVM (of a certain version) For that reason, and because another unfortunately quite prominent operating system does not have a comparable package management model (*), it does not use a portable way of installing components of software other than just files that are downloaded and put somewhere (in the case of Maven, that's ~/.m2/repository). On a side note, that is an approach you will find with -- as far as I know -- every other build tool for Java projects which does dependency management (ivy (which is an add-on for Ant), gradle, etc...) +-+------------------------------------------------------------- | (*) To prevent off-topic discussions about Windows and MSI: +-+------------------------------------------------------------- |S| Yes, it has, to some extent, but it has always and partly |I| still is very difficult to use, and simply isn't the model |D| that has developed with its users: Windows users have always |E| and will always just download archives somewhere and use them | | from there, without much system integration -- nothing |N| *prevents* java archives to be used and handled centrally in |O| the same way as DLLs (well, sort of, for some of them ...) or |T| in the same way as it is done on Linux, but it is simply not |E| how Windows users and developers do it, for whatever reasons | | (I have a few ideas about those reasons but won't mention | | them because I don't want to be rude). | | | | In any way, let's not discuss this here, it is irrelevant. +-+------------------------------------------------------------- Hence, we are faced with two different models of managing dependencies and, in a way, the Java approach is a lot more like MacOSX' DMG, or klik on Linux, or just prehistoric zip files on Windows, which is to include most dependencies (libraries, tools) as part of an "image" of some sort (which is usually a tarball or a zip file). So, the real question is: do we want to fight an uphill battle against what 95% of Java developers are doing, or even forced to do as that's what their build environments are doing and transform every possible Java based piece of software (**) we want to have in the distro or repositories into our RPM philosophy/approach (***), or do we want to be more pragmatic about it (being aware of the tradeoffs) ? (**) which spans a very broad horizon from desktop sorts of applications (including things like Eclipse and Netbeans) to server-room stuff like Tomcat or JBoss (***) which is to remove all the Java libraries (jar files) that are shipped with a Java software distribution or retrieved using mechanisms such as Maven's, and instead have those as individual dependencies -- e.g. remove xerces from ant and have ant use a system-wide xercesImpl.jar from /usr/share/java/... Okay, now that you've answered that question for yourself thinking about Vuze or Eclipse or Netbeans, ask yourself the same question again in the shoes of a system administrator with Tomcat or JBoss.
(It is okay to have a build cycle in OBS, it should be just only very few packages and not >100 what would make the bootstrap process rather long).
Once you have a few build tools (Ant, Maven) and their dependencies (which are a lot more than that, probably around 50 to 100), you're good. But that's quite some amount of work.
The other side are add-on packages for libs and applications. I personally see no reason why we should become just a binary only hoster here and have an exception just because it is written in java.
Very clearly: convenience for users (which very explictly includes system administrators). Personally, I don't believe it makes much sense to fight the uphill battle I described above. In my not so humble opinion, it is perfectly fine to ship e.g. Eclipse or Ant or Maven with all the jar files it needs as its own set of dependencies (e.g. have Eclipse's dependencies in /usr/lib/eclipse/lib/ instead of /usr/share/java/log4j, /usr/share/java/asm, ... and a million others) as they ship from upstream rather than building every single of those dependencies on its own. Pros: + we can actually provide packages of such things without too much effort Cons: - we can't patch the sources ourselves Now, both points raise questions themselves: - do we want to provide such pieces of software as packages in the first place ? * after all, one can simply grab a tarball of Eclipse or Maven from their respective websites and install them, even without being root, aka "the windows way" * some of us hate java, mostly because they don't understand it or because of a very few GUI java applications that are slow - how likely is it that we are going to patch an upstream java library or application ourselves, rather than updating it to an upstream release that fixes the issue ? * very few in this project are fluent with java * is it an issue to push a newer version to fix rather than backporting changes/patches for those packages ? I have my personal opinion on those points above, I'll leave it up to everyone to wager theirs.
Esp. when you look at the current Google vs. Oracle fight, it makes it actually obvious for me that we need to be able to do a legal review for the java stack.
Are you sure that you understand what you are talking about ?
The downside might be that we loose quite some packages because we do not have anyone able or willing to package it anymore. Can we live without Eclipse, josm and friends?
Well, assuming you mean "without Eclipse *packages*", yes and no: * yes, because there are other ways of installing java based applications and libraries (I personally just pull eclipse from eclipse.org and put them into some directory under my home), especially for desktop applications * no if in any way we want to attract more developers (tools such as Eclipse, Netbeans, Maven, Ant are paramount to doing so, and I'm not only talking about Java developers) * no if we want to provide packages of more server oriented applications such as Tomcat, JBoss, Wildfire, Tigase, ...), which are obviously much more interesting to install in a system-wide way using our usual mechanisms (rpm, zypp).
Open question is what is more important here.
Certainly, but the other question is whether we want a holistic or a pragmatic approach. Or, rather: can we live with a more pragmatic approach ? Personally, I believe that sticking to the holistic approach ("always build from source, always. period.") just for the sake of sticking to it is stupid. If we are aware of drawbacks, it should be perfectly fine to make exceptions, if the advantages are worth those drawbacks. Which kind of brings us back to your question :) My personal opinion: hell yes, there are packages where the drawbacks are worth the benefits. But there are also lots of others where it isn't. cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf