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
-~----------~----~----~----~------~----~------~--~---

Reply via email to