version.properties

[hdockter]

I think the place where we store the version.properties is not the  
place where it should live. Right now it lives in gradle-core. But in  
fact the version is the version of the distribution not of the  
library. That means that we would need to check for the changed input  
properties of all our archives to see whether we need a new version  
file. That would be possible. But I think a simpler approach would  
work as well. I think we should get rid of the version.properties file  
all together. Instead the GradleVersion class could read the version  
from one of the gradle libraries in GRADLE_HOME/lib. We would have to  
give up of the buildTime attribute in gradle -v. But I don't think  
this attribute is relevant. Either you have a released version or you  
have a version with a timestamp. The latter gives you all the  
information you need for a snapshot.

In a snapshot build we would then always use a new timestamped version  
(as we do now). But it would only affect the naming of the archives  
not the content. With Adam's planned optimization for output file  
changes only (which in the case of an archive just renames the  
archive), our build could then make full use of the incremental build  
optimization. In fact the output file changes optimization is  
necessary to make all that work. Otherwise our (unchanged) archives  
are not in sync with the current timestamped version.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[John Murph]

That seems reasonable to me.  The version.properties file seems redundant, so let's do away with it.  From which jar would you read the version (gradle-core)?  Also, I suggest you get it from the IMPLEMENTATION VERSION section of the manifest and not by parsing the jar file name.


--
John Murph
Automated Logic Research Team

[hdockter]

Hi John,

On Oct 26, 2009, at 5:35 PM, John Murph wrote:

> That seems reasonable to me.  The version.properties file seems  
> redundant, so let's do away with it.  From which jar would you read  
> the version (gradle-core)?

I think so.

>   Also, I suggest you get it from the IMPLEMENTATION VERSION section  
> of the manifest and not by parsing the jar file name.

Because you think this is more reliable?

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[John Murph]

Hans,

 Also, I suggest you get it from the IMPLEMENTATION VERSION section of the manifest and not by parsing the jar file name.

Because you think this is more reliable?

I think it is better form that parsing the file name, because of the reliability issue.  It also happens to enforce that the version information is put in the jars manifest, which is nice.  But mostly, because that's how IDEA determines the version of Gradle and consistency is good.


--
John Murph
Automated Logic Research Team

[Russel Winder-4]

On Tue, 2009-10-27 at 11:08 -0400, John Murph wrote:
> Hans,

>                  Also, I suggest you get it from the IMPLEMENTATION
>                 VERSION section of the manifest and not by parsing the
>                 jar file name.
>        
>         Because you think this is more reliable?


> I think it is better form that parsing the file name, because of the
> reliability issue.  It also happens to enforce that the version
> information is put in the jars manifest, which is nice.  But mostly,
> because that's how IDEA determines the version of Gradle and
> consistency is good.

Gant originally parsed the jar name to get the version number but this
proved seriously unreliable in situations such as Debian and Ubuntu
where the version number is removed for packaging.

Also perverse people might just change the version number embedded in
the file name just for the hell of it.

So I switched to ensuring the version was put into the jar metadata, aka
manifest, and getting it from there.  Much more reliable.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder