Re: [sdd] Alternate definition of artifact

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

Julia McCarthy wrote:
> An example of deployed bits that are calculated rather than copied is a 
> .ini file that is modified slightly based on user input before being 
> created in the file system.

Depending on the implementation, the unadulterated .ini file could be part
of the payload, or just an artifact.

Some implementations deliver the unadulterated .ini file into a "templates"
directory as a deliverable object on the target hosting environment.
Then, the installer (or the user) makes a copy of the file,
edits it, and places it in the "live configuration" area.  In this case,
the unadulterated .ini file is part of the payload.  The inputs used to
create the diffs are artifacts.

Other implementations simply read in the unadulterated ini settings from
some location within the solution package, make in-memory edits, and
spit out the result in to the "live configuration" area.  The default
settings are never extracted or recorded on disk, they simply are in the
solution package as a private "template" for use by the install or config
application.  In this case, there is no unadulterated file that exists
outside the solution package.  The adulterated ini file ultimately copied
into the "live configuration area" I would consider an artifact or a
configuration file, but I would not consider it part of the payload.

> I agree with your A -> B example. What is copied from the solution 
> package to a hosting environment is artifacts. These are temporary. They 
> are used to create the deployed solution content, which is long-lived.

So then would a potential set of definitions be:

Payload:

Binary packaged content intended to be delivered through a solution
deployment.

Artifact:

Zero or more temporary files or metadata used to perform a lifecycle
operation on a resource, but not specifically tied to the objective of
the operation.

?

-jhf-

> Julia McCarthy
> Tivoli Development
> Deployment Engine Design
> julia@us.ibm.com
> 349/8156
> 877-261-0391
> 
> 
> 
> Inactive hide details for James Falkner <james.falkner@sun.com>James 
> Falkner <james.falkner@sun.com>
> 
> 
>                         *James Falkner <james.falkner@sun.com>*
> 
>                         04/20/2006 01:31 PM
> 
> 	
> 
> To
> 	
> 
> cc
> 	
> sdd@lists.oasis-open.org
> 
> Subject
> 	
> Re: [sdd] Alternate definition of artifact
> 
> 	
> 
> 
> 
> 
> Julia McCarthy wrote:
>  > It sounds like you two (Debra and James) define payload as the bits in
>  > the package that end up copied as the deployed resources. That is what I
>  > was calling the package content that is closely similar to the deployed
>  > resources. (A copied bit is not the same bit.) Not all deployed
>  > resources are copied from bits in the solution package. Some deployed
>  > bits are calculated during deployement. Would you consider the inputs to
>  > those calculations to be payload?
> 
> Can you give a concrete example here?  I think that the inputs used to
> calculate or create dynamic deployed bits are really configuration
> parameters, and not part of the payload itself.  The only things that
> I consider payloads are things that exist in the solution package that
> are copied to the hosting environment and are not modified by the install
> or deployment runtime.  Anything that exists in the solution
> package that is modified or changed before being copied,
> based on configuration or other inputs, I would consider an artifact.
> 
> 
>  > I believe that the bits that end up copied to the deployed solution are
>  > part of the artifact as well as bits that are used to calculate contents
>  > or provide other instructions for deploying content.
> 
> OK, I think I may see your point.   A solution package exists on machine A.
> The end user wants to deploy it to machine B.  So, something is first copied
> from A to B.  This is the artifact (for example, an FTP transfer of
> setup.exe).  Then the actual copying from the artifact
> blob to their final destination on machine B occurs.  I'm fine with calling
> that intermediate blob an "artifact".  It is short-lived (i.e. the artifact
> is deleted from machine B's temporary directory once the payload bits are
> copied out of it and into their final resting place, and all other dynamic
> content based on things in the blob are created, such as config files).
> Is that right?
> 
>  > I still don't see
>  > the value in distinguishing between bits that are directly copied vs.
>  > bits that are used to calculate or provide instructions.
> 
> Well, now I might disagree.  Bits that are directly copied are the payload.
> Bits used to calculate dynamic values to me sound like configuration values
> (aka artifacts) which are used to lay down dynamic data
> (in config files, or whatever).
> 
>  > Even if there
>  > is value in distinguishing (I imagine I'm alone in not seeing the
>  > value), I think that both concepts are part of artifact. i.e. What you
>  > call payload can be an artifact... or payload plus metadata... or
>  > payload alone.
> 
> Will wait for your reply on my above A vs. B example before responding.
> 
> -jhf-
>