You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Karen Lease <ka...@gmail.com> on 2022/10/21 11:07:01 UTC
Camel annotations: question about "label"
Hi all,
I started to look at CAMEL-18559 to add a "remote" property to the
UriEndpoint annotation and I noticed there it has a deprecated "label"
property which is replaced by a list of Category enum values.
But the Metadata, UriPath & UriParam annotations still have the "label"
property.
This seems inconsistent but on the other hand, there are quite a lot of
values for label on UriParam which are not currently defined as a
Category, and there are already a lot of Category value (some very
specific and others more general) so adding more doesn't seem like a
good plan either.
Any opinions on whether it's worth deprecating label on the other
annotations or not?
Cheers,
Karen Lease
Re: Camel annotations: question about "label"
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Oct 21, 2022 at 3:51 PM Karen Lease <ka...@gmail.com> wrote:
> Thanks Claus,
> I will create a JIRA unless you already did.
>
>
Yes please do - I have not created a ticket
> Karen
>
> On 21/10/2022 13:25, Claus Ibsen wrote:
> > Hi
> >
> > Ah yeah it would be good to align this.
> >
> > Using a "free form" String allows you to come up with new labels on the
> > fly. But also prevent you from using an existing label that fits better
> or
> > covers this 95% anyway.
> >
> > I think it would be best to use Category only and deprecate the String
> and
> > remove it in Camel v4.
> > For Category then we can look at reducing the number as they were
> initially
> > created from the String labels.
> > But we should try to group more into the same label.
> >
> > hadoop => bigdata
> > payment => finance
> > azure => cloud
> >
> >
> > We have 84 categories today, and that is too many. Lets try to reduce
> this.
> >
> > If we can reduce this to approx 50 etc then it would be awesome if we, on
> > the website, could have a word cloud with the labels, to quickly filter
> the
> > list of components, etc.
> >
> >
> > On Fri, Oct 21, 2022 at 1:07 PM Karen Lease <ka...@gmail.com>
> wrote:
> >
> >> Hi all,
> >> I started to look at CAMEL-18559 to add a "remote" property to the
> >> UriEndpoint annotation and I noticed there it has a deprecated "label"
> >> property which is replaced by a list of Category enum values.
> >> But the Metadata, UriPath & UriParam annotations still have the "label"
> >> property.
> >> This seems inconsistent but on the other hand, there are quite a lot of
> >> values for label on UriParam which are not currently defined as a
> >> Category, and there are already a lot of Category value (some very
> >> specific and others more general) so adding more doesn't seem like a
> >> good plan either.
> >>
> >> Any opinions on whether it's worth deprecating label on the other
> >> annotations or not?
> >>
> >> Cheers,
> >> Karen Lease
> >>
> >
> >
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel annotations: question about "label"
Posted by Karen Lease <ka...@gmail.com>.
Thanks Claus,
I will create a JIRA unless you already did.
Karen
On 21/10/2022 13:25, Claus Ibsen wrote:
> Hi
>
> Ah yeah it would be good to align this.
>
> Using a "free form" String allows you to come up with new labels on the
> fly. But also prevent you from using an existing label that fits better or
> covers this 95% anyway.
>
> I think it would be best to use Category only and deprecate the String and
> remove it in Camel v4.
> For Category then we can look at reducing the number as they were initially
> created from the String labels.
> But we should try to group more into the same label.
>
> hadoop => bigdata
> payment => finance
> azure => cloud
>
>
> We have 84 categories today, and that is too many. Lets try to reduce this.
>
> If we can reduce this to approx 50 etc then it would be awesome if we, on
> the website, could have a word cloud with the labels, to quickly filter the
> list of components, etc.
>
>
> On Fri, Oct 21, 2022 at 1:07 PM Karen Lease <ka...@gmail.com> wrote:
>
>> Hi all,
>> I started to look at CAMEL-18559 to add a "remote" property to the
>> UriEndpoint annotation and I noticed there it has a deprecated "label"
>> property which is replaced by a list of Category enum values.
>> But the Metadata, UriPath & UriParam annotations still have the "label"
>> property.
>> This seems inconsistent but on the other hand, there are quite a lot of
>> values for label on UriParam which are not currently defined as a
>> Category, and there are already a lot of Category value (some very
>> specific and others more general) so adding more doesn't seem like a
>> good plan either.
>>
>> Any opinions on whether it's worth deprecating label on the other
>> annotations or not?
>>
>> Cheers,
>> Karen Lease
>>
>
>
Re: Camel annotations: question about "label"
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Ah yeah it would be good to align this.
Using a "free form" String allows you to come up with new labels on the
fly. But also prevent you from using an existing label that fits better or
covers this 95% anyway.
I think it would be best to use Category only and deprecate the String and
remove it in Camel v4.
For Category then we can look at reducing the number as they were initially
created from the String labels.
But we should try to group more into the same label.
hadoop => bigdata
payment => finance
azure => cloud
We have 84 categories today, and that is too many. Lets try to reduce this.
If we can reduce this to approx 50 etc then it would be awesome if we, on
the website, could have a word cloud with the labels, to quickly filter the
list of components, etc.
On Fri, Oct 21, 2022 at 1:07 PM Karen Lease <ka...@gmail.com> wrote:
> Hi all,
> I started to look at CAMEL-18559 to add a "remote" property to the
> UriEndpoint annotation and I noticed there it has a deprecated "label"
> property which is replaced by a list of Category enum values.
> But the Metadata, UriPath & UriParam annotations still have the "label"
> property.
> This seems inconsistent but on the other hand, there are quite a lot of
> values for label on UriParam which are not currently defined as a
> Category, and there are already a lot of Category value (some very
> specific and others more general) so adding more doesn't seem like a
> good plan either.
>
> Any opinions on whether it's worth deprecating label on the other
> annotations or not?
>
> Cheers,
> Karen Lease
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2