Hi! Thanks for the nice reply! On Wed, Jul 20, 2011 at 8:15 AM, Thomas Mueller <[email protected]> wrote: > Hi, > >> not allows usage of network and compiled binaries. >> We shall build everything from the source offline > > I understand (and agree). > >> Ant build.xml but only move reference to a >> class-path jars to a, e.g. "libraries.properties" > > H2 has the following compile time depedencies: > > servlet-api-2.4.jar > lucene-core-3.0.2.jar (or optional 2.2.0) > slf4j-api-1.6.0.jar > org.osgi.core-1.2.0.jar > > I didn't find Lucene 3.0.2 and osgi.core at http://www.jpackage.org/browser.
We decided to ignore JPackage, because it is a slowly dying project. Second, Lucene 3 is not ready anywhere yet. I want it though, but it is not a time yet to go there. Finally, OSGi core is here: http://goo.gl/X7xSy (SUSE Build service) > Should I rely on Lucene 2.2, or should the build work with *either* > Lucene 2.2.0 or 3.0.2? As I understand, it would be beneficial for some users to have an ability to link with Lucene 3. But in order to package your latest version would be great to have Lucene 2 available. By the way, about Lucene. Why H2 is asking for Lucene 2.2 and refuses 2.4? Is 2.4 is any different that much? > Would it be a big problem if I used my own build tool, if it doesn't > require any network connection ("./build.sh offline") if the right jar > files are in the "ext" directory? Not at all. That then is just fine, as long as you list up all the deps somewhere in the .properties and read from there. Then in the .spec file I will resolve all the stuff in "ext", delete JARs from "ext" and will generate my system-dependent .properties file. Something like e.g. if you could have "build/libraries.properties" like this: foo=ext/foo.jar bar=ext/bar.jar Then I will do in the .spec something like: BuildRequires: foo BuildRequires: bar ... cat > build/libraries.properties << EOF foo=$(find-jar foo) bar=$(find-jar bar) EOF And then run your solution that will build a JAR and JavaDoc and then do the rest. > I can add a file > "libraries.properties" in the ext directory if it helps. Is there a > better name for the "ext" directory (ext for "external dependencies")? Anything you like for "ext" rename as long as no clashes around. If I can untar your source, ./build.sh <ENTER> offline and it does not asks for Lucene 3 (for now) — perfect. > If required, I can write a wrapper Ant build.xml that calls my build > tool (but I prefer not to, actually). No, not necessary as long as your build tool comes in sources and does not requires to be packaged in prior to that. :) But you javac it first to a bytecode and then running, right? > Maven has some advantages, but: > > 1 - It pulls a *huge* amount of libraries from the network > 2 - Building a project isn't always repeatable, > I guess most current project can't be built in a few years. > 3 - It doesn't verify dependencies (with *local* hash codes) > 4 - You don't have a clear and simple list of dependencies > 5 - You first have to install it (the right version of it) > 6 - I don't like XML too much > 7 - You can't debug the build > 8 - It's hard to extend Very interesting. Can you a little bit more input on "2"? Why is that they will not be able to build later? Is that is because the artifacts changes on the maven repo while projects are getting to be old or what? > That's why I wrote my own build tool. Which isn't popular so far, I > know, but solves most of the problems. Is there any plans to make this build tool more sophisticated and as a separate project? So then we could even replace Ant with it, if it really helps that much. Writing an XML to javac a pile of Java sources is really a PITA if you have 99999 packages... Thank you very much! -- 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.
