Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Message-ID: <1501859332.21748.23.camel@gmail.com>
Subject: Re: Component Extensions
From: Tomohisa Igarashi <tm.igarashi@gmail.com>
To: dev@camel.apache.org
Date: Fri, 04 Aug 2017 11:08:52 -0400
In-Reply-To: <CAGB5yNmRD0w6+gUMv+uN1Xk1FfCb-0Qh83+iGSZ4+Qca6YBwCQ@mail.gmail.com>
References: 
	<CAMpNYoaKSWosELiPOryHayZDruEQ2ut6FqLNvE64F2ZOR-GvRw@mail.gmail.com>
	 <CAGB5yNnndOPm8-gzPLPJ6ZQhX-ZM3eZMGWM2-q3Ggcr2=ARATw@mail.gmail.com>
	 <CAMpNYoba_Pd93sdjgcwdq94Vz8EJa++5kxjft_3-pK4-JLSf0A@mail.gmail.com>
	 <CAGB5yNmRD0w6+gUMv+uN1Xk1FfCb-0Qh83+iGSZ4+Qca6YBwCQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
archived-at: Fri, 04 Aug 2017 15:09:14 -0000

+1 looks promising for data type metadata as well!

It'll need something similar for DataFormat so it can hold type
metadata as well as components, but it can be addressed separately.

Thanks,
Tomo


On Fri, 2017-08-04 at 14:13 +0200, Claus Ibsen wrote:
> On Fri, Aug 4, 2017 at 2:09 PM, Luca Burgazzoli <lburgazzoli@gmail.co
> m> wrote:
> > Would be nice to make @Metadata repeatable so we can better express
> > multiple concepts like:
> > 
> > @Metadata(label = "extensions", types = { A.class, B.class, ...})
> > @Metadata(label = "cloud,saas")
> > class MyComponent extends DefaultComponent {
> > }
> > 
> 
> Yeah that seems like a good idea, as having only 1 @Metadata for all
> sort of generic stuff and what we may add in the future, can easily
> clutter it up.
> 
> 
> 
> > 
> > ---
> > Luca Burgazzoli
> > 
> > 
> > On Fri, Aug 4, 2017 at 1:35 PM, Claus Ibsen <claus.ibsen@gmail.com>
> > wrote:
> > > Hey Luca
> > > 
> > > Just took a bit of look, especially the first commit about the
> > > changes
> > > involving camel-core.
> > > 
> > > I really like this, great work, its more cleaner and the code is
> > > separated into that component.extension package.
> > > 
> > > +1
> > > 
> > > Down the road we should have the some metadata on @Metadata or
> > > something so we can harvest this via the camel apt compiler
> > > plugin and
> > > generate in the json metadata file which extensions a component
> > > provides, so tooling can be aware of this. We can then have a
> > > list of
> > > known extensions such as the verifier, and metadata etc.
> > > 
> > > 
> > > 
> > > On Fri, Aug 4, 2017 at 11:50 AM, Luca Burgazzoli <lburgazzoli@gma
> > > il.com> wrote:
> > > > Hello,
> > > > 
> > > > I've recently been working on CAMEL-11550 [1] aimed to
> > > > introduce the
> > > > concept of "Component Extensions" which are functionalities not
> > > > directly
> > > > targeting Camel runtime but that can provide some useful stuffs
> > > > as
> > > > example for tooling.
> > > > 
> > > > You can find the implementation on my camel fork [2] which
> > > > include:
> > > > 
> > > > - Core API for ComponentExtensions
> > > > - Refactor of the ComponentVerifier to be exposed as extension
> > > > and
> > > >   deprecation of the old VerifiableComponent
> > > > - Creation of a MetaDataExtension for ServivceNow aimed to
> > > > retrieve
> > > >   a Json Schema definition for the ServiceNow objects
> > > > - Creation of a maven plugin to generate POJOs for the
> > > > ServiceNow
> > > >   objects leveraging the MetaDataExtension
> > > > 
> > > > As this new "Component Extension" concept has some minor
> > > > impacts on
> > > > camel-core I'd like to have your opinion before merging it.
> > > > 
> > > > 
> > > > Regards,
> > > > Luca
> > > > 
> > > > 
> > > > [1] https://issues.apache.org/jira/browse/CAMEL-11550
> > > > [2] https://github.com/lburgazzoli/apache-camel/tree/component-
> > > > extensions
> > > > 
> > > > 
> > > > ---
> > > > Luca Burgazzoli
> > > 
> > > 
> > > 
> > > --
> > > Claus Ibsen
> > > -----------------
> > > http://davsclaus.com @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2
> 
> 
>