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