Git and build.properties

[Justin Mclean <ju...@classsoftware.com>]

Hi,

I asked this before but got no answer - anyone have an idea of how to deal with build.properties. In order to build the SDK you need to make changes to it (eg TLF path), however we don't want to always check in those changes but the file does needs to be in version control as you can't build without it.

This will stop any use of git pull --rebase with "Cannot pull with rebase: You have unstaged changes."

Thanks,
Justin

RE: Git and build.properties

[Gordon Smith <go...@adobe.com>]

+1 to Alex's comments. Having to create your own build.properties is a bad idea because, in addition to being an extra setup step, when the template for it changes you won't know and you won't pick up the intended changes.

A standard build.properties should exist and work if you use a standard setup. People using a nonstandard setup should override with local.properties.

- Gordon

-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com] 
Sent: Monday, April 15, 2013 11:04 PM
To: dev@flex.apache.org
Subject: Re: Git and build.properties

I just pulled and tried ant release and it immediately failed because there is no build.properties.  I liked the old way we had it which was:
1) a build.properties is in version control
2) anything you need to override in your system was changed in local.properties for which there was a local.template.properties

It had the advantage of not requiring a file to be copied to just run the default build configuration.

The build.xml still references local.properties.

What are the advantages of the build.template.properties way of doing things?  Can we go back to local.properties?  Won't it be easier to have a default build.properties that works on the CI server and the release kit builds instead and have all overrides in local.properties (and env.properties)?

Thanks,
-Alex

On 4/14/13 6:40 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
>>> The local changes can be made in this file.  The template remains 
>>> unchanged.
>>> 
>>> We can add a specific entry into gitignore for the build.properties file.
>> 
>> I'll give it a try and see if I can get it to work.
> 
> Looks like I got it working, checked in - as always feedback welcome.
> 
> Thanks,
> Justin

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Git and build.properties

[Alex Harui <ah...@adobe.com>]

On 4/16/13 4:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
>>> I'm as far as the docs build now.  Is there something I need to change to
>>> see the issue in the experimental swc?
> 
> An "ant doc' in framework/projects/experimental should show the first issue.
> 
OK, I am seeing an error where it can't find s:SolidColor and things like
that.  Looking into it...

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Git and build.properties

[Justin Mclean <ju...@classsoftware.com>]

Hi,

>> I'm as far as the docs build now.  Is there something I need to change to
>> see the issue in the experimental swc?

An "ant doc' in framework/projects/experimental should show the first issue.

Justin

Re: Git and build.properties

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I'm as far as the docs build now.  Is there something I need to change to
> see the issue in the experimental swc?

Not that I can recall.

Justin

Re: Git and build.properties

[Alex Harui <ah...@adobe.com>]

On 4/16/13 3:34 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> HI,
> 
>> The default location for TLF should be a flex-tlf directory that is a sibling
>> of the flex-sdk directory.
> The path as far as I know in build.properties needs to be a full path not a
> relative path, so thats going to be be different on different machine. Perhaps
> this can be fixed?
So far, my little ant hack that I checked in several weeks ago seems to be
working.  It checks relative directories and sets a variable/property and it
seems to be working.  I don't remember if ANT resolves those to absolute
paths or not, but it is good enough for building TLF.

I'm as far as the docs build now.  Is there something I need to change to
see the issue in the experimental swc?

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Git and build.properties

[Justin Mclean <ju...@classsoftware.com>]

HI,

> The default location for TLF should be a flex-tlf directory that is a sibling of the flex-sdk directory.
The path as far as I know in build.properties needs to be a full path not a relative path, so thats going to be be different on different machine. Perhaps this can be fixed?

Justin

RE: Git and build.properties

[Gordon Smith <go...@adobe.com>]

The default location for TLF should be a flex-tlf directory that is a sibling of the flex-sdk directory. You should not have to set TLF_HOME unless you rename your local repositories to have different names than they have remotely, or don't put them side-by-side in the same local directory.

- Gordon

-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com] 
Sent: Tuesday, April 16, 2013 11:03 AM
To: dev@flex.apache.org
Subject: Re: Git and build.properties




On 4/16/13 2:45 AM, "Kessler CTR Mark J" <ma...@usmc.mil> wrote:

> +1 to the TLF_HOME
I think I am going to go in the direction of a versioned build.properties, a local-template.properties and TLF_HOME.

