On 2012-04-20 15:55:35 (+0200), Adrian Schröter
Am Freitag, 20. April 2012, 12:20:45 schrieb Pascal Bleser: [...]
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.
The thing with Maven is that: - packaging Maven itself is very tricky precisely because of its bootstrapping: it downloads Maven modules to build itself after bootstrapping a small Maven core - Maven would require to be patched, too, to * avoid Maven downloading artifacts dynamically while building (although offline mode should be enough for that (mvn -o)) * look up libraries in our RPM based installation scheme (/usr/share/java/.../*.jar), which is quite different from Maven's (*) (*) Maven uses the following layout, which has established itself as a de-facto standard in the java world: $M2_REPO/groupId/artifactId/version/artifactId-version.jar e.g. ~/.m2/repository/net/sourceforge/cobertura/cobertura/1.9/cobertura-1.9.jar (groupId is "net.sourceforge.cobertura" here, which is why it maps to the filesystem and to HTTP URLs as "net/sourceforge/cobertura") I think it would make things a lot easier in many regards if instead of /usr/share/java/foo/foo.jar we were using the same scheme as Maven for java library RPMs, namely something like /usr/share/java/repository/net/sourceforge/cobertura/cobertura/1.9/cobertura-1.9.jar instead of /usr/share/java/cobertura/cobertura-1.9.jar That way, using Maven or Gradle or Ivy, it would be as simple as defining one of the repositories to be /usr/share/java/repository instead of having to implement our current scheme with patches and hacks in Maven.
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).
Sure, that's not the issue. There are a few things that I believe would still be useful as RPMs though, specifically to have something to start/bootstrap whole chains of dependencies with. Specifically: * Maven * Ant * Gradle (those are the three most common build tools) Ant is already packaged in openSUSE since a long time (although the package is really weird and doesn't always work because it apparently strips off some parts of it or hides them into non-obvious subpackages, but I never investigated the details or a fix.) And Eclipse and Netbeans probably make a lot of sense too, as those are very widely use development environments, and not just for Java. [...]
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) ? [...] 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?
I don't, never. But I'm not sure I can be compared to the average developer who comes from a Windows or MacOSX background. And then there are a few desktop applications in Java that cater to users rather than developers. For sysadmins who run production systems, I can see the advantage of using RPM packages of containers such as Tomcat, Jetty, JBoss, etc... though.
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.
Okay, valid point, although it's not always true, there are exceptions already, such as Firefox, but the reasons are quite different (massive codebase for Firefox, and issues with build systems and dependency handling for java)
...
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.
I believe that not catering to developers is a huge mistake. Seriously, how many actual developers are there in our community? From what I can see, and that includes inside SUSE, very, very few. How much people do we have who are capable and willing to contribute to real development efforts in our project? Very, very few. I don't mean hacking some perl scripts, I mean proper software development. Larger stuff. That's certainly a different topic and debate to be had, but to me, those are linked.
...
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).
Oracle did not show anything up to now, there are basing their claims on currently very dubious and unclear rules (especially regarding the term "API" and what _their_ interpretation of it is in court). There's an article or two on the current proceedings at groklaw, one can read it in more depth over there. And, furthermore, we are not implementing our own virtual machine based on Java, are we ? Those are completely different things. The documentation that Oracle has provided and shown during the trial up to now very clearly makes the point, again, if it had to be made at all, that there is no issue whatsoever with software that is developed using java and/or runs on java. Bar none. As with libraries written in C, it only comes down to the license of the library itself, and the compatibility to its dependencies. Exactly the same really. See the JVM as being the glibc, from a licensing point of view. And openjdk itself is GPL. Again, to make this very clear: there is _absolutely_ no issue with licensing and open source here, except those that we have with non-java components too (the license of the piece of software itself, whether it is accurate and doesn't have individual files that have different copyright headers, and the license compatibility with its dependencies, unless it's under Apache license because then we don't even have to care about license compatibility). If we package binary upstream tarballs as RPMs using their dependencies inside the package, then there is potentially an additional verification to be made on the license of those, as those jar files typically don't include information about their licenses -- that is, if we don't trust upstream to make the same verifications prior to releasing something. Except, again, if it's under Apache license because AFAICR it doesn't have any clauses on license compatibility towards dependencies. It can even depend on non open source bits, if I'm not mistaken. IANAL, but I'm pretty sure, and I could check in detail if needed, although we have more qualified people for that ^^ [...]
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).
There is no discussion to be had about the open source aspect, because we all agree on that, and because all those java libraries/dependencies/applications _are_ open source (the vast majority being under http://spdx.org/licenses/Apache-2.0 which doesn't have any copyright compatibility issues with dependencies). (Yes, it's the third time I'm saying that, but I want this to be _very_ clear :))
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).
I'm not sure how that relates to this matter. Do you mean we would need to make complete source code reviews before accepting anything? Then move everything to another country, because that's simply not feasible, regardless of java or not. cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf