light is the key I guess
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-04 15:03 GMT+01:00 Werner Keil <werner.k...@gmail.com>: > While I totally agree, annotations should be defined on an API level and be > independent of implementations. > > Log4J 2 is a perfect example: > http://logging.apache.org/log4j/2.x/ > > And guess what, its implementation "Log4J Core" got plenty of configuration > of its own: > http://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/config/package-summary.html > > Maybe dreaming a bit now, but a future Log4J 2.x version could/should use > Tamaya there. At least if we do this right;-) > > Werner > > On Thu, Dec 4, 2014 at 2:58 PM, Werner Keil <werner.k...@gmail.com> wrote: > >> Similar to Agorava, those (CDI, POJO, Spring, Guice,...) look like >> implementation-details. >> >> While Tamaya (similar to Agorava which went the same path after JCP EC >> found a JSR wasn't suitable at the time, ironically Agorava comes back "in >> pieces" especially a large chunk through JSR 375, Security for Java EE;-D) >> isn't a JSR a clear separation between API and implementations is crucial >> (also to some future factoring out of parts into a JSR if the community >> wanted that) >> >> Werner >> >> On Thu, Dec 4, 2014 at 2:49 PM, Andres Almiray <aalmi...@gmail.com> wrote: >> >>> annotation package should work on all environments, iow, it's the lowest >>> common denominator. >>> cdi packages is, well, you guessed, only related to CDI. >>> >>> Given that Tamaya's API is supposed to be used between SE and EE >>> environments our driving design goal *should be* IMHO to cater for SE's >>> requirements first and then plug-in EE's. >>> >>> Cheers, >>> Andres >>> >>> ------------------------------------------- >>> Java Champion; Groovy Enthusiast >>> http://jroller.com/aalmiray >>> http://www.linkedin.com/in/aalmiray >>> -- >>> What goes up, must come down. Ask any system administrator. >>> There are 10 types of people in the world: Those who understand binary, >>> and >>> those who don't. >>> To understand recursion, we must first understand recursion. >>> >>> On Thu, Dec 4, 2014 at 2:45 PM, Romain Manni-Bucau <rmannibu...@gmail.com >>> > >>> wrote: >>> >>> > tamaya config cdi -> cdi package? >>> > tamaya pojo binding -> binding package? >>> > >>> > annotation is way too generic to help anyone, it is like searching for >>> > "java" on google now >>> > >>> > >>> > Romain Manni-Bucau >>> > @rmannibucau >>> > http://www.tomitribe.com >>> > http://rmannibucau.wordpress.com >>> > https://github.com/rmannibucau >>> > >>> > >>> > 2014-12-03 21:57 GMT+01:00 Oliver B. Fischer <o.b.fisc...@swe-blog.net >>> >: >>> > > @gerhard This is true but we should also think about the usability of >>> an >>> > > API. Packages with too many elements are always a pain. It is even >>> > difficult >>> > > to browse the API documentation. >>> > > >>> > > And please keep in mind the question of the user: How can I control >>> the >>> > > injection of configuration values? There do I have to look? >>> > > >>> > > And what is the search entered into Google: Tamaya config annotation >>> > > >>> > > The answer will be: the annotation package >>> > > >>> > > WDYT? >>> > > >>> > > Oliver >>> > > >>> > > Am 03.12.14 17:13, schrieb Gerhard Petracek: >>> > > >>> > >> @oliver: >>> > >> the point here is that it's a package which is only related to a >>> > technical >>> > >> concept of the language and not a "domain" concept/area/... . >>> > >> >>> > >> you can ask the same question you mentioned about interfaces, enums, >>> > >> exceptions,... >>> > >> >>> > >> regards, >>> > >> gerhard >>> > >> >>> > >> >>> > >> >>> > >> 2014-12-03 16:32 GMT+01:00 Werner Keil <werner.k...@gmail.com>: >>> > >> >>> > >>> There are even a few cases like Java Batch JSR (353) where they put >>> > >>> annotations into a completely separate (OSGi/Maven) bundle. We may >>> not >>> > >>> want >>> > >>> to go that far, but modularity as you also see with DeltaSpike is a >>> > good >>> > >>> thing. Whether you do this "horizontally" via a purpose or aim of >>> > >>> particular types or call it "annotation" at the end of the day is >>> not >>> > as >>> > >>> important as designing it as modular as we can. >>> > >>> >>> > >>> And (despite it's Stephen's birthday today;-) try to avoid grave >>> > mistakes >>> > >>> of especially JSR 310 where top level core types have plenty of >>> > >>> dependencies to various sub-packages and far worse, the sort of >>> "API" >>> > >>> interfaces themselves depend on implementation details like a >>> Duration >>> > or >>> > >>> DateTime class;-O >>> > >>> >>> > >>> Werner >>> > >>> >>> > >>> On Wed, Dec 3, 2014 at 4:19 PM, Oliver B. Fischer < >>> > >>> o.b.fisc...@swe-blog.net> >>> > >>> wrote: >>> > >>> >>> > >>>> @gerhard: From the language view you are right. But programmers use >>> > such >>> > >>>> package names for navigation in IDEs and code. Their question is >>> > "Where >>> > >>>> a >>> > >>>> the annotations I can use?" The answer is "They are in the >>> annotation >>> > >>>> package." >>> > >>>> >>> > >>>> Oliver >>> > >>>> >>> > >>>> >>> > >>>> Am 03.12.14 15:50, schrieb Gerhard Petracek: >>> > >>>> >>> > >>>> @romain: +1 >>> > >>>>> >>> > >>>>> we also dropped it in deltaspike, because annotations are a >>> regular >>> > >>>>> part >>> > >>>>> of >>> > >>>>> the language (you also >don't< create packages like "classes", >>> > >>>>> "interfaces",...) >>> > >>>>> using an own package for annotations was "modern" with java 5 >>> (since >>> > >>> >>> > >>> they >>> > >>>>> >>> > >>>>> were provided as "secondary" part in the beginning). >>> > >>>>> >>> > >>>>> regards, >>> > >>>>> gerhard >>> > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> 2014-12-03 15:25 GMT+01:00 Werner Keil <werner.k...@gmail.com>: >>> > >>>>> >>> > >>>>> See DeviceMap that's an option, too. >>> > >>>>>> >>> > >>>>>> A whole lot of JSRs do provide dedicated "annotation" or >>> "exception" >>> > >>>>>> packages, but if we grouped it into some logical or semantic >>> > >>>>>> structure, >>> > >>>>>> why >>> > >>>>>> not. >>> > >>>>>> Probably best to sketch anything in that direction on the Wiki >>> > rather >>> > >>>>>> than >>> > >>>>>> passing around names and structures;-) >>> > >>>>>> >>> > >>>>>> On Wed, Dec 3, 2014 at 3:15 PM, Romain Manni-Bucau < >>> > >>>>>> rmannibu...@gmail.com> >>> > >>>>>> wrote: >>> > >>>>>> >>> > >>>>>> we don't need to clutter anything, we need to split it as well >>> > >>>>>> (event, >>> > >>>>>>> >>> > >>>>>>> configuration, listener, ...we have several topics) >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> Romain Manni-Bucau >>> > >>>>>>> @rmannibucau >>> > >>>>>>> http://www.tomitribe.com >>> > >>>>>>> http://rmannibucau.wordpress.com >>> > >>>>>>> https://github.com/rmannibucau >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> 2014-12-03 15:13 GMT+01:00 Werner Keil <werner.k...@gmail.com>: >>> > >>>>>>> >>> > >>>>>>>> Well, there are 10 annotations now in the "annot" package right >>> > now. >>> > >>> >>> > >>> I >>> > >>>>>>>> >>> > >>>>>>>> would not want to clutter the top level with too many things, >>> > unless >>> > >>> >>> > >>> we >>> > >>>>>>>> >>> > >>>>>>>> reduce the annotations to 2 or 3 it seems better to give them a >>> > >>>>>>>> >>> > >>>>>>> separate >>> > >>>>>>> place. >>> > >>>>>>>> >>> > >>>>>>>> Werner >>> > >>>>>>>> >>> > >>>>>>>> On Wed, Dec 3, 2014 at 3:05 PM, Romain Manni-Bucau < >>> > >>>>>>>> >>> > >>>>>>> rmannibu...@gmail.com> >>> > >>>>>>> >>> > >>>>>>>> wrote: >>> > >>>>>>>> >>> > >>>>>>>> if we can just not use it it is better. annotation doesn't >>> bring >>> > >>> >>> > >>> much >>> > >>>>>>>>> >>> > >>>>>>>>> information IMHO. Otherwise to stay consistent we put a >>> package >>> > >>>>>>>>> classes, another one interfaces, an enumerations etc... >>> > >>>>>>>>> >>> > >>>>>>>>> >>> > >>>>>>>>> Romain Manni-Bucau >>> > >>>>>>>>> @rmannibucau >>> > >>>>>>>>> http://www.tomitribe.com >>> > >>>>>>>>> http://rmannibucau.wordpress.com >>> > >>>>>>>>> https://github.com/rmannibucau >>> > >>>>>>>>> >>> > >>>>>>>>> >>> > >>>>>>>>> 2014-12-03 15:02 GMT+01:00 John D. Ament < >>> johndam...@apache.org >>> > >: >>> > >>>>>>>>> >>> > >>>>>>>>>> +1 for full names wherever possible and the norm. >>> > >>>>>>>>>> >>> > >>>>>>>>>> On Wed Dec 03 2014 at 8:54:58 AM Andres Almiray < >>> > >>> >>> > >>> aalmi...@gmail.com >>> > >>>>>>>>> >>> > >>>>>>>>> wrote: >>> > >>>>>>>>> >>> > >>>>>>>>>> +1 on "annotation" >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> ------------------------------------------- >>> > >>>>>>>>>>> Java Champion; Groovy Enthusiast >>> > >>>>>>>>>>> http://jroller.com/aalmiray >>> > >>>>>>>>>>> http://www.linkedin.com/in/aalmiray >>> > >>>>>>>>>>> -- >>> > >>>>>>>>>>> What goes up, must come down. Ask any system administrator. >>> > >>>>>>>>>>> There are 10 types of people in the world: Those who >>> understand >>> > >>>>>>>>>>> >>> > >>>>>>>>>> binary, >>> > >>>>>>>> >>> > >>>>>>>> and >>> > >>>>>>>>>> >>> > >>>>>>>>>> those who don't. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> To understand recursion, we must first understand recursion. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> On Wed, Dec 3, 2014 at 2:51 PM, Werner Keil < >>> > >>> >>> > >>> werner.k...@gmail.com >>> > >>>>>>>>>> >>> > >>>>>>>>>> wrote: >>> > >>>>>>>>>> Hi, >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> Looking not only at Java EE ( >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>> http://docs.oracle.com/javaee/7/api/) >>> > >>>>>>> >>> > >>>>>>> you'll >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> find plenty of packages from "javax.annotation" to >>> > >>>>>>>>>>>> "javax.servlet.annotation", etc. >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> I already raised this to Anatole before Tamaya, that >>> > >>>>>>>>>>>> "org.apache.tamaya.annot" should be called >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>> "org.apache.tamaya.annotation" >>> > >>>>>>>>>> >>> > >>>>>>>>>> , >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> too. >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> Anybody against that?;-) >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> I could also create a JIRA ticket for that. >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> Werner >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > >>>> -- >>> > >>>> N Oliver B. Fischer >>> > >>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany >>> > >>>> P +49 30 44793251 >>> > >>>> M +49 178 7903538 >>> > >>>> E o.b.fisc...@swe-blog.net >>> > >>>> S oliver.b.fischer >>> > >>>> J oliver.b.fisc...@jabber.org >>> > >>>> X http://xing.to/obf >>> > >>>> >>> > >>>> >>> > > >>> > > -- >>> > > N Oliver B. Fischer >>> > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany >>> > > P +49 30 44793251 >>> > > M +49 178 7903538 >>> > > E o.b.fisc...@swe-blog.net >>> > > S oliver.b.fischer >>> > > J oliver.b.fisc...@jabber.org >>> > > X http://xing.to/obf >>> > > >>> > >>> >> >>
