[prev in list] [next in list] [prev in thread] [next in thread]
List: jpackage-discuss
Subject: [JPackage-discuss] [Fwd: ... we've got to get on with the film
From: Henning Schmiedehausen <hps () intermeta ! de>
Date: 2006-09-03 15:19:36
Message-ID: 1157296776.3969.0.camel () forge ! intermeta ! de
[Download RAW message or body]
Grmbl. Also wrong list. Sorry 'bout that.
-------- Forwarded Message --------
> From: Henning Schmiedehausen <hps@intermeta.de>
> Reply-To: hps@intermeta.de
> To: Jason Corley <jason.corley@gmail.com>
> Cc: jpackage-announce@zarb.org
> Subject: ... we've got to get on with the film show... (was: Re:
> [JPackage-discuss] [JPackage-announce] [RPM (1.7)] eclipse-3.1.2-6jpp)
> Date: Sat, 02 Sep 2006 19:01:17 +0200
>
> On Fri, 2006-09-01 at 09:34 -0400, Jason Corley wrote:
> > You seem to be operating under a number of misconceptions. Let's see
> > if we can't correct those by playing along with the home game.
>
> Hi Jason,
>
> well, I hope that you take the time to read my mail to the end. Maybe
> afterward, you might understand why your home game is not only rigged
> but already lost... but more of that a bit later.
>
> [...]
>
> > The reason is actually pretty straightforward. The way jpackage works
> > is we take things and modularize them into "packages." Perhaps you're
> > familiar with the concept. Instead of shipping the embedded tomcat
>
> Oh really? I _never_ heard of that before.
>
> > that comes with eclipse (which imho is horribly stupid) we use the one
>
> Yes. IYHO. That is the point. Get e.g. the eclipse 3.2.0 build from
> RedHat Rawhide (which is heavily related to the jpackage one,
> unfortunately you don't have 3.2.0 yet at all. Try installing BIRT from
> callisto. Discuss the result.
>
> > that is available in the jpackage repository. In case you haven't
> > noticed, we have precious few people working on the project right now.
>
> I've tried to contribute. A number of times. If you look at the mailing
> list archives, you will notice my name a number of times. At some point
> I gave up. If ones bug reports are ignored (neither acknowledged nor
> rejected but simply ignored), then at some point there are bigger fish
> to fry than helping a project that seems to be pushed by the "free
> software players" that don't understand how the java world works.
> I do have an outside view, that might be wrong, admittedly, I'm happy to
> learn.
>
> > As a result we are dropping packages we see little demand for from
> > our next release. Tomcat 4.1.x is one of those being dropped. Since
> > it won't be in the repo, we need to upgrade the requirements to the
> > one that is. Furthermore tomcat 5.x supports every servlet and jsp
> > specification that tomcat 4.x did, plus the newer ones. Therefore an
> > application that requires tomcat 4.1.x is broken, take it up with
> > them.
>
> You seem to have the fundamental assumption, that "everything always
> works in a backwards compatible way". If you want to spare yourself
> learning the lesson the hard way, check out gump.apache.org.
>
> Executive summary: Your assumption is wrong.
>
> What you are trying to do is "shipping always the latest and greatest".
>
> I stay on Tomcat here because there it is the most glaring obvious. I
> could also use log4j. (Man, am I looking forward to the 1.2 -> 1.3
> update of log4j... You are in for a rude "log4j-1.2.13 ->
> log4j12-1.2.13 / log4j-1.3" split here).
>
> Short and sweet: There is no upgrade path that goes
> Tomcat 4.1 -> Tomcat 5.0 -> Tomcat 5.5. Never was. That is even
> documented on tomcat.apache.org
> (http://tomcat.apache.org/whichversion.html - "We recognize that
> upgrading across major version may not be a trivial task,[...]").
>
> It surely is not "rpm -Uvh".
>
> You can't pull out Tomcat 4.1 out of a program that uses it as a
> component and put in Tomcat 5.5 and believe everything still works. It
> might _look_ that it still works. But there are subtle problems that
> will show up sooner or later.
>
> What I told you about JNDI datasource factories is not "a bug". That is
> why there is no "bug report" for it. It is a symptom of your packaging
> problems. And it shows that your fundamental assumption of "we should
> have only one copy of a library everywhere and hope it still works"
> might work for the world of C-languages but it is bound to break for the
> Java world.
>
> In the C-world, as long as your apps can bind against libc, they work
> most of the times. But as soon as you move in the world of heavy duty
> library users (let's say a gnome or kde linked app), you can forget that
> you can do a library core update and the application will not suffer.
> That is why distributions ship a whooping number of new RPMs whenever a
> new KDE minor update comes out.
>
> > Hopefully this clears up some of your FUD.
>
> I know that you will consider this whole mail either "FUD" or a flame.
>
> Yes, there is some frustration venting here. But in the end, I know that
> my points are valid. If you choose to ignore them, fine. But due to the
> fact that all major distributions try to adopt jpackage, you, yes, *YOU*
> Jason Corley and your fellow committers _WILL_ screw up Linux as a major
> Java platform. And that would be a real shame. Because we would have to
> play the "get the JDK, put it into /opt/java/, add some links and hope
> for the best" game ad infinitum. I do like the jpackage idea. Not the
> current implementation, though.
>
> You asked about "contributing" and "bug reports": Why do I not
> contribute more to jpackage? Because my intentions for that kind of
> project that I would envision jpackage to be, would be fundamentally
> different. I would be interested in "getting an environment where stuff
> works together". Not to prove a political point.
>
> I will now show you a number of practical applications of your
> principles:
>
> Let's take a look at some of the jpackage 1.7 RPMs:
>
> rpm -qp --requires ...
>
> jetty5-extras requires geronimo-jta-1.0.1B-api
> ==> you can't install jetty with Sun JTA. Even if
> jta-1.0.1B is installed, you will end up with two
> jar's in /usr/share/java. Good luck with that. Especially
> if your app running _in_ jetty brings the Sun jar...
>
> apache-axiom requires geronimo-javamail-1.3.1-api
> ==> Same as above.
> You can't install axiom with Sun Javamail
> And it requires an explict version. There is no
> versioning in there. There is an explicit
>
> --- cut ---
> Requires: geronimo-javamail-1.3.1-api
> --- cut ---
>
> in the SPEC file. Not "Requires: javamail >= 1.3.1". What if
> this is upgraded to 1.3.2 (we are at 1.3.3 already BTW)? Do we end
> up with geronimo-javamail-1.3.1-api-1.0 and geronimo-javamail-1.3.2-api-1.0???
>
> Ah and BTW axis2 requires in turn apache-axiom
> ==> You can't install axis2 with the Sun packages. You are forced to
> use the geronimo ones. Even if I know them to be buggy...
>
>
> And so on and so on and so on. I can build that list to indefinite
> length. And you want to tell me that this is _not_ a political move but
> "just an oversight"? Come on. Let's stop bullshitting each other. It
> walks like a duck, it quacks like a duck. It is a duck. Thank you.
>
> Let's do another small test. I just ran a mirror of the jpackage archive
> and set up a yum repo for 1.7.
> Enter a clean Fedora 5. Just JDK 1.5 from Sun installed as RPM. Trying
> to install tomcat5 from jpackage 1.7:
>
> [...]
> Error: Missing Dependency: j2sdk = 2000:1.4.2_12-fcs is needed by package java-1.4.2-sun-compat
>
> Ok, let's go slow. Installing jpackage-utils and
> java-1.5.0-sun-compat-1.5.0.08-1jpp.noarch.rpm by hand. Why is that in
> non-free BTW? The package contains only a few symlinks and directories.
> Politics?
>
> 2nd try: % yum install tomcat5
> Error: Missing Dependency: eclipse-ecj >= 0:3.1.1 is needed by package tomcat5-common-lib
>
> Oh, wait. It's in fedora4; my fault. Didn't expect to have any
> architecture dependent RPM requirement when installing tomcat5.
>
> Yes, A *Java* compiler surely _is_ platform dependent. (Uhm, didn't I
> just install a JDK? Which might, by accident, contain a ... compiler?
> Ah, never mind. Apache does the same thing anyway. They screwed up,
> let's screw up, too).
>
> Let's install that compiler to see where we end up...
>
> % rpm-ivh /home/mirror/jpackage/1.7/fedora-4/free/RPMS/eclipse-ecj-3.1.2-1jpp.i386.rpm
>
> 3rd try: % yum install tomcat5
> [...]
> Dependencies Resolved
>
> =============================================================================
> Package Arch Version Repository Size
> =============================================================================
> Installing:
> tomcat5 noarch 5.5.17-5jpp jpackage-1.7 233 k
> Installing for dependencies:
> ant noarch 1.6.5-2jpp jpackage-1.7 1.0 M
> axis noarch 1.4-2jpp jpackage-1.7 10 M
> bcel noarch 5.1-8jpp jpackage-1.7 459 k
> burlap noarch 3.0.8-1jpp jpackage-1.7 31 k
> caucho-services noarch 3.0.8-1jpp jpackage-1.7 7.5 k
> classpathx-jaf noarch 1.0-9jpp jpackage-1.7 58 k
> classpathx-mail noarch 1.1.1-4jpp jpackage-1.7 757 k
> geronimo-jta-1.0.1B-api noarch 1.0-3jpp jpackage-1.7 21 k
> hessian noarch 3.0.8-1jpp jpackage-1.7 84 k
> jakarta-commons-beanutils noarch 1.7.0-5jpp jpackage-1.7 348 k
> jakarta-commons-collections noarch 3.1-6jpp jpackage-1.7 490 k
> jakarta-commons-daemon noarch 1:1.0.1-6jpp jpackage-1.7 31 k
> jakarta-commons-dbcp noarch 1.2.1-7jpp jpackage-1.7 109 k
> jakarta-commons-digester noarch 1.7-5jpp jpackage-1.7 175 k
> jakarta-commons-discovery noarch 1:0.3-4jpp jpackage-1.7 72 k
> jakarta-commons-el noarch 1.0-7jpp jpackage-1.7 107 k
> jakarta-commons-fileupload noarch 1:1.0-6jpp jpackage-1.7 24 k
> jakarta-commons-httpclient noarch 1:3.0-7jpp jpackage-1.7 207 k
> jakarta-commons-launcher noarch 0.9-6jpp jpackage-1.7 42 k
> jakarta-commons-logging noarch 1.0.4-6jpp jpackage-1.7 65 k
> jakarta-commons-modeler noarch 1.1-8jpp jpackage-1.7 112 k
> jakarta-commons-pool noarch 1.3-3jpp jpackage-1.7 64 k
> log4j noarch 1.2.13-3jpp jpackage-1.7 320 k
> mx4j noarch 3.0.1-6jpp jpackage-1.7 1.8 M
> regexp noarch 1.4-2jpp jpackage-1.7 35 k
> saxon noarch 6.5.3-4jpp jpackage-1.7 414 k
> servletapi4 noarch 4.0.4-4jpp jpackage-1.7 74 k
> tomcat5-common-lib noarch 5.5.17-5jpp jpackage-1.7 89 k
> tomcat5-jasper noarch 5.5.17-5jpp jpackage-1.7 465 k
> tomcat5-jsp-2.0-api noarch 5.5.17-5jpp jpackage-1.7 59 k
> tomcat5-server-lib noarch 5.5.17-5jpp jpackage-1.7 1.6 M
> tomcat5-servlet-2.4-api noarch 5.5.17-5jpp jpackage-1.7 104 k
> wsdl4j noarch 1.5.2-4jpp jpackage-1.7 227 k
> xerces-j2 noarch 2.7.1-8jpp jpackage-1.7 1.0 M
> xml-commons noarch 1.3.03-5jpp jpackage-1.7 8.8 k
> xml-commons-resolver11 noarch 1.3.03-5jpp jpackage-1.7 63 k
>
> Let's see. ant? axis?? bcel??? burlap???? caucho-services????? Hello, I
> wanted Tomcat, not Resin. Ah, and Resin is under GPL, not Apache
> License. I thought, when I install Apache Tomcat, I will get an Apache
> licensed stack... Politics?
>
> There is wsdl4j. Mother of all dependencies.
>
> I do wonder how the Apache people manage to do that. Those crazy
> miseducated Java developers that ship their Apache Tomcat 5.5.17 as a
> binary package from apache.org, they surely *must* not have any idea
> what they are doing...
>
> That BTW is what you get with the Apache binary distribution:
>
> bootstrap.jar
> catalina-ant-jmx.jar
> catalina-ant.jar
> catalina-cluster.jar
> catalina-optional.jar
> catalina-storeconfig.jar
> catalina.jar
> commons-daemon.jar
> commons-el.jar
> commons-logging-api.jar
> commons-modeler.jar
> jasper-compiler-jdt.jar
> jasper-compiler.jar
> jasper-runtime.jar
> jsp-api.jar
> naming-factory-dbcp.jar
> naming-factory.jar
> naming-resources.jar
> servlet-api.jar
> servlets-cgi.renametojar
> servlets-default.jar
> servlets-invoker.jar
> servlets-ssi.renametojar
> servlets-webdav.jar
> tomcat-ajp.jar
> tomcat-apr.jar
> tomcat-coyote.jar
> tomcat-http.jar
> tomcat-i18n-en.jar
> tomcat-i18n-es.jar
> tomcat-i18n-fr.jar
> tomcat-i18n-ja.jar
> tomcat-jkstatus-ant.jar
> tomcat-juli.jar
> tomcat-util.jar
>
> To me, that constitutes to servletapi2.4, commons-daemon, commons-el,
> commons-logging, commons-modeler, jsp-api2.4. I'm willing to throw log4j
> in the mix for good measure. That's it.
>
> But let's not be unfair. The Apache Tomcat people probably repackaged a
> number of sources. Let's go to the Tomcat source code. Still. No caucho.
> No hessian. No burlap. Only Apache licensed code. No GPL code.
>
> And no wsdl4j, for heavens sake.
>
> classpathx-mail? Snicker. Snicker. So we might end up with
> geronimo-javamail-1.3.1-api and classpathx-mail? Two implementations for
> one API? Great. You really proved your point of having "only one library
> for all applications".
>
> jar tvf /usr/share/java/geronimo-javamail-1.3.1-api.jar | grep javax/mail/Store
> 2832 Tue Mar 07 19:01:02 CET 2006 javax/mail/Store.class
> 711 Tue Mar 07 19:01:02 CET 2006 javax/mail/StoreClosedException.class
>
> jar tvf /usr/share/java/javamail.jar | grep javax/mail/Store
> 4441 Mon Aug 21 11:23:04 CEST 2006 javax/mail/Store.class
> 698 Mon Aug 21 11:23:04 CEST 2006 javax/mail/StoreClosedException.class
>
> Face it folks. You are now dead in the water. What if an application
> that uses axis2 (which requires the geronimo-javamail thing) runs in
> tomcat (which in turn requires the classpathx thing)? You do end up with
> two different implementations on one classloader path.
>
> Welcome to class loader hell. You are trying to amend that with symlink
> tricks. That is the same game that is played with the runtime linker in
> the C-world. Microsoft lost that game in DLL hell. You will lose that
> game, too. In class loader hell.
>
> I do rest my case now. I know that you are trying to apply "C" ideas of
> shared libraries and common code to Java and some of the jpackage people
> that wrote me personal mail, consider the Java world "20 years behind".
>
> Well, here is a thought. Maybe, after 20 years of struggling with common
> libraries and DLL hells, someone _got_ a clue and considers this "not a
> good idea".
>
> Maybe it _is_ better to have a few copies of a 20 or 200 kb library
> called "commons-collections.jar" because the programs depending on it
> have been tested against subtle different versions of it. Yes, I am
> aware of "zlib". That's what you have a package system for. And you
> cannot even avoid it when you dissect perfectly well working packages.
> You will end up with missing functionality (naming-factory-dbcp.jar) or
> still repackaged classes.
>
> Or you screw up a licensed stack (Tomcat under Apache License) by
> pulling in GPLed components. And *THAT* folks, *THAT* is a disservice to
> your users. Because it screws them hard if they ever rely on jpackage
> and care about licenses.
>
> My advice for you is: Don't try to be perfect. Try to be good.
>
> And Java is not C. Do not make the mistakes of the past. Again.
>
> Best regards
> Henning
>
>
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development
Linux, Java, perl, Solaris -- Consulting, Training, Engineering
"For a successful technology, reality must take precedence over
public relations for Nature cannot be fooled" - Richard P. Feynman
_______________________________________________
JPackage-discuss mailing list
JPackage-discuss@zarb.org
https://www.zarb.org/mailman/listinfo/jpackage-discuss
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic