[Anthill-pro] Using Stamp Templates in 3.4

Wed Dec 19 12:57:40 CST 2007

I have a project property called my-stamp-prop with value 1.1.1.1, Pass
to Builders YES, Set in Environment YES.

I also have a workflow property called inputversion (can be changed by
the user, not required)

Stamp strategy: DEV. value: ${+property:my-stamp-prop}, Context script:
"User Input Version"

Stamp Context script called "User Input Version" (used in my project):

String input = PropertyLookup.getValue("inputversion");

if (input != null && input.length() > 0) {

ProjectLookup.getCurrent().getProperty("my-stamp-prop").setValue(input);

}

Scenario 1:

I'm running a build without entering a manual version (leaving
inputversion empty). Result: build stamped 1.1.1.2, my-stamp-prop value
= 1.1.1.2

Scenario 2 (done after Scen. 1):

I'm running a build and I enter 1.3.0.0 in as inputversion. Result:
build stamped 1.1.1.3, my-stamp-prop value = 1.3.0.0

Scenario 3 (done after Scen. 2):

I'm running a build without entering a manual version (leaving
inputversion empty). Result: build stamped 1.3.0.1, my-stamp-prop value
= 1.3.0.1

Scenario 2 is the problematic one, it first stamps the build then
changes my-stamp-prop value instead vice versa.

Hope this helps,

NirS

________________________________

From: Steve Boone [mailto:sbb at urbancode.com] 
Sent: Wednesday, December 19, 2007 8:26 PM
To: Silgi, Nir
Cc: AnthillPro user and support list.
Subject: Re: [Anthill-pro] Using Stamp Templates in 3.4

Nir,

Can you provide an example of the property values.

What are they before you the build...  and can you provide examples of
the output when you increment, and when you dont increment. 

We are trying to narrow down where this error might be occuring. 

Regards,
Steve 

On 12/19/07, Silgi, Nir <nsilgi at shopping.com> wrote:

Hey,

Any news/solutions for this problem?

Thanks,

NirS

________________________________

From: Silgi, Nir 
Sent: Monday, December 17, 2007 6:09 PM
To: 'Steve Boone'; AnthillPro user and support list.
Subject: RE: [Anthill-pro] Using Stamp Templates in 3.4

String input = PropertyLookup.getValue("inputversion");

if (input != null && input.length() > 0) {

ProjectLookup.getCurrent().getProperty("my-stamp-prop").setValue(input);

}

Basically it's the exact script you sent me (a few mails below).

NirS

________________________________

From: Steve Boone [mailto:sbb at urbancode.com] 
Sent: Monday, December 17, 2007 5:59 PM
To: AnthillPro user and support list.
Cc: Silgi, Nir

Subject: Re: [Anthill-pro] Using Stamp Templates in 3.4

Nir,

Can I see the exact scrip that you are using for your context script? 

It sounds like we are not returning the stamp from the script, and
perhaps its not grabbing the actual value we are looking for.  

Regards,
Steve

On 12/13/07, Silgi, Nir <nsilgi at shopping.com> wrote:

I experience a weird behavior. This is the problematic flow:

When I use ${+property:my-stamp-prop}:

1.	The stamp context script updates my-stamp-prop with my manual
version.
2.	The old my-stamp-prop is incremented and used in the build.
my-stamp-prop is updated but not used.
3.	In the next run, the updated my-stamp-prop is used (if I don't
manually specify a version)

When I use ${property:my-stamp-prop}:

1.	The stamp context script updates my-stamp-prop.
2.	the updated my-stamp-prop is used (as it should be) 
3.	In the next build (if I don't specify a version manually) the
same my-stamp-prop is used (understandable because I don't increment it)

It seems that when I use +, it mixes up the updater somehow.

NirS

________________________________

From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Steve
Boone
Sent: Wednesday, December 12, 2007 8:46 PM
To: AnthillPro user and support list.
Subject: Re: [Anthill-pro] Using Stamp Templates in 3.4

Nir,

assuming your stamp version is going to be a project-property, and that
you don't want to abstract out the different portions of it into
separate properties (e.g. one property for build count, one for major
version etc), this sript should work. 

String input = PropertyLookup.getValue("input-prop");
if (input != null && input.length() > 0) {

ProjectLookup.getCurrent().getProperty("my-stamp-prop").setValue(input);

}

You would also have to have your stamp set up to be 

${+property:my-stamp-prop}

I believe this will give you the same functionality as your old script. 

Regards,
Steve Boone

On 12/12/07, Silgi, Nir <nsilgi at shopping.com> wrote:

I'm trying to understand the new custom stamp system in 3.4. I created a
Stamp Context Script called User Input Stamp and I'm trying to use it in
a workflow.

I took my user input stamp from 3.3 and put it as a Stamp Context Script
in 3.4, the script is below, I only changed the last line (I don't know
why are some words with strikeout)
Then in the Workflow definition I put ${stampContext:scriptedversion}.

When I run the workflow I get the error:

Caused by: org.apache.bsf.BSFException: BeanShell script error: Sourced
file: inline evaluation of: ``import 

com.urbancode.anthill3.runtime.scripting.helpers.*;import
com.urbancode.a . . . '' : Typed variable declaration : Void
initializer. : at Line: 4 : in file: inline evaluation of: ``import 
com.urbancode.anthill3.runtime.scripting.helpers.*

;import com.urbancode.a . . . '' : current = input 

 BSF info: noFile at line: 0 column: columnNo

        at
com.urbancode.bsh.BeanShellBSFEngine.eval(BeanShellBSFEngine.java:216)

        at org.apache.bsf.BSFManager$5.run
(BSFManager.java:445)

        at java.security.AccessController.doPrivileged(Native Method)

        at 
org.apache.bsf.BSFManager.eval(BSFManager.java:442)
        at
com.urbancode.anthill3.runtime.scripting.ScriptEvaluator.doEvaluate
(ScriptEvaluator.java:206)
        ... 11 more

2007-12-12 19:35:58,298 INFO  16920 - Job 16920 released working
directory /home/build/p4ws/mercury on agent IL Linux Test Agent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.urbancode.com/pipermail/anthill-pro/attachments/20071219/09a7070d/attachment-0001.htm