+1 for @Unmanaged (+1 for @Exclude if it's the only alternative we can agree on)
regards, gerhard 2011/12/28 Marius Bogoevici <[email protected]> > 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 > >>> > > > >
