RE: Anthill Scripts Have DOS File Format?

Thanks Erik,

I unpacked it using gunzip and tar, and that seems to have fixed the
problem!

Cheers,

Andrew

-----Original Message-----
From: Erik Husby [mailto:mhusby@...]
Sent: Wednesday, 1 December 2004 1:32 AM
To: andrews@...; Anthill user list
Subject: Re: [Anthill] Anthill Scripts Have DOS File Format?

You did not say how you unpacked the Anthill distribution. I've had
problems similar to this if I used a Windows utility such as WinZip to
unpack the distribution to a Unix filesystem. I've not had any problems
with the Anthill scripts on my Unix and Linux systems if I unpacked
using Unix utilities.

--
Erik Husby
Team Lead for Software Quality Automation
Broad Institute of MIT and Harvard
Rm. 2192  320 Charles St
Cambridge, MA 02141-2023
mobile: 781.354.6669, office: 617.258.9227, mhusby@...

Anthill OS multiple VSS repositories

Hi,
   Is it possible to use anthill to build projects in multiple VSS 
repositories? Since SSDIR needs to be set and it can point to only one VSS 
repository, does anyone know of a way to work around this so that builds for 
projects in multiple repositories can run from the same anthill?

Thanks in advance.

_________________________________________________________________
Choose what you want to read. Protect your mail from spam. 
http://server1.msn.co.in/sp04/hotmailspamcontrol/  Win the war in 9 steps!

RE: Anthill Digest, Vol 10, Issue 20

Eric,
I Was wondering about issue anthillos-217. Presumably this fix will be
for 1.8. Is there an ETA on 1.8? Is there any way to get a maintenance
release with this issue resolved before 1.8?   

Thanks,
DJR
-----Original Message-----
From: anthill-request@...
[mailto:anthill-request@...] 
Sent: Friday, November 19, 2004 12:56 PM
To: anthill@...
Subject: Anthill Digest, Vol 10, Issue 20

Send Anthill mailing list submissions to
	anthill@...

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.urbancode.com/mailman/listinfo/anthill
or, via email, send a message with subject or body 'help' to
	anthill-request@...

You can reach the person managing the list at
	anthill-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Anthill digest..."

Today's Topics:

build error=193 Anthill

_______________________________________________
Anthill mailing list
Anthill@...
http://lists.urbancode.com/mailman/listinfo/anthill

Re: build error=193 Anthill

_______________________________________________
Anthill mailing list
Anthill@...
http://lists.urbancode.com/mailman/listinfo/anthill

Question on keeping build.properties when building

Hi,
I just started up with Anthill OS 1.7.1 after trying out CruiseControl (gack!).

My question is: How can I make sure that files in the work dir (files not in CVS, like build.properties) are
not deleted every build? Is there a possibility to add an exclude pattern or something? I am in a Windoze environment.

I tried setting a write protection on the files, but alas! no success.

Of course I could do a workaround by copying the files from somewhere in a pre-script to the real one, but it's
kind of ugly IMHO.

Thanks in advance,
Magnus

_________________________________
Magnus Mickelsson
H & M Hennes & Mauritz AB
Direct phone: +46 8 796 14 93
Cell phone: +46 704 922182
mailto:magnus.mickelsson@...

Re: Question on keeping build.properties when building

Hi Magnus,

I think a work around like the one you're describing would be the way to 
do it for now. There really isn't anything that preserves the working 
directory (or some part of it) in the current release.

Regards,

Eric

Magnus.Mickelsson@... wrote:

