Another option is for the version number to be in build.xml, and for it to generate a runtime file (so that Clojure can know its own version number) and set the version number inside a generated pom.xml. You can use Ant resource copying with filters to accomplish both these goals.
On Thu, Apr 23, 2009 at 8:24 AM, Laurent PETIT <laurent.pe...@gmail.com> wrote: > > 2009/4/23 Rich Hickey <richhic...@gmail.com>: >> >> >> >> On Apr 22, 12:41 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote: >>> 2009/4/22 Rich Hickey <richhic...@gmail.com>: >>> >>> > [...] >>> > {:major 1, :minor 0, :incremental 0, :qualifier :rc1 :interim true} >>> >>> > for interim versions and >>> >>> > {:major 1, :minor 0, :incremental 0} >>> >>> > for releases. :interim tracks the SNAPSHOT segment of the version >>> > string. >>> > [...] >>> > I don't mind the build producing clojure-1.0.0.jar etc, but it doesn't >>> > now. The master build is Ant. Where is the best place to put the >>> > version info so it can be leveraged by Ant, Maven and the clojure core >>> > runtime in order to produce *clojure-version* ? >>> >>> Here a patch that allows to initialize from ant and from a file >>> version.properties the values in *clojure-version*. >>> >>> The patch only addresses the problematic of having a single place for >>> version attributes. >>> Having the ant build also use these properties for creating correctly >>> numbered jars is not part of the patch. >>> >>> Note that I had to create a new file, src/clj/clojure/core_version.clj >>> , which is created by ant as a combination of template file >>> core_version-template.clj and the properties from version.properties. >>> >>> You'll see that if you don't like the names of the keys in >>> version.properties, build.xml is the single place where to change them >>> (apart from version.properties, of course). >>> Also, if you don't like the name version.properties (e.g. if it should >>> be named project.properties or whatever for easing maven users), then >>> you just have to change its occurence in build.xml too. >>> >>> If you like it, it can file an issue to google code and attach the patch, >>> >> >> Thanks! >> >> I can't say I love the idea of generating a file during build. > Me too, that's why I have made the file as short and independent as possible. > > Well, I tried to keep close to the idea of having the version numbers > "built-in", similarly to what was commited where it was also not read > from a "simpler file" at load time. > >> What about clojure.jar containing a properties file it reads at load time? > > Why not, indeed ? The file would have to placed in the classpath, e.g. > in directory src/jvm/clojure/lang or src/clj/clojure. > >> Could the same file be read by the various builds? > > For ant, yes. > > For maven2, it's more complex. > Indeed, I have read past the entire reference of the pom, searched > through the ml, and it seems that it's not possible at all to have > maven2 read properties file but its own which are not suitable for our > purpose. > > So I that even if we don't generate a clojure source file by reading > version.properties at load time from the classpath, it will be > difficult to avoid having to generate the maven2 pom.xml file from a > pom-template.xml ... > > Not that it would be difficult, it's just a matter of adding a > init-mvn task in the ant build.xml, and make all mvn related ant tasks > depend on it. > > Concerning what Howard suggested, having the maven2 pom.xml file be > the reference where the version information is placed, I can't say I > like this idea very much. > That's because maven2 pom.xml is not as structured as you have > structured the current version information (maven2 just has a single > "version" element where you place whatever you want, it's not > decomposed into major, minor, ... so it will be more difficult to do > the pattern matching :-). > And also, maven2 pom.xml is not the master build file, it's ant, so it > sounds weird to have ant go parse maven2.xml file to extract the > versioning information. > > My 0,02€, > > -- > Laurent > > > > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---