Re: [sdd] Alternate definition of artifact

[James Falkner <james.falkner@sun.com>]

I am in agreement with Julia.  We need a definition of payload if we
are going to use it in the context of another definition.

In my opinion, end users who are deploying solutions
don't care how it works -- they care that the appropriate bits are
put in place and the appropriate services are started.  I consider the
"appropriate bits" as the payload.  Everything else (the SDD, the RPM
metadata, etc) is just ancillary to the ultimate goal of getting the
bits laid down and services started.

In other words, when I hear "payload" I think of that as the
"appropriate bits" that the end user is interested in deploying,
not the support metadata and "helper applications" that help (aid)
in getting the payload in place.  payload == the load that pays.

When I hear "artifact" I think of all the ancillary, helper bits that
aid in getting the payload deployed, but aren't of interest to the
end user doing the deployment, and don't typically live on to see the
light of day after deployment operation is complete.

So, I am uncomfortable with including "payload" as part of the
artifact definition.  I think of artifact as anything that
is not the "payload".  Artifacts are short-lived, helper stuff (SDD XML,
deployer tools, XSLTs used at deploy time, etc) used to get
the bits in place (or "perform a lifecycle operation on a resource").

-jhf-

Christine Draper wrote:
> How about:
> 
> *Artifact:* zero or more files representing the payload (e.g. binary 
> content, instructions, definitions, scripts) necessary to perform a 
> lifecycle operation on a resource.
> 
> Regards,
> Christine
> 
> 
> Senior Technical Staff Member
> IBM, 11501 Burnet Road, Mail Point 901-6B10
> Austin, TX 78758
> 1-512-838-3482 tl 678-3482
> Inactive hide details for Julia McCarthy/Raleigh/IBM@IBMUSJulia 
> McCarthy/Raleigh/IBM@IBMUS
> 
> 
>                         *Julia McCarthy/Raleigh/IBM@IBMUS*
> 
>                         04/19/2006 06:44 PM
> 
> 	
> 
> To
> 	
> 
> cc
> 	
> sdd@lists.oasis-open.org
> 
> Subject
> 	
> Re: [sdd] Alternate definition of artifact
> 
> 	
> 
> 
> This proposal depends on the definition of payload. You seem to be 
> defining it as only the solution content that is so closely similar to 
> the resulting solution resources that people think of it as the same thing.
> 
> Note that even when the package content is closely similar to the 
> deployed resource, it is never the same thing. A file in a package is 
> not the same thing as a file created in a filesystem. To my thinking, 
> all of the content of a solution package is instructions for creating 
> the solution. The instructions might happen to be a list of the exact 
> bits that will be created on the file system - for example, a readme 
> file that gets created in a particular location by copying the set of 
> bits included in the solution package. I don't yet see any value in 
> distinguishing between instructions that are closely similar to the 
> resulting resource and instructions that are clearly different from the 
> resulting resource. And since I don't see value in that distinction, I 
> am not inclined to define payload as only the solution content that is 
> closely similar to the resulting solution resources. Which means I am 
> not inclined to agree with your proposal.
> 
> Julia McCarthy
> Tivoli Development
> Deployment Engine Design
> julia@us.ibm.com
> 349/8156
> 877-261-0391
> 
> 
> 
> Inactive hide details for "Josh Allen" <jallen@macrovision.com>"Josh 
> Allen" <jallen@macrovision.com>
> 
>                                                 *"Josh Allen"
>                                                 <jallen@macrovision.com>*
> 
>                                                 04/19/2006 07:23 PM
> 
> 	
> To
> 	
> <sdd@lists.oasis-open.org>
> cc
> 	
> Subject
> 	
> [sdd] Alternate definition of artifact
> 
> 	
> 
> 
> Hi all,
> 
> On the call today I suggested an alternative definition of the term 
> *artifact* that might help us feel more comfortable with this term. At 
> request I've included it here for review:
> *
> Artifact:* zero or more files representing a payload and if necessary a 
> set of instructions about how to use that payload to perform a lifecycle 
> operation on a resource.
> 
> Thanks,
> Josh
>