Mailing-List: contact users-help@taverna.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@taverna.incubator.apache.org
Message-ID: <558290FB.7040101@manchester.ac.uk>
Date: Thu, 18 Jun 2015 10:35:55 +0100
From: "Donal K. Fellows" <donal.k.fellows@manchester.ac.uk>
Organization: University of Manchester
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: users@taverna.incubator.apache.org
Subject: Re: Deployment of nested components on taverna server
References: 
 <CAA8bF+V2dRj5kjqV=AD8wOSJXLiZQuqNc6RHus5ZcTPLCNRh8Q@mail.gmail.com>
In-Reply-To: 
 <CAA8bF+V2dRj5kjqV=AD8wOSJXLiZQuqNc6RHus5ZcTPLCNRh8Q@mail.gmail.com>
Content-Type: multipart/mixed;
 boundary="------------030506010600090601080108"

This is a multi-part message in MIME format.
--------------030506010600090601080108
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 17/06/2015 10:44, Daniele Tartarini wrote:
> I developed a series of taverna components most of them nested.
> I would like to deploy them on a taverna server instance on a different
> machine.
>
> How can this be done in reliable way?

Since you're talking about local components, you have two basic options
right now.

Option 1: Upload the components to myExperiment (strictly anything that
talks the API, but myE is the only service I know of that actually does
that). You do not need to make the components public, but you'll need to
set a workflow run to have appropriate username/password pair for
myExperiment to access them if you use non-public components. (That's
actually obviously necessary, once you think about it.) If you're making
the components public, this is actually very convenient indeed.

Option 2: Put the components on the server somewhere and edit the
workflows to know about that server-local location. This is what I did
with components in the SCAPE project, and it actually works really well
(I was merging the components into the customised server build that we
were using, but I also had a really complicated workflow rewriter that
made that sort of thing really easy). The downside is that the workflow
that you run on the server is not the workflow that you run on your desktop.

NOT AN OPTION: Just uploading the workflow and hoping that it will all
magically work. We don't have that sort of magic. :-D The server has a
different filesystem to your client; the local component registry
address doesn't map to anywhere else.

Donal.

--------------030506010600090601080108
Content-Type: text/x-vcard; charset=utf-8;
 name="donal_k_fellows.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="donal_k_fellows.vcf"

begin:vcard
fn:Donal K. Fellows
n:Fellows;Donal
org:The University of Manchester;School of Computer Science
adr:;;Oxford Road;Manchester;;M13 9PL;United Kingdom
email;internet:donal.k.fellows@manchester.ac.uk
version:2.1
end:vcard


--------------030506010600090601080108--