> 
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Tuesday, April 16, 2013 2:42 AM
> To: dev@flex.apache.org
> Subject: Re: Git and build.properties
> 
> 
> 
> 
> On 4/15/13 11:33 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> 
>>>  I liked the old way
>> So did I but it didn't work with git in a nice way.
> TLF is the only reason?  Or did you run into other things?
>> 
>>> we had it which was:
>>> 1) a build.properties is in version control
>>> 2) anything you need to override in your system was changed in 
>>> local.properties for which there was a local.template.properties
>> 
>> Issue here is the TLF path - there's no reasonable default as it 
>> could be anything. You might be able to assume "../flex-tlf" but that 
>> is only going to be a match a a small % of cases.
>> 
> Why couldn't we use the "old way" and a TLF_HOME environment variable?

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

RE: Git and build.properties

[Kessler CTR Mark J <ma...@usmc.mil>]

My end state really would be to open up a new clone of the flex-sdk and just be able to build it (given I have the application dependencies).  So properties that survive growth/ future changes would what I vote for overall.


-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com] 
Sent: Tuesday, April 16, 2013 2:03 PM
To: dev@flex.apache.org
Subject: Re: Git and build.properties




On 4/16/13 2:45 AM, "Kessler CTR Mark J" <ma...@usmc.mil> wrote:

> +1 to the TLF_HOME
I think I am going to go in the direction of a versioned build.properties, a
local-template.properties and TLF_HOME.

Re: Git and build.properties

[Alex Harui <ah...@adobe.com>]

On 4/16/13 2:45 AM, "Kessler CTR Mark J" <ma...@usmc.mil> wrote:

> +1 to the TLF_HOME
I think I am going to go in the direction of a versioned build.properties, a
local-template.properties and TLF_HOME.

> 
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Tuesday, April 16, 2013 2:42 AM
> To: dev@flex.apache.org
> Subject: Re: Git and build.properties
> 
> 
> 
> 
> On 4/15/13 11:33 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> 
>>>  I liked the old way
>> So did I but it didn't work with git in a nice way.
> TLF is the only reason?  Or did you run into other things?
>> 
>>> we had it which was:
>>> 1) a build.properties is in version control
>>> 2) anything you need to override in your system was changed in
>>> local.properties for which there was a local.template.properties
>> 
>> Issue here is the TLF path - there's no reasonable default as it could be
>> anything. You might be able to assume "../flex-tlf" but that is only going to
>> be a match a a small % of cases.
>> 
> Why couldn't we use the "old way" and a TLF_HOME environment variable?

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

RE: Git and build.properties

[Kessler CTR Mark J <ma...@usmc.mil>]

+1 to the TLF_HOME 

-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com] 
Sent: Tuesday, April 16, 2013 2:42 AM
To: dev@flex.apache.org
Subject: Re: Git and build.properties




On 4/15/13 11:33 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>>  I liked the old way
> So did I but it didn't work with git in a nice way.
TLF is the only reason?  Or did you run into other things?
> 
>> we had it which was:
>> 1) a build.properties is in version control
>> 2) anything you need to override in your system was changed in
>> local.properties for which there was a local.template.properties
> 
> Issue here is the TLF path - there's no reasonable default as it could be
> anything. You might be able to assume "../flex-tlf" but that is only going to
> be a match a a small % of cases.
> 
Why couldn't we use the "old way" and a TLF_HOME environment variable?

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Git and build.properties

[Justin Mclean <ju...@classsoftware.com>]

Hi,

>> So did I but it didn't work with git in a nice way.
> TLF is the only reason?  Or did you run into other things?
It's the major one. I think most of the other values (version number, locale etc) a local.properties file works fine as they all have reasonable default values.

> Why couldn't we use the "old way" and a TLF_HOME environment variable?
It was specified in build.properties before but I guess that would work. Again it's extra work ie the variable must be set up if you want to build a clean checkout.

Thanks,
Justin

Re: Git and build.properties

[Alex Harui <ah...@adobe.com>]

On 4/15/13 11:33 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>>  I liked the old way
> So did I but it didn't work with git in a nice way.
TLF is the only reason?  Or did you run into other things?
> 
>> we had it which was:
>> 1) a build.properties is in version control
>> 2) anything you need to override in your system was changed in
>> local.properties for which there was a local.template.properties
> 
> Issue here is the TLF path - there's no reasonable default as it could be
> anything. You might be able to assume "../flex-tlf" but that is only going to
> be a match a a small % of cases.
> 
Why couldn't we use the "old way" and a TLF_HOME environment variable?

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Git and build.properties

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I just pulled and tried ant release and it immediately failed because there
> is no build.properties.
Yes as discussed on list we you need to copy the template file and edit. Once in place there no need to change it again and it wont be overwritten.

>  I liked the old way
So did I but it didn't work with git in a nice way.

> we had it which was:
> 1) a build.properties is in version control
> 2) anything you need to override in your system was changed in
> local.properties for which there was a local.template.properties

