On Apr 27, 5:01 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> New patch with corrections posted to google code,
>
That patch has been applied. I recommend everyone who is able to
please try out the latest version from SVN - this will become a
release candidate. The patch generates jar files with version numbers
in the names. It was suggested on IRC that perhaps it should also copy
the jar to their traditional (non-versioned) names, for greater
compatibility. Maven users please make sure that side of the build
works for you.
Feedback welcome,
Rich
> 2009/4/27 Laurent PETIT <laurent.pe...@gmail.com>:
>
> > I've created issue 110 with the patch attached in clojure's google code
> > project.
>
> > Hi Rich, Howard,
>
> > I'll answer to both at the same time, trying to reconcile things a bit.
>
> > Howard, my first patch was already along the lines of what you
> > described below, I think (concerning the fact to use ant to generate
> > with filters from templates).
>
> > Then Rich asked if it was possible to not have to generate files. I
> > understand this question a little less broadly than "not generate
> > files at all cost", but "not generate files in the source code". So
> > that if the generation step is not followed by some tool for some
> > reason, things don't break - at compile time or run time -.
>
> > That's why I came up with this new version:
>
> > * a src/clj/clojure/version.properties file
> > * this version.properties file is the reference for version numbers.
> > It is on the classpath so it can be seen by clojure at runtime. It is
> > in a subdirectory of clojure-the-project so any tool can refer to it
> > relatively to the installation of clojure.
>
> > * I've added the needed code to clojure to load clojure version
> > number at startup time
>
> > I've also added function (clojure.core/clojure-version) that will
> > return a string representing the version from the structured
> > *clojure-version* map. The algorithm here is simple:
> > <MAJOR>.<MINOR>[.<INCREMENT>][-<QUALIFIER>][-SNAPSHOT]
>
> > * I've changed the ant build.xml so that it creates fully qualified
> > names with version attributes for the generated jars.
> > * Note on the :interim attribute: to protect the person who makes
> > releases from itself, instead of considering :interim to be true if
> > there is the "true" string in the properties file, I've made the
> > opposite choice: interim is true for any value other than "false". So
> > if there is a typo in version.properties (e.g. tru instead of true),
> > then the release will be marked as interim, and that will not be a big
> > deal. In the other case, it would be a big deal if an official release
> > was made accidentally instead of an interim.
>
> > * finally, pom.xml file is now generated from ant as part of the
> > classic init step.
>
> > Note: I strongly suggest that the clojure.version.interim property
> > remains true in svn, so that it's not possible to inadvertently
> > release a version "too early".
>
> > HTH,
>
> > Feel free to use or not,
>
> > --
> > Laurent
>
> > 2009/4/24 Howard Lewis Ship <hls...@gmail.com>:
>
> >> 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
-~----------~----~----~----~------~----~------~--~---
