Re: [sdd] Alternate definition of artifact

[Julia McCarthy <julia@us.ibm.com>]

I think payload files are part of artifacts. (Using your definition of payload.) Artifacts can be payload files or metadata or metadata plus payload files. An artifact is everything that needs to be given to the hosting environment in order to perform a lifecycle operation on a resource.

How about these modifications to your proposed definitions:

Payload:

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

I still don't see the value of distinguishing between content that is delivered without change and content that is changed or used to compute delivered content. Can you give me an example of the value provided by distinguishing between what you call payload content and the other content of the solution package - such as the .ini file that will be modified or the DDL script?

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.

Temporary would be ok with me in this definition, except it seems to be used here to indicate these are not payload files. I believe that all payload files would be part of some artifact or other, since being part of an artifact is the only way they become available to a hosting environment to perform a lifecycle operation.

I actually think we could do without two concepts. We just need the concept of "everything provided by the solution package to the hosting environment to allow a lifecycle operation to be performed". That's what I call an artifact. I don't care whether those things are copied exactly, modified slightly or instructions that are completely thrown away. What I care about is what the hosting environment needs to perform the operation.


Julia McCarthy
Tivoli Development
Deployment Engine Design
julia@us.ibm.com
349/8156
877-261-0391



James Falkner <james.falkner@sun.com>

James Falkner <james.falkner@sun.com>

04/25/2006 03:46 PM

To	Julia McCarthy/Raleigh/IBM@IBMUS
cc	sdd@lists.oasis-open.org
Subject	Re: [sdd] Alternate definition of artifact

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-
>