>Hi,
>I just started up with Anthill OS 1.7.1 after trying out CruiseControl (gack!).
>
>My question is: How can I make sure that files in the work dir (files not in CVS, like build.properties) are
not deleted every build? Is there a possibility to add an exclude pattern or something? I am in a Windoze environment.
>
>I tried setting a write protection on the files, but alas! no success.
>
>Of course I could do a workaround by copying the files from somewhere in a pre-script to the real one, but
it's kind of ugly IMHO.
>
>Thanks in advance,
>Magnus
>
>_________________________________
>Magnus Mickelsson
>H & M Hennes & Mauritz AB
>Direct phone: +46 8 796 14 93
>Cell phone: +46 704 922182
>mailto:magnus.mickelsson@...
>
>_______________________________________________
>Anthill mailing list
>Anthill@...
>http://lists.urbancode.com/mailman/listinfo/anthill
>
>
>  
>

Re: Question on keeping build.properties when building

My workaround is to check the build.properties files for all of my
environments into source control, appending the environment to the end
of the filename:

build.properties.integration
build.properties.development

from anthill I specify which file to use in the switches to ant

-propertyfile build.properties.integration.

Seems a little cleaner to me, your mileage may vary.

Ed.

On Mon, 2004-12-06 at 10:24, Eric Minick wrote:
> Hi Magnus,
> 
> I think a work around like the one you're describing would be the way to 
> do it for now. There really isn't anything that preserves the working 
> directory (or some part of it) in the current release.
> 
> Regards,
> 
> Eric
> 
> Magnus.Mickelsson@... wrote:
> 
> >Hi,
> >I just started up with Anthill OS 1.7.1 after trying out CruiseControl (gack!).
> >
> >My question is: How can I make sure that files in the work dir (files not in CVS, like build.properties) are
not deleted every build? Is there a possibility to add an exclude pattern or something? I am in a Windoze environment.
> >
> >I tried setting a write protection on the files, but alas! no success.
> >
> >Of course I could do a workaround by copying the files from somewhere in a pre-script to the real one, but
it's kind of ugly IMHO.
> >
> >Thanks in advance,
> >Magnus
> >
> >_________________________________
> >Magnus Mickelsson
> >H & M Hennes & Mauritz AB
> >Direct phone: +46 8 796 14 93
> >Cell phone: +46 704 922182
> >mailto:magnus.mickelsson@...
> >
> >_______________________________________________
> >Anthill mailing list
> >Anthill@...
> >http://lists.urbancode.com/mailman/listinfo/anthill
> >
> >
> >  
> >
> 
> _______________________________________________
> Anthill mailing list
> Anthill@...
> http://lists.urbancode.com/mailman/listinfo/anthill
--

-- 
Edward Zarecor <edward_zarecor@...>
Harvard University

Robert E Dobbins/Alpharetta/IBM is out of the office.

_______________________________________________
Anthill mailing list
Anthill@...
http://lists.urbancode.com/mailman/listinfo/anthill

RE: Question on keeping build.properties when building

> My workaround is to check the build.properties files for all of my
> environments into source control, appending the environment to the end
> of the filename:
> build.properties.integration
> build.properties.development

I make it a point to not have build.properties in CVS... only
"default.properties" which are global and not developer-specific.

build.properties, in my case, contains developer-specific settings, for ex.
"db.password=timo_foo" so I don't want developers overwriting each others
settings in CVS.

So I had the same problem as Magnus - however, I solved it differently. I
realize this is the Anthill OS list, so not sure if this will work without
Anhill "Pro"...

1) make the project buildable, from clean checkout, with only
default.properties 
2) add non-cvs settings using Anthill Pro 

In the build track editor, I specify "Property File Property Name" =
"integration_props" and then list the properties in the "Property File"
block.
"db.password=real_pass"

In the build.xml file, I add these lines:

<!-- these props will come from AnthillPro -->
<property file="${integration_props}"/>
<!-- these props will be developer specific overrides -->
<property file="${build.dir}/build.properties"/>
<!-- these will be global defaults stored in CVS for all developers -->
<property file="${build.dir}/default.properties"/>

When AHP builds, the integration props override the defaults. Et voila! 

Cheers,
Timo
P.S. for environment specific (i.e. Integration/QA/Production) settings, I
have a custom Java component hooked in via Spring that pulls in the correct
setting, but that's a bit beyond the scope of this particular question.