Re: Java policy and ABI changes
[EMAIL PROTECTED] writes: Quoting Andrew Haley [EMAIL PROTECTED]: In my opinion, Java libraries without stable interfaces shouldn't be deployed in free OSes. If they are to be used, you're going to have to change the jar name, but even that may not work: if you use such a library Mozilla, some other version of the same package might be used by some other Java application running in the same process, and unless it's firewalled by some ClassLoader trickery it'll break. If that happens, some trickery like Jar Jar Links may be your only hope. Hm. All this is a bit extreme. Even the Linux kernel changes its API all the time and things are working okay. This really is grossly unfair to the kernel deveopers, who go to great lengths to avoid breaking the ABI. Would that Java package mantainers were so careful. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting Maven Into Main - What Next?
Paul Cager wrote: This is the desert island test [1], No it isn't. The Desert Island Test is something quite different, to do with the freeness of the upstream license. Please ignore this bit, as I hadn't got my brain in gear! The Debian prohibition against downloading during a package build stands, though. [1] http://people.debian.org/~bap/dfsg-faq.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java policy and ABI changes
Marcus Better writes: Andrew Haley wrote: In my opinion, Java libraries without stable interfaces shouldn't be deployed in free OSes. That's a nice goal but unfortunately the world is not so perfect, because users occasionally require new software with shiny new bells and whistles. Besides we cannot control upstream and prevent them from breaking ABI. As a distribution we need to find a balance between features and stability. I think the Java policy needs to be tweaked to allow for multiple versions of the same library. The problem is much easier than for C libraries, since we don't have a dynamic linker, so the user is responsible for adding the correct library to the classpath. We just need to make sure the different versions don't conflict, which usually means that both of them cannot install the generic symlink /usr/share/java/foo.jar. As I pointed out before, that doesn't work for Java in the general case because a single running VM can load multiple libraries, which come from different sources, which may need different versions of the same library. You're into dependency hell very quickly. It seems it would suffice to have the symlink created by postinst, which would point it at the latest installed version (similar to ldconfig). Note that I'm not suggesting we should package several versions of libraries. That should be avoided, but when necessary there should be a way to do it. I'm not going to argue with that. Sometimes everybody has to do bad things. :-) Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting Maven Into Main - What Next?
* Paul Cager: Now that we are making progress with packaging Maven's Build-Dependencies, I'm beginning to wonder what happens next. I've noticed from the JavaCC packaging that it seems to be all right to include a bootstrap jar in the upstream source. Is this right? I guess to be valid: * When building the package a new Jar must be built (from source) that could replace the bootstrap Jar. This is a bit tricky. Theoretically, you are supposed to bootstrap from an installed version (IOW, a self-depdency). However, several packages (Ocaml, for instance) bootstrap from blobs. In case of source code generators, it's also common to ship the processed source files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting Maven Into Main - What Next?
Florian Weimer wrote: * Paul Cager: Now that we are making progress with packaging Maven's Build-Dependencies, I'm beginning to wonder what happens next. I've noticed from the JavaCC packaging that it seems to be all right to include a bootstrap jar in the upstream source. Is this right? I guess to be valid: * When building the package a new Jar must be built (from source) that could replace the bootstrap Jar. This is a bit tricky. Theoretically, you are supposed to bootstrap from an installed version (IOW, a self-depdency). However, several packages (Ocaml, for instance) bootstrap from blobs. In case of source code generators, it's also common to ship the processed source files. If someone would say that if this was allowed with Maven it would make life so much easier as Maven has to many build dependencies. Then Michael Koch's binary package could be used to build all of those dependencies and then a proper Maven could be built easily. -- Trygve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting Maven Into Main - What Next?
Florian Weimer wrote: * Paul Cager: Now that we are making progress with packaging Maven's Build-Dependencies, I'm beginning to wonder what happens next. I've noticed from the JavaCC packaging that it seems to be all right to include a bootstrap jar in the upstream source. Is this right? I guess to be valid: * When building the package a new Jar must be built (from source) that could replace the bootstrap Jar. This is a bit tricky. Theoretically, you are supposed to bootstrap from an installed version (IOW, a self-depdency). So we couldn't use bootstrapping to get the *first* version into Debian? We could only use version (n-1) to build version (n)? However, several packages (Ocaml, for instance) bootstrap from blobs. Ah - so we might get away with it? Maybe I should use ask the FTP masters? In case of source code generators, it's also common to ship the processed source files. Yes, that's a possibility. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting Maven Into Main - What Next?
* Paul Cager: This is a bit tricky. Theoretically, you are supposed to bootstrap from an installed version (IOW, a self-depdency). So we couldn't use bootstrapping to get the *first* version into Debian? If there are architecture-dependent binary packages, they need to built and uploaded manually, for each architecture. The same thing happens when you break the chain. The upload history for MLton might be quite instructive here. It's basically a non-issue for architecture-independent packages. The only requirement is that the package can be rebuilt with itself. We could only use version (n-1) to build version (n)? You need to start from somewhere, obviously. 8-) However, several packages (Ocaml, for instance) bootstrap from blobs. Ah - so we might get away with it? Maybe I should use ask the FTP masters? The current Java policy requires that you strip the JARs. Not that it is rigorously followed, but you should decide first what you actually want, and then you can pester the ftpmasters. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting Maven Into Main - What Next?
Florian Weimer wrote: * Paul Cager: Now that we are making progress with packaging Maven's Build-Dependencies, I'm beginning to wonder what happens next. I've noticed from the JavaCC packaging that it seems to be all right to include a bootstrap jar in the upstream source. Is this right? I guess to be valid: * When building the package a new Jar must be built (from source) that could replace the bootstrap Jar. This is a bit tricky. Theoretically, you are supposed to bootstrap from an installed version (IOW, a self-depdency). However, several packages (Ocaml, for instance) bootstrap from blobs. In case of source code generators, it's also common to ship the processed source files. Thinking about it, am I worrying unnecessarily here? The source downloaded from svn *does* include Jars, but I think these are only used to run the unit tests. (I'm guessing; Trygve could you confirm this, please?). Once we have the build-dependencies packaged we should be able to download the svn source, delete the jars and create an upstream source tarball. Then debian/rules could just call the bootstrap.sh script (possibly amended to prevent net access). I don't think my brain is working this week... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A Java Packaging Wishlist
On 5/26/07, Trygve Laugstøl [EMAIL PROTECTED] wrote: Arnaud Vandyck wrote: If we wanna use maven to build, we need maven in main. If we want to extract metadata, we just need an xslt or some perl/python/java/whatever xml parser. No you don't. I meant that you can use Maven to generate the files and include in debian/. That way you can leverage the project's meta-data and start working on integration Maven into the build process until it is properly into main and those files can be generated build-time. I don't like the idea of generating those files at build time. But maybe I don't understand what you mean. Anyway, tools used to generate and build debian package are in main so if we want to include maven calls in those scripts, we need maven to be in main. -- Arnaud Vandyck
Re: A Java Packaging Wishlist
On Saturday May 26 2007, Arnaud Vandyck wrote: On 5/26/07, Trygve Laugstøl [EMAIL PROTECTED] wrote: Arnaud Vandyck wrote: If we wanna use maven to build, we need maven in main. If we want to extract metadata, we just need an xslt or some perl/python/java/whatever xml parser. No you don't. I meant that you can use Maven to generate the files and include in debian/. That way you can leverage the project's meta-data and start working on integration Maven into the build process until it is properly into main and those files can be generated build-time. I don't like the idea of generating those files at build time. But maybe I don't understand what you mean. Sorry to be unclear. I meant at the time when you are first assembling the package from the upstream source. The information in the pom can be used to derive a lot of data in the debian control files. In addition when another version is available from upstream the pom content can be verified back into the control files to do amendments. That wont be fully automatic of course. manfred -- Manfred Moser http://www.mosabuam.com skype: mosabua http://www.linkedin.com/in/manfredmoser
Re: A Java Packaging Wishlist
Arnaud Vandyck wrote: On 5/26/07, Trygve Laugstøl [EMAIL PROTECTED] wrote: Arnaud Vandyck wrote: If we wanna use maven to build, we need maven in main. If we want to extract metadata, we just need an xslt or some perl/python/java/whatever xml parser. No you don't. I meant that you can use Maven to generate the files and include in debian/. That way you can leverage the project's meta-data and start working on integration Maven into the build process until it is properly into main and those files can be generated build-time. I don't like the idea of generating those files at build time. But maybe I don't understand what you mean. I think you understood me correctly. There is nothing wrong with generated files, there are already lots of them begin built on every .deb build. I know it's not ideal to check in generated files, but given the benefit it shouldn't be a big problem. I made a Maven 2 plugin for this over *3* years ago [1], but still no-one has been able to leverage any of the metadata in Maven. Anyway, tools used to generate and build debian package are in main so if we want to include maven calls in those scripts, we need maven to be in main. Yes, do be a integral part of the build cycle it has to be. But it does not have to be there to be able to leverage a lot of the information that is inside every Maven-based project. [1]: Probably even earlier than that, but that was when the repository was initialized: http://fisheye.codehaus.org/changelog/mojo?cs=5 -- Trygve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting Maven Into Main - What Next?
On Friday May 25 2007, Paul Cager wrote: I have practically no experience with Maven (yet!), so it's good to meet someone who is active with it. Would you be interested in getting involved with the testing of any packaging we produce? We'd do some basic testing, of course, but it would be nice if there was testing against real world projects. Yeah. For sure. I could at least build it against my project (large JEE project with lots of subprojects using all sorts of plugins). I am currently using the upstream version as well as Michael Kochs package. Both are fine. Just to summarise what I understand to be plans for Maven: Firstly we want to package maven itself, so that users can aptitude install maven, aptitude install maven2 I assume... and Maven will work just as though the users had downloaded and installed it manually. * Create a local repository for Maven, e.g. debian/.m2/repository. For each build-dependency create the appropriate directory structure (e.g. debian/.m2/repository/plexus/plexus-utils/1.0.2/). I would actually suggest to start building a debian build server internal maven repository. Debian imposes quite strict (but sensible) rules on how its packages can be built. One restriction is that the package must be able to be built from source, without downloading anything (except other packages from the Debian archive). This is the desert island test [1], and probably disallows access to a standard maven repository. This is why I am proposing creating a temporary local repository (on the build machine) each time a package is built. I understand that restriction. I was actually proposing to create a debian private repo as part of the Debian archive into which all maven packages and dependencies go as well as into which all future packages can get their artifacts into and use others from there. I look forward to the progress. I wish I could help more but time is very short at the moment... at least I hope to be able to help by giving my input. manfred -- Manfred Moser http://www.mosabuam.com skype: mosabua http://www.linkedin.com/in/manfredmoser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
