As if we didn't have enough alternatives, here's another one that popped up while discussing with Gerhard the relative merits of @Veto and @Exclude:
@Unmanaged I think that this solves a few problems that we currently have: a) @Veto is technically accurate, but not intuitive (and requires an understanding of class processing, which is not a user concern) b) @Exclude is intuitive when considered in the context of scanning but it's a bit unclear on a larger scale - 'what exactly is this class excluded from?' - the c) the annotation must be applicable to packages IMO, @Unmanaged describes best what happens to the class: it will *not* generate a managed bean automatically. It is very similar to @NoBean early suggested by Gerhard, but works on packages too, and it describes a quality of the annotated item, in the same way as @Transient stands for "not serialized". On 2011-12-27, at 5:43 PM, Marius Bogoevici wrote: > +1 @Veto > > -1 @Exclude > > @Veto has a very narrow meaning, and hints to ProcessAnnotatedType.veto(), > which is precisely what happens to such annotated types. I have mixed > feelings about @Exclude - I'd rather not introduce a new term, especially one > that does not immediately make you think of CDI processing. > > > On 2011-12-26, at 6:41 PM, Gerhard Petracek wrote: > >> it looks like @Exclude is the alternative which would work for several of >> us. >> -> we have to choose between @Exclude and @Vote >> >> +1 for @Exclude >> >> regards, >> gerhard >> >> >> >> 2011/12/26 Jakob Korherr <[email protected]> >> >>> +1 to @Veto and @Exclude >>> >>> Also I agree with Pete's comments about the other suggestions. >>> >>> Regards, >>> Jakob >>> >>> 2011/12/24 Pete Muir <[email protected]>: >>>> We chose @Veto originally, as it didn't deviate from the spec's veto() >>> method, so should be less of a learning curve. I don't like @Deactivate as >>> it makes it sound like you have to activate other beans. @Ignore is too >>> overloaded a term for me to be comfortable with it (@IgnoreWarnings). I >>> like @Exclude as it's closest to what makes most intuitive sense. >>>> >>>> On 24 Dec 2011, at 09:33, Christian Kaltepoth wrote: >>>> >>>>> Perhaps we should build a list of all suggestions and then start a >>>>> vote which one to use. >>>>> >>>>> I think these are the names that were suggested: >>>>> >>>>> @Veto >>>>> @Skip >>>>> @Exclude >>>>> @Deactivate >>>>> @Ignore >>>>> >>>>> >>>>> >>>>> 2011/12/23 Gerhard Petracek <[email protected]>: >>>>>> hi arne, >>>>>> >>>>>> would be also ok for me -> +1 >>>>>> >>>>>> regards, >>>>>> gerhard >>>>>> >>>>>> >>>>>> 2011/12/23 Arne Limburg <[email protected]> >>>>>> >>>>>>> What about @Exclude? >>>>>>> >>>>>>> Cheers, >>>>>>> Arne >>>>>>> >>>>>>> -----Ursprüngliche Nachricht----- >>>>>>> Von: Gerhard Petracek [mailto:[email protected]] >>>>>>> Gesendet: Freitag, 23. Dezember 2011 21:28 >>>>>>> An: [email protected] >>>>>>> Betreff: Re: [DISCUSS] [DELTASPIKE-8] @Veto >>>>>>> >>>>>>> +0.5 for @Skip >>>>>>> as mentioned in the original thread @Veto is accurate from a technical >>>>>>> perspective, but it sounds strange for users who aren't aware of the >>>>>>> mechanism behind. >>>>>>> >>>>>>> if we are talking only about @Veto vs @Skip and not about the other >>>>>>> alternatives: +1 for @Skip >>>>>>> >>>>>>> regards, >>>>>>> gerhard >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2011/12/23 Dan Allen <[email protected]> >>>>>>> >>>>>>>> Veto is rationally the most appropriate since it directly translates >>>>>>>> to calling ProcessAnnotatedType#veto() >>>>>>>> >>>>>>>> However, I'd like to offer one other alternative: >>>>>>>> >>>>>>>> @Skip >>>>>>>> >>>>>>>> While veto describes what the extension is doing internally, skip is >>>>>>>> how the developer perceives the result of the action. The class is >>>>>>>> "skipped over" during the scanning process. This is similar to the >>>>>>>> suggestion @Ignore, and I think both would get the point across >>> equally >>>>>>> well. >>>>>>>> >>>>>>>> -Dan >>>>>>>> >>>>>>>> p.s. Apologizes for dropping the rest of the thread. I wasn't >>>>>>>> receiving messages when this thread started. >>>>>>>> >>>>>>>> -- >>>>>>>> Dan Allen >>>>>>>> Principal Software Engineer, Red Hat | Author of Seam in Action >>>>>>>> Registered Linux User #231597 >>>>>>>> >>>>>>>> http://www.google.com/profiles/dan.j.allen#about >>>>>>>> http://mojavelinux.com >>>>>>>> http://mojavelinux.com/seaminaction >>>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Christian Kaltepoth >>>>> Blog: http://chkal.blogspot.com/ >>>>> Twitter: http://twitter.com/chkal >>>> >>> >>> >>> >>> -- >>> Jakob Korherr >>> >>> blog: http://www.jakobk.com >>> twitter: http://twitter.com/jakobkorherr >>> work: http://www.irian.at >>> >
