On Mon, Jul 18, 2011 at 8:04 PM, Thomas Mueller <[email protected]> wrote: > If this is the spec file you mean: > http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html, then > I would prefer "The %build Section" to be: "./build.sh jar" or > something similar. If this doesn't work, then I would like to > understand what the problem is, so I can fix the build script, or > improve the build documentation.
Yes. This is .spec file that we use for RPM packaging. OK. The main problem is that building an RPM does not allows usage of network and compiled binaries. At all. This is not a technical reason, but a policy for us, as a software provider. We shall build everything from the source offline, especially for our SUSE Linux Enterprise product line. The problem with the whole Maven is that generally it grabs *binaries* from the *network* to *resolve* the deps and thus replicates the reason why RPM and its ecosystem exists for. Now, on top of that we have a "joy" that in Java there is no such one single standard thing, like "configure; make; make install" routine, but everybody solving in their own odd way (partly because they can, or because they prefer something, or they think it is better etc). So it results that the every single package needs a special treatment. We tried many ways, as well as Debian folks and RedHat guys. But what best works for us is to: 1. If Ivy involved — rip off that cr%p away and convert to a plain Ant. 2. If Maven, then mvn ant:ant 3. If Ant only, we are in a business. 4. Resolve all the classpath inside the build.xml (more fun, when it is converted from Maven) and make sure project builds. 5. Move all that substitution from a shell scripts to the .spec file inside. 6. Run %ant macro 7. Copy/install required stuff (javadoc, jars, resources etc) where it needs to be so. Usually javadoc goes to the separate RPM package. Like this. > I could create an Ant build.xml or Maven pom.xml, but I would prefer > not to because that would be a partial solution only. That's what we need: an Ant build.xml but only move reference to a class-path jars to a, e.g. "libraries.properties" or something, but nothing else. The file "libraries.properties" would be just a variables with a full path to the real jars. Hence JPackage utils will find required dependency JARs and remove "hardcoded" paths in that "libraries.properties" file and Ant will compile project as expected. The goals should be: 1. Source should contain ONLY sources. 2. Should be compiled offline. 3. Dependencies are managed by the package manager (RPM in our case). Of course, if we hit some JAR dep that we don't have package for, we go first package it, and so on, and so on, recursively for the entire deps tree. So you now know what the hell is to be a Java packager for Linux. :-) > There are > multiple problems to use Maven or Ant, the main reason is: it would be > more complicated. Currently, Maven is only called in some cases (to > download build dependencies, and to upload the jar file into the local > repository). I do know both Ant and Maven quite well by the way. Maybe you can help with some ideas how better to deal then? We want basically "configure; make; mike install" for Java. And Ant looks like closest so far, and the most reliable. Yes, it is ugly in some places and has trade-offs, but still it is most reliable tool around. For instance, if you know what are best ideas (or have already some homegrown tools) how to convert best Maven to Ant — would you like to share? > Do you need to know the list of runtime dependencies? Well, H2 doesn't > have any runtime dependencies except for a JDK. However, there are > optional dependencies, for example if you want to use the Lucene > Fulltext Search feature you need Lucene. But that's not used by > default. There are other such optional dependencies (the Servlet API > if you want to use the H2 Console Servlet). Those dependencies are > also used when compiling, and are downloaded by the build script > (using Maven, if installed, as you found out). Well, I had to build entire Lucene just to package it. :-) But also we can not go with your latest version, because you require Lucene 3, which is not yet packaged anywhere. We all are on Lucene 2 right now... Lucene 3 is in ToDO list, but who knows when it will be finished, since it requires tons of other dependencies that we not yet there. :) Thanks! -- bo -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
