lburgazzoli
commented
6 years ago Should the developer able to upload extensions straight from the RH DevStudio so by-pass the citizen integrator or everything should be done via Syndesis UI ?
Closed kcbabo closed 6 years ago
lburgazzoli
commented
6 years ago Should the developer able to upload extensions straight from the RH DevStudio so by-pass the citizen integrator or everything should be done via Syndesis UI ?
kcbabo
commented
6 years ago Great question. Our assumption has always been that the personas are layered in such a way that anyone more technical can necessarily perform a task that someone less technical can perform. So I create user stories from the perspective of the least technical persona capable of performing them.
Developers can definitely upload the technical extensions on their own. In fact, it may turn out to be more common for developers to go ahead and upload the technical extension. We should not restrict which type of persona can perform this operation. I don't think we've discussed doing this directly from the IDE as there are auth issues, etc. that need to be addressed. Probably best to just focus on the web-based UI for upload.
lburgazzoli
commented
6 years ago ok so for this first iteration only web based upload is supported, should we open an issue to investigate RH DevStudio authentication ?
apupier
commented
6 years ago Should the developer able to upload extensions straight from the RH DevStudio so by-pass the citizen integrator or everything should be done via Syndesis UI ?
If everything needs to go through the Syndesis UI, it looks alike a very long roundtrip to test a new extensions:
It might be fine as a first iteration but if steps 2, 3 and 4 can be fully automated, it will save a lot of time to Dev (but yes there will be Auth implementation to do and Syndesis will need to provide an API)
apupier
commented
6 years ago ok so for this first iteration only web based upload is supported, should we open an issue to investigate RH DevStudio authentication ?
Lars created this "Feature request" for the deployment part: https://issues.jboss.org/browse/FUSETOOLS-2630 I think we can reuse it to specify what we need on Fuse Tooling side.
kcbabo
commented
6 years ago Just to be clear, I absolutely agree with Aurelien that support within the IDE would be valuable from a workflow perspective. Just didn't want to create more work for tooling at this point. :-)
chirino
commented
6 years ago This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its recipients. This is a temporary error. The following address(es) deferred:
chirino@gmail.com Domain hiramchirino.com has exceeded the max emails per hour (155/150 (103%)) allowed. Message will be reattempted later
------- This is a copy of the message, including all the headers. ------
Received: from o1.sgmail.github.com ([192.254.114.176]:38400)
by host313.hostmonster.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)
(Exim 4.89_1)
(envelope-from bounces+848413-18a6-hiram=hiramchirino.com@sgmail.github.com)
id 1f0Nmd-0013ZG-VU
for hiram@hiramchirino.com; Mon, 26 Mar 2018 02:47:16 -0600
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com;
h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe;
s=s20150108; bh=5XV61U9lUKO5MejdyK9XSyz0xqc=; b=o9eyTJ2OJ777AX7h
SLBqjRKnOid0VYTIb4rPsdAXC2Cr/8dLPVz55xFzyLZERz80eqbEW6nIVqJHU+nG
TvN41W69a1lwrVVWJyHl/AeNloZypZKqzfali5p/rIiyaJe3qKCFK9QoX7ZuVrPu
qVo+MAtexDTEj7LjQA2h79QGcIg=
Received: by filter0268p1iad2.sendgrid.net with SMTP id filter0268p1iad2-31372-5AB8B388-27
2018-03-26 08:47:05.019329269 +0000 UTC
Received: from smtp.github.com (out-1.smtp.github.com [192.30.252.192])
by ismtpd0045p1mdw1.sendgrid.net (SG) with ESMTP id OkFcOMZWRgqhYShV_CHmCA
for hiram@hiramchirino.com; Mon, 26 Mar 2018 08:47:04.904 +0000 (UTC)
Date: Mon, 26 Mar 2018 08:47:05 +0000 (UTC)
From: Zoran Regvart notifications@github.com
Reply-To: syndesisio/syndesis-project reply@reply.github.com
To: syndesisio/syndesis-project syndesis-project@noreply.github.com
Cc: Subscribed subscribed@noreply.github.com
Message-ID: syndesisio/syndesis-project/issue/151/issue_event/1540317103@github.com
In-Reply-To: syndesisio/syndesis-project/issues/151@github.com
References: syndesisio/syndesis-project/issues/151@github.com
Subject: Re: [syndesisio/syndesis-project] As a developer, develop custom
steps for Syndesis (#151)
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_5ab8b388ab123_98e2af361a96ecc48579a";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: zregvart
X-GitHub-Recipient: chirino
X-GitHub-Reason: subscribed
List-ID: syndesisio/syndesis-project
----==_mimepart_5ab8b388ab123_98e2af361a96ecc48579a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit
Closed #151.
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/syndesisio/syndesis-project/issues/151#event-1540317103 ----==_mimepart_5ab8b388ab123_98e2af361a96ecc48579a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Closed #151.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
----==_mimepart_5ab8b388ab123_98e2af361a96ecc48579a--
As a developer, I need to help citizen integrators on my team when they need functionality in an integration flow that is not provided OOTB by Syndesis. This functionality often involves code and/or technical configuration outside the expertise of our citizen integrators. To address this need, I want to use my traditional Camel development environment to create Camel routes and package those as steps that can be invoked from an integration flow by citizen integrators. My team refers to these extension packages as "technical extensions".
It should be possible to create technical extensions using any development environment. An archetype or sample project should be provided which defaults to the correct packaging configuration along with sample metadata and configuration. RH DevStudio should contain a specific project wizard for creating technical extensions.
Each technical extension can contain one or more Camel routes which can be used as steps within an integration flow. Routes can use the Java or XML DSL. Developers should be able to declare and leverage additional beans and have full access to the CamelContext for their extension. All technical extension projects should be self-contained and runnable outside of the Syndesis environment to facilitate independent unit testing of the extension.
Steps contributed by a technical extension should appear as native steps within the Syndesis environment. Developers must define required metadata for each step contained within a technical extension, including : step name, step description, input data type and output data type. If an extension does not require data type information and/or does not change the data's type, then the data type metadata is optional. Additionally, the developer can provide a name and description of the tech extension itself in its metadata.