On 04/20/2012 04:55 PM, Adrian Schröter wrote:
Am Freitag, 20. April 2012, 12:20:45 schrieb Pascal Bleser:
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
On 2012-04-20 09:55:44 (+0200), Adrian Schröter
wrote: 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. I aggree.
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) I admit, that I do not have any inside of maven. But when we can not create multiple packages, it is still better to create one big package, but generate everything from source there IMHO.
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...) When it can not be done inside of rpm, maybe it is up to the users to install it with their tools (similar to gem). But it should not be part of our distro. And currently we consider everything inside of build.opensuse.org as a potential candidate for openSUSE (can be discussed as well of course).
+-+------------------------------------------------------------- | (*) 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. Frankly, you as java developer. Are you using our rpms at all? Or do you prefer to install the latest version yourself as jar file?
In my personal POV, it is better not to ship this software then to break our promisses, we usually gave when shipping rpms. We do promise that the stuff is reviewed and we are able to fix it in a compatible way _ourself_. Anything where this is not true should not be part of our distro IMHO.
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). You would win some users here and loose others, maybe more important ones on
... the other side. Eg. companies who want to preload our stuff, but we won't be able to give any guarantees for our stuff anymore.
...
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 ? I had esp. the copyright violation in mind. Oracle showed that they are willing to sue others when they copy non-free stuff from them. And exactly this information is lost when you have just jar files. Our license digger will be able to detect such copyright violations anymore (and it does find quite some issues in the factory submissions, all of them would be not deteced anymore).
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*" yep
, 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. I am still obsolute 100% behind that the openSUSE distro must be fully open source and being manageable by us (or everybody who is able to work on sources).
It might be okay that we define some other namespace in OBS where these rules are explicit not required. (Btw, the todays german court decision between YouTube& GEMA showed that courts may require us to screen submission from users before making them accessable. But that has only partly some effect here).
Some very good points there Adrian. I agree that openSUSE must remain 100% open source and if including Java binaries means less openness, then lets stick to not having some Java packages in OBS. Regards, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org