Re: Developing with Java on Debian
Hi Matthew, Matthew Johnson schrieb: It's unclear to me what they want to be configured at runtime by changing the classpath. I'll ask them and report back. I talked about the classpath issue with the jpackage guys. We didn't go into detailed arguments as it is a minor policy issue that doesn't concern my current work too much and may be easily switched when changed. They just said that they still maintain the policy and that they may respond themselves here on the list. They are subscribed. Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
On Mon, June 30, 2008 14:26, Matthew Johnson wrote: > > Sufficiently clever build systems should propagate the build CLASSPATH > to the manifest automatically anyway. I'm a bit confused by this. Doesn't that assume that the build and runtime classpaths are identical? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
Thanks Matt for taking the time to look through my package. Your comments helped a lot. I've updated the package: deb http://debian.richcole.org.s3.amazonaws.com unstable/ deb-src http://debian.richcole.org.s3.amazonaws.com unstable/ in line with your suggestions. I had originally mistakenly believed it was building correctly but it was using the jar that came with the source to create the timezone files rather than the built jar. (Hence my confusion about the classpath in the manifest :) After fixing that issue the process to generate the timezone files bombs out with [java] Exception in thread "main" java.lang.ArithmeticException: Adding time zone offset caused overflow This only occurs when running with gcj on the built jar, a jar built with gcj but run on the sun jvm on the other hand succeeds. It is also the case that gcj requires a modification to one of the source files to compile (it has to do with a class extending Calendar which implements Comparable) I wonder if the exception I'm getting is due to me having chosen a bad version of gcj or whether for the time being its a showstopper for compiling with gcj. To make some progress time being I changed the dependency to sun-java6-jdk. I went to create an ITP and discovered that joda-time has already been packaged. Somehow I missed it previously. Credit to reportbug for asking me to search :) The current version of the package (libjoda-time-java) doesn't build on my system. It gets the same exception as I listed above when trying to generate the timezone files. If an existing package doesn't build at what point is it a bug. Should it build in the current version of testing? Is there any system that regularly tests that existing packages are still buildable? Or is it developers who test? I guess if it built and the tests ran before and now it doesn't then its more likely the latest version of gcj that is to blame. regards, Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
Hi Matthew, Matthew Johnson schrieb: Ah, hmm, I think it only looks in /usr/share/java, since this was a tool for Debian, and thats where all our jars are stored. I forgot to mention that I modified your script to look into "my" directory. This is a very simple modification and makes your script _very_ useful to analyse not-yet-installed package dependencies during packaging. This should therefore not be the problem. And as I said, your script correctly retrieves the dependencies on other packages that are included in "my" directory. My modification is hardcoded so not very useful as a general patch to your script. If you like you might add a parameter to your script that allows addition of further jar repositories to be included in the analysis. I think this would be useful for other packagers as well. Rgds, Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
Hi Matthew, Matthew Johnson schrieb: It's unclear to me what they want to be configured at runtime by changing the classpath. I'll ask them and report back. Wrapper scripts without classpath manifest items also result in large classpaths containing items you shouldn't have to know about (your dependencies' dependencies) and causes unnecessary transitions when these change. Ok, that makes sense to me. You may also have a look at their build support system as they have some quite useful helper scripts as well. jpackage-utils is available in universe/contrib. But not available in Debian. Sorry, didn't know that. It must be a Ubuntu-only package then. Hmm, if you can give me a test case, I'd be very interested. It _should_ only suffer from giving you too many dependencies when there are multiple jars containing the same class. Sure. The problem occurred for me when I tried to build the jbossmq.jar in the jbossas4 package. To reproduce you'd have to download the jboss source code package from [1]. This package comes with a lot of binaries (which we are now replacing by jars built from source). Extract all the jars from the source package and put them in one directory. Then try to establish the dependencies of jbossmq.jar. It has a build dependency on jboss-j2ee.jar which doesn't show up for me when I analyze jbossmq.jar. All other dependencies are correctly discovered. Rgds, Florian [1] http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942&release_id=548923 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
On Mon Jun 30 10:01, Florian Grandel wrote: > Hi Java developers, > >> One problem that I haven't solved so far is how to get the classpath >> into the MANIFEST file as was proposed earlier in this thread. > > As you may have remarked from my earlier posts I am working with the > JPackage guys recently. Their "recommendation to Java developers" arguments > against adding classpaths to the manifest. Well, they are wrong. > Probably the first three arguments do not apply to the Debian > environment, but the last one may. I have not yet made up my mind on > that. I just didn't want you to loose their arguments: > "Do not use Class-Path references in MANIFESTs > > The Class-Path system of MANIFESTs is evil because: > > * It doesn't work with JDK 1.x. > * It only works at runtime, not at build time. > * It only works for a specific installation hierarchy. These are, as you say, not relevant for Debian. I particularly like the second point, since their solution of wrapper scripts means maintaining two lists of classpath, one in the build system and one in the wrapper _anyway_. The specific installation heirarchy thing is interesting. The wrapper script is going to have to have _some_ guess at the heirarchy and if that doesn't work you are just pushing the problem of creating the classpath onto the user, which is clearly bad. Sufficiently clever build systems should propagate the build CLASSPATH to the manifest automatically anyway. > * It can not be configured. It's unclear to me what they want to be configured at runtime by changing the classpath. > Wrapper scripts are much versatile and universal. We provide a set of > convenient shell helper functions for setting up such Unix scripts easily > (see jpackage-utils in project CVS)." [1] Wrapper scripts without classpath manifest items also result in large classpaths containing items you shouldn't have to know about (your dependencies' dependencies) and causes unnecessary transitions when these change. > You may also have a look at their build support system as they have some > quite useful helper scripts as well. jpackage-utils is available in > universe/contrib. But not available in Debian. > And as Richard was asking earlier how to identify dependencies within jar > packages: I am using Matthew's java-propose-classpath a lot and it works > fine (Thank you Matthew!). But sometimes it seems to miss some > dependencies, I have not yet found out why. Hmm, if you can give me a test case, I'd be very interested. It _should_ only suffer from giving you too many dependencies when there are multiple jars containing the same class. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Developing with Java on Debian
Hi Java developers, One problem that I haven't solved so far is how to get the classpath into the MANIFEST file as was proposed earlier in this thread. As you may have remarked from my earlier posts I am working with the JPackage guys recently. Their "recommendation to Java developers" arguments against adding classpaths to the manifest. Probably the first three arguments do not apply to the Debian environment, but the last one may. I have not yet made up my mind on that. I just didn't want you to loose their arguments: "Do not use Class-Path references in MANIFESTs The Class-Path system of MANIFESTs is evil because: * It doesn't work with JDK 1.x. * It only works at runtime, not at build time. * It only works for a specific installation hierarchy. * It can not be configured. Wrapper scripts are much versatile and universal. We provide a set of convenient shell helper functions for setting up such Unix scripts easily (see jpackage-utils in project CVS)." [1] You may also have a look at their build support system as they have some quite useful helper scripts as well. jpackage-utils is available in universe/contrib. And as Richard was asking earlier how to identify dependencies within jar packages: I am using Matthew's java-propose-classpath a lot and it works fine (Thank you Matthew!). But sometimes it seems to miss some dependencies, I have not yet found out why. Maybe it's just a configuration error on my side. I also found http://www.kirkk.com/main/Main/JarAnalyzer. Looks promising as it should give you all dependencies in one run. Has anybody of you already used this? Cheers, Florian [1] http://www.jpackage.org/jpprequest.php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
On Sun Jun 29 23:25, Richard Cole wrote: > > I'd be pleased if you (the collective of debian java packagers) would > look over what I've done and provide comments, hints and suggestions. Well, some general observations just looking at the packaging. There is a built jar in the source, which isn't a problem, as long as it _has_ source (which it does) and you don't use it during the build (or rebuild it first, which you don't). You have also missed changing some of the templates such as the javadoc author and the ITP close, but you were presumably leaving those until later. In the rules file you do: jh_build -o-nowarn joda-time.jar src/* mkdir -p $(TZ_DEST_DIR) java -cp joda-time-1.5.2.jar org.joda.time.tz.ZoneInfoCompiler -dst $(TZ_DEST_DIR) -src $(TZ_SRC_DIR) $(TZ_ZONES) jh_build -o-nowarn joda-time.jar src/* You should use joda-time.jar not joda-time-1.5.2.jar, since the former is the one built from source. You should also call a specific version of Java, not which ever is first in path. If you are setting JAVA_HOME for jh_build, then $JAVA_HOME/bin/java is correct. I also think it would be better to manually add the classes to the jar with fastjar uf joda-time.jar , in which case those lines become something like: jh_build -o-nowarn joda-time.jar src/* $JAVA_HOME/bin/java -cp joda-time.jar org.joda.time.tz.ZoneInfoCompiler -dst $(TZ_DEST_DIR) -src $(TZ_SRC_DIR) $(TZ_ZONES) fastjar uf joda-time.jar $(TZ_DEST_DIR)/* > One problem that I haven't solved so far is how to get the classpath > into the MANIFEST file as was proposed earlier in this thread. > > I presume that the standard java class loader honours the classpath in > the MANIFEST. Is that right? Should javahelper be adding junit.jar to > the classpath. Yes, it does and javahelper provides a couple of ways of doing so. jh_build should add it automatically. If you used the ant script then jh_manifest can be used to add it to the jar afterwards. In fact, testing it here, it does: $ jar xf joda-time.jar META-INF/MANIFEST.MF $ cat META-INF/MANIFEST.MF Class-Path: /usr/share/java/junit.jar This also causes junit to be added to the depends (and so, you don't need it in your debian/control file): $ cat debian/libjoda-time-java.substvars java:Depends=junit > I choose not to use the ant-script that came with Joda-time but > instead used the java-helper primitives.One issue I encountered was > that joda-time generates timezone files as part of the build process > using itself and then includes those in the jar. You'll see that I > call jh_build twice, one to build the jar, then again to package the > jar after adding the generated timezone files. > > At this stage I just tested with gcj. I had some problems building, but I appear to have a broken installation of gcj on the machine I have available to test at the moment. As you say, this is a slightly unusual build, so it will not fit exactly with the simple work flow in javahelper. > >> by which you presumably mean sun-java6-jdk, if you haven't noticed that > >> it's now in non-free > > > > sun-j2sdk1.6 is the package generated by java-package. If you want to > > really epend on a propriatory JDK please use sun-java6-jdk instead. > > Ah, I hadn't noticed that it was in non-free now. I presume this means > I can get rid of java-package and the packages it produced and swap to > the sun-java6-jdk. Yes, you can. Hope those comments were useful, Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Developing with Java on Debian
To better understand debian packaging java libraries I used javahelper to package joda-time which is a pretty nice date-time library for java. I've put my effort at: deb http://debian.richcole.org.s3.amazonaws.com unstable/ deb-src http://debian.richcole.org.s3.amazonaws.com unstable/ You can't get a directory listing there, so here's the contents: 2$ s3cmd ls s3://debian.richcole.org/ Bucket 'debian.richcole.org': 2008-06-30 05:35 570 s3://debian.richcole.org/unstable/Packages 2008-06-30 05:35 434 s3://debian.richcole.org/unstable/Packages.bz2 2008-06-30 05:35 422 s3://debian.richcole.org/unstable/Packages.gz 2008-06-30 05:35 1523 s3://debian.richcole.org/unstable/Release 2008-06-30 05:35 529 s3://debian.richcole.org/unstable/Sources 2008-06-30 05:35 412 s3://debian.richcole.org/unstable/Sources.bz2 2008-06-30 05:35 392 s3://debian.richcole.org/unstable/Sources.gz 2008-06-30 05:35 1592 s3://debian.richcole.org/unstable/joda-time_1.5.2-1.diff.gz 2008-06-30 05:35 685 s3://debian.richcole.org/unstable/joda-time_1.5.2-1.dsc 2008-06-30 05:35 1017 s3://debian.richcole.org/unstable/joda-time_1.5.2-1_i386.changes 2008-06-30 05:35 1270854 s3://debian.richcole.org/unstable/joda-time_1.5.2.orig.tar.gz 2008-06-30 05:35 1434758 s3://debian.richcole.org/unstable/libjoda-time-java_1.5.2-1_all.deb I'd be pleased if you (the collective of debian java packagers) would look over what I've done and provide comments, hints and suggestions. One problem that I haven't solved so far is how to get the classpath into the MANIFEST file as was proposed earlier in this thread. I presume that the standard java class loader honours the classpath in the MANIFEST. Is that right? Should javahelper be adding junit.jar to the classpath. I choose not to use the ant-script that came with Joda-time but instead used the java-helper primitives.One issue I encountered was that joda-time generates timezone files as part of the build process using itself and then includes those in the jar. You'll see that I call jh_build twice, one to build the jar, then again to package the jar after adding the generated timezone files. At this stage I just tested with gcj. >> by which you presumably mean sun-java6-jdk, if you haven't noticed that it's >> now in non-free > > sun-j2sdk1.6 is the package generated by java-package. If you want to > really epend on a propriatory JDK please use sun-java6-jdk instead. Ah, I hadn't noticed that it was in non-free now. I presume this means I can get rid of java-package and the packages it produced and swap to the sun-java6-jdk. regards, Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
On Sun, Jun 29, 2008 at 11:56:52PM +0100, Matthew Johnson wrote: > On Sun Jun 29 15:04, Richard Cole wrote: > > I've started looking into javahelper, very nice package. > > > > I tried to package a small library (jarjar) following the javahelper > > tutorial but I got stuck. I was trying to build with sun-j2sdk1.6. I > > by which you presumably mean sun-java6-jdk, if you haven't noticed that > it's now in non-free sun-j2sdk1.6 is the package generated by java-package. If you want to really epend on a propriatory JDK please use sun-java6-jdk instead. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
On Sun Jun 29 15:04, Richard Cole wrote: > I've started looking into javahelper, very nice package. > > I tried to package a small library (jarjar) following the javahelper > tutorial but I got stuck. I was trying to build with sun-j2sdk1.6. I by which you presumably mean sun-java6-jdk, if you haven't noticed that it's now in non-free > tried calling jh_build from debian/rules: > > jh_build jarjar.jar src/main > > jh_build then tried to call javac src/main, but javac said that > src/main was an invalid flag. It seems that you have to list all the > java files to be compiled when you call the sunjava version of javac. Hmm, I remember changing something related to that. But I can't now find it. Indeed you are correct, GCJ does what you would expect and Sun javac does not. I shall change it to find | xargs, but be annoyed at having to do so. There doesn't seem to be a way (afaict) to compile more java files than will fit on a command line, which is a bit of a pain. The fix will be in the next upload. > So it seems that most software in debian is being compiled with > java-gcj. Is there a significant difference in the class files that > are produced by java-gcj and sunjava? Is java-gcj the current > preferred compiler in debian by virtue of it being open source? Is > anyone thinking of ways to select either a java-gcj or sunjava built > system? Are their issues mixing jars from the two compilers? How > stable is java-gcj? The only difference is the default version of class file produced. As long as you are producing class files of at most as new a version as your runtime supports, it doesn't matter which compiler you use. Since it is only compiled to byte code there is not much of an issue of optimization either. The main difference is whether there are any language features etc which you use that gcj doesn't support yet. It is pretty good with 1.5 features, but as yet does not have a class library with generics to compile against, so using generics from the standard library won't work (but will in your own classes). Of course, the main difference is that if you compile with gcj the package can go in main, not contrib. openjdk should fix that. Generally we recommend building with gcj (or, rather, default-jdk) where possible. > Is there any plan to integrate javahelper with common debian build > system, so that one can reduce the size of ones debian/rules files? Well, it is already as terse as debhelperized packages (which amount of code I personally like). If someone who knows cdbs would like to integrate it into there I would be more than happy, however, I don't know cdbs and therefore cannot do so myself. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Developing with Java on Debian
I've started looking into javahelper, very nice package. I tried to package a small library (jarjar) following the javahelper tutorial but I got stuck. I was trying to build with sun-j2sdk1.6. I tried calling jh_build from debian/rules: jh_build jarjar.jar src/main jh_build then tried to call javac src/main, but javac said that src/main was an invalid flag. It seems that you have to list all the java files to be compiled when you call the sunjava version of javac. So it seems that most software in debian is being compiled with java-gcj. Is there a significant difference in the class files that are produced by java-gcj and sunjava? Is java-gcj the current preferred compiler in debian by virtue of it being open source? Is anyone thinking of ways to select either a java-gcj or sunjava built system? Are their issues mixing jars from the two compilers? How stable is java-gcj? Is there any plan to integrate javahelper with common debian build system, so that one can reduce the size of ones debian/rules files? regards, Richard. On Tue, Jun 24, 2008 at 10:05 AM, Matthew Johnson <[EMAIL PROTECTED]> wrote: > On Tue Jun 24 09:39, Richard Cole wrote: >> So I'm still wondering how the packaging of java packages in Debian works. > > Hi, I am very interested in improving the state of Java packaging in > Debian. In fact, I have written a set of tools to help with it which do > some of the things you described below. Have a look at > javatools/javahelper. > >> Lets say that I do some more research on Hibernate and discover it >> really cannot run without Log4j because classes in Hibernate directly >> reference Log4j. [1] Then I submit a bug report and the dependency >> gets added. Where's the classpath? Are there any tools for (i) working >> out whether a classpath is closed with respect to resolution of direct >> class references [2], > > I was looking at the problem of automatically constructing classpaths, > which is intractable because there are jars with duplicate classes in > them. However, javahelper has a script which guess a classpath based on > that, but which needs checking. It's called java-propose-classpath. > >> (ii) do java libraries in debian express their >> classpath? Should they have a classpath, something like >> /usr/share/java/hibernate-annotations-1.2.jar.classpath ? > > Currently there is no policy that libraries should include the Classpath > manifest item for recursive dependency resolution. I think this is > definitely something we should do. At the moment people are constructing > the entire classpath in their wrapper scripts, which needs to pain, > suffering and unneeded transitions. It also allows people to use a tool > such as jarwrapper to launch Java programs via executable jar files, > rather that with wrapper scripts. > >> My guess is that if we had (i) and (ii) we would not be very far from >> (a) an automated way to verify package binary correctness, and (b) an >> automated way to infer dependencies that integrates with debhelper and >> cdbs. > > I have written such a tool in javahelper. jh_depends will set the > java:Depends substvar to satisfy the Classpath manifest item in any > jars in the package. > >> I'm new to Debian packaging, still trying to understand and practice >> packaging, so I'm wondering if I'm thinking in the right direction. >> Are there records of discussions had by the java packaging team at >> Debian? > > Not many, but we need to have more (-: > >> [1] A side question on policy here, should I submit a bug report with >> some limited knowledge, or should I wait and research the issue in >> detail before submitting a bug report? > > You can always add followups to the bug report, so there's no reason not > to submit it earlier. > > Matt > > -- > Matthew Johnson > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIYSlv2XtckeYvo1gRAmcPAKCXSp3n0zj2gwv8gc0PsallwAykLQCgqQE7 > So4TccJOPgwIbmWNxRiXVDY= > =8g5h > -END PGP SIGNATURE- > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
Richard Cole wrote: So I'm still wondering how the packaging of java packages in Debian works. Lets say that I do some more research on Hibernate and discover it really cannot run without Log4j because classes in Hibernate directly reference Log4j. [1] Then I submit a bug report and the dependency gets added. Where's the classpath? Are there any tools for (i) working out whether a classpath is closed with respect to resolution of direct class references [2], (ii) do java libraries in debian express their classpath? Should they have a classpath, something like /usr/share/java/hibernate-annotations-1.2.jar.classpath ? The current state doesn't (so far as I understand) seem very good since the idea is to put jars under /usr/share/java or perhaps /usr/share/xyzzy and the package probably works out the classpath based on assuming everything is there. However I've been talking with the people who are developing the modules support planned for Java 7 (JSR 277). Something I've asked them is how this should play out for the linux distros (in general). What they're telling me is it will be possible for a distro (e.g. Debian) to have a module repository built into the packaging system. With that the Java runtime would be automatically able to handle a lot of this for you. This will require some kind of glue layer (service provider implementations) to interface ... But that's Java 7, and by the statement we made at JavaOne last month it won't be available until mid-2009. As for today... http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html Jar files can directly express their classpath requirements using the Class-Path entry in the JAR manifest. I suppose the debian packaged jar's could interpolate their dependencies into these JAR manifest entries. No need for a separate file. - David Herron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
On Tue Jun 24 09:39, Richard Cole wrote: > So I'm still wondering how the packaging of java packages in Debian works. Hi, I am very interested in improving the state of Java packaging in Debian. In fact, I have written a set of tools to help with it which do some of the things you described below. Have a look at javatools/javahelper. > Lets say that I do some more research on Hibernate and discover it > really cannot run without Log4j because classes in Hibernate directly > reference Log4j. [1] Then I submit a bug report and the dependency > gets added. Where's the classpath? Are there any tools for (i) working > out whether a classpath is closed with respect to resolution of direct > class references [2], I was looking at the problem of automatically constructing classpaths, which is intractable because there are jars with duplicate classes in them. However, javahelper has a script which guess a classpath based on that, but which needs checking. It's called java-propose-classpath. > (ii) do java libraries in debian express their > classpath? Should they have a classpath, something like > /usr/share/java/hibernate-annotations-1.2.jar.classpath ? Currently there is no policy that libraries should include the Classpath manifest item for recursive dependency resolution. I think this is definitely something we should do. At the moment people are constructing the entire classpath in their wrapper scripts, which needs to pain, suffering and unneeded transitions. It also allows people to use a tool such as jarwrapper to launch Java programs via executable jar files, rather that with wrapper scripts. > My guess is that if we had (i) and (ii) we would not be very far from > (a) an automated way to verify package binary correctness, and (b) an > automated way to infer dependencies that integrates with debhelper and > cdbs. I have written such a tool in javahelper. jh_depends will set the java:Depends substvar to satisfy the Classpath manifest item in any jars in the package. > I'm new to Debian packaging, still trying to understand and practice > packaging, so I'm wondering if I'm thinking in the right direction. > Are there records of discussions had by the java packaging team at > Debian? Not many, but we need to have more (-: > [1] A side question on policy here, should I submit a bug report with > some limited knowledge, or should I wait and research the issue in > detail before submitting a bug report? You can always add followups to the bug report, so there's no reason not to submit it earlier. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Developing with Java on Debian
So I'm still wondering how the packaging of java packages in Debian works. Lets say that I do some more research on Hibernate and discover it really cannot run without Log4j because classes in Hibernate directly reference Log4j. [1] Then I submit a bug report and the dependency gets added. Where's the classpath? Are there any tools for (i) working out whether a classpath is closed with respect to resolution of direct class references [2], (ii) do java libraries in debian express their classpath? Should they have a classpath, something like /usr/share/java/hibernate-annotations-1.2.jar.classpath ? My guess is that if we had (i) and (ii) we would not be very far from (a) an automated way to verify package binary correctness, and (b) an automated way to infer dependencies that integrates with debhelper and cdbs. Storing classpath's in addition to package dependencies would allow for finer grained dependencies, e.g. if package X provides jars A and B, and Y has a jar C that needs A, then Y requires X, but the classpath for C would mention just A (and we would close the classpaths before using them). I'm new to Debian packaging, still trying to understand and practice packaging, so I'm wondering if I'm thinking in the right direction. Are there records of discussions had by the java packaging team at Debian? regards, Richard. [1] A side question on policy here, should I submit a bug report with some limited knowledge, or should I wait and research the issue in detail before submitting a bug report? [2] .i.e. if one class references another class directly, not through a string or some such, then we should be able to resolve that class with the classpath. On Fri, Jun 20, 2008 at 8:18 AM, Florian Grandel <[EMAIL PROTECTED]> wrote: > Hi Richard, > >> Right now I see that hibernate is available as a library package that >> has put jars in /usr/share/java. If I depend on these jars and write a >> unit test I discover that there are more dependencies, I need some of >> the apache commons libraries and the log4j library, but I can't see >> those as dependencies. > > Are you speaking about declaring dependencies within Eclipse (=configuring > the project's build path)? > > Or are you speaking about missing jar-packages required for the hibernate > package on the Debian package layer? > > In the second case, if there are dependencies that have not been > automatically installed on the system you should probably file a bug as > Andrew said. > > In the first case however (which I think you were talking about) I don't > know about an Eclipse plugin that is capable of interpreting Debian package > dependencies and "importing" them as build path dependencies to Eclipse. The > only thing I can think of is that you manually look at the package > dependencies (either through a script using dpkg or through Synaptic GUI -> > package properties) and see which jars or sources have been installed by > packages depending on the library you are interested in. > > If you are an advanced scripter you might write a script that updates your > .classpath-File in the Eclipse project folder based on information retrieved > from Debian packages. I'd be really interested if you invented something > like this. It might even not be very hard to do it that way. :-) > > Florian > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
Hi Richard, Right now I see that hibernate is available as a library package that has put jars in /usr/share/java. If I depend on these jars and write a unit test I discover that there are more dependencies, I need some of the apache commons libraries and the log4j library, but I can't see those as dependencies. Are you speaking about declaring dependencies within Eclipse (=configuring the project's build path)? Or are you speaking about missing jar-packages required for the hibernate package on the Debian package layer? In the second case, if there are dependencies that have not been automatically installed on the system you should probably file a bug as Andrew said. In the first case however (which I think you were talking about) I don't know about an Eclipse plugin that is capable of interpreting Debian package dependencies and "importing" them as build path dependencies to Eclipse. The only thing I can think of is that you manually look at the package dependencies (either through a script using dpkg or through Synaptic GUI -> package properties) and see which jars or sources have been installed by packages depending on the library you are interested in. If you are an advanced scripter you might write a script that updates your .classpath-File in the Eclipse project folder based on information retrieved from Debian packages. I'd be really interested if you invented something like this. It might even not be very hard to do it that way. :-) Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developing with Java on Debian
Richard wrote: > This is a bit of a newby question. > > What I'm wondering is whether one can use the debian package system as > a kind of build system. Let me illustrate with an example, say for > example I want to write an app and package it with debian and this app > uses Hibernate, then I would like to declare a dependency on the > hibernate libary package and start developing in eclipse right away. > > Right now I see that hibernate is available as a library package that > has put jars in /usr/share/java. If I depend on these jars and write a > unit test I discover that there are more dependencies, I need some of > the apache commons libraries and the log4j library, but I can't see > those as dependencies. So report a bug against the hibernate package: it certainly should require all of its dependencies. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Developing with Java on Debian
This is a bit of a newby question. What I'm wondering is whether one can use the debian package system as a kind of build system. Let me illustrate with an example, say for example I want to write an app and package it with debian and this app uses Hibernate, then I would like to declare a dependency on the hibernate libary package and start developing in eclipse right away. Right now I see that hibernate is available as a library package that has put jars in /usr/share/java. If I depend on these jars and write a unit test I discover that there are more dependencies, I need some of the apache commons libraries and the log4j library, but I can't see those as dependencies. I'm guessing what I want is a vanilla java library debian source package and a plugin for eclipse that understands how to read the build dependencies, but I would not like to have to rediscover the dependencies of the hibernate, they should have been specified by the package maintainer for that system, and I should get them for free. I would also be nice to be able to get the source in a package called for example: libhibernate3-java-dev or libhibernate3-java-dbg that would make go-to-definition work much better in eclipse. Is any of this possible with Debian? What should I be reading? Are there examples I can look at? Are there forums where the strategy for java and debian is being discussed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
