New patch with corrections posted to google code,
regards,
--
laurent
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
-~----------~----~----~----~------~----~------~--~---