Issue here is the TLF path - there's no reasonable default as it could be anything. You might be able to assume "../flex-tlf" but that is only going to be a match a a small % of cases.

This means everyone must have a local.properties with the TLF path in it and you have exactly the same issue ie an initial check out it will fail to build because there's no local.properties file.

Justin

Re: Git and build.properties

[Alex Harui <ah...@adobe.com>]

I just pulled and tried ant release and it immediately failed because there
is no build.properties.  I liked the old way we had it which was:
1) a build.properties is in version control
2) anything you need to override in your system was changed in
local.properties for which there was a local.template.properties

It had the advantage of not requiring a file to be copied to just run the
default build configuration.

The build.xml still references local.properties.

What are the advantages of the build.template.properties way of doing
things?  Can we go back to local.properties?  Won't it be easier to have a
default build.properties that works on the CI server and the release kit
builds instead and have all overrides in local.properties (and
env.properties)?

Thanks,
-Alex

On 4/14/13 6:40 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
>>> The local changes can be made in this file.  The template
>>> remains unchanged.
>>> 
>>> We can add a specific entry into gitignore for the build.properties file.
>> 
>> I'll give it a try and see if I can get it to work.
> 
> Looks like I got it working, checked in - as always feedback welcome.
> 
> Thanks,
> Justin

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Git and build.properties

[Justin Mclean <ju...@classsoftware.com>]

Hi,

>> The local changes can be made in this file.  The template
>> remains unchanged.
>> 
>> We can add a specific entry into gitignore for the build.properties file.
> 
> I'll give it a try and see if I can get it to work.

Looks like I got it working, checked in - as always feedback welcome.

Thanks,
Justin

Re: Git and build.properties

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I suggested this a while ago.  We check in build.properties.template.  
That would break the CI build I believe (if it was currently working).

> The developer (or the build script) copies the contents into build.properties
> while building.
I think build.properties is read before the script runs so not sure if that that would work? Not 100% sure there.

And of course we wouldn't want it to over write the file each time - as you would loose your changes.

>  The local changes can be made in this file.  The template
> remains unchanged.
> 
> We can add a specific entry into gitignore for the build.properties file.

I'll give it a try and see if I can get it to work.

Justin

Re: Git and build.properties

[Justin Mclean <ju...@classsoftware.com>]

Hi,

>  build.properties is need for paths to various bits required in building the SDK.

And java settings and the like.

Justin

Re: Git and build.properties

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Could we just have the build version in the command line or accessed like a
> system variable?

I've fixed the build version issue by changing it to be the date in YYYYMMDD format, build.properties is need for paths to various bits required in building the SDK.

Thanks,
Justin

Re: Git and build.properties

[Mark Kessler <ke...@gmail.com>]

Could we just have the build version in the command line or accessed like a
system variable?


On Sun, Apr 14, 2013 at 8:28 PM, OmPrakash Muppirala
<bi...@gmail.com>wrote:

> I suggested this a while ago.  We check in build.properties.template.  The
> developer (or the build script) copies the contents into build.properties
> while building.  The local changes can be made in this file.  The template
> remains unchanged.
>

Re: Git and build.properties

[OmPrakash Muppirala <bi...@gmail.com>]

I suggested this a while ago.  We check in build.properties.template.  The
developer (or the build script) copies the contents into build.properties
while building.  The local changes can be made in this file.  The template
remains unchanged.

We can add a specific entry into gitignore for the build.properties file.

Thanks,
Om
On Apr 14, 2013 5:12 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> HI,
>
> This also breaks the usefulness of "git stash" in that you have to reapply
> the changes made to build.properties. Is there as easy way to tell git
> stash to ignore a file or only stash a set of files?
>
> Justin

Re: Git and build.properties

[Justin Mclean <ju...@classsoftware.com>]

HI,

This also breaks the usefulness of "git stash" in that you have to reapply the changes made to build.properties. Is there as easy way to tell git stash to ignore a file or only stash a set of files?

Justin

Re: Git and build.properties

[Alex Harui <ah...@adobe.com>]

All of our ant scripts should load a local.properties that override the
build.properties.  Build.properties should have some sensible values and
should not be changed very often.

Local.properties should have a template and the template should be checked
in, and local.properties should be in .gitignore.

Is that pattern not working for some reason?


On 4/14/13 5:01 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
> I asked this before but got no answer - anyone have an idea of how to deal
> with build.properties. In order to build the SDK you need to make changes to
> it (eg TLF path), however we don't want to always check in those changes but
> the file does needs to be in version control as you can't build without it.
> 
> This will stop any use of git pull --rebase with "Cannot pull with rebase: You
> have unstaged changes."
> 
> Thanks,
> Justin

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui